Link to home
Start Free TrialLog in
Avatar of qbjgqbjg
qbjgqbjgFlag for United States of America

asked on

HY000: Connection is busy with results for another command

I have Crystal reports that were originally created using an ODBC connection using SQL Server. There reports have 2 SQL commands linked together. When our IT dept changed us over to SQL Native Client, the reports no longer work. They get this error: HY000: Connection is busy with results for another command. Is there a solution for this?
Avatar of EugeneZ
EugeneZ
Flag of United States of America image

try to create new connection from CR
 
what did they do : <IT dept changed us over to SQL Native Client>?
it is for sql server 2005- what sql server are you using (make sure it has fresh service pack installed)
also Make sure that MDAC was updated on the CR box as well
check
FIX: "Connection is busy with results for another command" error message occurs when you run a linked server query  
http://support.microsoft.com/kb/822668 
Avatar of qbjgqbjg

ASKER

We are using sql server 2005.  The Fix that you mentioned is for 2000.
Avatar of James0628
James0628

No idea if this will help, but in one of the reports that gets that error, go to File > "Report Options" and see if "Perform Query Asynchronously" is checked.  If it is, try unchecking it and trying the report again.  Like I said, I really don't know if that will help, but the "busy with results for another command" made me think of that option.  Maybe your old connection allowed asynchronous queries and the new one does not.  If unchecking that option fixes the problem, you might see if there is an option in the new connection to allow asynchronous queries.

 James
ok then
did you install fresh service pack for sql server 2005?
where from are you running CR: is it the same box where sql server 2005 installed?
if there is no sql server 2005 on box with CR - you may need frswh OLEDB drivers -> check fresh MDAC
 
http://www.microsoft.com/downloads/details.aspx?FamilyID=6c050fe3-c795-4b7d-b037-185d0506396c&displaylang=en
 --
How to check for MDAC version
http://support.microsoft.com/kb/301202
 
====
also - try to switch back to oledb driver for sql server or old one to see if the report is still working from point of view to make sure that it is driver problem
not report was "fixed"..
I spoke with Microsoft. The ODBC connection can have MARS set to yes, by doing a register edit. As long as the version of Crystal being used is can use the MARS setting, it will work. I tried it. It seems to be working, but the reports are running much slower than they were onder SQL Server 2000.
Did you check to see if the reports have "Perform Query Asynchronously" checked and, if so, did you trying unchecking it?  If the reports are running a lot slower using MARS, and turning off "Perform Query Asynchronously" allows them to run without MARS (and they run faster), then that might be a better alternative.

 James
I had already looked at the "Perform Query Asynchronously" and it was already unchecked. So that did not allow the reports to run.
OK.  Just checking.  It seems like you might be stuck with MARS (and the slower performance).  I suppose the last option might be to look at the SQL and see if it can be changed so that it runs without MARS (or go back to the old connection :-).

 James
The slow performance turned out not to be related to MARS. Turning on Mars was the solution for this issue. We were able to turn it on for the odbc connection by editing the register,
ASKER CERTIFIED SOLUTION
Avatar of James0628
James0628

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Honestly, we were not able to find the reason for the slow performance. My network people had tried a lot of different things trying to find the solution for the Crystal Issue. So, they just reloaded my computer and that resolved the performance issue. I do not believe the performance issue was related to MARS. But turning on MARS in the ODBC connection did resolve the error we were getting and made it possible for users to run the reports.
Ah, one of "those" problems.  :-)  Well, I'm glad you were able to fix the performance problem, even if you never really figured out exactly what was causing it.

 James
Not to complain, but my post wasn't the solution and I don't think I deserve the points.  Looking back through the messages, it seems that you solved this without help from anyone here, in which case you could accept one or more of your own posts as the solution.  Points aside, having the right posts flagged as the solution would help anyone that might come along later with a similar problem.  If you like, you can have the question re-opened.

 James