> > > Terry,
> > >
> > > If you like the best of both worlds, you can use a RecordID field as your primary key, and an InvoiceNumber, PartNumber, or what ever you want as well. Use the RecordID field as the foreign key field in all of the other tables and now your InvoiceNumber or PartNumber can change and you don't have a problem (other than making sure it is unique.) Give it some thought - disk space is cheap and a "RecordID" integer field only costs four bytes. One more field won't add appreciably to your database size, and it can save you hours of work.
> > >
> > > Ken
> > > You shall know the truth - and the truth shall set you free. (John 8:33)
> >
> > Hi Ken
> >
> > Disk space is so cheap I suggest you consider the GUID. That way if you have to combine branch offices into a single table, there will be no worries about conflicting integer values. :)
> >
> >
> > Mike Yearwood
>
> Mike,
>
> Not sure what you are saying. If I had to combine branch offices (and I did have to a short while ago) it would be done with two commands:
>
>

> REPLACE ALL Supporter.OfficeID WITH lnSpringhillOfficeID ;
>         FOR Supporter.OfficeID = lnDartmouthOfficeID ;
>         IN [Supporters]
> REPLACE ALL Offices.Status WITH lnRetiredStatus ;
>         FOR Offices.RecordID = lnDartmouthOfficeID ;
>         IN [Offices]
> 

> No conflicts at all.
>
> If you are talking about combining the data from 2 databases, that is another matter, but I would probaby write a little conversion program if I had to do that.

Combining two tables - yes. :) With guid, no conversion program is necessary. :)
>
> Ken
> You shall know the truth - and the truth shall set you free. (John 8:33)



Mike Yearwood