Saturday, February 11, 2012

"Connection busy with another hstmt" and RIMS

Hello all,

We've got a problem which we've been trying to solve for three days now, to no avail. We're trying to set up RIMS 7.1.2 on a bunch of desktops, connecting to an SQL 6.5 database on an NT4 server. The desktops are all running Windows 98 2E.

Every time we try to launch RIMS, we get the error "Connection is busy with the results of another hstmt". This happens right after we double-click the RIMS icon, before we can even log in.

We have tried upgrading the MDAC version we were using to 2.7, but that didn't help. We even tried using older versions of the sqlsrv32.dll and odbcbcp.dll files (we found a MSKB article saying that MDAC 2.6 and 2.7 could cause this error on SQL 2000, and it specified these files). We've tried reinstalling. _Nothing_ seems to be working.

The only other thing we could think of was that maybe it has to do with the fact that the desktops have the SQL 7.0 client while the server has 6.5?

_Any_ help on this one would be greatly appreciated. We're stuck...Is it this error ? "Connection is busy with results for another hstmt" Which service pack of sql server 6.5 are you running (service pack 1 fixed an error like this) ?|||We are running 5a on the server. I don't think we're running any service packs on the clients or for the RIMS software, though...|||Is the application using both sql servers ? Have you been successful before installing this application or is this a first installation ? Is there a reason why the server is 6.5 and not 7/2000 ? Do you know what the code was written in ? This issue could be caused by software or database. Have you contacted the vendor ?|||We've never had a problem installing it before. The reason we're using 6.5 is that everytime we upgrade, we apparently have to do a major overhaul of the database. Don't know what the application is written in -- I'll see if I can find that out.

The company said to try using Named Pipes as the connection protocol instead of TCP/IP, and we did try that but it didn't fix the problem.

The boxes are all on a secure network. We're going to try connecting one of them to the main network and see if we can make it work. That should at least give us a better idea of whether it's a server problem or a problem with the desktop...

<sigh>

No comments:

Post a Comment