Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Boudewijn Lutgerink
  Where is Boudewijn Lutgerink?
 Hoonaardstraat, Driel
 Boudewijn Lutgerink
 To: Khalil Shaddad
  Where is Khalil Shaddad?
 Khalil Shaddad
Subject: RE: Locking Appended record
Thread ID: 16253 Message ID: 16364 # Views: 1 # Ratings: 0
Version: Unknown Category: General VFP Topics
Date: Thursday, October 17, 2002 8:14:19 AM         

> Hi,
> I have one form with the following conditions:
> 1- private data session (this is a must)
> 2- optimistic row buffering (could be pessimistic but should be row buffering mode)
> 3- multi-user, multi-session in one user environment.
> 4- each bufferred record should be locked (this is a must).
> Lets say mytable has 10 records, if I APPEND BLANK twice [before issuing TABLEUPDATE()] in the same process or with two different processes I am getting RECNO() = 11 and here the problem comes. How to lock the appended record before or after tableupdateing without moving to another record?
> Khalil Shaddad (Lebanon)

ONE REMARK. Due to the fact that you use a private datasession the two individual processes have no clue about eachothers activities (either when you use twice the same form in one process or the same form in two different processes) therefore counting the records in those processes and adding one for the appended record always return the number of records in the physical table + 1, even if in another process simultaniously a record is appended. This reccount() is a function that accesses the tableheader where the number of records is stored.
Only after a tableupdate() the header of the table is adjusted as well (the table is truly updated with new information) Those records are only available for other processes once the new record is written from buffer to the physical table on disk.
That is exactly what private datasessions are for. Not getting bothered with what is happening in other processes.

One Q. Why lock an appended record when it is not modified yet? As far as I can see, under the circumstances you describe this is not neccesary.
You already use a private session so there is no way the users outside this session can access this newly appended record.

Speaking about EXISTING records is another story.
Basically what I do is as follows:
I have the form buffering set to 2 (optimistic) and the bufferModeOverride of the cursors in the DE set to 1 (use form settings).
When I want to EDIT an existing record I first attempt to lock that record and add the user's name and the datetime to audit fields. If that is succesful then the record can be edited, if a lock can not be set then a message appears telling the user that the record is locked by user (NameInAuditField).
OF course, after saving the record or canceling any modifications the record is unlocked and the edit mode of the form switches back to readonly mode.
BTW I also use the user's name and the datetime before a delete is done. That way one can always tell who deleted what and when.


www.foxite.com - EFFORT is too often seen as PRODUCTIVITY. Therefore programming jobs are too often experienced as sword-dancing in a hot fire.


Locking Appended record Posted by Khalil Shaddad @ 10/14/2002 12:49:32 PM
RE: Locking Appended record Posted by Karben Selim Mejia @ 10/14/2002 4:52:48 PM
RE: Locking Appended record Posted by Boudewijn Lutgerink @ 10/17/2002 8:14:19 AM
RE: Locking Appended record Posted by Khalil Shaddad @ 10/18/2002 10:35:24 AM