Hallo...

ich bin mit meinem Latein am Ende.

Gegeben:
- Tabelle mit "ID" als Autoinc. (PK) (der Rest ist eher uninteressant)
- gewachsenes Programm was so mit anderen DBMS gut funktioniert

IST:
1. TADOTable
2. Tabelle ist leer

markieren

Delphi-Quellcode:

Table.Append;
Table... füllen (außer ID logischerweise)
Table.Post;
Table.Refresh; // hier knallts mit Fehler... sinngemäß "Datensatz wurde geändert oder gelöscht. Die aktuelle Zeile wird gelöscht"

...eigentlich sollte das Post ja die Tabelle aktualisieren. Ich vermute, daß das bei ADO nicht funktioniert. Da auf dem Server die ID existiert und in der Datenmenge nicht und er den PK nicht zuordnen kann. An diversen Stellen konnte ich durch ein Open/Close einen Workaround hinbiegen. An anderen Stellen, wo die ID, nach dem Post, weiterverarbeitet wird geht das nicht, da der Datensatzzeiger dann auf dem ersten steht und nicht auf dem letzten Eingefügten.

Erledigt:
Dann habe ich testweise das DBFramework auf SDAC umgerüstet... keinerlei Fehler ! Leider kann ich die Entscheidung nicht selbst treffen.
Versuche mit den Properties der Connection und der ADOTable... ohne Erfolg.

Bitte:
Welche Tricks verhindern diese bescheuerten Meldungen.

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.

markieren

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

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

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.

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:

markieren

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.

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

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

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...

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.