ADO Guru gesucht

[sx2008]

Zitat von haentschman:

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

[Uwe Raabe]

Zitat von sx2008:

Mögliche Auswege:
Beim SQL Server kann man z.B. die Abfrage SELECT @@Identity ausführen um den zuletzt eingefügten PK zu erhalten.

Alternativ kann man auch die OUTPUT-Klausel verwenden:http://msdn.microsoft.com/de-de/libr...CaptureResults

[Bernhard Geyer]

Zitat von sx2008:

Mögliche Auswege:
Beim SQL Server kann man z.B. die Abfrage SELECT @@Identity ausführen um den zuletzt eingefügten PK zu erhalten.

Die Abfrage von @@Identity ist nicht sicher wenn man mit Replikationen arbeitet. Wird auch in der MSDN beschrieben was man machen muss um Replikationssicher zu werden.

[haentschman]

Guten Morgen...

...danke für eure Anteilnahme. Die Autoinc ID ist auch primary Key. Ich dachte bisher immer, daß eine Table den Inhalt der Datenbanktabelle repräsentiert. (incl. des Autoinc nach dem Post). Das scheint bei ADO nicht so zu sein.
Leider bin ich auf die Tables festgelegt, ob mir das gefällt oder nicht.
Noch ein Beispiel was in anderen DBMS funktioniert:

Delphi-Quellcode:

Table.Append;
Table.Post; // um die ID zu kriegen ... die Table sollte dann aktuell sein, normalerweise.
Table.Edit; // dann knallts hier...
Table... füllen (außer ID logischerweise)

... ich würde lieber heute als morgen diesen Kram über Bord werfen... leider wäre dafür der Aufwand zu hoch.

[Uwe Raabe]

Wenn der ID ein AutoIncrement und als aktiver Index eingestellt ist, müsstest du nach dem Post mit einem Refresh; Last; zum Ziel kommen.

[grl]

Zitat von Uwe Raabe:

Wenn der ID ein AutoIncrement und als aktiver Index eingestellt ist, müsstest du nach dem Post mit einem Refresh; Last; zum Ziel kommen.

Also, das würd ich nicht tun - wie stellst du denn da sicher, daß das DEIN letzter Eintrag ist und nicht der vom zeitgleich postenden Nachbarn?

GRL

[p80286]

bei Oracle geht das, da wird jede ID nur einmal generiert, da wird sie allerdings Tabellenunabhängig, zentral erzeugt. (nextval)

[haentschman]

Hallo...

Zitat:

Ich würde es mal mit der Eigenschaft 'AutoGenerateValue' des persistenten Feldes versuchen. Für das Identity-Feld sollte dieser Wert auf 'arAutoInc' stehen (leider macht das ADO bzw. Delphi nicht von alleine, wenn man die Felder einliest).

...führte nur halb zum Teilziel. AutoGenerateValue funktioniert nur mit persistenten Feldern und kann nicht zur Laufzeit gesetzt werden. TField.FieldType hat auch ftAutoInc. Den dann auf das ID Feld gesetzt und es sind die ID´s nach dem Post in der Tabelle

Soweit so gut...

Delphi-Quellcode:

Table.Append;
Table.Post; // um die ID zu kriegen ...hier ist die ID auch nun da
Table.Edit;
Table... füllen (außer ID logischerweise) 
Table.Post; // --> Fehler: "Der Schlüsselwert für diese Zeile wurde in der Datenquelle geändert oder gelöscht. Die lokale Zeile ist nun gelöscht "

...Die ID ist vor dem Post exakt identisch wie vor dem Edit. Es werden nur andere Felder befüllt.

Ein Workaround der durchläuft:

Delphi-Quellcode:

Table.Append;
Table.Post; // um die ID zu kriegen ...hier ist die ID auch nun da

LastID:= Table.FieldByName('ID').AsInteger; // ID merken
Table.Close;
Table.Open;
Table.Locate('ID',LastID,[]); 

Table.Edit;
Table... füllen / ändern (außer ID logischerweise) 
Table.Post;

Wenn das mit dem AutoInc zu tun hat futtere ich nen Besen.
Verzweiflung, weil ich mich quälen muß.

Zitat:

Irgendwie ist mein Beitrag noch nicht richtig angekommen.

Zitat:

Tja, meiner auch nicht.

... meint ihr ich ignoriere Euch ? Im Gegenteil.

Die Frage ist doch, warum ADO so mit den AutoInc umgeht und andere Zugriffskomponenten das anders handlen. Und ein Edit + Post ist ja das normalste der Welt... nur bei ADO nicht.

Nochmal:
Ich kann weder auf Querys ausweichen noch sonst irgendwas. Ich muß mit dem Append, Post, Edit leben ! Wenn es nach mir ging wäre ADO schon von Anfang an weg gewesen. Das ADO seine Eigenheiten hat ist ja hinlänglich bekannt.

Danke an alle die sich einen Kopf machen.

[jobo]

Das Prinzip sollte schon auch unter ADO funktionieren, selbst wenn es die bereits genannten Probleme gibt. Zumindest tut es das bei mir unter Oracle. Hier wird zwar mit Trigger/Sequence der PK generiert, aber das sollte clientseitig egal sein.
Ich würde mal klären, welche Versionen du für ADO > MDAC und in Delphi verwendest.
Die MDAC Version ist je nach Systemaufbau ein Zufallsprodukt der Office Version, unter Delphi gab es immer wieder auch Updates zu ADO.
TADOTable bietet leider auch den geringsten Spielraum. Per Query kannst Du die explizite Rückgabe des PK anfordern und und und...

[Bernhard Geyer]

Zitat von jobo:

Die MDAC Version ist je nach Systemaufbau ein Zufallsprodukt der Office Version, ...

MDAC nicht. Das wird ganz normal per Windows-Update verteilt. Was du meinst ist die JET-Engine. Diese ist aber schon seit Jahren kein Bestandteil von MDAC mehr.
MDAC ist mittlerweile praktisch nur noch zur Verteilung des ADO/OLEDB, Native Clients für den MS SQL-Server zuständig.