Kbase P145593: SAVE-ROW-CHANGES ignores fields not in dataset when checking current changed
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
05/05/2009 |
|
Status: Unverified
SYMPTOM(s):
SAVE-ROW-CHANGES ignores fields not in dataset when checking current changed
SAVE-ROW-CHANGES fails to report database record changed
proDataSet's optimistic locking strategy doesn't catch changes to fields that are not in the temp-table
proDataset doesn't ensure record concurrency when saving changes if changes are made to fields not in the dataset
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.x
CAUSE:
This is expected behavior. All currently available comparison methodologies test for differences between the fields that exist in both the source and target buffers.
FIX:
The following four methodologies are potential workarounds for this. All of these require storing some data in the temp-table to be checked before executing SAVE-ROW-CHANGES on the before buffer. The best way to handle this storage is in a AFTER-ROW-FILL callback procedure on the buffer being filled:
1) Add a field to the original database table to store a timestamp for when the record is changed in the database. This would also require adding a write trigger to update the timestamp.
- The upside of this method is that it requires very little storage space in the client temp-table
- The downsides of this method include:
You have to make changes to your database table and recompile existing r-code in order to implement it
There is no way to tell which fields/data changed in the record so all you know is that the record changed, not what changed
2) Add an INTEGER field to the temp-table to store the value from the RECORD-LENGTH attribute of the original buffer.
- The upside of this method is that it requires very little storage space in the client temp-table.
- The downsides of this method include:
Changes to the fields in the record that don't change the record length will be missed
There is no way to tell which fields/data changed in the record so all you know is that the record changed, not what changed
3) Add a RAW field to the temp-table to store the entire original database record on the client side and compare this to a similar snapshot before saving.
- The upside of this method is that you have the ability to do a granular field by field comparison to determine which data changed and can make decisions in your code on whether to proceed with changes based on that
- The downside of this method is the amount of space required to store the entire RAW value of the original record and thus the network packet size when using AppServer to pass the temp-table record back to the client
4) Add a RAW field to the temp-table and use the MD5-DIGEST function to get a hash value of the original database record from the RAW value of that record. This provides what amounts to a record checksum or CRC of the data for later comparison.
e.g.
RAW-TRANSFER <buffer> TO <raw_variable>.
<raw_variable> = MD5-DIGEST(<buffer>).
- The upside of this method is that it requires very little storage space in the client temp-table
- The downside of this method is that there is no way to tell which fields/data changed in the record so all you know is that the record changed, not what changed