Re: AutoNumber Regeneration

#1

The issue of using AutoNumber keys in joins is problematic for the reasons
outlined. You should use hardcoded id's for joins to avoid the issue
altogether...

Tony D'Ambra
Web Site: aadconsulting.com
Web Blog: accessextra.net

<jimfortune (AT) compumarc (DOT) com> wrote

Quote:

Sometimes I use Autonumber fields for ID fields. Furthermore,
sometimes I use those same fields in orderdetail type tables. So it's
important in that case that once an autonumber key value is assigned to
a record that it doesn't change. Occasionally I find that due to
corruption or an accidental deletion and restore of a record from a
backup the autonumber field needs to be tidied up. So when I create
(through AddNew) the autonumber key to be used for joins, I also save a
copy in a backup ID field (Long). I could get by with always using the
backup ID for the join but I don't like having backup ID's that are
different from the autonumber value. I decided that I really wanted to
regenerate the autonumber field to match the Backup ID values. I
couldn't get the 'force update on autonumber field to previously
deleted values' idea from a recent post to work so I created some code
to do it. It's still a little rough but might suffice to get someone
to point out an easier way. The code is in A97. I didn't have any RI
to deal with. The form shows the tables in the database and once the
table is selected, the fields populate two comboboxes for choosing the
primary key field and the backup ID field. txtNewTableName is for the
name of the new table with the repaired autonumber values. The main
idea is to use AddNew without an Update until the next backup ID is
reached.

'-------Form Code
Option Compare Database
Option Explicit

Private Sub cbxDatabaseTable_AfterUpdate()
Dim MyDB As Database
Dim tdf As TableDef
Dim fld As Field

If IsNull(cbxDatabaseTable.Value) Then
cbxIDFieldName.RowSource = ""
cbxBackupIDFieldName.RowSource = ""
cbxIDFieldName.Value = Null
cbxBackupIDFieldName.Value = Null
Exit Sub
End If
'Put the field names in cbxIDFieldName and cbxBackupIDFieldName
Set MyDB = CurrentDb
cbxIDFieldName.RowSourceType = "Value List"
cbxBackupIDFieldName.RowSourceType = "Value List"
For Each fld In MyDB.TableDefs(cbxDatabaseTable.Value).Fields
If Nz(cbxIDFieldName.RowSource, "") = "" Then
cbxIDFieldName.RowSource = fld.Name
Else
cbxIDFieldName.RowSource = cbxIDFieldName.RowSource _
& ";" & fld.Name
End If
If Nz(cbxBackupIDFieldName.RowSource, "") = "" Then
cbxBackupIDFieldName.RowSource = fld.Name
Else
cbxBackupIDFieldName.RowSource = cbxBackupIDFieldName.RowSource _
& ";" & fld.Name
End If
Next fld
Set MyDB = Nothing
End Sub

Private Sub cmdFixAutonumber_Click()
If IsNull(cbxDatabaseTable.Value) Then
MsgBox ("No table was selected.")
Exit Sub
End If
If IsNull(txtNewTableName.Value) Then
MsgBox ("No new table name was selected.")
Exit Sub
End If
If IsNull(cbxIDFieldName.Value) Then
MsgBox ("No ID Field was selected.")
Exit Sub
End If
If IsNull(cbxBackupIDFieldName.Value) Then
MsgBox ("No Backup ID Field was selected.")
Exit Sub
End If
Call FixAutoNumber(cbxDatabaseTable.Value, txtNewTableName.Value, _
cbxIDFieldName.Value, cbxBackupIDFieldName.Value)
MsgBox ("Done.")
End Sub

Private Sub Form_Load()
Dim MyDB As Database
Dim tdfLoop As TableDef

Set MyDB = CurrentDb
cbxDatabaseTable.RowSourceType = "Value List"
For Each tdfLoop In MyDB.TableDefs
If Left(tdfLoop.Name, 4) <> "MSys" Then
If Nz(cbxDatabaseTable.RowSource, "") = "" Then
cbxDatabaseTable.RowSource = tdfLoop.Name
Else
cbxDatabaseTable.RowSource = cbxDatabaseTable.RowSource _
& ";" & tdfLoop.Name
End If
End If
Next
Set MyDB = Nothing
End Sub
'-------End Form Code

'-------Module Code
Option Compare Database
Option Explicit

Public Sub FixAutoNumber(strOriginal As String, strNew As String, _
strIDFieldName As String, strBackupIDFieldName As String)
Dim MyDB As Database
Dim AutoRS As Recordset
Dim NewRS As Recordset
Dim strSQL As String
Dim tdfAuto As TableDef
Dim fldAuto As Field
Dim lngCount As Long
Dim lngI As Long
Dim lngKey As Long
Dim tdf As TableDef
Dim fld As Field
Dim idxAuto As Index
Dim idx As Index
Dim boolFound As Boolean

'Place contents of table called strOriginal into table called
'strNew whenever the new autonumber matches BackupID
Set MyDB = CurrentDb
'Make sure index names and fields match
For Each idxAuto In MyDB.TableDefs(strOriginal).Indexes
If idxAuto.Name <> "PrimaryKey" Then
boolFound = False
For Each fld In idxAuto.Fields
If idxAuto.Name = fld.Name Then
boolFound = True
Exit For
End If
Next fld
If boolFound = False Then
MsgBox ("An index name doesn't match a field name.")
Set MyDB = Nothing
Exit Sub
End If
End If
Next idxAuto
'Delete the new table if it already exists
For Each tdf In MyDB.TableDefs
If tdf.Name = strNew Then
MyDB.Execute "DROP TABLE " & strNew & ";"
Exit For
End If
Next tdf
Set tdf = MyDB.CreateTableDef(strNew)
Set tdfAuto = MyDB.TableDefs(strOriginal)
For Each fldAuto In tdfAuto.Fields
If fldAuto.Type = dbText Then
Set fld = tdf.CreateField(fldAuto.Name, dbText, fldAuto.Size)
Else
Set fld = tdf.CreateField(fldAuto.Name, fldAuto.Type)
fld.Attributes = fldAuto.Attributes
End If
tdf.Fields.Append fld
Next fldAuto
MyDB.TableDefs.Append tdf
tdf.Fields.Refresh
For Each idxAuto In MyDB.TableDefs(strOriginal).Indexes
If idxAuto.Name <> "PrimaryKey" Then
Set idx = tdf.CreateIndex(idxAuto.Name)
If idxAuto.Name = strIDFieldName Then idx.Primary = True
If idxAuto.Required Then idx.Required = True
idx.Fields.Append idx.CreateField(idxAuto.Name)
tdf.Indexes.Append idx
End If
Next idxAuto
tdf.Indexes.Refresh
DoEvents
strSQL = "SELECT * FROM " & strOriginal & " ORDER BY " _
& strBackupIDFieldName & ";"
Set AutoRS = MyDB.OpenRecordset(strSQL, dbOpenSnapshot)
strSQL = "SELECT * FROM " & strNew & ";"
Set NewRS = MyDB.OpenRecordset(strSQL, dbOpenDynaset)
If AutoRS.RecordCount > 0 Then
AutoRS.MoveLast
lngCount = AutoRS.RecordCount
AutoRS.MoveFirst
For lngI = 1 To lngCount
lngKey = 0
Do Until lngKey = AutoRS(strBackupIDFieldName)
NewRS.AddNew
DoEvents
lngKey = NewRS(strIDFieldName)
Loop
For Each fldAuto In tdfAuto.Fields
If fldAuto.Name <> strIDFieldName Then
NewRS(fldAuto.Name) = AutoRS(fldAuto.Name)
End If
Next fldAuto
NewRS.Update
If lngI <> lngCount Then AutoRS.MoveNext
Next lngI
End If
AutoRS.Close
Set AutoRS = Nothing
NewRS.Close
Set NewRS = Nothing
Set MyDB = Nothing
End Sub
'-------End Module Code

James A. Fortune

#2

"Tony D'Ambra" <tdambra (AT) swiftdsl (DOT) com.au> wrote:

Quote:

The issue of using AutoNumber keys in joins is problematic for the reasons
outlined. You should use hardcoded id's for joins to avoid the issue
altogether...

Eh? I've been using autonumber primary keys in all my systems since the first one I
created in A2.0 using natural keys. Thus the autonumber keys are present in all the
joins. Or am I misunderstanding something?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

#3

In A97 you can APPEND a record to an autonumber table/field,
to put any unused value into the field.

In later versions you can ALSO change the table permissions
to allow you to edit autonumbers.

In both A97 and later versions you can APPEND a value to
an autonumber table/field in SQL Server, but it is a two-step
process in A97: later versions have /different/ problems
with SQL Server.

(david)

<jimfortune (AT) compumarc (DOT) com> wrote

Quote:

Sometimes I use Autonumber fields for ID fields. Furthermore,
sometimes I use those same fields in orderdetail type tables. So it's
important in that case that once an autonumber key value is assigned to
a record that it doesn't change. Occasionally I find that due to
corruption or an accidental deletion and restore of a record from a
backup the autonumber field needs to be tidied up. So when I create
(through AddNew) the autonumber key to be used for joins, I also save a
copy in a backup ID field (Long). I could get by with always using the
backup ID for the join but I don't like having backup ID's that are
different from the autonumber value. I decided that I really wanted to
regenerate the autonumber field to match the Backup ID values. I
couldn't get the 'force update on autonumber field to previously
deleted values' idea from a recent post to work so I created some code
to do it. It's still a little rough but might suffice to get someone
to point out an easier way. The code is in A97. I didn't have any RI
to deal with. The form shows the tables in the database and once the
table is selected, the fields populate two comboboxes for choosing the
primary key field and the backup ID field. txtNewTableName is for the
name of the new table with the repaired autonumber values. The main
idea is to use AddNew without an Update until the next backup ID is
reached.

'-------Form Code
Option Compare Database
Option Explicit

Private Sub cbxDatabaseTable_AfterUpdate()
Dim MyDB As Database
Dim tdf As TableDef
Dim fld As Field

If IsNull(cbxDatabaseTable.Value) Then
cbxIDFieldName.RowSource = ""
cbxBackupIDFieldName.RowSource = ""
cbxIDFieldName.Value = Null
cbxBackupIDFieldName.Value = Null
Exit Sub
End If
'Put the field names in cbxIDFieldName and cbxBackupIDFieldName
Set MyDB = CurrentDb
cbxIDFieldName.RowSourceType = "Value List"
cbxBackupIDFieldName.RowSourceType = "Value List"
For Each fld In MyDB.TableDefs(cbxDatabaseTable.Value).Fields
If Nz(cbxIDFieldName.RowSource, "") = "" Then
cbxIDFieldName.RowSource = fld.Name
Else
cbxIDFieldName.RowSource = cbxIDFieldName.RowSource _
& ";" & fld.Name
End If
If Nz(cbxBackupIDFieldName.RowSource, "") = "" Then
cbxBackupIDFieldName.RowSource = fld.Name
Else
cbxBackupIDFieldName.RowSource = cbxBackupIDFieldName.RowSource _
& ";" & fld.Name
End If
Next fld
Set MyDB = Nothing
End Sub

Private Sub cmdFixAutonumber_Click()
If IsNull(cbxDatabaseTable.Value) Then
MsgBox ("No table was selected.")
Exit Sub
End If
If IsNull(txtNewTableName.Value) Then
MsgBox ("No new table name was selected.")
Exit Sub
End If
If IsNull(cbxIDFieldName.Value) Then
MsgBox ("No ID Field was selected.")
Exit Sub
End If
If IsNull(cbxBackupIDFieldName.Value) Then
MsgBox ("No Backup ID Field was selected.")
Exit Sub
End If
Call FixAutoNumber(cbxDatabaseTable.Value, txtNewTableName.Value, _
cbxIDFieldName.Value, cbxBackupIDFieldName.Value)
MsgBox ("Done.")
End Sub

Private Sub Form_Load()
Dim MyDB As Database
Dim tdfLoop As TableDef

Set MyDB = CurrentDb
cbxDatabaseTable.RowSourceType = "Value List"
For Each tdfLoop In MyDB.TableDefs
If Left(tdfLoop.Name, 4) <> "MSys" Then
If Nz(cbxDatabaseTable.RowSource, "") = "" Then
cbxDatabaseTable.RowSource = tdfLoop.Name
Else
cbxDatabaseTable.RowSource = cbxDatabaseTable.RowSource _
& ";" & tdfLoop.Name
End If
End If
Next
Set MyDB = Nothing
End Sub
'-------End Form Code

'-------Module Code
Option Compare Database
Option Explicit

Public Sub FixAutoNumber(strOriginal As String, strNew As String, _
strIDFieldName As String, strBackupIDFieldName As String)
Dim MyDB As Database
Dim AutoRS As Recordset
Dim NewRS As Recordset
Dim strSQL As String
Dim tdfAuto As TableDef
Dim fldAuto As Field
Dim lngCount As Long
Dim lngI As Long
Dim lngKey As Long
Dim tdf As TableDef
Dim fld As Field
Dim idxAuto As Index
Dim idx As Index
Dim boolFound As Boolean

'Place contents of table called strOriginal into table called
'strNew whenever the new autonumber matches BackupID
Set MyDB = CurrentDb
'Make sure index names and fields match
For Each idxAuto In MyDB.TableDefs(strOriginal).Indexes
If idxAuto.Name <> "PrimaryKey" Then
boolFound = False
For Each fld In idxAuto.Fields
If idxAuto.Name = fld.Name Then
boolFound = True
Exit For
End If
Next fld
If boolFound = False Then
MsgBox ("An index name doesn't match a field name.")
Set MyDB = Nothing
Exit Sub
End If
End If
Next idxAuto
'Delete the new table if it already exists
For Each tdf In MyDB.TableDefs
If tdf.Name = strNew Then
MyDB.Execute "DROP TABLE " & strNew & ";"
Exit For
End If
Next tdf
Set tdf = MyDB.CreateTableDef(strNew)
Set tdfAuto = MyDB.TableDefs(strOriginal)
For Each fldAuto In tdfAuto.Fields
If fldAuto.Type = dbText Then
Set fld = tdf.CreateField(fldAuto.Name, dbText, fldAuto.Size)
Else
Set fld = tdf.CreateField(fldAuto.Name, fldAuto.Type)
fld.Attributes = fldAuto.Attributes
End If
tdf.Fields.Append fld
Next fldAuto
MyDB.TableDefs.Append tdf
tdf.Fields.Refresh
For Each idxAuto In MyDB.TableDefs(strOriginal).Indexes
If idxAuto.Name <> "PrimaryKey" Then
Set idx = tdf.CreateIndex(idxAuto.Name)
If idxAuto.Name = strIDFieldName Then idx.Primary = True
If idxAuto.Required Then idx.Required = True
idx.Fields.Append idx.CreateField(idxAuto.Name)
tdf.Indexes.Append idx
End If
Next idxAuto
tdf.Indexes.Refresh
DoEvents
strSQL = "SELECT * FROM " & strOriginal & " ORDER BY " _
& strBackupIDFieldName & ";"
Set AutoRS = MyDB.OpenRecordset(strSQL, dbOpenSnapshot)
strSQL = "SELECT * FROM " & strNew & ";"
Set NewRS = MyDB.OpenRecordset(strSQL, dbOpenDynaset)
If AutoRS.RecordCount > 0 Then
AutoRS.MoveLast
lngCount = AutoRS.RecordCount
AutoRS.MoveFirst
For lngI = 1 To lngCount
lngKey = 0
Do Until lngKey = AutoRS(strBackupIDFieldName)
NewRS.AddNew
DoEvents
lngKey = NewRS(strIDFieldName)
Loop
For Each fldAuto In tdfAuto.Fields
If fldAuto.Name <> strIDFieldName Then
NewRS(fldAuto.Name) = AutoRS(fldAuto.Name)
End If
Next fldAuto
NewRS.Update
If lngI <> lngCount Then AutoRS.MoveNext
Next lngI
End If
AutoRS.Close
Set AutoRS = Nothing
NewRS.Close
Set NewRS = Nothing
Set MyDB = Nothing
End Sub
'-------End Module Code

James A. Fortune

#4

david epsom dot com dot au wrote:

Quote:

In A97 you can APPEND a record to an autonumber table/field,
to put any unused value into the field.

In later versions you can ALSO change the table permissions
to allow you to edit autonumbers.

In both A97 and later versions you can APPEND a value to
an autonumber table/field in SQL Server, but it is a two-step
process in A97: later versions have /different/ problems
with SQL Server.

(david)

Thanks for the excellent information. I learned a lot about how
indexes are implemented in Access from prior posts so writing the code
was not a total waste. The other post about rolling your own key, such
as MAX + 1, is also worthy of consideration in a case like mine where
collisions are rare. I'm simply trying to get the best of both worlds.

James A. Fortune
Access numerical data to pdf histogram:
http://www.oakland.edu/~fortune/Histogram.zip

#5

Quote:

Access numerical data to pdf histogram:
http://www.oakland.edu/~fortune/Histogram.zip

I had an experimental version there. I will replace it tonight with
the correct one.

James A. Fortune

#6

Firstly, I find your use of "Eh?" offensive. Your MVP status does not exempt
you from the rules of simple courtesy...

By hard-coded joins I mean joins made using a custom ID field: look at the
sample Northwinds .mdb join: Cutomers-Orders, which uses a custom ID field,
CustomerID, which is not an autonumber field.

Also, the following article excerpt is relevant:
Teach your Access users to be wary of AutoNumbered primary keys

Feb 5, 2002
Peter Nelson
© 2002 TechRepublic, Inc.

As an active Microsoft Access developer, I've got a good view of one side of
the database development environment. But as an active Microsoft Access
instructor, I also get to see what the rest of the nontechnical developer
world is doing with Access. It's this latter view of Access that has
revealed how common it is for nontechnical Access users to incorrectly use
an AutoNumber field type as a table's primary key.

Here is why it's so important to steer end users away from this dangerous
practice.

Ignorance is rarely bliss when it comes to Access
Most business users, or even junior developers, do not have an in-depth
understanding as to what a primary key is, let alone the ramifications of an
ill-conceived primary key selection.

When a user saves a new table in Access, a dialog box pops up asking if the
user wants to create a primary key if one doesn't exist. The message says,
"Although a primary key isn't required, it's highly recommended. A table
must have a primary key for you to create a relationship between this table
and other tables in the database. Do you want to create a primary key now?"

Many of the users I've talked to in introductory, intermediate, and
sometimes even advanced Access classes usually say, "I saw the message and I
figured, what the heck, seems like a good thing to do." So, while they are
actually taking the right step in creating a primary key, they don't know
how to correctly complete the task.

A simple plan
Poorly designed applications are usually more cumbersome and costly to
maintain than those with the benefit of good initial planning.

Well-designed databases are generally characterized by a group of tables
storing related data that is joined together through keys. For example, a
database that stores information on customers and their related orders would
likely have two tables: Customers and Orders. The Orders table would not
contain any information about an order's related customer (address, phone
number, and so forth). Instead, it would contain the key that identifies the
row containing the customer's information in the Customers table.

AutoNumber: A double-edged sword
When choosing a key, it's generally a bad idea to choose a field that can be
edited by a user. Doing so forces you either to restrict the user from
editing the field after the record's creation or to provide a way of
detecting and correcting key collisions. If you restrict the user from
editing the field, you may discover that your application isn't flexible
enough. The second choice is problematic as well; providing for the
detection and correction of key collisions can be too complicated, seriously
hindering your application's performance.

The AutoNumber datatype offers a handy solution to this problem but not
without making your application more vulnerable to failure. On the positive
side, using the AutoNumber datatype provides a field that will give you a
unique value for every record, while also paving the way for establishing
relationships between multiple tables. The negative side is that the
application stands a much better chance of failing if the AutoNumbered
values become corrupt.

Tony D'Ambra
Web Site: aadconsulting.com
Web Blog: accessextra.net

"Tony Toews" <ttoews (AT) telusplanet (DOT) net> wrote

Quote:

"Tony D'Ambra" <tdambra (AT) swiftdsl (DOT) com.au> wrote:

The issue of using AutoNumber keys in joins is problematic for the reasons
outlined. You should use hardcoded id's for joins to avoid the issue
altogether...

Eh? I've been using autonumber primary keys in all my systems since the
first one I
created in A2.0 using natural keys. Thus the autonumber keys are present
in all the
joins. Or am I misunderstanding something?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

#7

"Tony D'Ambra" <tdambra (AT) swiftdsl (DOT) com.au> wrote:

Quote:

Firstly, I find your use of "Eh?" offensive. Your MVP status does not exempt
you from the rules of simple courtesy...

Sorry you found usage of that offensive. I did not realize that it was discourteous.

Quote:

By hard-coded joins I mean joins made using a custom ID field: look at the
sample Northwinds .mdb join: Cutomers-Orders, which uses a custom ID field,
CustomerID, which is not an autonumber field.

Yup, I see what you mean. And as an example that's adequate. But what about the
OrderID field on the order table?

As far as I'm concerned Northwinds should have two versions. One with autonumber
primary keys and one with natural keys.

Quote:

Also, the following article excerpt is relevant:
Teach your Access users to be wary of AutoNumbered primary keys

He's wrong. Autonumber keys work and work well. Finding a natural key and coding
it can be a lot of work. For example how do you get a natural key for a person?
Name? No. Name and birthdate? No. SSN? No. Name and address? Name and phone
number?

How do you handle the situation where you have invoice line items? Now you need code
to create the multipart key, ie invoice #, line 0001, line 0002, line 0003 and so on.

Quote:

The negative side is that the
application stands a much better chance of failing if the AutoNumbered
values become corrupt.

This was a problem in some versions of Jet 4.0 but SPs fixed those. While I still
mostly work in A97 I've never had a problem with Autonumber values becoming corrupt.

Also the Access GUI simply doesn't handle multi part keys well. Although Jet seems
to reasonably well.

That said this can become a religuous argument. Tom Ellison has argued very
eloquently for the user of natural keys. But I still disagree and am exceedingly
happy with autonumber keys.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

#8

Tony Toews wrote:

Quote:

"Tony D'Ambra" <tdambra (AT) swiftdsl (DOT) com.au> wrote:

The negative side is that the
application stands a much better chance of failing if the AutoNumbered
values become corrupt.

This was a problem in some versions of Jet 4.0 but SPs fixed those. While I still
mostly work in A97 I've never had a problem with Autonumber values becoming corrupt.

What are the symptoms of a corrupt autonumber field? Do the values
already stored mysteriously change or are duplicates suddenly allowed
in a primary key field?

Or something else?

#9

rkc <rkc (AT) rochester (DOT) yabba.dabba.do.rr.bomb> wrote in
news:OvMvd.64553$AL5.21598 (AT) twister (DOT) nyroc.rr.com:

Quote:

Tony Toews wrote:
"Tony D'Ambra" <tdambra (AT) swiftdsl (DOT) com.au> wrote:

The negative side is that the
application stands a much better chance of failing if the
AutoNumbered values become corrupt.

This was a problem in some versions of Jet 4.0 but SPs fixed
those. While I still mostly work in A97 I've never had a problem
with Autonumber values becoming corrupt.

What are the symptoms of a corrupt autonumber field? Do the values
already stored mysteriously change or are duplicates suddenly
allowed in a primary key field?

Or something else?

The most common is the "loss of seed value" error, where each new
record gets the same Autonumber, sometimes a previously-used value,
sometimes not.

This was a very common weakness in the first versions of Jet 4, one
that I'd never seen in any previous version of Jet. It was fixed
about SP4 or so, if I'm remembering correctly.

Of course, it wasn't until SP6 that Jet 4 was really stable.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

#10

rkc wrote:

Quote:

Tony Toews wrote:
"Tony D'Ambra" <tdambra (AT) swiftdsl (DOT) com.au> wrote:

The negative side is that the
application stands a much better chance of failing if the
AutoNumbered
values become corrupt.

This was a problem in some versions of Jet 4.0 but SPs fixed those.
While I still
mostly work in A97 I've never had a problem with Autonumber values
becoming corrupt.

What are the symptoms of a corrupt autonumber field? Do the values
already stored mysteriously change or are duplicates suddenly allowed
in a primary key field?

Or something else?

I haven't had to nuke an autonumber field for about eight months so my
details might be a little sketchy. When that happened it seems that
values of other fields, perhaps indexed, reverted back to previously
stored values. Even values changed directly in the table would revert.
I think the values that showed up were the values associated with the
primary key just before it got corrupted. I don't think the field
index was a problem because recreating the autonumber primary key
solved the problem. IIRC, before the recreation the new autonumber
values were very large. The large autonumber values didn't seem to be
duplicating. Is there a simpler way to handle this?

James A. Fortune