FieldPut() will nicht

[georg]

Hallo,


wenn ich mit klassischen dBase-Dateien arbeite, verwende ich (wie auch hier) FOXCDX, sowie eine Klasse, die den Zugriff auf die Daten steuert. In zig Applikationen funktioniert es, aber jetzt habe ich eine Tabelle, bei der Zugriffe nach einem nicht erkennbare Schema nicht funktionieren.

Xbase Version ist 355 mit allen derzeit verfügbaren Patches.
FOXCDX läuft ohne Anpassung irgendwelcher Parameter.

Datei: PostTrack.dbf {{"PTID", "N", 15, 0}, {"PTCOUNT", "N", 8, 0}}
geöffnet ist die Datei mit dem Alias POSTTRACK

Der Programmcode:

Code: Alles auswählen

...
lResult := .T.
FOR nI := 1 TO nFields
   xValue := (self:cAlias)->(FieldPut(nI, aFieldList[nI]))
   lResult := lResult .AND. (xValue == aFieldList[nI])
NEXT
...

nFields enthält die Anzahl Felder in der Datei, in diesem Fall 2
aFieldList sieht so aus: {2050621, 2726}
self:cAlias hat den Wert "POSTTRACK"
(self:cAlias)->(FieldGet(1)) => 2050621
(self:cAlias)->(FieldGet(2)) => 3
der Datensatz kommt nur einmal vor
der Datensatz ist gesperrt
die FieldPut() Anweisung gibt einmal 2050621, und dann 2726 zurück

Was mich jetzt so irritiert: der Wert des zweiten Feldes wird NICHT verändert. Normalerweise ist nur eine Instanz des Programms aktiv. Seitdem der Fehler auftritt, habe ich noch DBU (Xbase compiliert) im Hintergrund offen.

Es gibt keine Fehlermeldung noch sonst etwas. Es scheint so, als würden neue Sätze (die über die gleiche Schleife laufen, nachdem ein dbAppend() durchgeführt wurde) korrekt geändert. Ob alle Updates gegen die Wand laufen, kann ich derzeit noch nicht sagen, würde es aber vermuten.

Das Problem scheint aber auch nur bei dieser einen Datei aufzutreten ...

Also habe ich die Datei umbenannt, den Index gelöscht, Datei und Index neu erstellt, die Daten aus der Kopie übernommen => gleicher Fehler.

[brandelh]

Sehr seltsam, die Variable self:cAlias ermittelst du bestimmt nach dem Öffnen per alias() oder ?
Wenn ja, ist das OK, obwohl ich immer den numerischen Alias (Select()) vorziehe.
Das würde dann aber auch beide Felder betreffen, sehr seltsam das Ganze

[georg]

Hallo, Hubert -


ich habe die einzelnen Codezeilen im Debugger ausgeführt und geprüft, indem ich die Anweisung in der Befehlseingabe des Debuggers ausgeführt habe und auch die Werte geprüft.

Und, ja, die Instanzvariable cAlias enthält zu diesem Zeitpunkt den Wert "POSTTRACK". Die wird bei der Initialisierung des jeweiligen Objektes beschickt.

Daran kann es also m.E. nicht liegen.

[Markus Walter]

Hi,

sieht mir nach einem Locking-Problem aus (würde evtl. erklären, warum es beim Anhängen von Datensätzen mit dbappend() geht).

Wie ist die Tabelle offen (exclusiv, share)?
Falls geshared: wie wird gesperrt, entsperrt (die Daten werden erst beim unlock wirklich geschrieben!)?

[georg]

Hallo, Markus -


in diesem Fall werden die Dateien shared geöffnet, d.h. ich kann die Datei "nebenher" in DBU öffnen.

Vor der Änderung wird der Datensatz gesperrt, und das Ergebnis-Array von (self:cAlias)->(dbRLock()) listet auch nur die Satznummer dieses einen Satzes auf.

Nach dem FieldPut() kommt dann dieser Code-Teil:

Code: Alles auswählen

   IF lUnlock
      ::unlockRecord()
   ENDIF
RETURN(lResult)

lUnlock ist ein Aufrufparameter der Methode und wird per default auf TRUE gesetzt.
::unlockRecord() führt den unlock auf den Datensatz aus.

Und vor dem Aufruf der Methode sieht's so aus:

Code: Alles auswählen

IF oPostTrack:dbrLock()
   oPostTrack:UpdateRecord(aSet)
ENDIF

aSet enthält die beiden Werte, die zurückgeschrieben werden sollen, da kein zweiter Parameter angegeben ist, wird der Datensatz nach dem Update "automatisch" freigegeben.

Auch nach dem Unlock, dem Update auf den nächsten Satz, dem Schliessen des Programms, dem Neustart des PCs - ist das zweite Feld unverändert. Und das ist es, was ich nicht verstehe, da der FieldPut() den NEUEN Wert zurückgibt, aber nichts zuweist und auch keinerlei Fehlermeldung produziert.

Andere Änderungen, die über die gleiche Klasse (andere Datei, anderes Objekt der gleichen Klasse) ausgeführt werden, sind sofort "da".

[AUGE_OHR]

In zig Applikationen funktioniert es, aber jetzt habe ich eine Tabelle, bei der Zugriffe nach einem nicht erkennbare Schema nicht funktionieren.
Datei: PostTrack.dbf {{"PTID", "N", 15, 0}, {"PTCOUNT", "N", 8, 0}}

Frage : wird dort auch die PostTrack.dbf mit "der" Structure verwendet ?

wenn es nur die beiden Felder sind , also alle Felder, versuch es mal so

Code: Alles auswählen

AEval( aValues, {|x,i| x:=FieldGet(i) },,, .T. )

ob dann die Felder "richtig" gefüllt werden.

[georg]

Hallo,


also ich habe mal ein paar Versuche gemacht. Der erste Wert gibt den Ausgangswert an, der zweite den (gewünschten) neuen Wert, und die Auswirkung in der DBF-Datei:

Code: Alles auswählen

  1 -> 1.255 Fehler
  0 ->     2 OK
263 ->   266 OK
  4 ->     5 OK
 24 ->    25 OK
  1 -> 1.260 Fehler
538 ->   539 OK

Aha. Beim Überschreiten der 1.000er Grenze scheint es ein Problem zu geben. Ich habe dann die Aktualisierung von 2 auf 2.776 (die schon mehrfach gescheitert war), zuerst mit 499, 799, 2.776 versucht, und dann ging es.

Ich habe damit einen Workaround gefunden, da ich jetzt mal eine Prüfung auf die Überschreitung der 1.000 (als imaginäre Grenze) einbaue und in dem Fall mehrere Updates (ohne UnLock) durchführe. Aber das erklärt das Problem nicht...

@Jimmy: ja, der Code wird korrekt ausgeführt und liefert die Werte aus dem aktuellen Satz. Hattest Du etwas anderes erwartet?

[brandelh]

bist du sicher, dass 1.255 als 1255 interpretiert wird und nicht als 1,255 ?

[georg]

Hallo, Hubert -


ja. Weil ich die Tausender-Punkte zur besseren Visualisierung eingefügt habe.

Die Werte kommen aus HTML-Seiten, sind also "C" und werden mittels Val(cWert) ins Array geschrieben.

Wäre es nicht "N" vom Typ her, müsste der FieldPut() auf einen Fehler laufen, oder?

[brandelh]

Ich meinte ja nur um sicher zu gehen
Also du erhälst "1234" und machst mit val() daraus 1234 und beim Speichern in ein N 8,0 Feld wird der Wert dort ...
1. nicht geändert, oder
2. falsch gespeichert (wie ?)

Ich kann es mir ja auch nicht erklären
Fehler kommen übrigens NIE beim fieldput() / REPLACE immer erst beim tatsächlichen schreiben (dbSkip() oder UNLOCK etc.)

[georg]

Hallo, Hubert -


Du hast Dir einen Orden verdient ...

Val() wandelt "1.239" (Eingangswert) in 1,239 (1 + 239/1000) um. DAS ist der Fehler, denn meine Prüfung auf die Schwelle bei 1000 hat nicht gegriffen.

Fall gelöst.

[brandelh]

Du hast Dir einen Orden verdient ...

den nehm ich gerne
in Gold oder in Bronze ?

[Manfred]

Hubert ich würde mich sogar für Platin einsetzen....

So, das war die erste Schleimspur in 2013