I have an excel workbook with 8 Power BI queries to a Sharepoint site. The queries work, but every day I have to clear the permissions on the data source. I then have to reconnect by re entering credentials. Is there a way to remove this step? Ultimately I want to automate this process.
Issue was caused by file sitting on a server that was being accessed by various users. Solution was to move to a local machine. This allowed the credentials to be stored correctly.
Related
I am currently testing a functionality which is built on SAP SRM with Fiori as its frontend, for which I need some support
Testing Tool - MF Load Runner
Protocol - SAP-Web
Test Case
After the initial login into the system, we need to Create an invoice in the system which will generate an excel. Need to download the same and alter with few document specific data.
After the data is modified, the excel needs to be uploaded again, which will automatically trigger save action.
At this point, we need to measure the time taken to upload excel and the time taken to save the document.
Follwed by this, i need to trigger the next step for calculation of few values which is a async process and its completion is only informed by a notification on the Fiori screen of the application.
After the calculation is done, i need to perform an another step. the completion of that step is also notified only by a notification.
We have tried by Ajax TruClient protocol as well, but it didn't worked out.
I am able to download the excel and save it locally but not able to edit the data. Any alteration of the data with the script is not happening.
Also, Can someone suggest any other method to capture the time taken at multiple steps.
Think about this architecturally. You have Truclient which is a browser. It is not a generic functional automation solution that exercises anything that is not a browser. You need to operate two apps, Excel and a Browser, so you need to move up the stack.
Don't time the stuff in Excel. This is 100% client based.
You have three options if you absolutely under every circumstance must run excel.
GUI Virtual User. This is a full blown automation client. In the Microfocus universe, this is QuickTest Pro. I can automate your browser. It can automate your excel. It can automate your Powerpoint. It can even automate solitaire. You will need a single full OS instance to run this
Citrix Virtual User. If you head this route you have options. You have Microfocus, Tricentis, Login VSI, and perhaps a handful of smaller players
Remote Desktop Virtual User. Similar to Citrix but fewer players. Microfocus is the Dominant solution.
If you leave the absolute non volatile requirement to run excel behind, then you can have a pre-prepared modified excel file for upload that represents the "changed" document and run this purely as an HTTP virtual user. TruClient is not going to operate your Windows Common Dialog Box (again, not a Browser) to allow you to pick a file.
I have a Google Apps Script that builds a new csv file any time someone makes an edit to one of our shared google sheets (via a trigger). The file gets saved off to a dedicated Shared Drive folder (which is first cleaned out by trashing all existing files before writing the updated one). This part works splendidly.
I need to take that CSV and consume it in SSIS so I can datestamp it and load it into a MSSQL table for historical tracking purposes, but aside from paying for some third-party apps (i.e. CDATA, COZYROC), I can't find a way to do this. Eventually this package will be deployed on our SQL Agent to run on a daily schedule, so it will be attached to a service account that wouldn't have any sort of access to the Google Shared drive. If I can get that CSV over to one of the shared folders on our SQL server, I will be golden...but that is what I am struggling with.
If something via Apps Script isn't possible, is there someone that can direct me as to how I might then be able to programmatically get an Excel spreadsheet to open, refresh its dataset, then save itself and close? I can get the data I need into Excel out of the Google Sheet directly using a Power Query, but need it to refresh itself in an unattended process on a daily schedule.
I found that CData actually has a tool called Sync which got us what we needed out of this. There is a limited-options free version of the tool (that they claim it's "free forever") that runs as a local service. On a set schedule, it can query all sorts of sources, including Google Sheets, and will write out to various destinations.
The free version has limited availability in terms of the sources and destinations you can use (though there are quite a few), but it only allows 2 connection definitions. That said, you can define multiple source files, but only 1 source type (i.e. I can define 20 different Google Sheets to use in 20 different jobs, but can only use Google Sheets as my source).
I have it setup to read my shared google sheet and output the CSV to our server's share. A SSIS project reads the local CSV, processes it as needed, and then writes to our SQL server. Seems to work pretty well if you don't mind having an additional service running, and don't need a series of different sources and destinations.
Link to their Sync landing page: https://www.cdata.com/sync/
Use the Buy Now button and load up the free version in your cart, then proceed to check out. They will email you a key and a link to get the download from.
I am working in a business in New Zealand. We currently use a remote server (Plexus) to store a large amount of data (some tables > 2 billion rows). We have started down the SharePoint route, and I have created a number of databases and apps in SharePoint that use this data. Currently, I have to run a program in New Zealand that downloads the data to our local server and then pushes up that data into an Azure database, which the web apps connect to. I would like to remove this middle step for many reasons but the biggest reason is that the web connection between NZ and the US tends to result in a lot of time outs and long pulls due to having to pull large data sets across the Pacific. The remote database we are using is Plexus.
Ideally, I would like to have my C# code sitting in Azure and have this connect to the remote server directly. This way I could simply send the SQL request to Plex and have this data go directly into the Azure databases. The major advantage would be that this would mean it would all be based in the US which would make things a lot faster.
The major hurdle is that we need to install an ODBC Driver given to us by the remote server into Azure so it recognises the calls as genuine. Our systems adminstrator has said he has looked into it and it seems this can't be done?
I was hoping someone on the StackOverFlow community has encountered a similar issue and resolved it?
Note: Please dont think I am asking whether Azure has an ODBC connection because I know it does. I am not asking if I can connect TO Azure, I am asking if I can connect Azure to another external data source.
In a Worker Role/Cloud service in azure you can install the ODBC driver in a startup task using powershells ODBC commandlets.
More info here: Powershell Add-OdbcDsn and here: Powershell startup task in cloud services
One option is to create a virtual machine in the same Azure data center as your database and install your ODBC driver and your C# app.
I have a web application (using MongoDB database, AngularJS on front-end and NodeJS on back-end) that deployed on 2 places. First is on static ip so that it can access from anywhere and second is on one local machine so that user can use it when the internet connection is not available. So on both places, data can be inserted by user. My requirement is to sync the both databases, when internet connection is available on local machine i.e. from local system database to remote system database and vice-versa without loosing any data on both places.
One way I am thinking about is provide the sync button in the application and sync the databases using insert/update query. I am not sure is there any better and automated way to do this task so that the databases sync automatically like data copied in replica set.
Please provide the best solution to do this task. Thanks in advance.
Pardon my outrageous silliness, I don't know if this is even possible.
Here's the situation.
There is an MS Access "database" (yes, I know, believe me, I know) which I'll need to SELECT, UPDATE and INSERT to from a remote location. The catch is that this needs to happen securely.
I have complete control over the remote machine which hosts the MS Access file, so I can put in drivers and software as I please. The server is Microsoft Windows Server 2003.
The approach that I had intended to take was to host a PHP script on an HTTPS server (using either Apache or IIS, doesn't matter), send XML to the PHP script which would then do its thing on the MS Access database and send XML results back. However, due to time restraints, I'm trying to figure out if I can connect directly through ODBC in a secure manner, and have it speak to an MS Access database.
It's my understanding that ODBC is not exactly famous for being secure, but that there are ODBC drivers that support encrypted connections, or that I can somehow tunnel the ODBC connection through SSL. However, all the information I have found so far relies on the database being Microsoft SQL.
In particular I'm interested if there are ways to SSL-ify ODBC connections without regard to the underlying database. I could probably figure that out on a Unix-clone by myself, but the host is a Windows Server 2003 in which case, I don't know how to proceed.
Is this possible at all? Any information highly appreciated!
The problem here is you are not quite understanding how an ODBC connection works with access. We are not talking about a TC/IP or socked based connection here.
If you look at ANY connection string for an JET to access file, you see in the ODBC connection will always, I REPEAT ALWAYS include a fully qualified windows path name. When I say a fully qualified windows path name, I am talking to about a file that sitting on the hard disk.
At the end of the day we are thus talking about opening a plain Jane windows file. A horse is a horse is a horse and a windows file is a windows file, is a windows file.
In other words we are talking about opening a file sitting on the hard disk. So, this whole process is not any different than opening excel file, a text file, a PowerPoint file, or in this case an access file that just also happens to be sitting on the hard disk.
There's no server or particular database software that EVER has to be installed on the computer where this file sets. It is the CLIENT SIDE that must have the software and execute a standard windows file open command to pull the data off the disk drive. Remember when you place a word file on a server and open it, you never had to install word on the server, is the client side that's doing a windows standard file open, and the exact same scenario applies to JET when it opens a access file.
What this means then if you're going to open this file up over an Internet connection, you therefore must extend windows networking over the Internet. HTTP, or even FTP is nothing remotely close to the windows file networking protocol.
However, you can extend windows networking system over the Internet, and this is typically done by which called a VPN (virtual private network). That means you'll have to set up a VPN. This will thus allow you to see this other computer via network neighborhood and browse to the files on that folder on the server, and simply open it. Again your opening a standard windows file, there's not some type of service running on the server that you can connect to like with SQL server.
You can read the following article of mine and I explain why running a VPN over the Internet with windows networking and a JET (access) file simply will not work in an reliable fashion:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
So, just keep in mind that if you look at any JET ODBC connection string, you'll notice it's never a IP based, but must be a FULLY QUALIFIED STANDARD windows file name. I cannot stress and repeat again that we talking about a standard windows file name and location that we going to open.
Remember this is no different than opening word or excel or PowerPoint. The ODBC driver confuses this issue, since the driver is ONLY required to be installed and setup on the client side, there's nothing to connect two on the server side, except the required ability to open a standard plain Jane windows file.
What you thus ask as possible with a VPN, but not practical. You can read the above article and it explains in detail why this cannot reliably work and function.
With the advent of several free editions of SQL server, and so many other choices, the above limitation is likely not going to be an issue for you. These other server database systems are not file based, and your connection strings will NEVER resolve to some file name. And, thus these database servers also do not require the windows networking proto call to open that file, and therefore you can even connect to servers such as running linux etc. that don't even have windows networking installed. For a jet connection, you have to use windows networking to directly open the file .
Usually one puts an intermediary between clients and the database. The intermediary handles authentication, authorization, secure data transmission, etc. You assume that the database is inside your firewall, in a secure area. All the things you want to add to make things secure for clients that are outside your firewall are handled by the intermediary.
Being a Java person, I would automatically think web client talking to one or more servlets. Let the servlet handle authentication and authorization. HTTP means no firewall worries. You can use HTTPS, too.
I think that'd be easier to put in place. Besides, even an SSL-ified ODBC connection still exposes your database to the wider Internet. I wouldn't want my data in such a repository. Would you?
Why does your MS-Access (really MS-Jet) database have only 1 file?
I can't picture that. If it were not an ODBC database, then I can picture it.
Most MS-Jet ODBC databases have 100's of *.MDB files in them,
where each MDB file is acting as either a: single table, group of tables, or partial table that is logically and physically spread (not split, and with no linking) across dozens or 100's of MDB files. No MDB file is considered a database in and of itself.
This is how I have seen ODBC databases built using the MS-Access Driver and
MS-Jet Engine.
Most ODBC MS-Jet/MS-Access Driver databases are around 5 billion rows and 1 Terabyte in size.