spikepl
Eledittingent Beliped
- Local time
- Today, 03:53
- Joined
- Nov 3, 2010
- Messages
- 6,142
To create some unique incrementing custom number, two methods seem to exist
1. On Form Update event for the record, use Dmax to retrieve the current max and assign it to the record, if record does not yet possess that unique ID.
2. Maintain a table with the max. Lock table, retrieve max, increment max, apply to record, save max, release table. Requires dbTable in OpenRecordset to be able to lock. dbTable requires separate opening of table in Backend from frontend, and some retrial strategy, eg.
http://books.google.com/books?id=qtgInMAAA0oC&pg=PT312&lpg=PT312&dq=access+dbDenyWrite&source=bl&ots=JkrBufTiiV&sig=OHdf3HSqo8jMIS0eb1NgZXWGAn0&hl=en&ei=hP-KTv2bI9DQ4QSL-9WBBA&sa=X&oi=book_result&ct=result&resnum=8&ved=0CGcQ6AEwBw#v=onepage&q=access%20dbDenyWrite&f=false
Ad 1. This seems to work in most cases - I guess the room for a separate user inserting the same value is counted in microseconds. But it does seem to exist, and so Murphy lurks ...doesn't he?
Ad 2. This is a fully secure belt-and-braces approach, as far as I can tell. But much more code to maintain.
Anyone with any comments on how secure method 1 is ? A little transparent error handling in case of duplicate key found would seem sufficient to close the millisecond gap.
1. On Form Update event for the record, use Dmax to retrieve the current max and assign it to the record, if record does not yet possess that unique ID.
2. Maintain a table with the max. Lock table, retrieve max, increment max, apply to record, save max, release table. Requires dbTable in OpenRecordset to be able to lock. dbTable requires separate opening of table in Backend from frontend, and some retrial strategy, eg.
http://books.google.com/books?id=qtgInMAAA0oC&pg=PT312&lpg=PT312&dq=access+dbDenyWrite&source=bl&ots=JkrBufTiiV&sig=OHdf3HSqo8jMIS0eb1NgZXWGAn0&hl=en&ei=hP-KTv2bI9DQ4QSL-9WBBA&sa=X&oi=book_result&ct=result&resnum=8&ved=0CGcQ6AEwBw#v=onepage&q=access%20dbDenyWrite&f=false
Ad 1. This seems to work in most cases - I guess the room for a separate user inserting the same value is counted in microseconds. But it does seem to exist, and so Murphy lurks ...doesn't he?
Ad 2. This is a fully secure belt-and-braces approach, as far as I can tell. But much more code to maintain.
Anyone with any comments on how secure method 1 is ? A little transparent error handling in case of duplicate key found would seem sufficient to close the millisecond gap.