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

[Booth Martin <booth@xxxxxxxxxxxx>]

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.