Suboptimal ist in diesem Zusammenhang sehr freundlich, bei uns galt das immer als Synonym für ein absolutes NoGo. Und das ist es hier in diesem Falle auch.
Was die Datenbankschnittstelle zusätzlich zum eigentlichen Insert noch so an Statements absetzt, ist eher irrelevant. Soweit ich das bisher in meiner Programmierpraxis mit
ADO feststellen konnte, erfährt ein TDataSet nichts von den von der Datenbank erzeugten Schlüssel, bis man die Daten neu von der Datenbank abfragt.
Interesant wäre es mal zu wissen, wie die Einstellungen der Datenbankverbindung bzw. der DataSet-Komponente sind.
Was steht z. B. in CacheSize, CursorLocation, CursorType, ExecuteOptions, LockType, ...? (Nach Herstellung der Datenbankverbindung.)
Änderungen an diesen Eigenschaften können zu massiv unterschiedlichem Verhalten führen und haben, je nach Datenbanktyp, sehr unterschiedliche Konsequenzen auf das Laufzeitverhalten von Programmen.
Der hier vorliegende Fehler tritt immer auf, wenn in der Datenbank noch "selbstständig" Werte vergeben werden (Trigger, Sequenzen, AutoInc ...)
Ein Abfolge von Append, Post, Edit, Post ... funktioniert nur dann, wenn immer alle Inhalte der Datensätze in der Datenbank und im DataSet identisch sind (also fast nie in Client/Serverumgebungen
)
Wenn es zwingend erforderlich ist (warum auch immer) bei Insert und Post zu bleiben, dann versuche mal, ob ein sofort auf das Post folgendes Refresh das Problem löst. Das DataSet wird dadurch gezwungen, die Daten erneut von der Datenbank abzufragen, man muss den Datensatzzeiger aber neu auf dem zu verarbeitenden Datensatz positionieren.
Allerdings:
Es wird immer die gesamte Datenmenge neu geladen, die Funktion ist stark von der Einstellung der oben genannten Eigenschaften abhängig und erhöht ggfls. die Laufzeit (datenmengenabhängig) massiv.
Zitat:
Da diese Dataset mit keinerlei Filtern oder Ereignissen verknüpft sein wird, ist ja wohl sichergsetellt, dass der Datensatz nach dem Post derselbe ist wie der, der gepostet wurde.
Darauf würde ich nicht wetten, wenn z. B. ein Index gesetzt ist, kann sich beim Post die Position im TDataSet verändern, ob der Cursor entsprechend "mitwandert" oder auf dem Satz steht, der sich nun an der (ehemaligen) Position des Satzes befindet, müsste man mal überprüfen (z. B. Eigenschaften IndexFieldNames, IndexName bei TAdoTable).
Hier hat die Eigenschaft CursorLocation ggfls. Auswirkungen. Prüf' hier bitte mal, ob eine Änderung von clUseClient nach clUseServer, bzw. umgekehrt, je nach aktuellem Zustand, zu einem veränderten Verhalten führt.