I know you already said it's ok, but I'd double check for READs where READUs belong. Especially since you've described this as having a Pick heritage from a time when some Pick implementations and programmers did not handle locking well. One user's changes can easily wipe out another's. WRITE will make use of the lock table even when the program does not ask for it explicitly.
Consider 2 programs updating the same record, one using READU, the other without explicit locking, where the chronological chain of events is this: 0. --- on disk Rec 123: 'A~B~C~Moby Dick' --- ('~' is an attribute mark) User Jack User Jill ========= ========= Wants to Wants to change Moby Dick change A~B~C to Tom Sawyer to X~Y~Z 1. READU REC FROM F,'123' - sets lock - gets 'A~B~C~Moby Dick' 2. REC<1> = "X" REC<2> = "Y" REC<3> = "Z" in private memory: (X~Y~Z~Moby Dick) 3. ---( on disk still as 'A~B~C~Moby Dick' )--- 4. READ REC FROM F,'123' (ignores lock, sets none.) gets 'A~B~C~Moby Dick' 5. REC<4> = 'Tom Sawyer' In private momory : (A~B~C~Tom Sawyer) 6. WRITE REC TO F, '123' 7. behind the scenes UV check for & ends up waiting for Jill to release the lock...waiting... ...waiting...waiting... 8. ---( on disk still 'A~B~C~Moby Dick' )--- 9. WRITE REC TO F,'123' 10. ---( on disk rec 123: 'X~Y~Z~Moby Dick' )--- 11. readu lock is released. 12. UV *implicitly* 12. CRT 'Jill, success: A~B~C was sets the lock on changed to X~Y~Z. Congrats.' Jack's behalf! Jack's version of the rec is written, readu lock released. 13. ---( on disk rec 123: 'A~B~C~Tom Sawyer' )--- Time passes 14. Jill calls Pam, "Hey! Where are my changes? Computer said I changed A~B~C to X~Y~Z but it's A~B~C again!?!? I think we need MSSQL." Other variations on this theme will yield similar corruption if READUs are not used consistently, exclusively, and explicitly whenever updates are performed. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/