TAdoQuery Row cannot be located .. bei post

[Bernhard Geyer]

Delphi-Quellcode:

  try
    Table1.Post;
  except
  end;

Kann man den Entwickler für dieses Konstrukt noch zur Rechenschaft ziehen?
Ein stilles verschlucken von Fehlermeldungen an dieser Stelle ist - sagen wir mal so - suboptimal.
Ich glaube nicht das die Anwendung vernünftig weiter arbeiten kann wenn beim Speichern in der DB ein Fehler auftritt.

[nahpets]

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.

[norwegen60]

Zitat von Bernhard Geyer:

Delphi-Quellcode:

  try
    Table1.Post;
  except
  end;

Kann man den Entwickler für dieses Konstrukt noch zur Rechenschaft ziehen?
Ein stilles verschlucken von Fehlermeldungen an dieser Stelle ist - sagen wir mal so - suboptimal.
Ich glaube nicht das die Anwendung vernünftig weiter arbeiten kann wenn beim Speichern in der DB ein Fehler auftritt.

Absolut einig. Der Entwickler zeigt sich auch einsichtig. Das hilft aber nicht wirklich, da das was er in 15 Jahren programmiert hat, so ist wie es ist.
Durch das Hinterfragen der ein oder anderen Technik ist uns heute auch klar, warum es hin und wieder Fehlermeldungen aus dem Feld gibt, wo irgendwelche Daten unvollständig, oder noch schlimmer, einem anderen Datensatz zugeordnet wurden. Mittlerweile wundert es uns, dass solche Fehler nicht viel häufiger vorkommen.
Von daher ist es keine Frage, dass das komplett aufgeräumt werden muss. Nur bei all dem, was da sonst so drum rum programmiert wurde, ist das nichts was man mal in ein paar Stunden macht. Deshalb suche ich jetzt nach dem Quick&Dirty-Weg, der zumindest sicherstellt, dass ich nach dem Post auch noch auf dem richtigen Datensatz stehe. Ich kenne die TAdo nicht sehr gut da ich mit UniDac gearbeitet habe. Verlasse mich dort nach einem Post aber meist auch darauf, dass sich die Position nicht ändert.

Die Dataset-Einstellungen sind weitgehend Standard:
AutoCalcFields = true, CahceSize = 1, CommandoType = cmdText, CursorLocation = clUserClient, CursorType = ctKeyset, EnableBCD = False, IndexFieldNames = NULL, LockType = ltOptimistic, MarshalOptions = moMarshalAll, ParamCheck = False, Prepared = False, StoreDefs = False
Datenbank ist wie gesagt MsSQL 2008R2 und 2014

In diesem speziellen Fall sollten die Daten immer identisch sein, da jede Workstation nur seine Daten ändern kann. Auch wenn das eine Einschränkug ist, die eher stört.

Zitat von nahpets:

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.

Genau das wollte ich ja machen, suche aber noch nach optimalen Weg, wie ich sicher wieder auf den Datensatz zurück komme, den ich bearbeitet habe. Beim Insert habe ich noch keinen eindeutigen Key.

Ein Anstatz wäre, den Satz per

Zitat:

Insert Into..
select SCOPE_IDENTITY() as ID');

anzulegen. Dann hätte ich den PK und könnte den Rest weiter per Dataset und Locate... abhandeln. Wirklich toll finde ich die Lösung allerdings nicht. Aber in mind. einen sauren Apfel muss ich wohl beißen.

Auf jeden Fall haben mir eure Tips noch den ein oder anderen Gesichtspunkt genannt, an den ich noch nicht gedacht habe.

[hoika]

Hallo,
schau mal hier

https://stackoverflow.com/questions/...dodb-recordset