"Jamie Collins" wrote in message
oups.com...
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?)

The point of the article seems to have been that a combination of fields
would provide adequate demonstration of uniqueness to satisfy the auditor
that the record is not a duplicate. My point is that it would not. The
meaningless number would not satisfy the auditor, nor would any combination
of the fields used in the example.
No, I do not claim to "know best", but a natural key argument based on
flawed logic does not convince me that the author does either. I expect
there is a valid point in the article, but the example gets in the way.
The logic would have been flawed no matter who had written the article. On
the subject of open-mindedness, do you make any particular claims? ;-)

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 prefer to stay away from situations that would involve updating all of the
records in a related table. Perhaps this is a result of inexperience, and
you would not give such an update a second thought. Companies are bought,
sold, merged, and so forth all the time, so even if somebody today says the
number is stable, that person may be out of work in a month when the company
is bought out and a new system is put in place. I would rather guard
against that not improbably circumstance. You are not daunted by the
prospect of what to me looks like a massive update. As you said, 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'.

In table design view the Data Type is listed as Autonumber, and the Field
Size as Long Integer. There is probably a semantic reason why the
terminology is inaccurate, but these are the terms Access uses. An
autonumber can be related only to a Long Integer field. I don't know what a
ReplicationID is, or how it differs from other use of an autonumber field.
I was responding to your reminding me that autonumber is not a format.


Jamie.

--