TAdoQuery Row cannot be located .. bei post

[norwegen60]

Zitat von Aviator:

Ist das wirklich der komplette Auszug? Oder fehlt da noch was zwischen dem Table1.Edit und dem Table1['Field5'] := 'Wert5'; ? Weil so sollte das eigentlich funktionieren.

Auf der anderen Seite könntest du auch sagen, dass du seinen SourceCode optimierst und dann auch die Felder gleich vor dem ersten Post (be)schreibst. Macht ja nur Sinn und beschleunigt das Programm auch etwas. Ich würde solche Stellen direkt überarbeiten wenn ich mir sicher bin, dass das Programm danach genau gleich oder sogar besser/effizienter arbeitet.

Ja, das ist alles. Im Except wird noch in ein Log geschrieben, aber sonst ist es alles. Was fehlt denn noch? Der wollte einfach immer wieder Zwischenspeichern (Auch wenn es gar kein Sinn macht, wenn der Datensatz unvollständig ist)

Durch das Optimieren bin ich da ja drauf gestoßen. Aber die Zuweisungen ziehen sich über 1000 Zeilen, also nicht mal so auf dei Schnelle optimiert, auch wenn eine Überarbeitung dringenst nötig wäre. Der Fehler tritt aber schon im zweiten post-Edit Block auf.

[jobo]

Wie sieht es denn mit einem Primary Key auf der Tabelle aus.

[TigerLilly]

Check mal, ob es ev einen Filter gibt, der dafür sorgt, dass nach dem Post ein anderer Datensatz den Fokus hat.
Kontrolliere mal Indices, ob es da welche gibt, die die Sichtbarkeit beeinflussen.

Sind die Zuweisungen wirklich "Wert1" etc?

Die Table ist ja an eine Datenbank gebunden. Welche ist das denn? Kannst du anzeigen lassen, was direkt auf der Datenbank passiert, mit einem Trace oder Profiler?

Bei den Felddefinitionen gibt es die Einstellung, wie die Aktualisierung in der DB durchgeführt werden soll + welche Felder berücksichtigt werden sollen: KeyOnly, WhereChangedOnly etc. Schau mal, ob sich die Felder da unterscheiden.

[nahpets]

Der Fehler ist typisch, wenn man die Ergebnismenge eines SQLs wie eine Tabelle verändert und dabei ein Schlüsselwert geändert wird.
Ebenfalls tritt der Fehler auf, wenn durch eine Änderung mehrere Sätze betroffen sind und man dann später einen bereits geänderten Satz ein weiteres mal ändern will.

Z. B. sowas:select * from tabelle where field1 = :wert1 Wird nun Field1 ein neuer Wert zugewiesen, und ist nicht (zwingend) eindeutig, so kann die Datenbank nicht mehr sicher feststellen, welcher Datensatz geändert werden soll. Dies führt (u. a.) zur vorliegenden Fehlermeldung.
Alternativ könnten hier bei einer Wertzuweisung auf field1 mehrere Sätze geändert werden. Möchte man nun einen so geänderten Satz ändern, ist der genannte Fehler unvermeidlich.

Um hier etwas genauer auf einen möglichen Fehler prüfen zu können, schau bitte mal, ob Table1 ein Attribut RowsAffected (o. ä.) hat. Wenn direkt nach einem Post dort ein Wert > 1 enthalten ist, wurden mehrere Sätze geändert und die Änderung eines dieser Sätze führt im späteren Verlauf zwingend zu dieser Fehlermeldung.

Das vom Programmierer gewählte Vorgehen funktioniert nur dann, wenn in der Auswahl der Daten garantiert ein eindeutiger Schlüssel vorhanden ist und der Schlüssel nicht geändert wird und sichergestellt ist, dass eine Änderung nur einen Satz betrifft.

Es handelt sich hier eher um eine sehr instabile Vorgehensweise.

Um zu schauen, ob das Konstrukt überhaupt sicher aufrecht zu erhalten ist, müsste man mal sehen, wie die Datenauswahl für Table1 aussieht und auch mal des Createstatement der zugrundeliegenden Tabelle "begutachten".

Eventuell ist es aber sinnvoller, sich von dieser Routine (ohne weitere Nachforschung) zu verabschieden und die Änderungen per SQL-Update durchzuführen.

Sofern mit der Table1 keine Datasource und keine Anzeigekomponenten verbunden sind, würd' ich mir hier keine Gedanken machen, sondern die Routine wegwerfen und die Änderungen per Update table set field1 = :Wert1 ... where Schlüsselspalte = :Schlüsselwert machen.

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

[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