what would cause a linked server to return a limited amount of data? - sql

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.

Related

Excel Linked Server in SQL Server 2008 R2 OLEDB error

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.

OLE DB provider "Search.CollatorDSO" returns "Command was not prepared"

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.

Using linked server returns error - "Cannot obtain the schema rowset for OLE DB provider"

I tried to move data aka ETL from one sql server to another as mentioned in a previous question - Copy data from one column into another column. Now, I get an error when I try to execute a query.
Query -
INSERT INTO [Target_server].[Target_DB1].[dbo].[Target_Table1](Target_Column1)
SELECT Source_Column222
FROM [Source_server].[Source_DB1].[dbo].[Source_Table1]
WHERE Source_Column1 = 'ID7162'
Error -
OLE DB provider "SQLNCLI" for linked server "MYLINKEDSERVER" returned message "Unspecified error".
OLE DB provider "SQLNCLI" for linked server "MYLINKEDSERVER" returned message "The stored procedure required to complete this operation could not be found on the server. Please contact your system administrator.".
Msg 7311, Level 16, State 2, Line 1
Cannot obtain the schema rowset "DBSCHEMA_TABLES_INFO" for OLE DB provider "SQLNCLI" for linked server "MYLINKEDSERVER". The provider supports the interface, but returns a failure code when it is used.
If your wrote that simple select is not working, the issue is in security configuration of the linked server and permissions which your user receive there.
Among this, when you execution your query, you don't need to specify the server name and DB name for both parts - source and target. You simply need to execute the query on target server and target database. In this case your query instead of
INSERT INTO [Target_server].[Target_DB1].[dbo].[Target_Table1](Target_Column1)
SELECT Source_Column222
FROM [Source_server].[Source_DB1].[dbo].[Source_Table1]
WHERE Source_Column1 = 'ID7162'
will looks like the following:
INSERT INTO [dbo].[Target_Table1](Target_Column1)
SELECT Source_Column222
FROM [Source_server].[Source_DB1].[dbo].[Source_Table1]
WHERE Source_Column1 = 'ID7162'
and you need your connection to be opened on server [Target_server] and database [Target_DB1]. Also the linked server security properties need to be checked on [Target_server] against the [Source_server].
If you are using loop back linked server (linked server refering to the same database in the same server) then refer the below mentioned link:
Transaction with loopback linked server - locking issues
If that is not the case, this is the solution provided by Microsoft.

Error while connecting with QRemote using QODBC

Getting this error in SQL Server at a time of connecting to QREMOTE using QODBC
OLE DB provider "MSDASQL" for linked server "QREMOTE" returned message "Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.
Please go to QODBC Setup screen --> Advanced tab --> Maximum Field Name Length --> Set " Maximum Field Name Length" to 70.
Also, Please Configure MSDASQL (Microsoft OLE DB Provider for ODBC Drivers)
[Note: MS SQL Express Edition do not have this setup options!!! ]
The OLE DB provider options for managing linked queries can be set in SQL Server Management Studio. In Object Explorer , right-click the provider name and select Properties for MSDASQL.
http://support.flexquarters.com/esupport/newimages/QRemoteSQLServer64Bit/image025.png
Dynamic parameter should be checked to allow parameter queries. Level zero only should be checked to allow four part naming to work. Allow InProcess should be checked to help performance.Non transacted updates should be checked if you want to be able to update QuickBooks data. Index as access path should be checked to help performance. Disallow adhoc accesses should be unchecked to allow OPENQUERY to function.
http://support.flexquarters.com/esupport/newimages/QRemoteSQLServer64Bit/image027.jpg
I would also like to suggest you to refer below mentioned link:
http://support.flexquarters.com/esupport/index.php?/Default/Knowledgebase/Article/View/2458/52/how-to-create-link-server-with-ms-sql-200520082012-64-bit-using-qodbcqremote
If you are still facing issue please create a support ticket at http://support.qodbc.com

SQL Server 2012 Migrating Spatial data across a Linked server, Query timeout?

We are doing a migration from our old system (sql server 2008) to the new system (SQL server 2012) , the data sources we are using are Remote so we have it configured as a linked servers , the data in the source we are migrating have special data (Geography type) , we are migrating the data per customer , so some customers have more data that the others, we batch the data and we are using OPENQUERY to pull the Spatial data across. For the customers with less data the migration goes smoothly and it completes successfully , but for customers with more than couple million records in one table the migration stops and gives mainly 2 errors:
This how the error comes like :
OLE DB provider "yyy" for linked server "xxx" returned message "Query timeout expired".
Msg 7399, Level 16, State 1, Server nnn, Line 1
The OLE DB provider "yyy" for linked server "xxx" reported an error. Execution terminated by the provider because a resource limit was reached.
Msg 7320, Level 16, State 2, Server ttt , Line 1
Cannot execute the query "
select top (200000)
[row] = row_number () over ( order by t.[x])
, .....
, [Spatial] = cast(ts.[Spatial] as varbinary(max))
from [..].[..].[..] t
join [...].[..].[… ] s
on t.[..] = s.[...]
where (t.[x] > '00000000-0000-0000-0000-000000000000')
and v.[x] = x
order by t.[x]
" against OLE DB provider "yyy" for linked server "xxx".Build step 'Execute Windows batch command' marked build as failure
also this problem happened with one other table that doesn't have a spatial data in it.
The approaches we tried to follow,
We have increased the timeout of the query,
We have dropped the batch size to 200,000 per batch
The Provider is “ in process mode”
we only have couple linked servers so the buffer size is more than acceptable ,
We tried to run the migration using an admin role to make sure it’s not a permissions problem
We are thinking this might be a network problem but it’s not a Load Balancer issue. maybe its something else,
The other error that comes frequently is
HResult 0x40, Level 16, State 1
TCP Provider: The specified network name is no longer available.
Any idea's for what could be a reason will be so much appreciated
Thank you,
Lsaif
I would say the "The specified network name is no longer available." error indicates no response from the remote server. Since SQL Server hasn't "heard" from the remote server in a while, it gives up. I would cut down the batch size to something really small and increase with success (rather than the other way around). That way you'll find a batch size that works. Also, this may vary between "customers" depending on your connection to them (i.e., type and size of line, traffic on the line, etc.).
Personally, I like the BCP OUT/BCP IN option as well because I know it works however, you still have to consider the transfer method of the data from the remote server. If you have a robust enterprise MFT over a dedicated T1 or better, you probably won't have an issue.
SSIS offers more of a direct transfer but I imagine you'll run into the same network issues you're having now. That said, you can create a general BCP solution within SSIS.