Der SQL-Server kann's schon lange, und mit ADO.NET kann man
@@Identity nun auch mit Access (OLEDB) verwenden. Am häufigsten wird
man in diese Verlegenheit kommen, wenn man nach einem Insert den
Primary-Key des letzten Datensatzes haben möchte.
Mit dem alten ADO ging das relativ easy via "rs.AddNew", "rs.Update"
und "id = rs("pmkey")" - damit hatte man zu 100% die ID des neuen
Datensatzes, den man via AddNew hinzugefügt hat.
Doch ist das auch bei einem @@Identity der Fall? Nein! Denn egal wie
man den Befehl einsetzt, in hundertprozentige Relation zum neuesten
Datensatz wird man ihn nie kriegen.
Im Klartext: @@Identity holt zwar immer die ID des aktuell letzten
Records, der muss aber nicht der z.B. eben hinzugefügte sein. Das ist
zwar bei den meisten Applikationen relativ unwahrscheinlich, aber die
theroretische Möglichkeit, dass jemand quasi "gleichzeitig" ein Insert
ausgeführt hat, sollte Bauchschmerzen bereiten - denn dann kann es
durchaus sein, dass eben jener fremde Datensatz dazwischenrutscht und
@@Identity so ein falsches Resultat liefert.
Die Lösung: aktuell ist es wohl die vernünftigste Lösung, wenn man
als Primary-Key ein Feld vom Typ GUID (in Access: "Replikations-ID")
verwendet, und dieses mit selbst generierten GUID's füttert. Das heißt
man generiert eine GUID und fügt diese beim Insert manuell mit hinzu -
und verzichtet so auf ein Feld z.B. vom Typ Autowert in Access.
