Avoiding PPCS error 130

[Jean Vallee]

I learned a valuable lesson (thank you Neil!) about timeoutlock I know the default setting is stored in the config file when you run the ppcs server. A record will stay locked for whatever time is specified unless you unlock it. I can imagine a scenario where my client starts editing a record, then goes to lunch or to a meeting and leaves the record open while they are gone, fully expecting to resume editing when they get back. Right now, the default is set to 4 minutes so the record would not still be locked if they take longer than 4 minutes to save. If I make it extremely long.. say 4 hours, but a workstation crashes and does not release the lock, the server must be restarted. otherwise anyone, including the original client would get “record is locked” error. Based on your experience with ppcs, what length of time do you recommend before the server unlocks a record? The other alternative I can imagine is to have a thread that does an autosave and relock until the user actually saves or cancels. Anyone doing this? Jean

[Michael]

On 07/06/2013 23:22, JV wrote:
> I learned a valuable lesson (thank you Neil!) about timeoutlock
>
> I know the default setting is stored in the config file when you run the
> ppcs server.
> A record will stay locked for whatever time is specified unless you
> unlock it.
>
> I can imagine a scenario where my client starts editing a record, then
> goes to lunch or to a meeting and leaves the record open while they are
> gone, fully expecting to resume editing when they get back.
>
> Right now, the default is set to 4 minutes so the record would not still
> be locked if they take longer than 4 minutes to save.
>
> If I make it extremely long.. say 4 hours, but a workstation crashes and
> does not release the lock, the server must be restarted. otherwise
> anyone, including the original client would get "record is locked" error.
>
> Based on your experience with ppcs, what length of time do you recommend
> before the server unlocks a record?
>
> The other alternative I can imagine is to have a thread that does an
> autosave and relock until the user actually saves or cancels. Anyone
> doing this?
>
> Jean
>

These sorts of things are always trade-offs. In typical ISAM systems, like Superbase, dBase, and SIMPOL, a record is locked prior
to editing. This ensures the record cannot be changed by anyone else while the record is being edited.

In most SQL systems, they opt for only locking when they are ready to write. The problem with that approach, is that the record
could have changed while the edits were being made. To cope with this, different SQL backends use different methods of signaling
that the record has changed.

They either have a row ID that changes each time the record is saved, or some other value like a datetime stamp that changes each
time. However they do it, the programmer needs to read the record, store some value that will always change when the record has
been changed, and then when the user is ready to commit their changes, reread the record with a lock and compare the newly read ID
with the previous one. If they are the same, they apply the changes to the locked record and store it. If they don't match, that
is where the fun begins. They can either compare field by field to see if the new changes will intersect the changed fields from
the updated record (but they would have had to keep a full copy of the old record), and then if no problem silently merge them, or
it can show the two records side by side somehow and ask the user to merge them, or it can just ell the user the record has
changed and make them do it over again.

It is important to realize that in SIMPOL, the locktimeout parameter for PPCS applies to making changes to an existing record.
Creating a new one can take as long as you like, since you don't have to lock it first. Normally, changes to an existing record
are considerably quicker than creating a new one. Still, selecting a locktimeout value is very much based on the use of the system
by the users. There are several ways you can workaround this.

One is to set a fairly long locktimeout (though I doubt I would allow more than 30 minutes in any case).

Another is to create a routine that is fired if the record is not locked error appears; something like I described above, where
you reread the record, check to see if the datetime stamp has been updated (which you would need to add as a text field in SIMPOL
for PPCS), and if it hasn't merge the changes and save, and if they have, decide what to do.

To say the least, there is a reason why database programming for networks is considerably messier than for single-user systems.

Ciao, Neil

[Author]

Posts