>>Great comments, Garrett! I'll use it. Currently, this is for a
>>rehabilitation practice that has 4 digits in the client id field.
>>I hadn't automatically assigned the id yet because usually in a
>>practice or facility environment, the case # is assigned on the
>>fly by a receptionist (manually using a chart).
>
>The president of the Fox User Group in Bangor gave a talk about a nursing home
>package that she had been working on: one of the requirements was that there
>were _no_ client id numbers: all patients had to be referred to by name.
>Of course, this is only practical when you're dealing with (in this case) 90
>records tops...
>
>>However, reading your note made me remember not to ASSume anything.
>>I'll put a call in to them Monday to see if they want the product to
>>assign the codes.
>
>That's not _quite_ what I meant. The primary keys I assign are never
>seen by the user. The user generally assigns a candiate id manually.
>This one actually _could_ be FOSTEDON01. Since the primary key is 185423,
>and this is the value that's stored in all tables referencing PatientID,
>we can change FOSTEDON01 to FITZGEDON01 in the Patient table, and not
>have to make any further changes.
>
>As I indicated before, USE AGAIN is a workable way to check for duplicate
>IDs, until Tahoe comes along with INDEXSEEK()....

I see. So the candidate could change, but you've still got your primary key for link integrity. Got it. I've actually incorporated a few ideas--the USE again, the release of the control source (different field), and your primary/candidate idea--already.

Working on 3 projects at a time, one can use 3 ideas to see which one works out the best!

JR