Workaround to decrementing Autonumber field

[Qtip23]

Hello Everyone,

I have been searching for ways to prevent the autonumber field from increasing when a user decides he/she does not wish to enter a record.

I searched Bytes and I think I saw something that alluded to setting up two distinct tables (let's call them Table B and Table C). Table B is the one with one field and the field name is the same as the Autonumber field of the host table in question (let's call it Table A). Then Table C is the other field that represents the calculated difference?

I think what happens next is an append query is created to find the difference between the host, and then after that I am lost with how the calculated field passes the next sequential number without any gaps.

If this does not make sense, perhaps someone can provide a more coherent approach.

Can you assist?

Thanks in advance.

Qtip23

[TheSmileyCoder]

What you can do is to stop using autonumber, and simply use Number, Long type for you field. Then when your about to save the record, you look for the max ID and simply add 1.

I think I would do this, in the forms beforeupdate event:

If Me.NewRecord Then
  Me.txtID=DMax("ID","myTable")+1
End If

[missinglinq]

Smiley's advice is spot on! The very fact that you're concerned about 'missing' numbers shows that you shouldn't be using an Autonumber!

Autonumbers are intended to be used for one purpose and one purpose only, to provide a unique identifier for each record. Here's a post I've archived from a gentleman named John Vinson, MVP, explaining how Autonumbers work and giving even more scenarios where there will be gaps:

When using Autonumber, do be aware that there will be gaps in the numbering - any record that's deleted will leave a gap; hitting <Esc> after starting a record will leave a gap; adding records using an Append query may leave a gap, often a huge one; replicating the database will make your invoice numbers random.

In short... it's best NOT to use Autonumbers for human consumption, and particularly not for consumption by accountants and auditors. Invoice sequences like 319, 321, 322, 385, 386, 221841246, -1083225152 make such people get very nervous.

Linq ;0)>

[Qtip23]

@TheSmileyOne
Thanks @SmileyONe. it worked like a charm.

I wonder what would make me think I could chnage Autonumber feature...lol @Linq

You both have been very helpful!

Best,
Qtip23

[Qtip23]

Oh, one more thing. I actually put the code on the form's BeforeInsert event.

I do not want the user to be able to enter any number as I have this field locked on the form. Therefore, the next sequential ID is automatically generated.

Cheers,
Qtip23

[missinglinq]

If this is a multi-user app, as it sounds from your post, you need to place the code in the Form_BeforeUpdate event, as Smiley suggested!

When placed there, the ID number will be generated at the very last second before the record is saved, greatly decreasing the chance of two users' records generating the same ID.

Using the Form_BeforeInsert event, on the other hand, generates the ID number the second a single character is entered in a new record, greatly increasing the chances of two records having the same ID number, and popping an error if the ID number is set to No Duplicates, as it should be.

For example, if using the Form_BeforeInsert event, if UserA starts a record, the ID is generated, and before he/she completes the record, UserB starts a record; the same ID will be generated for both.

Linq ;0)>

[Qtip23]

@Linq duly noted ..just in case we plan to expand for distributed use,, although our team is very small (8 to 10). We plan to have a primary person perform data entry duties. A secondary person will fill in as necessary.

So I guess the form's Record Locks property - Edited Record- would not be capable to avoid the possible record conflict you're describing?

Qtip23

[TheSmileyCoder]

The record locks Edited Record, simply means that your current record is now locked, so that others cannot edit the same record at the same time.
If it is a new record it is not even visible to the other users yet, so the lock at this point has no relevance as far as I can see.

Here we are talking about accidentally assigning the same ID to what is intended to be 2 different records.

Is there any reason you are reluctant to put it in the forms BeforeUpdate event?