Access Autonumber Feature

[jamesh320]

Hey guys. I was wondering if anybody knows if access could autogenerate
something like a code.
I know access has the autonumber feature, but it starts with the number 1,2,
and so forth.
Can microsoft access use the same feature as autonumber, but instead do
something like the code CA1-090001 on the first row, and auto generate the
code CA1-090002 on the next row?

 

[Keven Denen]

Hey guys. I was wondering if anybody knows if access could autogenerate
something like a code.
I know access has the autonumber feature, but it starts with the number 1,2,
and so forth.
Can microsoft access use the same feature as autonumber, but instead do
something like the code CA1-090001 on the first row, and auto generate the
code CA1-090002 on the next row?

There is no automatic function to do this, but you could write build
it into a form control to generate this for you automatically.

Keven Denen

 

[Piet Linden]

Hey guys. I was wondering if anybody knows if access could autogenerate
something like a code.
I know access has the autonumber feature, but it starts with the number 1,2,
and so forth.
Can microsoft access use the same feature as autonumber, but instead do
something like the code CA1-090001 on the first row, and auto generate the
code CA1-090002 on the next row?

http://www.mvps.org/access/strings/str0007.htm

 

[John W. Vinson]

Hey guys. I was wondering if anybody knows if access could autogenerate
something like a code.
I know access has the autonumber feature, but it starts with the number 1,2,
and so forth.
Can microsoft access use the same feature as autonumber, but instead do
something like the code CA1-090001 on the first row, and auto generate the
code CA1-090002 on the next row?

I presume the 09 is the year? Is CA1- a constant for all records, or might you
have OR1- for Oregon or NV1- for Nevada?

In any case, the answer is No, an Autonumber is not going to do this for you;
and the next deeper answer is Don't Do It. Storing two or perhaps three
different facts in one field is a very bad idea; fields should be atomic.
Dates are data and should be stored as data.

This kind of "portmanteau key" was very common in the old days when you had
only one label on a file folder or one indexed field in a database, but they
are far more trouble than benefit in a modern database system where any field
can be searched! Perhaps you could explain how this field will in fact be
used; I'm willing to suspend my objections if you have a good reason.