Re: 5250 and un-do -- ROW CHANGE TOKEN warning

A progress report:

Henrik, and others, have talked of timestamp & ROW CHANGE. Soooo.... being bored, and realizing that Y2K is no longer a concern, maybe its time I moved forward with my thinking.  Frankly is not going well.  Since SQL is new too me I decided to explore ROW CHANGE.  Although that is not going well it is clear to me that the whole set of problems is firmly and only in my own head.

The instructions I have seen so far remind me of the recipe for Russian Bear Soup: "First, catch a bear."


On 12/27/2017 7:18 AM, Mark Murphy wrote:

Nearly all these arguments you are making apply equally to the token method
and the duplicate field method put forward by Booth. You still have to send
the before value or values to the client. In both cases, those values have
to be sent to the client for other reasons. In both cases those before
values must be returned to the server to compare to the record before
update. The only significant difference is the number of values that must
be managed. Booth prefers multiple values because he can get a more
accurate picture of what has changed. If a small number of fields are
eligible for update in a table with a large number of fields, it may be
advantageous to check just those fields. Particularly when the table is
highly volitile.

Synon programs make a copy of the record and compares that with the current
record at the time of the update. This is similar to the token as it is an
all or nothing solution. Most of the time that works great, but sometimes I
have wanted a finer grained solution.