Tabelle mit "ID" als Autoinc. (PK) (der Rest ist eher uninteressant)
Man sollte keine AutoInc-Felder verwenden, wenn man den Wert für weitere Verarbeitung noch benötigt!
Zunächst muss man sich mal klarmachen, dass Tabellen ohne Primärschlüsselfeld nicht sicher sind, weil man einen bestimmten Datensatz nur über das eindeutige PK-Feld ändern oder löschen kann.
Code:
Farbe | Hersteller
blau | VW
silber | BMW
blau | VW
grau | Daimler
In der Beispieltabelle gibt es 2 gleiche Datensätze.
Mit
SQL gibt es keine Möglichkeit (!) nur einen dieser beiden Datensätze zu verändern oder nur einen davon zu löschen!
Schlussfolgerung
Tabellen ohne Primärschlüssel sind als "defekt" zu betrachten.
Bei einer Tabelle mit einem AutoInc-Feld als PK entsteht ein Problem:
Wenn mehrere Prozess in die gleiche Tabelle Datensätze einfügen,
wie kann dann ein Prozess herausfinden welcher Datensatz von ihm ist?
Da der Primärschlüssel das einzige sichere Erkennungsmerkmal für einen Datensatz ist, der Prozess aber den PK nicht kennt ist es mathematisch für einen Prozess unmöglich seinen gerade geschriebenen Datensatz wiederzuerkennen.
Schlussfolgerung
Autoinc-Felder darf man nur einsetzen wenn man den PK eines gerade eingefügten Datensatzes nicht benötigt.
Sobald aber der PK in einen anderen Tabelle als Fremdschlüssel benötigt wird ergeben sich Probleme.
Nur weil SDAC keinen Fehler erzeugt bedeutet das nicht, dass alles in Ordnung ist.
Mögliche Auswege:
Beim
SQL Server kann man z.B. die Abfrage SELECT @@Identity ausführen um den zuletzt eingefügten PK zu erhalten.
Manchmal muss man etwas nachhelfen und das Property TField.AutoGenerateValue im Code einstellen
http://docs.embarcadero.com/products...rateValue.html