I started at this company, and the jobs were pretty complex and undocumented.
One of the procs checks on txtfiles that SSIS creates by using a linked server that uses Microsoft.Jet.OLEDB.4.0 and points to its own C drive. Using that, the job does a count on each table, and compares it to its totals. Maybe unnecessarily complex.
It was working properly till last Friday, when I started getting the error:
OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "textserver"
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 "textserver".
The query used is:
SELECT COUNT(*) FROM textserver...[textfile#txt]
I've tried rebooting the server, and recreating the linked server to no avail.
Has anyone seen this issue before?
I've had similar problems in the past, but restarting the linked to server usually worked for me. A few things to try:
You may also want to verify the account running the SSIS package has rights to the linked server location on the C drive.
Also, make sure remote transactions are allowed.
Last suggestion would be to see if any MS updates or patches were installed since it last worked and try rolling them back.
Related
I was trying to pull data from Oracle to MSSqlserver database using Linked server.
select * from [LINK_NAME]..SCHEMA.TABLE;
But it was failing with the below error:
The OLE DB provider "OraOLEDB.Oracle" for linked server "LINK_NAME"
supplied inconsistent metadata for a column. The column "COLUMN_NAME"
(compile-time ordinal 6) of object ""SCHEMA"."TABLE"" was reported to
have a "LENGTH" of 100 at compile time and 200 at run time.
I also need to pass argument at run time in where condition. I found OPENQUERY as a solution but it does not support arguments at runtime.
Try using the OPENQUERY Syntax to see whether that helps..
SELECT * FROM OPENQUERY(LINK_NAME, 'SELECT * FROM db.Schema.Table')
More about OPENQUERY ...
I found solution:
The error was coming due to database column type mismatch.
ORACLE was using NVARCHAR for datatype but in case of SQLSERVER it was VARCHAR.
As NVARCHAR is double the size of VARCHAR that is why it was showing size mismatch error.
Changing the data type to same worked for me.
I have found a solution posted by this blogger. Try it out!
This tool from Sysinternals/Mark Russinovich is the best, and my only regret that day was not launching it earlier instead of scouring Google and going insane. I’ve limited Procmon to just sqlservr.exe, as it’s the SQL Service itself that loads/handles the providers and not the ssms.exe. Also of note is that the sqlservr.exe is a 64bit process while the management studio is still just 32bit. As the server service is loading the provider, and the service process is 64bit, the provider must also be available in 64 bit format.
The ODAC112021Xcopy_x64.zip was installed to C:\Oracle. What Procmon showed me however is that sqlservr is attempting to find the oci.dll in any folder but his! (It iterates through the %Path% sysvariable). When it finally gives up on find the dll, the SQL Service is in a unstable shape and the only way to stop the service was to kill it via taskmgr/procexp. Clearly I can see that the “xcopy” deployment – while not giving me any error messages – it also did not set the PATH variable! And this is what this post is really about… adding C:\Oracle and C:\Oracle\Bin to the Path variable or maybe it’s about employing investigative tools earlier in the process instead of relying on your search engine skills.
sqlservr.exe can now find the relevant DLL’s. The OCI.DLL in the root and the OraOLEDB11.DLL in the Bin subfolder. At this point I could query the database! If you did my steps as above and you still get the same error, I strongly suggest using Procmon.exe as I have instead of jumping to the next search result.
Full post is here with more details.
I've performed multiple searches and read numerous pages and tried loads of different configurations and nothing seems to solve a nuisance problem we have. We have a SQL server (2008 R2 v10.50.4000) that has several linked servers to several different access databases on a different server. They are all set up using UNC paths and they work...for a time.
At some point, something happens and then we can no longer access the databases and the only way I have found to solve this is to restart the SQL server service, which obviously isn't ideal in a production environment. This is the exact error message we get when we try to access it:
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "HIDDEN" returned message "The Microsoft Access database engine cannot open or write to the file '\servername\path01\path02\path03\databasename.mdb'. It is already opened exclusively by another user, or you need permission to view and write its data.".
Yet it works absolutely fine again if I restart the SQL Server service, so I know the settings are correct. I strongly suspect it has something to do with the Microsoft ACE driver because they all (the Access database linked servers) stop working at the same time - even though they all look at different files.
At this point I'm willing to try anything.
I need to query a database on a linked server, and unfortunately the database name contains a period.
This fails;
select top 10 *
FROM [LINKED_SERVER].[DATABASE_NAME.1].dbo.[TABLE_NAME]
with this error:
OLE DB error trace [Non-interface error: OLE DB provider unable to process object, since the object has no columnsProviderName='SQLOLEDB', Query="DATABASE_NAME.1"."dbo"."TABLE_NAME"'].
Msg 7357, Level 16, State 2, Line 2
Could not process object '"DATABASE_NAME.1"."dbo"."TABLE_NAME"'. The OLE DB provider 'SQLOLEDB' indicates that the object has no columns.
Connecting to the same linked server without a period in the database name works;
select top 10 *
FROM [LINKED_SERVER].[DATABASE_NAME].dbo.[TABLE_NAME]
As there are many references to the existing database name out of my control, I hope to find a solution that avoids re-naming the database permanently.
I would like to be able to create a synonym or some other alias, or find some other way to get this working.
Periods in database names accessed via linked servers are perfectly acceptable when escaped with brackets [] - the error your getting must be something else.
I can confirm this on my test rig:
One thought, your using the old SQLOLEDB provider for your linked server, have you tried using SQLNCLI10 instead?
Avoid periods in identifiers,
e.g. in SSMS
sp_help [sales.order]
will not work, even with brackets
I have been trying for the past week or so to import data programmatically to a SQL Server 2008 table from a Microsoft Access .mdb file. I have been getting nothing but errors, and solving one just reveals another. I made the file into a linked server, and now when I try to query it with:
Select * from OPENQUERY(Importdata, 'Select * from [IMBPieceBC]')
I get the error:
OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "Importdata" returned message "Cannot open database ''. It may not be a database that your application recognizes, or the file may be corrupt.".
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 "Importdata".
I've read several suggestions to relink dlls in the registry, but I've done that, and I'm still getting the error. Is there anything else I can do to fix it, or at least figure out what is wrong?
Migrating the data to a SQL Server instance is not an option. The mdb files are generated by a third-party program, so there's nothing we can do about it.
I have a similar situation at my workplace - a third party application that maintains data in MDBs, but other applications needing access to it. How I've done it is that this 'intermediary' application has links to the SQL Server tables and the MDB tables. You could use either a query or a VBA written form event to transfer information from the MDB table(s) involved into your corresponding SQL Server tables using a INSERT INTO query, fitted with a SELECT FROM subquery providing the values being inserted.
Hey all, the following select statement used to correctly query an Excel spreadsheet on a 64bit SQL Server 2008 R2, and now provides me with an error.
SELECT
MPNCode, Supplier, Stock , Price, Manufacturer, [Description]
FROM
OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Excel 12.0 Xml;Database=C:\inetpub\wwwroot\nCompass\Products\Import\SupplierProducts.xls;HDR=YES',
'SELECT * FROM [Sheet1$]') WHERE MPNCode IS NOT NULL
The error I get is.
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've tried restarting everything and googled the thing to death - somehow something has happened that is preventing this from working.
The file-path/file-name is correct because when I change the path I get a different error message.
Ad-hoc connections are enabled from the surface manager - after this I'm stumped at what the issue could be.
Any help will be very much appreciated.
Is the linked spreadsheet opened on the desktop? What happens if you create a new sheet in the same folder and try to open it instead?
I think SQL Server needs to access to TEMP folders to copy or create some files.
If the folder does not exist or ther SQL Service account does not have enough permission to access the folders, you'll get the exception.
Run Procmon.exe on the server and execute the query again. You can see what's happening and where the SQL Server wants to access.