TAdoQuery Row cannot be located .. bei post

[jobo]

Das ist mir nicht aufgefallen. Da nähern wir uns der Sache wohl!
Dem Append dürfte der PK wohl auch egal sein, solange nicht mehr als einmal editiert wird.
Aber das ist hier der Fall.
@peinlich:
Geht mir auch manchmal so, im Eifer des Gefechts.. es war ja eigentlich klar worum es Dir ging, also mir jedenfalls.

[norwegen60]

Vielen Dank für die Tips und dazu mein Feedback

• Ja, die Tabelle hat einen Primarykey
• Das Verhalten ändert sich nicht ob ich Insert oder Append verwende. Ich glaube nicht, dass Dataset hier überhaupt einen Unterschied macht. In beiden Fällen liefert DataSet.State = dsInsert und schau ich mir im MsSQL-Profiler an, was dort geschieht, sehe ich beide male
  Code:

  exec sp_executesql N'SET NOCOUNT OFF; INSERT INTO "TestDB".."analysis" ("Bezeichnung") VALUES (@P1); SELECT SCOPE_IDENTITY() AS SCOPE_ID_COLUMN',N'@P1 nvarchar(6)',N'Insert'

  (Diese Beispiel stimmt nicht mit der Datenstruktur oben überein, sondern war nur kurzer Test)
• DataSet hat einen Filter. Der ist so gesetzt, dass er nur die Daten der aktuellen Workstation anzeigt. Der neue Datensatz erfüllt diese Bedingung. Ich selber verwende nie Filter sondern filtere immer schon im SQL mit where. Ich werden den Filter eliminieren, auch wenn er keine Rolle spielen sollte.
• Ich habe alle Post - Edit entfernt. Ganz zum Schluss brauch ich dann aber doch eines, da in bestimmten Fällen, die erzeugte PK in eine Feld geschrieben wird. Das funktioniert jetzt zwar, aber da ich auch nicht sicher weiß warum die Exception auftritt, bin ich auch nicht sicher, ob ich in jedem Fall die korrekte PK zurück bekomme.
• Es gibt keine weiteren Ereignishandler in DataSet oder DataSource. Ich suche aber noch, ob vieleleicht auf einem der Editfelder was passiert.

Ich werde den kompletten Insert in eine eigenes Dataset legen, würde aber gern bei Insert - Post bleiben. Per SQL ist mir im Moment der Aufwand zu groß um eines für Insert und eines für Update mit den XX-Feldern zu schreiben. 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.

Welche Möglichkeiten gäbe es denn sonst noch um sicherzustellen, dass man nach dem Post auf dem korrekten Datansatz steht? Bei den Daten, die ich selber mit

Code:

  Insert Into..
 // hängt immer ein
 select SCOPE_IDENTITY() as ID');
 // Dran um die erzeugte ID zurück zu bekommen.

Gibt es sowas bei Post auch?

Mein Problem im vorliegenden Fall: Außer der PK, die ja erst beim Post erzeugt wird, habe ich keine eindeutigen Suchkey. Wenn, dann am ehesten das CreatDate. Da bin ich mir aber nicht sicher ob das immer funktioniert. Ich hatte mit MsSQL bei Realzahlen schon das Problem, dass die Originalzahl und die in der DB gespeicherte Zahl in den letzten Bits nicht übereingestimmt haben, ein Vergleich

Code:

Where rOriginal = Feld.Value

also fehlschlug.

[TigerLilly]

Ah, dein PK wird vom Server erzeugt!
1) Schau doch mal mit dem Profiler nach, welche where Klausel beim Post erzeugt wird.
2) Schau dir mal an, welche UpdateOptions bei den Felddefinitionen gesetzt sind.

Das Insert/Post funktioniert. Dabei ändert aber der Server den PK, was ja auch so gewollt ist. Bei deinem nachfolgenden Edit/Post sind die Daten in deinem Dataset + in der DB aber deshalb nicht mehr ident. Siehe auch:
http://docwiki.embarcadero.com/Libra...oGenerateValue

[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