Our users may need to take a portion of their database to work away from the office and then synch back later on. As such we can't use the autonumber feature for our record unique id because of the potential for duplicate. We are considering having a table that has a record for each user and their "next number".
Every transaction would hit the table to get the next number for that user and when they are away from the office that
table will be in their temporary database and will be used there. Our users will either be in, or out of the office, but not both during the same time period. Our new unique ID is some alphanumeric combination unique to the user followed by their own unique number.
If the autonumber is generated from the database and this method is also generated from the database is there any extra inefficency? Is the only related to the administration of that extra table for us.
We dont want to use the replication-synchronization or a GUID number, but is there another better alternative?
Every transaction would hit the table to get the next number for that user and when they are away from the office that
table will be in their temporary database and will be used there. Our users will either be in, or out of the office, but not both during the same time period. Our new unique ID is some alphanumeric combination unique to the user followed by their own unique number.
If the autonumber is generated from the database and this method is also generated from the database is there any extra inefficency? Is the only related to the administration of that extra table for us.
We dont want to use the replication-synchronization or a GUID number, but is there another better alternative?
