At 03:04 PM 3/10/2008 +1300, Sytze de Boer wrote: >Hi Folk > >Scenario: >ONE user is editing a stock record in a form, and goes to lunch >ANOTHER user is doing something else and his module issues a command like >REPLACE ALL something >It hits the 1st user stock item who has a record lock on the item that's >being edited
There are 2 schools of thought on this aspect: sort of the like: 1) first guy to start work on the record gets precedence 2) first guy to finish work on the record gets precedence (or Basically, under 1), you need to lock the record when the editing session starts (or come up with a scheme where your system can detect if someone is working on the record(s)). So, that would prevent other processes from doing a "replace all" or any other work on a record that is currently being edited. Under 2), pretty much you don't care if someone loses data/work. For example, in your scenario, the user would come back finish the work, and replace the data. This would cause the results of the "replace all" to be overwritten for that record. Or the same approach would be that the user comes back, tries to save the record, but gets a message that the underlying data had been changed by someone else. So he could either overwrite it with his data, or lose his work. Both approaches have their good/bad aspects. For item 1), while you are pretty safe from any data loss, there is a possibility of "deadly embrace". With 2) there is the likelihood of data loss but deadly embrace is always avoided. I usually go with approach 1). But not with just simply record locks. I have an additional table in the system that tracks who is working on what records. That way, when a function can't be performed because someone is working on data, I can inform the users who they need to tell to finish or wait on. I like that approach because no one loses data. A guy doesn't come back and find out he can't save his stuff, or someone that performed some function comes back and finds his data was overwritten after he did his work. With the "pre lock" mentality, everyone knows what is going on. Often, people opt for option 2). It's the easiest to implement, so the lazy developers go for it a lot. And, if you have a large amount of data, the "theory" is that the likelihood of more than 1 person trying to edit the same data should be small. In my experience, however, that is not the case (thus my usual approach). Now, for your particular case, it sounds like you've started with the 1) approach. So what you probably need to do is have all your functions check for "locking" before you try to do something like a REPLACE ALL: probably check with the FLOCK() function - if it fails, you shouldn't do the replace all. You could also do RLOCK() on all records as a check (set MULTILOCKS on), but if you've got millions of records, I think performance could significantly suffer. You could also implement an additional table that logs who is editing what records - stick in their log on ID - and then be able to retrieve that info for display if some lock process can't be done. Of course, I presume you're using a VFP database. If you're using SQL Server or some other DB server you're options are much more limited (pretty much to the 2) approach). -Charlie _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
