By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,849 Members | 2,339 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,849 IT Pros & Developers. It's quick & easy.

A2K - how to create my own unique internal employee id

P: n/a
What's the current thinking about generating your own internal id for each
record in a table? In my case I would like to add a field, for internal use
within the program, that uniquely tags each employee record.

There was never any need to capture an employee number to try to distinguish
records, I just need to be able to find a record that refers to a specific
employee.

I was thinking of randomising a number and maybe adding some descriptive
characters, then checking to see if it existed before adding it to the
record.

Would that be on the right lines?

thanks
Martin
Jan 16 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Deano wrote:
What's the current thinking about generating your own internal id for
each record in a table? In my case I would like to add a field, for
internal use within the program, that uniquely tags each employee
record.

There was never any need to capture an employee number to try to
distinguish records, I just need to be able to find a record that
refers to a specific employee.

I was thinking of randomising a number and maybe adding some
descriptive characters, then checking to see if it existed before
adding it to the record.

Would that be on the right lines?

thanks
Martin


I should add that my records are distinguished by the autonumber primary key
but I now need this additional field.
Jan 16 '06 #2

P: n/a
Deano wrote:
What's the current thinking about generating your own internal id for
each record in a table? In my case I would like to add a field, for
internal use within the program, that uniquely tags each employee
record.

There was never any need to capture an employee number to try to
distinguish records, I just need to be able to find a record that
refers to a specific employee.

I was thinking of randomising a number and maybe adding some
descriptive characters, then checking to see if it existed before
adding it to the record.

Would that be on the right lines?

thanks
Martin

While I continue to talk to myself may I ask if I'm being clever here :)

I create a random number like so;
Dim varASTid As Variant
varASTid = Int((10000000 * Rnd) + 1)

Then I concatenate it with the existing PK and assign it to the new field
like so;
Me.txtASTid = Me.Teacher_ID & varASTid & "Emp"

Given the PK is unique do I now have a guaranteed unique id? I'm thinking
that I don't have to check the table now before I assign it....
Jan 16 '06 #3

P: n/a
What's wrong with an autonumber primary key? Typical name searches work on
last/first/MI, then show birth dates/SSN/phone/etc. to distinguish similar
people. My experience with these "manufactured" unique ID's (e.g.. last 4
SSN + first 4 LastName, etc.) is that they all break at some point. Phone
books and the SSA work just fine without them.
-Ed

"Deano" <de***@mailinator.com> wrote in message
news:43***********************@ptn-nntp-reader03.plus.net...
What's the current thinking about generating your own internal id for each
record in a table? In my case I would like to add a field, for internal
use
within the program, that uniquely tags each employee record.

There was never any need to capture an employee number to try to
distinguish
records, I just need to be able to find a record that refers to a specific
employee.

I was thinking of randomising a number and maybe adding some descriptive
characters, then checking to see if it existed before adding it to the
record.

Would that be on the right lines?

thanks
Martin

Jan 16 '06 #4

P: n/a

What is the point?

The only reason most people would consider this is to create a key which is
easy for humans to remmber or calculate. If it's simply a
database/application internal pk then just use the autonumber field you
already have.

What you are proposing just creates more work and more room for error with
no apparent gain.
--

Terry Kreft
"Deano" <de***@mailinator.com> wrote in message
news:43***********************@ptn-nntp-reader03.plus.net...
Deano wrote:
What's the current thinking about generating your own internal id for
each record in a table? In my case I would like to add a field, for
internal use within the program, that uniquely tags each employee
record.

There was never any need to capture an employee number to try to
distinguish records, I just need to be able to find a record that
refers to a specific employee.

I was thinking of randomising a number and maybe adding some
descriptive characters, then checking to see if it existed before
adding it to the record.

Would that be on the right lines?

thanks
Martin

While I continue to talk to myself may I ask if I'm being clever here :)

I create a random number like so;
Dim varASTid As Variant
varASTid = Int((10000000 * Rnd) + 1)

Then I concatenate it with the existing PK and assign it to the new field
like so;
Me.txtASTid = Me.Teacher_ID & varASTid & "Emp"

Given the PK is unique do I now have a guaranteed unique id? I'm thinking
that I don't have to check the table now before I assign it....

Jan 16 '06 #5

P: n/a
Ed Robichaud wrote:
What's wrong with an autonumber primary key? Typical name searches
work on last/first/MI, then show birth dates/SSN/phone/etc. to
distinguish similar people. My experience with these "manufactured"
unique ID's (e.g.. last 4 SSN + first 4 LastName, etc.) is that they
all break at some point. Phone books and the SSA work just fine
without them. -Ed


Well I'm going with my own idea and I WILL now check for duplicate entries,
fingers-crossed it won't break.
Jan 16 '06 #6

P: n/a
Terry Kreft wrote:
What is the point?

The only reason most people would consider this is to create a key
which is easy for humans to remmber or calculate. If it's simply a
database/application internal pk then just use the autonumber field
you already have.

What you are proposing just creates more work and more room for error
with no apparent gain.


The point is to help with an extension of the database which breaks so many
database design rules I dare not post their details here! Nevertheless it
is a simple and useful way of accomplishing what I need to do without
reinventing the whole database (which is what I should do).

It is required for internal referencing and not for human use though I have
a few words in mind for the humans who are asking me to do this...
Jan 16 '06 #7

P: n/a
Deano wrote:
The point is to help with an extension of the database which breaks so many
database design rules I dare not post their details here!


Just use another autonumber.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Jan 16 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.