Some context: I am trying to upload data from Comcast into our database. Comcast sends the data in a macro-enabled workbook with file extension ".xlsm" which is disgusting. To circumvent this, I setup a power automate desktop flow to open the XLSM files and save them as XLSX files. I then run this query under an INSERT on our reporting server to get the data into the DB:
SELECT *
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Excel 12.0 Xml;Database=\\COMPANYNAME\company\customer\Comcast\Comcast.xlsx;', Sheet1$);
The only problem is, I'd like this to be automated. So I setup a cloud power automate flow to run the desktop flow and then execute a stored procedure in SQL Server. My flow receives the same error I do on my machine as well as any user outside of the COMPANYNAME\administrator session in SSMS on our reporting server:
Msg 7399, Level 16, State 1, Line 5
The OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" reported an error. The provider did not give any information about the error.
Msg 7303, Level 16, State 1, Line 5
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
It has been very difficult to research this issue as there seem to be many possible causes. I'm no IT wizard but I know enough to be dangerous. Thank you in advance for your time and help and I eagerly await your response!
Related
I have a number of files in different formats (Excel, Access, and CSV) saved on a network drive and I need to use opendatasource and openrowset to insert the data into a SQL table. These queries will only work if the files are saved on the SQL server. Is there a way to get around this?
I have admin rights on my local machine and on the server with full read/write permissions. The drives are also mapped on the server. Here are the queries and the error messages that I am getting:
SELECT Seq, Label
FROM OPENDATASOURCE ('Microsoft.ACE.OLEDB.12.0','Data Source = "G:\IMA Utilization Reports\\IMAv2k.mdb"' )...BackupLabels
Results in: OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "'G:\IMA Utilization Reports\DB\IMAv2k.mdb' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides.".
SELECT Seq, Label
FROM OPENDATASOURCE ('Microsoft.ACE.OLEDB.12.0','Data Source = "\\172.16.0.32\Finance\IMA Utilization Reports\DB\IMAv2k.mdb"' )...BackupLabels;
Results in: OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "The Microsoft Access database engine cannot open or write to the file '\172.16.0.32\Finance\IMA Utilization Reports\DB\IMAv2k.mdb'. It is already opened exclusively by another user, or you need permission to view and write its data.".
SELECT *
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'excel 12.0;HDR=yes;imex=1;driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)}; extended properties=excel 12.0 xml;
Database=G:\IMA Utilization Reports\Provider ID Numbers.xlsx',
'select * from [Employee ID Numbers$]')
Results in: Msg 7399, Level 16, State 1, Line 32
The OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" reported an error. The provider did not give any information about the error.
Msg 7303, Level 16, State 1, Line 32
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
If anyone has an answer or can point me to somewhere that does I would greatly appreciate it. Thanks in advance.
I have set up a linked server from SQL Server 2008 R2 to an Excel spreadsheet, from which I read the contents in to a table, for comparison during an import.
The spreadsheet is held on a network share from an application server.
Basically, this works perfectly on the SQL Server when I run:
SELECT * FROM SpreadsheetLink...[CONTENTS$]
However, as I now need to schedule this, I need to create an SSIS package on the application server, which runs the same query.
So now, whenever I try to do this though (either by writing the script in to SSIS or by logging in to SQL Server Mgmt Studio on the App server and then opening an SQL connection to the SQL Server and querying directly) I get an error:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "SpreadsheetLink" reported an error. The provider did not give any information about the error.
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "SpreadsheetLink"
I first wondered whether I had forgotten to install OLEDB12.0 on the application server, but it is there.
I next wondered whether it was a permissions issue, so I added the EVERYONE group, with "Full Control" to the folder containing the spreadsheet and also ensured that the account that I am both logged in with and running the query as is an administrator on both the SQL server and the Application Server.
I also checked that the account was a member of the Distributed COM user group on both servers (it was).
Additional info:
I have tried several things, but it still fails.
I added the following
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
I then re-tested, but got the same results (success from the local SQL server, failure from the other server).
Next, I tried creating a different query, referring to the spreadsheet directly by path, rather than by Link-name, but that resulted in exactly the same outcome:
SELECT * INTO TargetTableName FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Excel 12.0;Database=\\SERVER_NAME\PATH\fileName.xls;HDR=YES',
'SELECT * FROM [sheetName$]')
I also applied all of the suggestions in the following page:
http://visakhm.blogspot.co.uk/2013/12/how-to-solve-microsoftaceoledb120-error.html. But still no joy.
Has anybody been able to connect to Windows Search Service using the OLE DB Provider for Search in SQL Server? Below you'll find the error message I keep stumbling upon when configuring a Linked Server in Management Studio.
OLE DB provider "Search.CollatorDSO" for linked server "TESTSERVER" returned message "Command was not prepared.".
Msg 7399, Level 16, State 1, Line 2
The OLE DB provider "Search.CollatorDSO" for linked server "TESTSERVER" reported an error. Command was not prepared.
Msg 7350, Level 16, State 2, Line 2
Cannot get the column information from OLE DB provider "Search.CollatorDSO" for linked server "TESTSERVER".
I'm aware more people have been struggling with this problem over the last few years, but I haven't found a solution so far.
For reasons known only to Microsoft*, the Windows Search catalog is not accessible to SQL Server as an OLE DB datasource. The only feasible workaround for this issue is to create a CLR function and use it as a wrapper for querying the search catalog. A ready-to-run example can be found at http://www.nesterovsky-bros.com/weblog/2011/03/04/callingwindowssearchfromsqlserver2008.aspx.
*My best guess is that the search service is only partially SQL-compliant, in that it extends SQL-92 and SQL-99, but does not return the metadata or contain much of the functionality expected of a data source by SQL Server.
I am using Excel 2010 and sql server 2008 to import the data from excel to sql server. But am unsuccessful. Can you please check the way i am doing ?
sp_CONFIGURE 'show advanced options',1
RECONFIGURE
GO
sp_CONFIGURE 'optimize for ad hoc workloads',1
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0','Excel 12.0;Database=C:\Users\anayak\AppData\Roaming\Microsoft\Templates\Book1.xlsx; HDR=YES;IMEX=1','SELECT * FROM [sheet1$]');
where i am getting this error
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Unspecified error".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
I installed the Microsoft Access Database Engine 2010 Redistributable for Microsoft.ACE.OLEDB.12.0.
But when i use the command "ODBCAD32.EXE" to check the version of my excel then i am getting 14.00.4760.1000.
Then i tried my connection string to -
SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.14.0','Excel 14.0;Database=C:\Users\anayak\AppData\Roaming\Microsoft\Templates\Book1.xlsx; HDR=YES;IMEX=1','SELECT * FROM [sheet1$]');
but again it didnt work.
Can you please suggest what i am doing wrong here ?
Thanks.
Re: 7303 error
Distributed Queries in SQL Server, data from XLS
So your main error is likely this;
OLE DB provider "MICROSOFT.JET.OLEDB.4.0" for linked server "(null)" returned message "Unspecified error".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "MICROSOFT.JET.OLEDB.4.0" for linked server "(null)".
I would check some permissions.
Check the permissions on the Temp folder
This is needed because the provider uses the temp folder while retrieving the data. The folder can be one of the below based on whether you use a local system account or network domain account.
For network accounts, folder is
\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp
and for local system account its \Windows\ServiceProfiles\LocalService\AppData\Local\Temp
Right click on this folder and give it read write access to the account (or group) executing the code. That solved the error for me.
Also
http://blogs.msdn.com/b/spike/archive/2008/07/23/ole-db-provider-microsoft-jet-oledb-4-0-for-linked-server-null-returned-message-unspecified-error.aspx
This is because the SQL Server Service is trying to write the temp DSN to the temp folder for the login that started the service, in this case the Admin/Admin login.
The temp folder is something like: C:\Documents and Settings\Admin\Local Settings\Temp
.15 As mentioned, the OleDbProvider will always execute in the context of the user who initialized it, in this case User/User.
.16 User/User has no rights on this folder (C:\Documents and Settings\Admin\Local Settings\Temp).
If running FileMon when the SQL is executed, we can see the following:
(Actually, try using Process Monitor - http://technet.microsoft.com/en-us/sysinternals/bb896645)
sqlservr.exe:000 QUERY INFORMATION C:\DOCUME~1\Admini~1\LOCALS~1\Temp ACCESS DENIED Attributes: Error
So to summarize so far:
The SQL Server service is started as Admin/Admin, when the select is made, the OleDb provider is invoked by User/User.
Now the OleDb provider attempts to create a temporary DSN in the temp directory. This will be the temp directory for the SQL Server service (Admin/Admin)
but the user (in this case User/User) does not have write permissions on this folder. And the error occurs.
There are two ways to resolve this.
Option 1:
Log out of the machine and log in as the account that starts the SQL Server Service (in this case Admin/Admin) then start a command prompt
and type “set t” (no quotes), this will show something like:
TEMP=C:\DOCUME~1\Admin\LOCALS~1\Temp
TMP=C:\DOCUME~1\Admin\LOCALS~1\Temp
these are the environment variables set for %TEMP% and %TMP%, so go to that folder and right click and select Properties -> Security,
then add the user, in this case User/User, note that the default for the user is Read&Execute/List Folder Content/Read, this not enough, you have to select Write as well.
Log out, and log in again as User/User and rerun the command from SSMS. This time it should work.
Option 2:
Log on as Admin and change the TEMP and TMP variable to, for example, C:\Temp, basically this moves the Temp directory out of the Documents and Settings folder.
However, you must restart the SQL server for this to take effect.
So basically, what happens is that when SQL Server starts, it uses the Temp folder of the startup account (Admin/Admin) but the MICROSOFT.JET.OLEDB.4.0 will always execute
as the user who calls the SQL command (User/User) and this will fail unless this user does not have Write access to that temp folder.
Without knowing all setups out there, perhaps option 2 is the preferred solution since with option 1, you will have to add ALL the users that will invoke the provider which may not be practical.
Also, when changing the startup account for the SQL Server service, then the TEMP directory for that account will be used, and you will see the error again until you, again, give write permissions for all the users on this TEMP folder...or a user group (preferred).
We are having an issue with a server that we linked to our sql server 2012 instance.
The server that we linked through an odbc or oledb connection is Pervasive SQL.
Selecting from the linked server this way works as long as the result set is small:
select * from linked_server.database..mytable
If the result set is more than around 2mb (might be slightly more or less) then we get this error:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "KSLAP208" reported an error. The provider reported an unexpected catastrophic failure.
Msg 7330, Level 16, State 2, Line 1
Cannot fetch a row from OLE DB provider "MSDASQL" for linked server "KSLAP208".
However, the silly thing is that SSMS 2012 for instance displays all the columns that need to be returned and then immediatley errors out.
What would cause SSMS 2012 to produce an error on a result set that is too big? (more than 1-2mb)??
here's what i see in the odbc administrator:
Option 1, disable pre-fetch
Sometimes, disabling pre-fetch will solve problems like this.
You can disable the prefetch by clearing the "Enable pre-fetch of data
for queries" check box in the Performance tab when creating a DSN or
adding "PREFETCH=0" to the connection string when creating a DSN-less connection.
More on this:
In the ODBC Data Source Administrator panel on the server, configure
your linked server from System DSN. Under the Performance tab, uncheck
the box 'Enable pre-fetch of data for queries'. OK, OK. Delete and
re-create your linked server in SQL Management Studio.
Source
Option 2, Allow inprocess
Go to Linked Servers
Providers
MSOLAP (or similar)
Properties
Make sure "Allow inprocess" is enabled. Even if it is, turn it off. Save. And then turn it back on. Sometimes resetting this can help.