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