Breaking out of RecordLock...

[Ken Ray]

> >> Is there any way once you get a 363 error (Record Lock) to 
> be able to 
> >> manually unlock the cursor?
> 
> How? Cursor will not be created if it cannot lock required records.

I understand that, you get the 363 error if an attempt is made to get a
cursor on record(s) that are in use.

> >> For example, we're running our system on a
> >> small network of about 5 people and occasionally they get a record 
> >> lock error.
> 
> How often? 
> On some special table or different?

I wish I knew. The issue is obviously that there is some cursor that
hasn't been deleted properly, but we've been really careful to make sure
that this doesn't happen, so I'd be very surprised if this were the
case. 

Additionally, we have code that if a locked cursor is encountered, it
makes 5 attempts (one every 1/2 second) to try and reestablish the
cursor. Only after 5 unsuccessful attempts does it bring up our "Record
is locked" dialog box.

The problem is that we're having a hard time replicating it and once a
cursor is not deleted properly, it remains open until the person who
opened the cursor disconnects from Valentina. And since we don't know
who that is, we just ask everyone to exit our program (which disconnects
from Valentina) and relaunch it.

> > All users have disconnect, but db still have locks?
> > Cannot be.

No, actually, all users have left the area that has something locked in
our program (they haven't disconnected). For example, we have several
areas in our program (Addresses, Projects, Calendar, etc.). If someone
is trying to access a Project record, say, and they get the Record lock,
we ask everyone to exit the Projects module and go somewhere where no
Project access occurs (like the Addresses module). However, even if no
one is in the Project module, the record remains locked (attempts by one
of us as Admin to get at that record gets a record lock error).

So we were hoping that in circumstances like that, we would be able to
forcibly close an open cursor because we *know* that no one is using it
(although Valentina's keeping it open because it hasn't been properly
removed). 

As an example of how we're writing things, in general we use
SQLSelectRecords() to get data to display in our interface (for
single-record views), and SQLSelect() for updating/adding/deleting
records, or for progressive disclosure in list views. 

This brings up a question:

If I execute a SQLSelect() to get a cursor, then a Cursor_SetField() to
set the contents of a field, then a Cursor_UpdateRecord() to update the
database, but then forget to do a Cursor_Remove(), the field in the
table has still been updated, right? I mean *if* there was a way to
forcibly remove a locked cursor, and I forced this cursor to be removed,
the data I'd posted to the table would still be there, right? 

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/