Hallo,
mir scheint die Routine so korrekt zu sein.
Eventuell fragst Du mal vor dem Finally den Wert von RowsAffected ab, hier sollte stehen, wieviele Sätze betroffen wurden.
Ist RowsAffected <> 1, ist irgendwas schiefgegangen.
Versuche dann einfach das Ergebnis des
SQL's satzweise in eine Textdatei zu schreiben und Dir diese als Fehlerhinweis zukommen zu lassen oder wieauchimmer die Fehler weitergegeben werden.
Vielleicht kannst Du aber auch vor dem "edit" mal RecordCount abfragen, ist der <> 1 wurde zuviel oder zu wenig gefunden und dann die Ergebnismenge in einer für Dich verwertbarer Form ausgeben.
Wahrscheinlich sind in der Datenbank irgendwelche Daten etwas anders als erwartet.
Oder könnte es in extremen Fällen passieren, dass FsTripID leer ist?
Appropopopo: Was passiert, wenn FsTripID einen Wert einhält, den es in der Datenbank nicht (mehr) gibt?
Können die Benutzer die Daten gleichzeitig ändern, ist die ID änderbar?
Nach meiner Erfahrung stehen RowsAffected und RecordCount nicht bei allen Datenbanken zur Verfügung, so dass der Wert 0 für eines oder beide Attribute nicht unbedingt ein Fehler sein muss. Hier hilft leider nur Try and Error.
Der Ansatz mit dem Deaktivieren ist auch nicht verkehrt, hab' da mal ein Programm gehabt, bei dem es eine Anwenderin schaffte, sich quasi permanent selbst zu überholen, sie hat die Daten derart schnell erfasst und diverse andere Teile des Programmes bedient, so dass man an der Oberfläche sehen konnte, wie die ganze Aktuallisiererei hinterher hinkte.
Stephan