This may be an odd way of going about it, but the record lock tables are already very good at managing contention, etc.
If it's a first-come, first-served type of thing, couldn't you do a READU against a cross-reference file for the user ID as soon as it's entered by the user and hold the lock until after your WRITE statement (or cancellation of the session), and then write the xref record out to the cross-reference file? If you want to rely on file indexing alone, you could do a SELECTINDEX and, if there is no record indexed, set a "fake" READU lock against some scratch file, releasing it after the write, since the index would then handle subsequent queries. Whether the xref for that userID back to the number is there or not, your first user would have it and have it locked. Your LOCKED logic could indicate that it's either already on file or being assigned in another user session. Just a thought... -- James -----Original Message----- From: Wendy Smoak <[EMAIL PROTECTED]> Sent: Oct 8, 2004 1:12 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Enforcing uniqueness of two fields per record? > Richard A. Wilson wrote: > cant you just index both fields and use your check index logic That's what I do now, but there's no guarantee of uniqueness. The key is guaranteed unique-- you just can't write two records with the same key. But AFAIK nothing is going to stop me writing two records with a data field set to the same value. I think I have concurrency issues-- if two users try for the same UserID at the same time, they could both "think" they've got it. (Same code running twice, one just after the other.) That's why I'm thinking to use a database trigger to move that final check as close to the write as possible. -- Wendy Smoak ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
