>Because I see these few lines of code > ><><< && error - cannot update at all ><> >granted I did not take the time to fully break down your code, but I know what it looks like
Tableupdate() function returns .F. when trigger failed in database or other kind of error occurred during updating. This is COMPLETELY another kind of errors than table locking. This checking have nothing related to locking or changes on the server. Please, look to HELP on the tableupdate() command before assuming something like above.
> >>>But once again I see no way I could ever put that in my current app >>> >>>If a single users has to re-type and re-try to save, I would have to pay someone to test my food and start my car >> >>Hej, why you think users will have to re-type and re-try? >>In my working (not a sample I posted here) algorithm data saving process looks like following: >> >>1. User 1 change something and press save. During that user 2 saved changes so server now out of synch with local data. >>2. User 1 saves changes. I use tableupdate(.F.,.F.), that means - "Do not overwrite changes on server if any". This is quick checking for changes on server if you're tableupdated not failed because other errors. >>3. In such case I quickly check for differences between old values and values on server using oldval() and curval() functions. Depended on problem show message box to user - overwrite changes or leave them. >>4. If user press Yes, I just use tableupdate(.T.,.F.) and thats all. >>5. When user press Cancel - I cancel saving so user can go out and check if he really need to save these data. >>6. When user press 'No', I than ask him if he want to review all changed field values compare to server changes. If user press 'No', I just save all changed fields that are not changed on server. If user press 'Yes', I loop through the changed fields and for case value of that field changed on server I ask if overwrite or leave for each particular field. You can test f value changed locally by GetFldState function. >>7. After all above I repeat checking for changes for case when something changed again during time when user messed with above dialog boxes. If all ok, >>use tableupdate (.T.,.F.) anyway, but with correct values from server. When not - repeat again. >> >>SO, in any stage of saving user can cancel changes. N data needed to be retyped again. Above process also, when used with proper responsibility, never cause data loss or conflicts, when organized properly.
Vlad Grynchyshyn, Project Manager, MCP vgryn@yahoo.com ICQ #10709245 The professional level of programmer could be determined by level of stupidity of his/her bugs
It is not appropriate to say that question is "foolish". There could be only foolish answers. Everybody passed period of time when knows nothing about something.
