TAdoQuery Row cannot be located .. bei post

[p80286]

Zitat von nahpets:

Die Chance, dass das vorhanden Konstrukt nicht dauerhaft sicher und fehlerfrei "hinzubekommen" ist, ist sehr groß.

Etwas weniger diplomatisch ausgedrückt, wer die Daten einer Tabelle ohne eindeutige Identifizierung der Datensätze (PrimaryKey) bearbeitet und sich auf Nebeneffekte verläßt (z.B Sortierung) der handelt verantwortungslos.

Gruß
K-H

[jobo]

Also ich weiß nicht ob es hilfreich ist, dataset Befehle und SQL Queries in den Hinweisen zu vermischen.
Ein SQL Befehl ist vollkommen transparent, er braucht auch keinen PK. Alle Datensätze, die laut Where Bedingung betroffen sind, werden aktualisiert, analog bei Delete. Da ist sogar eine Sortierung egal, sie kann nicht mal angegeben werden.

Die Frage ist doch, wie ein Append im Dataset gegen eine spezifische DB implementiert ist und wie mglw gesetzte Eigenschaften des Datasets wie bspw. Filter, Sort ... da reinspielen. Und: Da append nicht insert ist, ein anhängen aber sehr wohl was anderes als ein insert, spielt hier schon eine Reihenfolge eine Rolle und eben die Frage, ob überhaupt ein PK definiert ist.

Dann gibt es noch Verfahren, die beim Update eine where Clause aus den alten Feldwerten bauen, um zu vermeiden, dass Daten aktualisert werden, die zwischenzeitlich verändert wurden. Das würde wohl direkt zu einer solchen Fehlermeldung führen.

Um das zu prüfen, müsste man mal die Post Events durchschauen und ob da noch irgendwelche anderen Komponenten verdrahtet sind.

[p80286]

Natürlich hast Du recht, mir ging es nur darum einen Datensatz eindeutig zu identifizieren. damit man alle Änderungen mit diesem Datensatz durchführen kann. Ein beliebter Fehler ist ja das Prinzip
Hole Datenmenge where Datum = 01.01.2001
ändere in Datenmenge Datum in 02.01.2001
Hole Datenmenge where Datum = 01.01.2001
ändere in Datenmenge Betrag in 0,01 ===> keine Datensätze verfügbar!

Gruß
K-H

[nahpets]

Was mir gerade noch einfällt:

Im Ausgangspost wird zuerst ein Append gemacht, Werte vergeben gespeichert. Dann der Satz wieder editiert und gespeichert.

Bei Append und anschließenden Post sind im Dataset in der Regel die technischen Schlüssel der Datenbank, die per Trigger, Sequence, AutoInc ... von der Datenbank vergeben werden nicht bekannt. Auch hier tritt der genannte Fehler auf.

Datenbank und Dataset können sich quasi nicht darauf einigen, welcher Datensatz zu ändern ist, da sie nicht gegenseitig über alle zur Identifizierung benötigten Informationen verfügen.

Erste Lösungsmöglichkeit wäre, die "zwischengeschobenen" Edits und Post zu entfernen.

Delphi-Quellcode:

Table1.Append;
  Table1['Field1'] := 'Wert1';
  Table1['Field2'] := 'Wert2';
  Table1['Field3'] := 'Wert3';
  Table1['Field4'] := 'Wert4';
  Table1['Field5'] := 'Wert5';
  Table1['Field6'] := 'Wert6';
  usw.... 
  // Erst dann, wenn alle Werte vergeben wurden.
  try
    Table1.Post;
  except
  end;

Eine Änderung des Datensatzes ist erst möglich, wenn er aus der Datenbank gelesen wurde, z. B. Table1.Refresh und Positionierung auf dem Satz.

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