Alternative to AutoNumber

A lot of talk has been about the failure of the Auto Number.

This has not been my experience.

I wonder how many of you have had real problems with the Auto Number failing. I am suggesting that you only count the Databases that you have written rather than those written by others and you have been ask to get involved.

My thinking is that this has only happened rarely. And in such cases there is most likely other problems with the Database.
 
A lot of talk has been about the failure of the Auto Number.

This has not been my experience.

I wonder how many of you have had real problems with the Auto Number failing. I am suggesting that you only count the Databases that you have written rather than those written by others and you have been ask to get involved.

My thinking is that this has only happened rarely. And in such cases there is most likely other problems with the Database.

I agree with this. I have seen corrupted autonumber seeds, which are easily repaired, by manually inserting a seed larger than the highest value in the table. There used to be a MS support article about this, but I can't see it now.

The important thing is to ensure that the autonumber is in a unique index, ideally the PK. A non-unique index would not detect this problem.
 
As a side note: The question was raised as to whether SSN is a natural or synthetic key. As a firm believer in Albert Einstein's ideas (mostly), my answer is "It's all relative." If YOU are the person working for the agency that issues SSNs, it is synthetic. To anyone else, it is natural because you didn't synthesize it. Don't forget that SSN actually is encoded. First 3 digits = geographic. Next 2 digits = ID of an issuing group/authority. Last 4 digits = autonumber.

As to the auditor question: there are ways around the non-contiguous number issue, but the simplest way is to use some variant of the DMax+1 scheme OR to document that an aborted autonumber index is neither stored nor re-used in Access. Good auditors understand the concept of mitigation and would know about non-contiguous numbering as a property of the indexing system. What you would have to do for auditors in that case is to have a separate logging table for what got stored.

Here is a counter-example. We can have long sequences on our system where nothing happened. Our timestamps in the log file are discontiguous but they didn't miss anything. OK, I know it is a stretch, but auditors who kvetch over a known discontiguous number method are just as unimaginative and humorless as those who kvetch over idle gaps in an audit log's time stamps. (Wait... unimaginative and humorless? They must be the Men in Black.)

Seriously, really GOOD auditors will ask for a system design document first before they look at what is on the system. If this design document says "this number will be increasing but not contiguously so" AND the system owners signed off to this document, the auditors can be literally told to shut up and do something constructive. No, I'm not being flippant. This is also why, if you look at documentation for fiduciary systems, they often refer to some external standard for such systems - which would have prevented you from picking that discontiguous situation in the first place. I guess what I'm saying is that in the world of business, if regulations allowed the numbering scheme to have gaps, then the "auditors" argument is moot. If regulations forbade it, you would not have chose that situation anyway.
 
If you are completely satisfied that it is unique then there is no reason why you should not use it.

I would do something similar. I would use this as the Main identifier for all to see. However I would still have an Auto Number hidden away which is the real PK.

If I used that scheme I would have to look up the surrogate key from the Members table every time a record was added to any of the related tables. My naturalistic PK is already a field in the related tables.

A surrogate key would just be another index to maintain. Moreover, the queries more complex if I used it.
 
If I used that scheme I would have to look up the surrogate key from the Members table every time a record was added to any of the related tables. My naturalistic PK is already a field in the related tables.

A surrogate key would just be another index to maintain. Moreover, the queries more complex if I used it.

Would your natural key still require to be indexed. You would be searching, filtering etc with the Auto Number. Sorting would not fit in with this.

So only the one Index would be required. (Plus others depending on the table make up)

I do not use your method as described in paragraph one. I have a Main Form Sub Form in my design so this idea of manually searching for the Key also is not required. I have no idea what or why you do.

I may not reply quickly for a while. Not feeling the best.
 
Galaxiom

As no one else is getting involved, I suggest that we finish this last point then call it a day. We could go on for ages otherwise.
 

Users who are viewing this thread

Back
Top Bottom