by nageswaragunupudi » Fri Jun 19, 2009 5:20 am
I fully agree with Mr. James on user psychology.
About checking whether any data is modified by a dialog, in a network environment, we need to consider two kinds of changes.
1) If our user has modified the data by editing the dialog.
2) If any other user changed the data, after our user read the data.
I normally use a class derived from TDataBase. I maintain two buffers, aOriginal and aBuffer. Comparing aOriginal and aBuffer tells me if our user has changed the data. If changed it needs to be saved. This comparison does not require a diskread, which is costly in network environments. ( This has another advantage. User might have edited a few Gets and again re-edited to the original values. In such a case we need not save the record ). Also maintaining two buffers aOriginal and aBuffer enables 'UNDO' without another diskread.
By comparing aOriginal with data in the table ( similar to modified method of TDataBase ) we know if some other user changed the data already. ( Comparing Version fields if maintained may appear to be faster, but our normal RDDs anyway read the entire record ).
Mr James' TData class stood the test of time. I do not know how TData class helps the programmer in this regard. Would Mr James or any user of TData like to enlighten us on this aspect of TData ?
It may be noted that ADO recordset also maintains these values to enable the programmer to do these kinds of comparisons. Every field has OriginalValue, UnderlyingValue and Value. Comparing Value with OriginalValue tells us if our user has modified data. Resync method to update only underlyingvalues reads the current data into this value. Comparing Value with UnderlyingValues tells is if other user modified the data. ( Using Version fields is faster while dealing with RDMSs )
In case, I am not using any classes, I normally have all the values in an array at the outset and compare with edited values in the dialog.
Incidentally I would like to share my views on oGet:Changed. This such a handy feature that we are tempted to use this value to determine if our user has changed the data. But this can be dangerously misleading. Every time a Get gets focus, the oGet;Changed is reset to .f. The user might have edited the data once and might have gone back to the same get and did not modify this time. oGet:changed shows .f.
Regards
G. N. Rao.
Hyderabad, India