Scope geht verloren

[Tom]

Hallo, Jimmy.

weil ich die "Optimierung" bei DBFNTX für nicht ideal halte und die alle abschalte

Inwiefern ist das Extended Locking nicht "ideal"? Was ist daran suboptimal oder sogar fehlerhaft?

[AUGE_OHR]

weil ich die "Optimierung" bei DBFNTX für nicht ideal halte und die alle abschalte

Inwiefern ist das Extended Locking nicht "ideal"? Was ist daran suboptimal oder sogar fehlerhaft?

da ich für DBFNTX noch gemeinsam alten Cl*pper Tools verwende ergeben sich daraus "Unterschiede" die auf Dauer ein Reindex notwendig machen wobei die NTX Datei dann "kleiner" wird als vorher.
auch bei DBFCDX und Comix/Sixdrive schalte ich die "Optimierungen" alle ab.

[Tom]

Hallo, Jimmy.

da ich für DBFNTX noch gemeinsam alten Cl*pper Tools verwende ergeben sich daraus "Unterschiede" die auf Dauer ein Reindex notwendig machen wobei die NTX Datei dann "kleiner" wird als vorher.

Das wäre eine sinnvolle Erklärung zum "raus nehmen" gewesen, gell? Wer nämlich nicht wie Du arbeitet, und das dürften viele sein, profitiert z.B. vom Extended Locking. Das zumindest nach meiner Erfahrung absolut fehlerfrei arbeitet und im konkurrierenden Betrieb sehr profitabel ist.

[AUGE_OHR]

Das wäre eine sinnvolle Erklärung zum "raus nehmen" gewesen, gell? Wer nämlich nicht wie Du arbeitet, und das dürften viele sein, profitiert z.B. vom Extended Locking. Das zumindest nach meiner Erfahrung absolut fehlerfrei arbeitet und im konkurrierenden Betrieb sehr profitabel ist.

Frage : wurde bei dir die DBF (NTX) aus Cl*pper oder Xbase++ erstellt ?
Das "Problem" taucht doch schon auf, im gemeinsamen Betrieb mit Cl*pper, wenn die DBF von Xbase++ erstellt wurde und Cl*pper die "benutzt".

mag sein das du Xbase++ als "Referenz" siehst, ich sehe Cl*pper als das "original" und wenn sich Xbase++ dann nicht so verhält dann stelle ich das ab bei gemeinsamen Betrieb ... unabhängig ob das mit Xbase++ (alleine) funktioniert oder nicht.

[Tom]

Hallo, Jimmy.

Ich habe zuletzt vor über 10 Jahren irgendwas mit Clipper angefasst. Und mir ist, mit Verlaub, scheißegal, ob ein Index zu 100 oder nur zu 79,59003 Prozent mit Clipper kompatibel ist, so lange er mit Xbase++ einwandfrei zu verwenden ist. Und das ist zweifelsohne der Fall.

Wenn Du also so originelle Vorschläge wie "raus nehmen" postest, dann wäre schon sinnvoll, dazu zu erklären, warum Du derlei empfiehlst. Sonst hacken zig Leute in ihrem (sich dadurch dramatisch verschlechternden) Code herum, obwohl das "raus nehmen" tatsächlich nur anzuwenden wäre, würde man so originell arbeiten wie Du eben.

[Werner_Bayern]

Jimmy,

da schließe ich mich Tom an, das kam mir jetzt schon sehr komisch vor. Ich benutze hier ausschließlich Xbase++, wir sind hier auch im entsprechenden Forum (nicht clipper). Alle DBF und NTX sind von Xbase++ erstellt, obwohl vor Jahren die Daten noch mit clipper gepflegt wurden, aber meine pack-Routine arbeitet schon immer mit copy to und der Index wird dabei immer anschließend logischerweise neu erzeugt mit OrdCreate().

[Tom]

Hallo, Werner.

Um zu Deiner Ausgangsfrage zurückzukommen: Da es äußerst sporadisch auftritt, ist ein systemischer Fehler (Bug in der DBE o.ä.) m.E. auszuschließen. Das erinnert mich an eine Klasse von Fehlern, mit der ich selbst hin und wieder konfrontiert werde und (glücklicherweise überwiegend) wurde: Da wurden zig Tabellen geöffnet und tausend Dinge sauber vorbereitet, ein Bearbeitungsdialog (von hunderten) wurde aufgerufen, der Daten aus einer bestimmten Tabelle anzeigte, und am Ende, beim Speichern nach dem Schließen dieses Dialogs war die fragliche Tabelle manchmal wech. Einfach so. Alle anderen waren noch da, nur diese nicht mehr. WTF? Ließ sich nicht nachstellen, alle Logs waren sauber, und dennoch geschah es. Einmal pro Vierteljahr oder so, bei mehreren tausend Arbeitsplätzen, auf denen die App läuft. Super. Immerhin führte es nicht zu Datenverlusten, von den paar Eingaben, die man im fraglichen Dialog gerade getätigt hatte, abgesehen, was schon ärgerlich genug war.
Die Ursache und damit die Lösung lag immer im Code. So konnte beispielsweise über ein Kontextmenü irgendwas aufgerufen werden, Textbausteine oder so. Über diese Funktionalität konnte man dann wieder neue Textbausteine erfassen, die Textbausteine drucken, wozu dann auf eine Art Lexikon zugegriffen wurde, solche Dinge. Und irgendwo da ganz tief drinnen steckte, schwer erreichbar und nur selten auf genau diese Weise verwendet, irgendwo ein DbUseArea(), das als ersten Parameter .F. statt .T. verwendete, wodurch die Zaubertabelle, die beim Aufruf der Funktion selektiert war, geschlossen wurde. Schlechte Programmierung, fraglos, aber, zu meiner Ehrenrettung, auch eine absolute Ausnahme. Meistens wird ganz anders gearbeitet, alles ist mehrfach gegeneinander abgesichert, was essentiell ist, denn bei mir können Benutzer alle Programmmodule so oft öffnen, wie sie wollen - was sie übrigens auch tun.
Allerdings: Solche Fehler sind bei dieser Art von Architektur nahezu unauffindbar. Wir haben das in solchen Fällen auch nur herausgefunden, weil sich ein paar Leute, die die fraglichen Systematiken intensiv genutzt haben, dazu bereiterklärt haben, ihre Sitzungen mitschneiden zu lassen. Erst dadurch konnten wir sehen, was der Anwender im dann glücklicherweise nach ein paar Tagen aufgetretenen Fehlerfall getan hat. Wir haben uns hier im Team dann gegenseitig gegen die Stirnen geklatscht und das ganz, ganz schnell korrigiert.

Ich halte es für sehr wahrscheinlich, dass da irgendwo bei Dir eine selten genutzte Funktion aufgerufen wird/aufgerufen werden kann, die zum Löschen des Scopes führt.

[Werner_Bayern]

Servus Tom,

danke für die ausführliche Antwort!
Ja, das vermute ich auch, so ähnlich läuft es bei mir auch ab, der (jeder) Thread kann beliebig oft geöffnet werden, dann gibt es eine PLZ-Datenbank, Textbausteine, Zusatzartikel (die wieder Zusatzartikel enthalten können), Lieferadressen, Ansprechpartner, etc. - alles sauber in extra dbfs, die auch immer komplett bearbeitet (also Sätze löschen, kopieren, neu anlegen, einfügen etc.) werden können.
Deshalb jetzt auch die eingebaute Fehlermeldung von mir, dass der Benutzer dann sich gleich bei uns melden soll.
Hat jetzt eh über 1 Jahr gedauert, bis ich es darauf reduzieren (hoffentlich!) konnte.

[AUGE_OHR]

hi,

da schließe ich mich Tom an, das kam mir jetzt schon sehr komisch vor.

Ich auch im Glauben das so was gar nicht passieren dürfte und es bei Cl*pper Comix/SixDrive mit SCOPE nie vorkam.
nun hab ich in Xbase++ ja Fälle gehabt wo das verhalten nicht wie bei Cl*pper war und deshalb alle DBFNTX "Optimierungen" abgeschaltet was die Fehler Quote verbesserte.

In deinem Fall kommen Thread dazu und das "locking" wo Xbase++ ja (immer) noch Probleme mit SMB hat... Cl*pper läuft "sauber" mit den Einstellungen.

Da du nun nicht ständig das Problem hast geht es eben nur noch um die 0.01% die den Unterschied ausmachen.
Es geht also nicht um ein wenig mehr Performance sondern dem Standard der erst mal funktionieren muss bevor man mit "Optimierung" beginnt.

klar würde es Zeit kosten die DBF zu schliessen und wieder zu öffnen aber dann "sollte" dein SCOPE auch zu 100% arbeiten.
Ich "vermute" wie schon gesagt deinen weiteren Thread (wird da auch ein SCOPE gesetzt ?) der im ungünstigen 0.01% Fall mit dem Timeing nicht hinkommt ... evtl. eine SLEEP(10) könnte helfen.


p.s. solche Cl*pper Applikationen werden nun auf SQL umgesetzt.

[brandelh]

Ich hatte zunächst die Threads im Verdacht, dass da einer dem anderen reinfunkt,
aber dann habe ich gelesen, dass du für jeden Thread seine eigenen DBFs öffnest und da dürfte eigentlich nichts passieren ...

[AUGE_OHR]

Ich hatte zunächst die Threads im Verdacht, dass da einer dem anderen reinfunkt,
aber dann habe ich gelesen, dass du für jeden Thread seine eigenen DBFs öffnest und da dürfte eigentlich nichts passieren ...

es sollte bei Thread, die einen eigene Workspacelist haben, nicht passieren ...
aber du vergisst das Thema "locking" was sich im weiten auch auf USE / CLOSE / FILTER / SCOPE und sonstigen bezieht.

Wenn ich als einziger User im Netzwerk auf eine DBF Zugreife ist das SHARE "exclusive"
Wenn ich nochmals im Thread auf die selbe DBF Zugreife tritt SMB in Kraft und Opslock "wirkt"
nun wird dabei der SHARE "exclusive" Status im 1th Thread geändert ... und wenn Thread 2 beendet wird wieder.

was ausser dem anderen Thread, der die selbe DBF im Zugriff hatte, kann es sonst noch sein ?

@Werner : bei 1 - 50 würde ich mir die RECNO() in einem Array merken, SCOPE weg und danach das Array abarbeiten
... dafür brauche man doch keinen Thread, oder ?

[brandelh]

bei mehreren threads muss man den Cache ausschalten (DBFDBE_LIFETIME auf 0 setzen), aber das hattest du meine ich schon geschrieben.

[Werner_Bayern]

Servus Jimmy,

danke für Deine ausführlichen Antworten.
Mir war es hier wichtig zu erfahren, ob es bekannte Probleme mit scope gibt, weil ich meinen Code schon seit > 1 Jahr auf diesen blöden gelegentlichen Fehler durchforste und in Bezug auf scopes eben schon mal was gefunden hatte, was offensichtlich bisher noch niemand bemerkt hatte (Umlaute im scope).

In allen meinen Programmen werden die dbfs zur Bearbeitung immer shared geöffnet, weil ja jedes Programmmodul (= jedes "Hauptfenster") ein eigener Thread ist, dieser öfters geöffnet werden kann und auch alles netzwerkfähig sein soll und damit auch muß.
Klar könnte ich das in ein Array schaufeln oder alles Mögliche andere drum rum programmieren, aber dann bräuchte es keine scopes. Die sind super toll, schnell und bequem.

Warum ein extra Thread: Weil das von mir beschriebene Codefragment nur ein kleiner Auszug aus dem ganzen Thread ist, nur der Abschluss der Bearbeitung z. B. eines Angebotes. Der Thread endet, wenn der Benutzer aus der Angebotsbearbeitung raus geht und anschließend aus dem Browse für die Adresssuche.

[Werner_Bayern]

bei mehreren threads muss man den Cache ausschalten (DBFDBE_LIFETIME auf 0 setzen), aber das hattest du meine ich schon geschrieben.

Genau davon hatte Jimmy abgeraten, aber das wurde inzwischen klar gestellt (Tom), ich lasse das auf 0. Obwohl es hier keinen Einfluß haben dürfte, weil es ja nicht um die Konsistenz der Daten geht, sondern um einen gesetzten Scope.

[AUGE_OHR]

bei mehreren threads muss man den Cache ausschalten (DBFDBE_LIFETIME auf 0 setzen), aber das hattest du meine ich schon geschrieben.

Genau davon hatte Jimmy abgeraten, aber das wurde inzwischen klar gestellt (Tom), ich lasse das auf 0.

Ich habe geschrieben

Werner_Bayern hat geschrieben:
Ja, ist ein eigener Thread.

du hast zwar schon

Code: Alles auswählen

   DbeInfo(COMPONENT_DATA,DBFDBE_LIFETIME,0)

drin aber gerade bei Thread hat man ja "manchmal" das Problem mit dem Timeing wo es noch nicht "stable" ist.

also genau das was auch Hubert schreibt weil es ein MUSS ist.

in deine DBESYS würde ich, bei DBTNTX,

Code: Alles auswählen

  DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

Die Aussage von Tom bezog sich auf LOCKING_EXTENDED

Obwohl es hier keinen Einfluß haben dürfte, weil es ja nicht um die Konsistenz der Daten geht, sondern um einen gesetzten Scope.

Beide Themen zusammen sind ja für das Verhalten von der selben DBF im Thread "irgendwie" verantwortlich wenn es nicht mehr stimmt also sollte man ausprobieren ob es einen Unterschied macht im Lang-Zeit Test.

ansonsten,wie schon vorgeschlagen, würde ich ein SLEEP(10), nach dem CLOSE, vor Ende des Threads ausprobieren um Xbase++ mehr Zeit zu geben.

[brandelh]

Obwohl es hier keinen Einfluß haben dürfte, weil es ja nicht um die Konsistenz der Daten geht, sondern um einen gesetzten Scope.

nach dem wie ich deine Beschreibung des Fehlers lese, kann es zwei Ursachen für das Verhalten geben:

1. Der Scope wurde tatsächlich aufgehoben => das kann man aber doch abfragen oder ? Also protokollieren um sicher zu sein.
2. Der Scope ist tatsächlich noch aktiv, aber die gefundenen Datensätze passen nicht, da die Zuordnung des Index zu den Daten in der Situation durcheinander kommt.

Das solltest du also wirklich abklären

[Werner_Bayern]

Servus Hubert,

mache ich eh. Der Scope ist in meinem Fall dann weg, als ob er gelöscht oder nie gesetzt worden wäre. Das zeigt mein Fehlerlog.

[brandelh]

ok, dann ist das geklärt ...

[AUGE_OHR]

mache ich eh. Der Scope ist in meinem Fall dann weg, als ob er gelöscht oder nie gesetzt worden wäre. Das zeigt mein Fehlerlog.

mit DbScope() kannst du nur feststellen was dir Xbase++ "sagt" aber nicht was das Windows OS() gerade macht.

ich tippe immer noch auf ein Timeing Problem bei den Thread und der selben DBF die bei bestimmten Umständen auftreten
können.

p.s. hast du jetzt schon ein Errlog bekommen nachdem du die Abfrage eingebaut hast ?

[Werner_Bayern]

hast du jetzt schon ein Errlog bekommen nachdem du die Abfrage eingebaut hast ?

Nein, hat bisher auch erst 1 Kunde und wir selbst im Einsatz.

[brandelh]

mache ich eh. Der Scope ist in meinem Fall dann weg, als ob er gelöscht oder nie gesetzt worden wäre. Das zeigt mein Fehlerlog.

mit DbScope() kannst du nur feststellen was dir Xbase++ "sagt" aber nicht was das Windows OS() gerade macht.

Ein SCOPE wirkt doch ausschließlich innerhalb von Xbase++ das hat doch mit dem OS nichts zu tun.

[AUGE_OHR]

Ein SCOPE wirkt doch ausschließlich innerhalb von Xbase++ das hat doch mit dem OS nichts zu tun.

YUP ... schon klar ... aber die Befehle zum öffnen/locking/schliessen gehen über das OS().

[Werner_Bayern]

p.s. hast du jetzt schon ein Errlog bekommen nachdem du die Abfrage eingebaut hast ?

Ja, gerade eben. Kunde hat auch gleich brav angerufen.
Er hat den Menüpunkt gerade aufgerufen, nichts gemacht, einfach nur kurz rein in das Angebot, was gelesen und wieder raus. Er hat nicht mal was bearbeitet.

Die Log zeigt sauber alles (ich lasse mir ja auch alle geöffneten DBFs anzeigen und den aktuellen Satz etc.), steht alles korrekt, jedoch der scope steht auf NIL.
Vorher schon mehrmals drin gewesen und jetzt anschließend auch, keine Probleme...

[Tom]

Hallo, Werner.

Es geht um eine spezielle Tabelle. Relevant sind die Operationen DbUseArea/USE, DbCloseArea/CLOSE, DbClearScope/SET SCOPE, DbSetScope/SET SCOPE.

Wenn Du die Funktionsaufrufe verwendest, würde ich Dir empfehlen, diese vier Funktionen auf eigene Funktionen zu verbiegen, die z.B. jeweils mit einem Unterstrich beginnen, das lässt sich mit Suchen und Ersetzen leicht bewältigen. In den Ersatzfunktionen testest Du, ob es um die fragliche Tabelle geht (wenn sie immer einen konkreten Alias hat, Abfrage mit Alias(), ansonsten Test auf den Dateinamen mit DbInfo()), und protokollierst dort den Callstack. Ins Blaue etwa so:

Code: Alles auswählen

FUNCTION _DbSetScope( nScope, xValue )
IF Alias() == '<eben der alias>' // oder: IF DbInfo(DBO_FILENAME) == '<physikalischer dateiname>'
  * CallStack über ProcName() protokollieren
ENDIF
RETURN DbSetScope( nScope, xValue )

(analog für die anderen Funktionen)

Dadurch sollte sich herausfinden lassen, an welcher Stelle der Scope gelöst oder gesetzt wird, oder wo die Tabelle abermals geöffnet wird, ohne den Scope zu setzen. Eine andere mögliche Ursache sind DbSetIndex() bzw. OrdListAdd(). Auch die löschen Scopes.

Ergänzung: Man muss nicht einmal Suchen und Ersetzen. Einfach eine Include-Datei erzeugen, in der z.B. das hier steht:

Code: Alles auswählen

#xtranslate DbSetScope(<nScope>,<xValue>) => _DbSetScope(<nScope>,<xValue>)

(analog für die anderen Funktionen)

Einbinden und alle PRGs neu kompilieren.

[Werner_Bayern]

Servus Tom,

danke, werd ich machen und berichten!