Well, I am using FOXWEB on the server side and it utilizes SESSION variables also so your methodology would seem to work.

Now, maybe you can help with my next concern....

I have started doing a little of this sort of thing just to get a taste of what is involved in building these types of applications. My initial discovery is that implementing Add,Edit,Delete operations within a single file is within reach. However, I am fearful of a complicated file structure with children where I might need to edit some of those children or add/delete children,etc...
It just seems that it might get to be a logistical nightmare to keep track of what fields were changed/deleted etc ...AND ... it seems that this all needs to be hand coded for each form used. Looks very labor intensive which translates into expensive for the customer. Am I missing something ?



>I use Web-Connection, but you can implement a similar method. WWC has sessions for identifying users, which time out after x seconds (1800 by default). If you want pessimistic locking, store the value of the user's sessionID in a field indicating that the record is locked. Then you can...
>
>Another user tries to edit:
>1. Field is blank --> OK
>2. Field is not blank but sessionID = user's SessionID --> OK
>3. Field is not blank, sessionID <> user's sessionID...
>.3a if sessionID has timed out -->OK
>.3b if sessionID is still valid --> FAIL
>
>With the exception of 3b, the record's sessionID then needs to be set to the user's sessionID.
>This works well as any users that crash out (or close their screen during editing) only lock records for a maximum of x seconds.
>
>This sounds clunkier than it is (I had a user who insisted on pessimistic locking) and is still VERY fast: you usually have only one copy of the server and it's practically working single-user. I use classes for data access so it can be built in at that level leaving your process code reasonably clean.
>
>If you can persuade your users, try using optimistic locking instead.
>
>
>In most applications, at some point you have a list of records from which you can choose a record to edit. Clearing a user's locks can be done when presenting the list (i.e. if you are reading the list, you are not reading any records).
>
>
>>My concern lies in the area of implementing some of the standard operations that a user would expect to use in a normal application. For example ... Adding a new record: That seems rather simple ... check for duplication and if none, add it to the database. Editing Records: That seems more complicated. Do I put some sort of FLAG in the record to indicated that it is being edited and only allow 1 editor on the record ? This seems ok. However, what if the editor drops dead and never comes back to the server? I suppose I could come up with some sort of timing routine to open the record up again after a given period but that seems rather clunky ...
>>
>>I would be interested in hearing from someone with firsthand experience with this. Ideas are fine but until actually implemented they fall short of a real-life solution.