Office: (Office 2010) RIESEN Bug in Access 2010!

Ausgangspunkt folgende Tabellendefinition:
Feld: ID / Type: Autowert (Inkrement) / Index: ohne Duplikate
Feld: Bezeichung / Type: Text / Index: PrimaryKey

Bei Datensatzeingabe läuft zu nächst alles wie erwartet.

Sollte der nächste zu setzen Autowert auf eine kleinere ID gesetzt werden (was mit einer Anfüge-Abfrage oder durch komprimieren der Fall sein kann), dann erhält ein neuer Datensatz wirklich diesen kleinen Wert, auch wenn bereits höhere Werte vorhanden sind. Da diese ja aber schon exisitieren, erhält man eine Fehlermeldung.
Fazit: Access 2010 vergibt unter umstände eine ID mehrfach *entsetzt
Das Dateiformat spielt dabei keine rolle (mdb/accdb).
Mit Access 2007 habe ich es nicht getestet

Habe dies unter Acc2003 getestet, und dort ist dieser Fehler nicht aufgetretten.

Anmerkung: Es passiert nur, wenn das AutowertFeld nicht den PrimaryKey hat. Dies mag zwar selten vorkommen, aber es gibt manchmal berechtigte Gründe dies so zu machen.

Gruß
JPA

:)

 

Hallo!

Das ist das übliuche Verhalten von Jet (auch schon bei früheren Versionen), wenn durch eine Anfügeabfrage das Autowertfeld befüllt wurde.
Autowert = Letzer eingetragener Wert + 1

Ein Grund wäre, dass du nicht sicherstellen willst, dass Werte nur einmal vorkommen. *wink.gif*
Falls die Werte nur einmal vorkommen dürfen, würde ich zumindest einen eindeutigen Index auf das Feld legen.

mfg
Josef

 

Habe ich ja gemacht.

Der Punkt ist, dass das Autowert-Feld eine bereits vergebene Nummer vergibt.
Dies hat Access 2003 nie gemacht.
Access 2010 macht es ja auch nicht, wenn das Feld den PrimaryKey hat.
Aber falls nicht, dann kann es passieren...
Es ist also kein "übliches" Verhalten, und für mich ein Bug (and not a feature:-).

 

Hallo!

Ich bin der Meinung, dass ich das bereits bei Access 2000/2002 (oder früher) feststellte. Wobei das auch auftritt, wenn das Autowertfeld der PK ist.

Zum Testen:
Code:

Durch das Anfügen passiert im Prinzip so etwas:
Code:

mfg
Josef

 

ok, über die programmierung mag es stimmen.

Gebe, manuell einen neuen Datensatz in der Tabelle ein, und in access 2003 bekommst du immer den nächst größeren Wert, auch wenn der autowert anders gesetzt wurde.
In access 2010 nicht; dort erhählst du den nächst größeren Wert, nicht in der Tabellen, sondern vom gesetzen Autowert (per anfüge-Abfrage oder komprimierung).

 

Hallo!

Hast du das mit dem gezeigten Code getestet?
Also z. B. so:
Code:

mfg
Josef

 

\@JPA:
ich frage mich was einen dazu treiben könnte, Lücken im Autowert mit einer Anfügeabfrage zu füllen. *confused.gif*

Deiner Aussage, dass dies auch nach Komprimierung passieren kann, möchte ich widersprechen. Das wäre IMHO tatsächlich ein Bug.

 

ok, habe es jetzt genauer getestet. Der Fehler ist ganz klar in der Komprimierfunktion von MS Access 2010.
Access 2007 verhält sich wie 2003, es betrifft also scheinbar nur acc2010.

Nach dem Komprimieren unter acc2010, ist der vergebene Wert im Autowert-Feld nicht mehr "Letzter Wert+1".

Ich habe ein Beispiel zusammengestellt, damit ihr dies nachvollziehen könnt.
Schaut dazu auf meinen Blogeintrag: http://msofficeinside.blogspot.com/2...ion-in-ms.html

VG
JPA

 

Hallo!

Wie hast du diese mdb erstellt?
Ich kann den Fehler mit deiner mdb reproduzieren. Wenn ich aber selbst eine Tabelle erstelle, gelingt es mir nicht, dieses Verhalten einzustellen.
Ein Komprimieren repariert mir dann sogar einen zuvor niedriger eingestellten Autowert, den ich per Insert-Anweisung (inkl. befülltes Autowertfeld) aktivierte.

/Edit: Und es geht doch. :-)
Vermutung: die Sortierung des PK muss unterschiedlich vom Autowertfeld sein und genügend Datensätze (vermutlich wegen Speicherseiten) beinhalten, dann verschluckt Jet/ACE jene Max-Autowerte, die nicht in der Nähe des höchsten PK sind.


Zum Glück, kann man den Bug (wie du beschrieben hast) einfach umgehen, wenn man das Autowertfeld zum PK macht. (Zum Verknüpfen kann man trotzdem die anderen Felder aus dem Unique Key verwenden.)

mfg
Josef

 

Die Tabelle wurde manuell angelegt.

Folgendes habe ich noch mal getestet:
- Neue Tabelle manuell angelegt mit den 4 Feldern (ohne Format-Eigenschaft)
- PrimaryKey wie gehabt gesetzt
- Über eine Anfüge abfrage die werte angefügt

Gleiches Verhalten, nach dem komprimieren wird die Nummer 4401 vergeben.

Auffallend ist, die neue Nummer 4401 ist exakt die folgendenummer von der Nummer die angezeigt wird, wenn man zum letzten Datensatz in der Datenblattansicht geht.

Gebe ich in einer leeren tabelle Zahlen ein, dann ist kein fehler.
Mit 100 Datensätze auch kein Fehler.
Mit 2000 Datensätze ist der Fehler wieder da.

Man müsste jetzt noch mehr tests machen, primarykey nur auf 2 felder usw... aber das sollte jetzt der job von Microsoft sein ;-)

Fakt ist, der Fehler ist reproduzierbar mit diesen Datenmengen. Das Dateiformat accdb/mdb spielt dabei gar keine ROlle. Es hat also was mit der Komprimierfkt in Acc2010 zu tun.

Bem.: Dies ist ein Problem aus der Praxis, bei einem Kunden von mir, wurden plötzlich bestehende ID's vergeben, nach dem ich die DB komprimiert habe.

 

It's not a bug, it's a feature! *biggrin.gif*
Das ist sogar extra ein Tipp bei donkarl, wie man den Autowert zurücksetzen kann.

 

Hallo!

@Toast78: Es geht nicht um die Möglichkeit, dass man den Autowert neu einstellen kann und es dann zu doppelten Werten kommt. (Das wäre nämlich wirklich kein Fehler sondern ein erwartetes Verhalten.)

JPA meint das Verhalten, bei dem man unter Access 2010 eine Tabelle befüllt, deren Autowertfeld nicht das PK-Feld ist. Dann kommt es nach dem Komprimieren zu doppelten Autowerten, wenn neu eingefügte PK-Werte nicht den Max-Werten entsprechen.

Im Anhang ist eine Test-Klasse (AccUnit). Falls jemand AccUnit im Einsatz hat, bitte einmal ausprobieren, ob das in den Test-Rows beschriebene Verhalten nachstellbar ist.

/edit:
Link zum Thema: http://msmvps.com/blogs/access/archi...escending.aspx

mfg
Josef

 

\@Josef
Vielen dank für die Rückmeldung und unterstützung. Sehr interessant, bin wohl nicht der einzige der dem das aufgefallen ist. Das beruhigt mich :-)

2 Stunden fehlersuche im Projekt, wenn man diesen bug nicht kennt :-(

 

Hallo Jean Pierre,

ich habe das Beispiel aus Deinem Blog nachvollzogen. Bei mir kommt es dabei nicht zum Problem:

- Ich habe die Datenbank heruntergeladen und geöffnet
- Dann habe ich einen weiteren Datensatz in die Tabelle eingefügt.
- Dieser bekam die ID 6224.
- Als nächstes habe ich die Datenbank komprimiert.
- Danach habe ich einen weiteren Datensatz eingefügt.
- Dieser bekam die ID 6225.

Ich verwende Access 2010, SP1. Das Beispiel habe ich jetzt 2 mal mit Deiner Datenbank nachvollzogen. Bisher kam es nicht zum von Dir festgestellten Fehler.

CU

 

Hallo Josef,

ich habe Deinen Testcode importiert und die Tests laufen lassen. Die Tests 7 und 10 werden nicht bestanden.

CU