row cannot be located for update... wenn eine View benutzt wird

[seb83]

Ich habe die Anbindung eines DBGrids auf eine andere View ändern müssen, da hier ein Union gebraucht wurde.
Diese View wurde mit View_Metadata erstellt und hat Instead of Trigger für alle Operationen.

Problem ist das manchmal nun bei ganz einfach Sachen, wie einen Feld ändern und dann Post, ich die Fehlermeldung "row cannot be located for update..." bekomme.
Query.Properties['Update Criteria'].value :...; Hab hier schon alle Versionen mal probiert um BeforePost, aber hat nichts geholfen.
Nehme ich die alte View ohne das alles gehts problemlos.
Was kann ich tun?

[Bernhard Geyer]

Mit

UNION

wird das nicht gehen.
Woher soll der SQL Server wissen in welche UNION-Teil er das Update machen soll.
Der Server wird sich nicht gemerkt haben welche Zeile von welchen Teil-Query kommt.

[seb83]

Die Zeilen, die durch Union kommen, werden nie geändert, die sind nur "readonly", es klappt alles bis auf manche Situation, wo der oben genannte Fehler kommt.
Erkenne nur keine Logik dahinter, warum es meistens geht und dann wieder nicht. Und für das echte Update ist ja der INSTEAD OF Trigger da.

[himitsu]

man könnte in die SELECTSs der UNION eine Spalte aufnehmen, wo man die Quelle reinschreibt
und dann wird ein UPDATE-Statement geschrieben, was je nach Quelle (im WHERE geprüft) in die richtige Tabelle schreibt.

Oder man schaut, ob sich das Problem mit einem Updatable-View lösen lässt.

[seb83]

Die View ist ja ansich durch die Trigger updatebar, was auch zu 98% der Fälle funktioniert. Nur manchmal eben nicht.

[jobo]

Woher weiß denn der User, das Programm, der Instead Of Trigger, wann um die 98% geht und wann nicht?
Vielleicht ist der Instead Of Trigger nicht 100% korrekt?

Ich würde sowas eher mit SP machen. Dann kannst Du die wildesten Views bauen, brauchst keine Trigger, nur eine (einzige) Update SP.
Und wenn Du es schön machen willst, vielleicht noch eine Prüffunktion, die vorhersagen kann, ob der Datensatz updateble ist (sprich editierbar).

[seb83]

Zitat von jobo:

Woher weiß denn der User, das Programm, der Instead Of Trigger, wann um die 98% geht und wann nicht?
Vielleicht ist der Instead Of Trigger nicht 100% korrekt?

Ich würde sowas eher mit SP machen. Dann kannst Du die wildesten Views bauen, brauchst keine Trigger, nur eine (einzige) Update SP.
Und wenn Du es schön machen willst, vielleicht noch eine Prüffunktion, die vorhersagen kann, ob der Datensatz updateble ist (sprich editierbar).

Wie kann ich den ein Grid an eine SP binden mit ADO?

[jobo]

Zitat von seb83:

Wie kann ich den ein Grid an eine SP binden mit ADO?

An ein Grid würdest Du gar nicht binden, wenn dann das Dataset, an dem das Grid (Datasource) hängt.
Du könntest eine TADOQueury nehmen und ein Update Statement abschicken.
Das machst Du im BeforePost vom TDataset und danach brichst Du das Post ab (dataset.cancel oder Abort).
Die TADOQuery mit dem Update Statement kannst Du als reines Update machen oder eine SP aufrufen, die irgendwelche Logik abarbeitet, falls notwendig.
Das Updatestatemen (oder die SP) gehen natürlich nur auf den "echten" Tabellenteil "diesseits" des Union.

Der Mechanismus vermeidet an sich erstmal keine unlogischen Aufrufe (update auf Union Daten, die nicht aktualsierbar sind). Geschieht dies wirklich, -es ist ja offenbar nicht klar, wann- kann es aber in der SP alles abgefangen werden. Wenn die SP Logik in Zustände kommt, die nicht erwünscht sind, sollte ein Fehler geworfen werden und vielleicht ein Log mit Detailangaben geschrieben werden.