Scope geht verloren

[Werner_Bayern]

Servus,

hat das schon mal jemand gehabt?
DBFNTX, DBF wird selectiert, der korrekte Index wird selectiert und manchmal ist der gesetzte Scope für den Index weg.
DBF und / oder Index wird vorher nicht geschlossen und wieder geöffnet.

[Wolfgang Ciriack]

Schaltest du vielleicht irgendwo inzwischen den Index um ?

[Jan]

Normaler Weise bleibt der Scope auf einem Index bestehen, bis man den explizit wieder entfernt. Oder die dbf schließt. Ein Index-Wechsel sollte also keine Auswirkungen haben. Außer das der Scope inaktiv (nicht gelöscht!) ist, wenn man einen anderen Index aktiviert.

Jan

[brandelh]

Aber der Scope "lebt" eindeutig vom richtigen Index !
Es wäre schon möglich, dass ein SET INDEX einen bestehenden Scope schließt.

Das müsste man ausprobieren ...

Der Wechsel der Workarea hingegen darf nichts an ihm ändern.

[Jan]

Moin Hubert,

richtig. Ein Wechsel der aktiven dbf darf nichts am Scope ändern. Aber auch nicht der Wechsel zu einem anderen Index auf der gleichen dbf. So lange der Index mit dem Scope offen ist, bleibt auch der Scope bestehen. Außer natürlich man löscht den Scope.

Jan

[brandelh]

Hallo JAN,

ich weiß es nicht, daher schreibe ich ja AUSPROBIEREN, aber so wie ich den Scope verstanden habe nutzt er immer den aktiven Index und wenn man den wechselt könnte ich mir schon vorstellen, dass Alaska dann den scope vorher löscht.

[Manfred]

aus der Anleitung

Ein gesetzter Scope bleib so lange aktiv, bis er entweder mit SET SCOPE TO (ohne Parameter) gelöscht oder der Index bzw. die Datenbank geschlossen wird.

das verstehe ich so, dass man auch hin und herschalten können sollte, ohne den Scope zu verlieren.

[brandelh]

da hast du völlig Recht, man SOLLTE das können
ob es sinnvoll ist, bleibt eine andere Frage ...

nur kam es schon öfters vor, dass eine Funktion funktionieren sollte und es dennoch nicht tat

[Manfred]

Das stimmt, aber deshalb ja die Frage von Werner, ob das jemand schon erlebt hat und somit die Funktion einen Fehler haben könnte.

[Jan]

Hubert,

nach meinen praktischen Erfahrungen wird ein Scope NICHT gelöscht bei einem Indexwechsel. So lange man den Index mit dem Scope weiter offen läßt ...

Jan

[Werner_Bayern]

Danke für die rege Diskussion
Ich starte da einen Thread, öffne anfangs alle dbf mit allen Indexen und anschließend wird je nach Benutzerauswahl ein scope gesetzt. Zwischendurch wird schon mal ein dbsetorder() ausgeführt, aber dann wieder zurück.

Mein Prüfcode sieht jetzt so aus:

Code: Alles auswählen

select formular
dbsetOrder(1)  // zur Sicherheit wg. Scope! 19.03.2013
if .not. DbScope()   // 25.09.2014
   fehler("Die Eingrenzung (Scope) auf die Formularnummer ist verloren gegangen, teilen Sie uns bitte unbedingt die genauen" +;
   " letzten Schritte unverzüglich mit!" + CRLF + "Aufruf aus: " + Trim(ProcName(1)) + "(" + LTrim(Str(ProcLine(1))) +;
   "), " + Trim(ProcName(2)) + "(" + LTrim(Str(ProcLine(2))) + ")" + CRLF + opendbf(.t.))
   return NIL
endif
dbgotop()
do while .not. eof()
   replace...
   skip
enddo
.
.
.

Die Routine hier läuft seit 2 Jahren bei mehreren Kunden, täglich x Mal, aber 1-2x / Jahr geht der scope verloren und dann kommt es zum Datenchaos.

Danke.

[Werner_Bayern]

Hubert,

nach meinen praktischen Erfahrungen wird ein Scope NICHT gelöscht bei einem Indexwechsel. So lange man den Index mit dem Scope weiter offen läßt ...

Jan

Völlig korrekt, nutze ich schon seit Jahren so. Ist ja ein elementares Feature von Xbase++.

[Wolfgang Ciriack]

aber 1-2x / Jahr geht der scope verloren und dann kommt es zum Datenchaos.

Evtl. ist da vorher die Indexdatei defekt geworden ?

[Werner_Bayern]

Evtl. ist da vorher die Indexdatei defekt geworden ?

Unwahrscheinlich, gerade ein paar Stunden vorher wurde dieser komplett neu erzeugt (Wartung in der Nacht). Lt. Kunde war da auch nichts, lt. unseren Log-Dateien stimmt das auch.

[AUGE_OHR]

Die Routine hier läuft seit 2 Jahren bei mehreren Kunden, täglich x Mal, aber 1-2x / Jahr geht der scope verloren und dann kommt es zum Datenchaos.

Frage : was brachte dich auf den Gedanken das der SCOPE "verloren" sei ?

hast du dann evtl. Umlaute im SCOPE ( PDR 6384 ) und erhält nicht die erwarteten Ergebnisse ?
passiert es bei "vielen" oder "wenigen" Treffern ? ( PDR 6098 / 5661 )

[Werner_Bayern]

Frage : was brachte dich auf den Gedanken das der SCOPE "verloren" sei ?

hast du dann evtl. Umlaute im SCOPE ( PDR 6384 ) und erhält nicht die erwarteten Ergebnisse ?
passiert es bei "vielen" oder "wenigen" Treffern ? ( PDR 6098 / 5661 )

Datenchaos: Weil die Eingrenzung fehlt.
Der PDR 6384 wurde von mir gefunden und gemeldet und der Scope ist numerisch. Der Scope ist auf ein Browse gesetzt, der Anwender würde es sofort erkennen. Formular ist z. B. die dbf mit allen Angeboten, der Scope ist dann die aktuelle Angebotsnummer, die bearbeitet wird (SCOPE_BOTH). Nach der Bearbeitung werden dann die Datensätze überprüft und mit aktuellen Zusatzdaten versorgt, da passiert es dann, dass alle Sätze der dbf "bearbeitet" werden.

[brandelh]

Ich würde mir ganz am Anfang den ersten Satz merken und bei der zweiten Bearbeitung (goTop()) die Recno() prüfen.
Wenn die falsch ist, dbSeek() und bei jedem Replace FOR Bedingung prüfen ...

Auf welchem OS läuft denn das Ganze ?

[Werner_Bayern]

Servus Hubert,

klar kann ich da alles Mögliche drum rum programmieren, ich will aber die Ursache finden, vielleicht hab ich ja einen Fehler gemacht, vielleicht ist es eine bestimmte Konstellation, vielleicht liegts an Xbase++ oder sonst was.

OS: Im letzten Fall ein Win7 auf dem MAC, bei anderen Kunden Win7 64 bit.

[AUGE_OHR]

Datenchaos: Weil die Eingrenzung fehlt.
Der PDR 6384 wurde von mir gefunden und gemeldet und der Scope ist numerisch. Der Scope ist auf ein Browse gesetzt, der Anwender würde es sofort erkennen.

OK ... aber es sind nur "wenige" Datensätze die zum SCOPE gehören ?

Formular ist z. B. die dbf mit allen Angeboten, der Scope ist dann die aktuelle Angebotsnummer, die bearbeitet wird (SCOPE_BOTH). Nach der Bearbeitung werden dann die Datensätze überprüft und mit aktuellen Zusatzdaten versorgt, da passiert es dann, dass alle Sätze der dbf "bearbeitet" werden.

da würde ich vermuten das die Daten noch nicht "richtig" in der DBF sind.

Frage : findet das ganze in einem Thread statt ? wie sieht deine DBESYS aus ?

ich würde es mal versuchen die DBF, nach der Bearbeitung zu schliessen und neu öffnen / positionieren.

[Werner_Bayern]

OK ... aber es sind nur "wenige" Datensätze die zum SCOPE gehören ?

1 - ca. 50.

da würde ich vermuten das die Daten noch nicht "richtig" in der DBF sind.

Frage : findet das ganze in einem Thread statt ? wie sieht deine DBESYS aus ?

??? Klar sind die in der DBF, sonst würde die Funktion nicht ausgeführt. Ja, ist ein eigener Thread.

Code: Alles auswählen

PROCEDURE dbeSys()
#include "dmlb.ch"
#include "DbfDbe.ch"
#include "ntxDbe.ch"
#define MSG_DBE_NOT_LOADED   "DBF Database-Engine nicht geladen!"
#define MSG_DBE_NOT_CREATED  "DBF Database-Engine konnte nicht erzeugt werden!"

   SET COLLATION TO GERMAN
   IF !DbeLoad("DBFDBE",.T.)
      fehler(MSG_DBE_NOT_LOADED)
   ENDIF
   IF !DbeLoad("NTXDBE",.T.)
      fehler(MSG_DBE_NOT_LOADED)
   ENDIF
   IF !DbeLoad("DELDBE",.f.)
      fehler(MSG_DBE_NOT_LOADED)
   ENDIF
   IF !DbeLoad("SDFDBE",.f.)
      fehler(MSG_DBE_NOT_LOADED)
   ENDIF

   IF !DbeBuild("DBFNTX","DBFDBE","NTXDBE")
      fehler(MSG_DBE_NOT_CREATED)
   ENDIF

   DbeSetDefault( "DBFNTX" )

   DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)
   DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,200000)
   DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10)
   DbeInfo(COMPONENT_DATA,DBFDBE_LIFETIME,0)

#ifdef SQL
  IF !DbeLoad("pgdbe")
    fehler("PostgreSQL DatabaseEngine konnte beim Programmstart nicht geladen werden!")
  ENDIF
#endif

RETURN

ich würde es mal versuchen die DBF, nach der Bearbeitung zu schliessen und neu öffnen / positionieren.

Würde im Netz eine unnötige Verzögerung verursachen.

[AUGE_OHR]

Würde im Netz eine unnötige Verzögerung verursachen.

JA ... aber bevor du dir deine DBF zerschiesst :-"

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.

in deine DBESYS würde ich, bei DBTNTX,

Code: Alles auswählen

   DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

raus nehmen ...

[Werner_Bayern]

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.

in deine DBESYS würde ich, bei DBTNTX,

Code: Alles auswählen

   DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

raus nehmen ...

2x Warum?

[AUGE_OHR]

2x Warum?

wie 2 x ?

[Werner_Bayern]

Auf Deine 2 Vorschläge frage ich 2x: Warum?

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

raus nehmen ...

[AUGE_OHR]

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

weil Xbase++ nicht alleine auf dem PC läuft und es noch andere Programme / Dienste gibt die Zeit benötigen

raus nehmen ...

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