• Welcome, Guest. Please login.
 
September 17, 2019, 01:50:44 pm

News:

Welcome to the SQLitening support forums!


SQLite Busy after disconnect

Started by Mark Strickland, March 13, 2008, 11:33:05 pm

Previous topic - Next topic

Mark Strickland

I get an error SQLite Busy (#5) after disconnecting then reconnecting.  The error happens when reconnecting.  The SERVER shows DISCONNECTED after the first disconnect.

Here is the exit code (copied from one of the example programs):


    'SQL - Close SQL DB
    IF gSQLsession THEN

        IF gRS THEN
            sql3_rsDestroy gSQLsession, gRS
        END IF

        ' Disconnect from the server (if connected)
        sql3_disconnect gSQLsession

        ' End the session
        sql3_EndSession gSQLsession

    END IF


Any thoughts?
Mark Strickland, CISSP
www.SimplyBASICsecurity.com

Paul Squires

Hi Mark,

I have created an example that gives the same error as you...... I am tracign the code to find out why it is happening. I will post an update once I figure this out.


Paul Squires

Found the problem. There is an error in the code where the request is not being sent to the server to destroy the recordset. By having the recordset open, we end up with a Busy error when we try to close the database.

Here is the current code:

      Case %SQL3_RSDESTROY
         If pSession = 0 Then errcode = %ERR_BADSESSION:  GoTo ExitOut

         pRS = @pMsg.rsClient
         If pRS = 0 Then errcode = %ERR_BADRECORDSET: GoTo ExitOut

         If @pSession.nUseMode = %SQL3_LOCAL Then
           
            ' Finalize the sql in order to free the SQLite compiled query.
            errcode = sqlFinalize( @pRS.pStmt )

         ElseIf @pSession.nUseMode = %SQL3_LOCAL Then 
            ' Send a message to the server to free the server side recordset
            @pMsg.nAction  = %SQL_FREERECORDSET_INTERNAL         
            @pMsg.rsServer = @pRS.rsServer
            errcode = ctx_SendToServer_Internal( pMsg )
            If errcode Then GoTo ExitOut

            ' Free the client side recordset
            MemFree @pRS.zColNames
            List_Destroy @pRS.pListCache
            MemFree pRS
         End If


Here is the corrected code:

      Case %SQL3_RSDESTROY
         If pSession = 0 Then errcode = %ERR_BADSESSION:  GoTo ExitOut

         pRS = @pMsg.rsClient
         If pRS = 0 Then errcode = %ERR_BADRECORDSET: GoTo ExitOut

         If @pSession.nUseMode = %SQL3_LOCAL Then
           
            ' Finalize the sql in order to free the SQLite compiled query.
            errcode = sqlFinalize( @pRS.pStmt )

         ElseIf @pSession.nUseMode = %SQL3_REMOTE Then 
            ' Send a message to the server to free the server side recordset
            @pMsg.nAction  = %SQL_FREERECORDSET_INTERNAL         
            @pMsg.rsServer = @pRS.rsServer
            errcode = ctx_SendToServer_Internal( pMsg )
            If errcode Then GoTo ExitOut

            ' Free the client side recordset
            MemFree @pRS.zColNames
            List_Destroy @pRS.pListCache
            MemFree pRS
         End If


As you can see, it is the "ElseIf @pSession.nUseMode" branch that should be %SQL3_REMOTE rather than %SQL3_LOCAL. You can make the change and recompile the DLL.



Mark Strickland

You posted your response before I finshed this but here it is anyway so you can see my other questions.  I assume you are going to post a new version with your corrected code.  OOPS --- I will recompile --- should have read all of your post first.

If it helps in debugging my logic is to NOT read the record set until I reach EOF simply because this is a special case that I know only has a single record in the set.  I do a single fetch and just use the data.  I probably need to spend a little time looking at your code but I have not done that yet.  I assume this "read to EOF" should not matter to SQLite because the record set logic is 100% in your Client Server extensions.

This brings up another question.  Should I destroy a record set before creating another one on the same table?

OK --- Sorry --- One more question.

From an architecture point of view would it make sense to create a global record set variable for each different table needed in the program.  Sort of like different handles in Cheetah.

Thanks.
Mark Strickland, CISSP
www.SimplyBASICsecurity.com

Paul Squires


Paul Squires

Quote from: Mark Strickland on March 14, 2008, 07:01:43 pm
Should I destroy a record set before creating another one on the same table?

I wouldn't keep open recordsets any longer than is needed so destroy them when finished with them. However, you should be able to have multiple recordsets open at any one time.

QuoteFrom an architecture point of view would it make sense to create a global record set variable for each different table needed in the program.  Sort of like different handles in Cheetah.

Sure. You can do it that way. Whatever way it is easier for you to relate your variables to the underlying SQLite tables so that you know what variable to refer to in any given situation. You could certainly reuse the same variables for different sessions and recordsets but it could get confusing.