2.1 Compatiblitly must be off (unchecked), you must use the QODBC DCOMs and have the optimizer setup to other than a user profile directory so the SQL Server can use it correctly. See: SQL Server 2005 Linked Server unable to run Optimized which in your case, you already know.

What happens when you run two:

'select * from openquery(qodbc,'select * from employee unoptimized)'

after each other? What about two:

'select * from openquery(qodbc,'select * from employee nosync)'

queries instead?

Just for clarification, 2.1 compatibility IS off, I am using the QODBC DCOMs and the optimizer is in C:\Program Files\QODBC\Optimizer.

You queries produced the exact same results. I did additional testing and here is some new info. The results I'll describe were exactly the same for all three queries (regular, unoptimized and nosync). If I execute the query and then execute again immediately afterwards it is fine (in fact I can execute 20+ times consecutively). If I wait approximately 3 seconds, then I get the 'fetch' error. I then have to wait 60 seconds (I used a stopwatch and verified many times) before I can successfully execute the query. If I try it after 55 seconds I MUST wait another 60 seconds before it will run successfully. Again, these results are the same for any of the queries you listed.

Any ideas? Thanks.

How many empolyees are in your table? What is your Iterator or Chuck Size setting? Should be 10,000 or higher instead of the default of 500.

MS SQL Server uses threaded queries, while this works nicely with multi-threaded SQL Server engines, in the case of XML requests to QuickBooks, it's kind of expecting one thing at a time. Using desktop applications (like VB Demo) I can get 3 or more queries all running at the one time with the third query waiting for the others to complete. However MS SQL Server will also change the Thread ID which means the other queries will loss their cursor position. If the queries are run quickly one after each other consecutively, no problems they all work using the one Thread ID, but 3 seconds later the Thread ID has changed from the one running and can't be changed until all the current results are returned. 

We only have 27 employees so that doesn't seem to be the issue (or am I wrong about that?). What you say regarding the threads seems to make sense (which means it is not a QODBC shortcoming but a QB XML shortcoming). And if that is the case (the thread ID's change) are we just kind of 'stuck' with it? Are there any settings on the SQL Server side that could help to avoid this problem? Or can we adjust some timeout to avoid the 60 seconds necessary to 'reset' the thread ID on the XML request side?

Thanks Tom.

If it's not too much trouble, you can try setting the Timeout on the Link Server from 0 to 120 seconds and let me know what happens? I think the result will be the same because timeout is only the connection timeout and in this case it connects, it just can't return the rows. 

Another approach could be to setup multple link tables (Connection 1, Connection 2, Connection 3, Connection 4) all with their own DSNs and seperate optimizer files.