There are at least two ways to solve it. The first is as Phil described. Have a DS that your CHAINs load the fields into. Save a copy of the entire DS and compare it against the DS that you get with the second CHAIN. Any difference tells your program that the record has changed since the user first saw it.

The second way might be to CHAIN with lock both times. Immediately after the first CHAIN do an UPDATE that sets a flag in the record that says the record is in use. That first UPDATE will release the lock, but any other program that reads the record can test the flag to see if it is in use for updating. The record will be retrieved, but your logic will have to ensure that no changes are made until the record can be safely read.

Whatever way you decide to handle it, your program will need to do the testing and to notify the user about the problem. The user will need to choose to wait or to see the changed record or whatever.

As I mentioned earlier, this is why many programs don’t handle the situation at all. The programs use a single CHAIN with lock and leave the record locked the entire time… because it’s easier.

Tom

When you acquire the row the first time you need to save a copy of a field, fields or more likely the entire record as a data structure. Then when you go into the update routine and acquire the record for a second time you need to compare the orginal with the new values, if they aren’t the same, the record was changed by someone else during the time you were viewing it.

Generally the screen fields have different names from the database fields regardless of update method. Typically when the user requests an update, the data must be validated before the file is updated.

Phil

Not quite yet.

There is still one problem that needs to be resolved. This problem is maybe the biggest reason that many programmers do not use two CHAINs to perform one UPDATE. They will use a single CHAIN that locks the row the entire time that the user has the record on the screen.

Here’s the problem:

User #1 asks for a record, and your program CHAINs without lock and displays the record.

Then, User #2 asks for the same record, and again your program CHAINs without lock and displays the record.

The same record is now on two screens at the same time.

User #2 makes a change and presses F5. Your program CHAINs with lock and UPDATEs the record.

What does User #1 have on the screen? When User #1 presses F5, what record will be retrieved when your program does the CHAIN? And when your program does the UPDATE for User #1, what happens to the change that was made by User #2?

Does either user know that the other user made any changes?

Tom

If you use the same names for the database and display files, you can’t move values between the fields because the program uses the same memory for both.

You can use the same names when you want the values to be the same in many programs. But if you read a record from the database file after reading the record from the display filewhen using the same names, the values from the display file will be lost.

So you need to use different names in an update program like the one you are writing. With different names, you move values back and forth whenever you decide is the right time.

Tom

you need to move the fields from the display to the physical file record, then update it.
then, how can i move the field value…
please give a suggestion…