I have a long running application that has quit working correctly for me. For several tables, I use the tried and true method suggested by Michael Fournier for generating a unique, sequential key for each record: A separate table contains a record for each table needing a key. To get the new key, we access that storage table, look up the appropriate working table, rlock() the record, retrieve the stored number, replace that number with number + 1, unlock the record and return the stored number formatted as a zero-padded string.

This code has worked for over 5 years without fail. Yesterday, in the middle of the afternoon, it quit working -- but only for one table. Let me point out that this application runs on a Novell network, has 5 to 10 users modifying data at the same time and has relatively small data tables (less than a million records in every table). It's not under a lot of stress.

As of yesterday afternoon, the users reported the following: A new record (these are correspondence records) is created on screen. All data is properly entered and the SAVE button is clicked. No error messages are generated BUT ... in 16 of 26 incidents the record was not saved. (There is code to display an error message if tableupdate does not return .t.!) The screen returns to either an empty record or to the last correspondence (prior to this add) for this client.

When I look at the table, I find that the storage table field has been incremented the correct number of times for the 26 records. The correspondence table has 42 new records in it of which 16 are duplicates. Not just the primary key, full duplicates. Within those 42 records there are 16 sequential numbers missing. In other words, the key, which should read 101,102,103,104, etc., reads as 101, 103,103,104,106,106, 107, 108, 109, 111, 111, etc. No pattern that I can determine for in some cases there is 120, 118, 120 sequence. Totally wacky.

The key generation code seems to work correctly. The screen displays no sign of error. There is not indication that the code is looping. The correspondence table appears to be solid and stable....

Can anyone offer some direction here? Where should I look for what might cause this type of behavior? I have been unable to duplicate this is test but it is still happening in the work environment. Any help would be GREATLY appreciated.