On 7 Aug, 12:49, "BruceM" wrote:
EmployeeID, FormID, and Date are not
sufficient in combination to verify uniqueness.

It sounds to me like the author used a real life example where a real
life domain expert said they would be challenged as 'duplicates' by a
real life auditor. But, hey, you know best, eh g? Perhaps you could
suspend disbelief and concentrate on the point: would the meaningless
unique number (petty cash form number) satisfy an auditor that no
duplicates had been entered? I can't tell you how to think but would
encourage you to open your mind (perhaps it would help if you imagined
and Access MVP had written the article g?)

My point about EmployeeID is [that]
it can be quite inconvenient when the EmployeeID number format
changes.
In my company some of the EmployeeID
numbers went up by 12
I just know that it is a nuisance. If they
decide to add a letter prefix to the number (which is now long integer),
there is yet another hassle in that the related field also needs to change
to a text field.

So a meaningless unique number (such as autonumber) solves a potential
problem that may never happen in reality. Big deal. I could say,
"Autonumbers make the data less readable, necessitating a join to the
referenced tables rather than examining just the referencing table
itself", noting that I look at a table far more often than a client
changes an enterprise key that has been mutually agreed to be
considered stable, and you could say, "Big deal." It's a balance.

I realize that
autonumber is a type of long integer.

Last time I looked autonumber could be a 'Replication ID' which is not
a 'long integer'.

Jamie.

--