Ok. I am starting to get the picture here. It appears there is no magic bullet to make all this stuff easy. You just have to grind it out. Of course, a good plan to begin with will help. I think what I will tend to do for my first effort will be to include a field (USERLOCK) in my main files and FILL or EMPTY this field as I "lock" and "unlock" records. The child records will be controlled by the lock status of the parent file. That should simplify things.

I am also wondering if VIEWS has any role in simplifying the process of moving data back and forth between client and server. I do not use the database concept in VFP and would prefer not to but if it provides me with any real time-saving features I would consider trying it again.




>Yes, the problem with child records is why optimistic locking is being recommended.
> However, in a well-written m/user application (with pessimistic locking), you usually have to do things like re-reading records, etc., and dealing with locked children anyway, so it's not that different. For example, you display a record and it can be edited because of the record's status ('UNPAID', say), so you enable an 'edit' button. Someone else changes the status elsewhere. Your 1st user clicks on the edit button - which should not now be possible (because of the status change) - you have to re-read the record's status BEFORE continuing with the edit to recheck (in effect) whether the button should have been enabled: this is in a 'normal' application, so the situation is no different in web-apps, just the methods you have to use differ slightly: you have a single app with multiple users, rather than multiple copies of the app each with a single user.
> You do not have to store the lock-status with the record, you could store it in memory (e.g. file:record:session), but you are right, you still have to check this and it involves extra work.
>
>
>>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 ?
>>