Hi marabu, hi Frank,
Vielleicht hilft es, wenn man weiss, wieso diese Meldung zustande kommt. Ich habe folgende Erfahrung gemacht:
Wenn man eine DML-Operation ausführt (also UPDATE, INSERT, DELETE) dann erwartet
ADO, das die
MSDE folgende Meldung zurückgibt:
"(1 row(s) affected)", also, das genau die Zeile verändert wurde. Wenn das nicht passiert, kommt
ADO ganz schön durcheinander.
Bei mir ist das passiert, weil ein Trigger in der Datenbank in einer anderen Tabelle einige Daten verändert hat. Da ich im Trigger kein 'SET NOCOUNT ON' an erster Stelle geschrieben habe, meldet die
MSDE(Bei z.B. UPDATE FooBar SET Bla='X' Where ID = 1) :
Zitat von
MSDE:
(0 rows affected) <-- vom Trigger
(1 rows affected) <-- von der Datenbankoperation
ADO bekommt zwar beide Meldungen mit, interpretiert aber die 1.Meldung als Antwort auf die Datenbankoperaton. Und ist nun völlig durcheinander. Schließlich hat es einen Befehl abgesetzt, der nur eine Zeile verändern soll. Wenn dann die Meldung kommt, das Nichts verändert wurde, geht
ADO davon aus, das die Zeile doch nicht verändert wurde. Das liegt dann (denkt
ADO) eben daran, das "die zum Aktualisieren angegebene Zeile" nicht gefunden wurde.
Nach meiner Einschätzung liegt das
a) an so einem gemeinen Trigger, der ohne 'SET NOCOUNT ON' progrmamiert wurde.
b) an einer 'Upateable View', die nicht genau die Meldung erzeugt '(1 row(s) affected)'.
c) wirklich daran, das das zu aktualisierende Record so nicht mehr funktioniert
Zu c) fällt mir noch etwas ein: Wenn Du eine TADOTable verwendest, dann erzeugt
ADO beim UPDATE einen ziemlich bescheuerten Befehl
ie Tabelle TBL enthält 3 Spalten (ID,B und C, Primary Key sei ID). Das Update sieht nun so aus:
UPDATE TBL SET B='Foo' WHERE ID=0 AND B='Old Value' AND C=12345
Wenn nun jemand gerade diese Zeile verändert hat (z.B. C=11111), dann klappt o.g. Statement einfach nicht mehr. Dann kommt nämlich zurück "(0 rows affected)" und DAS widerum erwartet
ADO nicht und spuckt die verhaßte Meldung aus.
Besser wäre doch soetwas:
UPDATE TBL SET B='Foo' WHERE ID=0
Dann kann auch jemand Anderes die Zeile verändern (gut, Löschen geht nicht).
Die berühmte Fehlermeldung habe ich im Zusammenhang mit dem TADOTable-Beispiel auch sporadisch bei einer Einzelplatzanwendung erlebt, und bisher kein Mittel dagegen gefunden. Außer, ich mache alle DML selbst, bastle mir also die UPDATE, INSERT und DELETE-Befehle selbst.
Vielleicht helfen meine Erfahrungen mit dieser S****-Meldung ja weiter
Schönes Wochenende!