ich habe bei einem Kunden folgendes Problem:
Ein Anwender ändert Daten innerhalb einer Maske. Beim Speichern dieser Änderungen werden die Änderungen in einem anderen Datensatz abgespeichert. Das Problem ist, dass dieser Fehler in der Vergangenheit nur hin und wieder aufgetreten ist und ich keine Anhaltspunkte habe, wo das Problem liegt.
Interessanter Weise tritt dieses Problem nur beim Kunden auf und ist nicht reproduzierbar. Wenn ich die kompletten Daten-Dateien auf mein Netzwerk einspiele und die Änderungen durchführe, wie sie der Kunde macht, tritt dieses Problem nicht auf.
Um den Grund der Fehlerursache zu kommen, habe ich in der Write()-Routine folgenden Code eingebaut:
Code: Alles auswählen
IF !::lAppend
// Datensatz-Nr. des angezeigten Datensatzes stimmt nicht mit Datensatzzeiger überein
IF ::nActEditRec <> oPage:server:RecNo()
AppInfoBox("Fehlercode (1), speichern nicht möglich")
Return (.F.)
ENDIF
// Der Inhalt des Get-Controls stimmt nicht mit dem Inhalt des
// Datenbankfeldes überein, wobei das Get-Control
// nicht editiert werden kann!
IF oPage:sleNr:GetValue() <> oPage:server:Fieldget(1)
AppInfoBox("Fehlercode (2), speichern nicht möglich")
Return (.F.)
ENDIF
ENDIF
Wieso dann der Inhalt des bezeichneten Get-Feldes nicht mit dem Inhalt des Feldes übereinstimmt, wenn die erste Bedingung nicht zutrifft, bleibt mit schleierhaft. Zumal dieses Feld nur beide Neu-Anlage eines Datensatz editiert werden kann und ansonsten gesperrt ist.
Die Vermutung, dass der Datensatzzeiger im Laufe des Editierens woanders hin gesetzt wird, bin ich auch nachgegangen. Allerdings müsste dann die aktuelle Satz-Nr. nicht mit der Datensatz-Nr. der Member-Variablen übereinstimmen.
Ich habe den Verdacht, dass das Problem im Zusammenhang mit CIRIX steht. Die Anwendung wird in einer Außenstelle des Kunden unter CITRIX genutzt. Die Außenstelle ist im Rahmen eines WLAN´s über Internet mit der Zentrale verbunden. Der entsprechende CTRIX-Server steht auch in der Zentrale.
Die Anwendung wurde mit xbase 1.82 erstellt.
Ich bin auch der Frage nachgegangen, ob die zur Datenbank zugehörige CDX-Index-Datei defekt ist. Tests haben aber ergeben, dass dies nicht die Fehlerursache sein kann. Ferner werden alle Speicherungsvorgänge mit einem Commit() und Skip(0) abgeschlossen.
Hat jemand eine Idee, wo das Problem liegen könnte?
Beste Grüße,
Olaf
