As I understand it, CURSORGETPROP( ) requires supplying an alias or work area. That's the problem - I know the handle that's busy but not the cursor that corresponds to it.
Even if I were to spin through all the open aliases in all datasessions, I don't see any property in CURSORGETPROP( ) that corresponds to the ODBC statement handle.
And SQLGETPROP( ) doesn't show the alias. That's the difficulty.
>Did you try CURSORGETPROP()?
>
>>I'm debugging a VFP app that uses a SQL Server backend. It consistently errors at one point with a SQL Server error. Extended information per AERROR( ) is:
>>
>>1526
>>Connectivity error: [Microsoft][ODBC SQL Server Driver]Connection is busy with results for another hstmt
>>[Microsoft][ODBC SQL Server Driver]Connection is busy with results for another hstmt
>>S1000
>>0
>>1
>>
>>At the point of failure there are 25 ODBC statements using one shared connection. Spinning through them using ASQLHANDLES( ) and SQLGETPROP( ) shows that the ConnectBusy property of the last one (#25) is .T., for all the others it's .F..
>>
>>These handles support remote views spread out across 5 datasessions. Is there a quick (or any) way to find out which RV/cursor corresponds to handle 25?
>>
>>FWIW the error happens because a framework routine tries to run a trivial query ( SELECT 1 ) using the same shared connection (ironically, to test functionality). Both before and after trying to run this trivial query there are 25 handles and #25's ConnectBusy is .T.
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up