Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Restore correct AUTONUMBER 1

Status
Not open for further replies.

jofoko

Technical User
Apr 25, 2002
4
AT
Hi,

after deleting the data record with the maximum Autonumber i get the false autonumber the next time i try to enter new datas.
I thought the command 'compress and repair' in the database utility menu will fix this problem so that i get the correct autonumber the next time.

Actually i works just SOMETIMES. I tried it several times but had just randomly success.

What can be the problem?? Is there anything else to do before the compressing task??

thanks for your help in advance

jochen
 
You are not getting a false number as you think......

First, if you are using an autonumber field as part of required data, you are in the wrong.....Autonumber should NEVER be used for ANYTHING except to uniquely identify a record...it should never be part of the data....

Second, if you do a compact, and the table is empty the autonumber will be reset to zero...otherwise, is it not....it will remain the same... Please remember to give helpful posts the stars they deserve!
This makes the post more visible to others in need! [thumbsup2]

Robert L. Johnson III, A+, Network+, MCP
Access Developer/Programmer
robert.l.johnson.iii@citigroup.com
 
I agree with mstrmage1768. You are getting the correct autonumber. If you want a counter, you should program something like a counter. An autonumber gives you a unique ID. Let me give you an example:

the table
Code:
tblEmployee
has a field
Code:
lngTaskId
and
the table
Code:
tblTask
has a field
Code:
lngTaskId
(an autonumber)

There is a relation between the two tables.

Now, if you could change the autonumber, the referential integrety would break! A task may then "mysteriously" appear for another employee or not at all. This is the reason that a key must never carry a "meaning". To put it more formally: a key may never contain data. It is just a pointer.

Best regards
 
Hi guys,

thanks for you ad hoc help. Your answers were quite clear and the added design - rule information made the information valuable and reasonable.

What you wrote makes sense.

thanks

jochen
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top