|
At 13:44 22.10.2002 -0500, you wrote:
I'd prefer comparing the changed values to the actual values in the file, not the stored ones in any state holder or hidden fields. That would make more sense in a generic way.How do you know that the actual values in the file haven't been changed by another user? If you truly do want a read next changed operation, the only real way to know is to compare to a saved copy of the data. It could be in some kind of session object, or you could have the client return the before and after versions of the data, but I don't think you could compare to the data file, as in 'Chain to the file to see if the record is different. If so, post these differences as changes"
Yes, one needs three sets of data - the original data sent to the browser, the possibly altered data from the browser and the current content of the file. If the current content isn't equal to the one sent to the browser, someone/something else has altered the data in the meantime. This functionality is even provided by UPDDTA. Never seen DFU0865? And the "read next changed" is just an analogy to READC that just reads those lines "touched". But that doesn't really fit here. Everything has to be read from the browser; by means of JavaScript one could know that a field has been "touched" instead of comparing to somehow saved or database values. But that isn't really reliable from my point of view. best regards / Mit freundlichen Grüssen Anton Gombkötö Avenum Technologie GmbH http://www.avenum.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.