Lesen von aktualisierten DB Inhalten [ERLEDIGT]

[Manfred]

Hi,

folgendes ist mir gerade aufgefallen:

1) Ich ändere ein Feld in einer Db und schreibe es zurück.
2) An der gleichen WS lese ich in einem anderen Programm dieses Feld ein und
3) bekomme den alten Wert zurück geliefert.
4) an einer anderen WS kann ich genau verfolgen, wie sich das Feld in der Db geändert hat. Also kann ich doch
5) davon ausgehen, das der Wert auch zurückgeschrieben wurde...

Also habe ich
6) ein DBSKIP(0) davor gesetzt, in der Hoffnung, das Feld würde jetzt den neuen Wert zurückliefern.

Nichts.

Dann habe ich DbRefresh() ausprobiert, aber das hilft auch nicht. Wenn ich im Debugger direkt das Feld anspreche, bekomme ich nur den alten Wert zurück, nicht den neuen.

[Rolf Ramacher]

Hallo Manfred,

machst du das verarbeiten mit einer xbp-Dialog-Maske ?

Wnn ja. Das Problem hatte ich hierbei auch mal. Ich habe dann die Maske neu gestartet und die Daten aus der Datenbank neu geladen.



gruß Rolf

[Manfred]

Hi Rolf,

nein, es ist eine Methode, die einfach nur das Feld ausliest um mit dem Wert eine Berechnung anzustellen.

[Koverhage]

vielleicht doch ein commit machen?, oder den Cache der WS ausschalten

[Manfred]

Hi Klaus,

ein Commit? Auf welcher Station? Auf der die schreibt? Das kann ja direkt von einer anderen gelesen werden. Das ist es ja, was mich überlegen läßt, woran es liegen könnte. Die Daten werden anscheinend direkt geschrieben, aber das PRG arbeitet mit alten Daten. merkwürdig ist halt nur, dass Dbrefresh() wohl doch nicht den Cache neu erzeugt, wie ich es m.E. in der Anleitung verstanden habe.

PS: Ich lese gerade in der Knowledgebase, das es wohl mit DBrefresh() ein Problem gibt, es sollte stattdessen mit DBSkip(0) gemacht werden. Das habe ich zuerst probiert, klappt aber auch nicht.

[Martin Altmann]

Hallo Manfred,
vielleicht ein Problem in Deiner Methode? Die Daten werden gar nicht neu eingelesen und Du hast die alten Daten in Deinen Variablen?

Viele Grüße,
Martin

[Manfred]

Hi Martin,

es wird ja direkt das Feld angesprochen db->feldname.

Ich hatte aber auch vorher auch mit Speichervars gearbeitet, die aktualisiert wurden. Es half nichts.

[Koverhage]

Manfred,
manchmal habe ich diese Probleme auch gehabt. Es ist klar das Du an einer anderen WS den richtigen Inhalt angezeigt bekommst, da an dieser ja die Daten aus der Tabelle neu eingelesen werden., d.h. es existiert kein Cache.
Ich würde probieren erst den Cache der WS abzuschalten.

[Manfred]

Hi,

ich habe mal bei Alaska nachgefragt:

Im Ernst, das von Ihnen beschriebene Szenario deutet auf
ein Caching-Problem hin; teilweise scheinen die Workstations
bzw. Programme mit "alten" Daten zu schaffen.

Bitte sehen Sie sich doch einmal die Einstellung DBFDBE_LIFETIME
für DbeInfo() an. Zu Testzwecken würde ich diese einmal auf
0 setzen. Ändert dies etwas an dem von Ihnen beobachteten
Verhalten?

alles schön und gut, aber was mache ich jetzt wie? Ich kann in der Anleitung nichts finden.

[AUGE_OHR]

hi

Bitte sehen Sie sich doch einmal die Einstellung DBFDBE_LIFETIME
für DbeInfo() an. Zu Testzwecken würde ich diese einmal auf
0 setzen. Ändert dies etwas an dem von Ihnen beobachteten
Verhalten?

alles schön und gut, aber was mache ich jetzt wie? Ich kann in der Anleitung nichts finden.

DBESYS.PRG ?

gruss by OHR
Jimmy

[Tom]

Der Wert steht offenbar standardmäßig auf 50 (Millisekunden? Tage? Jahrzehnte?):

Code: Alles auswählen

? DbeInfo(COMPONENT_DATA,DBFDBE_LIFETIME)

[Manfred]

Hi Jimmy,

das ist schon Suuuper. In der dbesys.prg hätte ich das schon gemacht. Ich habe nur keine Vorstellung, wie ich den Parameter jetzt angeben muß.

Ich habe mal in der Anleitung gesucht, aber nichts gefunden.

DBEINFO(und was kommt hier wie rein?)

@Tom,

hätte ich mal noch ein paar Sekunden gewartet

[Markus Walter]

Hallo Manfred,

so:

Code: Alles auswählen

  DbeInfo(COMPONENT_DATA, DBFDBE_LIFETIME, 0)

für DBF (falls Du Fox verwendest entsprechend FOXDBE_LIFETIME)

[Manfred]

Hi,

habe ich so gemacht, hat aber nicht geholfen.

[Karlo Bender]

Hallo Manfred,

wir haben ewig Probleme mit Caching gehabt (schon unter Clipper) und irgendwann beschlossen, nach jeder zusammenhängenden Transaktion von Schreibzugriffen die betreffende(n) Tabelle(n) zu schließen und wieder zu öffenn. Dazu haben wir eine eigene COMMIT-Routine geschrieben, die alle geöffneten Indizes und Relationen sowie Record-Pointer ermittelt und diese nach dem Schließen und Öffnen einer Tabelle wiederherstellt. Nennenswerte Performance-Probleme haben wir damit nicht. Allerdings haben wir dies bei Verwendung von ADS wieder abgeschaltet, d.h. bei einer ADS-Verbindung führt die oben genannte Routine ein einfaches COMMIT aus.

Karlo

[Manfred]

Hallo Karlo,

ich habe letzte Woche das Problem an den Support geschickt mit einem Beispiel dabei. Mal sehen, was die dazu sagen.

[Manfred]

Hi,

um die Sache etwas zu klären:

Das Grundprinzip klappt. Ich habe eine ähnliche Situation gestern durchlaufen und dabei wurde aktualisiert.
Jetzt muß ich nur irgendwann einmal die Muße finden und nachsehen, wo denn der Haken im oben genannten Programmteil liegt.