Inwiefern ist das Extended Locking nicht "ideal"? Was ist daran suboptimal oder sogar fehlerhaft?weil ich die "Optimierung" bei DBFNTX für nicht ideal halte und die alle abschalte
Scope geht verloren
Moderator: Moderatoren
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope geht verloren
Hallo, Jimmy.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
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.Tom hat geschrieben:Inwiefern ist das Extended Locking nicht "ideal"? Was ist daran suboptimal oder sogar fehlerhaft?weil ich die "Optimierung" bei DBFNTX für nicht ideal halte und die alle abschalte
auch bei DBFCDX und Comix/Sixdrive schalte ich die "Optimierungen" alle ab.
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope geht verloren
Hallo, Jimmy.
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.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.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
Frage : wurde bei dir die DBF (NTX) aus Cl*pper oder Xbase++ erstellt ?Tom hat geschrieben: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.
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.
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope geht verloren
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.
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.
Herzlich,
Tom
Tom
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
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().
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().
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope geht verloren
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.
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.
Herzlich,
Tom
Tom
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
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.
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.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
hi,
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.
Ich auch im Glauben das so was gar nicht passieren dürfte und es bei Cl*pper Comix/SixDrive mit SCOPE nie vorkam.Werner_Bayern hat geschrieben:da schließe ich mich Tom an, das kam mir jetzt schon sehr komisch vor.
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.
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope geht verloren
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 ...
aber dann habe ich gelesen, dass du für jeden Thread seine eigenen DBFs öffnest und da dürfte eigentlich nichts passieren ...
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
es sollte bei Thread, die einen eigene Workspacelist haben, nicht passieren ...brandelh hat geschrieben: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 ...
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 ?
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope geht verloren
bei mehreren threads muss man den Cache ausschalten (DBFDBE_LIFETIME auf 0 setzen), aber das hattest du meine ich schon geschrieben.
Gruß
Hubert
Hubert
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
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.
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.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
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.brandelh hat geschrieben:bei mehreren threads muss man den Cache ausschalten (DBFDBE_LIFETIME auf 0 setzen), aber das hattest du meine ich schon geschrieben.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
Ich habe geschriebenWerner_Bayern hat geschrieben:Genau davon hatte Jimmy abgeraten, aber das wurde inzwischen klar gestellt (Tom), ich lasse das auf 0.brandelh hat geschrieben:bei mehreren threads muss man den Cache ausschalten (DBFDBE_LIFETIME auf 0 setzen), aber das hattest du meine ich schon geschrieben.
also genau das was auch Hubert schreibt weil es ein MUSS ist.du hast zwar schonWerner_Bayern hat geschrieben:
Ja, ist ein eigener Thread.drin aber gerade bei Thread hat man ja "manchmal" das Problem mit dem Timeing wo es noch nicht "stable" ist.Code: Alles auswählen
DbeInfo(COMPONENT_DATA,DBFDBE_LIFETIME,0)
Die Aussage von Tom bezog sich auf LOCKING_EXTENDEDin deine DBESYS würde ich, bei DBTNTX,Code: Alles auswählen
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)
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.Werner_Bayern hat geschrieben:Obwohl es hier keinen Einfluß haben dürfte, weil es ja nicht um die Konsistenz der Daten geht, sondern um einen gesetzten Scope.
ansonsten,wie schon vorgeschlagen, würde ich ein SLEEP(10), nach dem CLOSE, vor Ende des Threads ausprobieren um Xbase++ mehr Zeit zu geben.
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope geht verloren
nach dem wie ich deine Beschreibung des Fehlers lese, kann es zwei Ursachen für das Verhalten geben:Werner_Bayern hat geschrieben:brandelh hat geschrieben: Obwohl es hier keinen Einfluß haben dürfte, weil es ja nicht um die Konsistenz der Daten geht, sondern um einen gesetzten Scope.
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
Gruß
Hubert
Hubert
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
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.
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.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
mit DbScope() kannst du nur feststellen was dir Xbase++ "sagt" aber nicht was das Windows OS() gerade macht.Werner_Bayern hat geschrieben: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.
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 ?
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
Nein, hat bisher auch erst 1 Kunde und wir selbst im Einsatz.AUGE_OHR hat geschrieben:hast du jetzt schon ein Errlog bekommen nachdem du die Abfrage eingebaut hast ?
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope geht verloren
Ein SCOPE wirkt doch ausschließlich innerhalb von Xbase++ das hat doch mit dem OS nichts zu tun.AUGE_OHR hat geschrieben:mit DbScope() kannst du nur feststellen was dir Xbase++ "sagt" aber nicht was das Windows OS() gerade macht.Werner_Bayern hat geschrieben: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.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope geht verloren
YUP ... schon klar ... aber die Befehle zum öffnen/locking/schliessen gehen über das OS().brandelh hat geschrieben:Ein SCOPE wirkt doch ausschließlich innerhalb von Xbase++ das hat doch mit dem OS nichts zu tun.
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
Ja, gerade eben. Kunde hat auch gleich brav angerufen.AUGE_OHR hat geschrieben:p.s. hast du jetzt schon ein Errlog bekommen nachdem du die Abfrage eingebaut hast ?
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...
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope geht verloren
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:
(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:
(analog für die anderen Funktionen)
Einbinden und alle PRGs neu kompilieren.
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 )
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>)
Einbinden und alle PRGs neu kompilieren.
Herzlich,
Tom
Tom
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope geht verloren
Servus Tom,
danke, werd ich machen und berichten!
danke, werd ich machen und berichten!
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>