• Welcome, Guest. Please login.
April 01, 2020, 03:22:58 am


Welcome to the SQLitening support forums!

Locked database error

Started by Gary Stout, August 16, 2012, 05:57:47 pm

Previous topic - Next topic

Fred Meier

QuoteThere are times when I may loop through a recordset to load a listview and once the loop exits, I may not issue the slCloseSet command at the end of the loop.
A record set is automatically closed when slGetRow returns False (loop exits).  Issuing a slCloseSet is not required and is ignored (doesn't hurt but is a waist of time).

QuoteI may continue using the information retrieved in the recordset until a sub-routine is finished and then close the recordset.
Record set is already closed, you are referring to data that you have copied from the record set using slF and slFN while it was open.

Gary Stout


Thanks again for the reply and clarification. I didn't realize the recordset was closed automatically. I was thinking that there were places in the program where I had left it open for later use, but maybe it was the data copied to the slF and slFN statements.

I need to go through the entire source and look for places that may be causing the "lock" issue. If I can accomplish this without the need for the slServer as you have done, I think this is the approach I am going to take. I have no need at this time for remote data...it would all be local on 2-10 computers with one computer acting as the server.

    If a SELECT has been done and a recordset has been loaded with records but not yet closed and another terminal preforms a read, would that be a problem?

No, you can test by running Test2A twice.  Any number of processes can do reads with out causing a lock-conflict.

It appears from the above quote, that if the slGetRow loop (2A) hasn't finished and another user tries to update (2B), that a error will occur. 2 or more users could read the file (2A) but if any of them try to update, an error will occur. I don't "think" I have done this type of thing in my code (where it waits for the user to do something before continuing), but I need to go through and double check.

Thanks again and I appologize for being so "thick headed" about all of this.
Gary Stout