Aktualisierungskonflikt bei Schreiben auf SQL-View

25/04/2008 - 16:43 von Christoph Dreßler | Report spam
Hallo,

ich habe sporadisch einen "Aktulisierungskonflikt" beim Schreiben in
einer SQL-View. Ich muss das etwas detaillierter beschreiben.

folgende Kobstellation:
- SQL-View (Lokal oder Remote spielt für das Problem keine Rolle), in
DBC gespeichert.
- Update-Kriterium nur Schlüsselfeler, Modus SQL UPDATE
- Buffermode der FORM Optimistic, View nicht in der Datunumgebung.
- Unterliegede Tabelle rel. groß > 100.000 DS
- Gut parametrisiert, ca 1.000 DS auf Client geladen.
- VFP9SP1, Hardware, Netzwerk BetrSystem sind ohne Einfluss

Problem:
Nach dem Tablerequery(<View>) werden deren Daten in ein temporàres
Format (Cursor) konvertiert, da vom Nutzer interaktiv bearbeitet,
dauert also ein paar Minuten.
Vor dem Rückkonvertieren lösche ich einen Teil der Daten in der View,
und da kommt es zum Aktualierungskonflikt bei diesem Befehl:

DELETE FOR Spalte1 = "ABC"

Warum, ist mir, ein völliges Ràtsel, denn:
- Der Fehler ist sporadisch und selten.
- Die gleichen Bearbeitungsschritte klappen 1 min. spàter.
- Ein Index- oder Netzwerkproblem kann es nicht sein, da das auch bei
Remote-Views auf MS-SQL passiert.
- Durch logische Sperren wird verhindert, dass andere Clients die
Daten bearbeiten können. Es kann also nicht zum klassischen
Konkurrenz-Problem kommen
- Der Fehler tritt bei dem DELETE auf, nicht beim TableUpdate().

Frage:
Könnten Zugriffsprobleme auf den DBC sowas zur Folge haben?
Wenn man FILEMON auf den DBC loslàsst, ist da ganz schön was los im
Mehrnutzerbetrieb.
Könnte das im tief verschachtelten Profilverz. liegende Temp-Verz. ein
Störfaktor sein? Evtl. auf c:\temp umstellen?
Das Abschalten des Virenscanners hat die Fehlerhàufigkeit gemindert,
aber nicht beseitigt.


Vielleicht hat jemand von Euch einen Rat?


Schönes Wochenende!
-christoph
 

Lesen sie die antworten

#1 Stefan Wuebbe
25/04/2008 - 17:19 | Warnen spam
Hallo Christoph -

ich habe sporadisch einen "Aktulisierungskonflikt" beim Schreiben in
einer SQL-View. Ich muss das etwas detaillierter beschreiben.


<...>
und da kommt es zum Aktualierungskonflikt bei diesem Befehl:
DELETE FOR Spalte1 = "ABC"



Das klingt als sei im aktuellen Arbeitsbereich ein Alias geöffnet
mit Zeilenpufferung, so dass die Datensatzbewegung beim
"Delete For " einen unbeabsichtigten Aktualisierungsversuch auslöst.
Du willst deswegen glaub ich eigentlich Buffering 5?
Wenn ja, wàr zwar immer noch die Frage, warum eine Aktualisierung
fehlschlàgt, aber du könntest bestimmt beim spàter folgenden expliziten
TableUpdate() Versuch per AError() feststellen, ob es vielleicht am
Daten-/Schlüsselfelder-Inhalt liegt.


hth
-Stefan


"Christoph Dreßler" schrieb im Newsbeitrag
news:
Hallo,

ich habe sporadisch einen "Aktulisierungskonflikt" beim Schreiben in
einer SQL-View. Ich muss das etwas detaillierter beschreiben.

folgende Kobstellation:
- SQL-View (Lokal oder Remote spielt für das Problem keine Rolle), in
DBC gespeichert.
- Update-Kriterium nur Schlüsselfeler, Modus SQL UPDATE
- Buffermode der FORM Optimistic, View nicht in der Datunumgebung.
- Unterliegede Tabelle rel. groß > 100.000 DS
- Gut parametrisiert, ca 1.000 DS auf Client geladen.
- VFP9SP1, Hardware, Netzwerk BetrSystem sind ohne Einfluss

Problem:
Nach dem Tablerequery(<View>) werden deren Daten in ein temporàres
Format (Cursor) konvertiert, da vom Nutzer interaktiv bearbeitet,
dauert also ein paar Minuten.
Vor dem Rückkonvertieren lösche ich einen Teil der Daten in der View,
und da kommt es zum Aktualierungskonflikt bei diesem Befehl:

DELETE FOR Spalte1 = "ABC"

Warum, ist mir, ein völliges Ràtsel, denn:
- Der Fehler ist sporadisch und selten.
- Die gleichen Bearbeitungsschritte klappen 1 min. spàter.
- Ein Index- oder Netzwerkproblem kann es nicht sein, da das auch bei
Remote-Views auf MS-SQL passiert.
- Durch logische Sperren wird verhindert, dass andere Clients die
Daten bearbeiten können. Es kann also nicht zum klassischen
Konkurrenz-Problem kommen
- Der Fehler tritt bei dem DELETE auf, nicht beim TableUpdate().

Frage:
Könnten Zugriffsprobleme auf den DBC sowas zur Folge haben?
Wenn man FILEMON auf den DBC loslàsst, ist da ganz schön was los im
Mehrnutzerbetrieb.
Könnte das im tief verschachtelten Profilverz. liegende Temp-Verz. ein
Störfaktor sein? Evtl. auf c:\temp umstellen?
Das Abschalten des Virenscanners hat die Fehlerhàufigkeit gemindert,
aber nicht beseitigt.


Vielleicht hat jemand von Euch einen Rat?


Schönes Wochenende!
-christoph



Gleichfalls!

|\_/| ProLib - programmers liberty --
(.. ) Our MVPs and MCPs make the Fox run
- / See us at www.prolib.de or www.AFPages.de

Ähnliche fragen