Verwendung von Aliasoperatoren bei Datenbankfeldern

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Verwendung von Aliasoperatoren bei Datenbankfeldern

Beitrag von henxl »

Hallo,

ich habe bei einer früheren Frage (Betriebssystemfehler) nach einer Lösung für den immer wieder auftretenden Laufzeitfehler

Code: Alles auswählen

FEHLERPROTOKOLL     : 14.08.2006 10:23:42 
* 
Programm            : "C:\Gb\GB.EXE", Version 2.3.11 Build 288 
* 
Xbase++ Version     : Xbase++ (R) Version 1.90.331 
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 2 
------------------------------------------------------------------------------ 
oError:args         : 
          -> VALTYPE: N VALUE: 141 
oError:canDefault   : J 
oError:canRetry     : N 
oError:canSubstitute: N 
oError:cargo        : NIL 
oError:description  : Betriebsystemfehler 
oError:filename     : 
oError:genCode      :         40 
oError:operation    : DbGoto 
oError:osCode       :          1 
oError:severity     :          2 
oError:subCode      :          4 
oError:subSystem    : BASE 
oError:thread       :          1 
oError:tries        :          0 
------------------------------------------------------------------------------ 
CALLSTACK: 
------------------------------------------------------------------------------ 
Aufgerufen von GB1_RVREAD(1189) 
gesucht. Dieser Fehler tritt auch im Zusammenhang mit DbCloseAll bzw. DbClearIndex auf.

Im Programm habe ich Datenbankfelder ohne Aliasoperator verwendet, diese jedoch mit Field definiert. Beispiel:

Code: Alles auswählen

FUNCTION x()
FIELD name
LOCAL cN
...
cN := name
...
RETURN cN
Ich habe nunmehr alle Datenbankfelder mit dem Aliasoperator versehen. Beispiel:

Code: Alles auswählen

...
(cDatei)->name
...
Seitdem sind die Laufzeitfehler nicht mehr aufgetreten. Ich bin mir nicht sicher, ob es daran liegt.

Meine Fragen:
Ist es zwingend erforderlich, Datenbankfelder mit dem Aliasoperator zu versehen.
Ist dies auch beim Erstellen von Indexdateien (Ordcreate(...) und bei Filterbedingungen zwingend erforderlich ?

Vielleicht kann mir jemand weiterhelfen. Danke.

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Heinz,
zwingend erforderlich ist es nicht, wenn man richtig (!) mit den workareas arbeitet und diese auch immer vorher selektiert.
Es hilft aber (wie Du ja selber gemerkt hast) ungemein, mit dem Aliasoperatoren zu arbeiten - vor allem bei MDI-Applikationen, wo man nicht immer weiß, was der Nutzer als nächstes machen wird...

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo Heinz,

wie Martin schon geschrieben hat, nötig ist es nicht, aber wenn man sich die Arbeit erleichtern will (Fehlersuche in MDI Anwendungen, die nur sporadisch auftreten), dann sollte man - so mache ich es - auf die automatische Typerkennung (ist es ein Feld oder eine lokal oder doch eine private ...) verzichten und per Compiler Schalter alle Warnungen einschalten.
Lieber genau schreiben beim Programmieren, als später Tippfehler in Variablennamen suchen ...
Gruß
Hubert
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Martin und Hubert,
vielen Dank für Eure Antworten.

Ich schreibe neue Anwendungen auch mit Aliasoperatoren. Nur bei der Indexerstellung und bei den Filterbedingungen habe ich die Aliasoperatoren bisher nicht verwendet. Wenn ich Euch richtig verstehe, sollte ich sie dort verwenden.

In einer älteren Datenbankanwendung (Hybridmodus) schließe ich alle Datenbanken nach fünf Arbeitsschritten (bspw. Neuerfassen oder Ändern von 5 Datensätzen) und öffne sie danach wieder einschließlich Indexdateien und Filterbedingungen. Ich arbeite nicht direkt mit den Datenbankfeldern, sondern übertrage die Inhalte in Variablen.

Obigen Fehler kann ich wiederholen, wenn ich diesen Vorgang ca. 50 mal wiederhole (also 50 mal schließen und wieder öffnen). Dann bekomme ich den Laufzeitfehler wie oben mit "DbCloseAll".
Ich bin mir sicher, dass kein fehlerhafter Zugriff auf ein Datenbankfeld stattfindet.

Vor der konsequenten Verwendung der Aliasoperatoren trat der Laufzeitfehler häufiger auf. Deshalb vermute ich das Problem dort.

Aber vielleicht liegt das Problem ganz wo anders ...

Nochmals danke, ich muss wohl weitersuchen ...

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Heinz,
henxl hat geschrieben:Nur bei der Indexerstellung und bei den Filterbedingungen habe ich die Aliasoperatoren bisher nicht verwendet. Wenn ich Euch richtig verstehe, sollte ich sie dort verwenden.
richtig - ruhig konsequent sein :D

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,
henxl hat geschrieben: Meine Fragen:
Ist es zwingend erforderlich, Datenbankfelder mit dem Aliasoperator zu versehen.
Ist dies auch beim Erstellen von Indexdateien (Ordcreate(...) und bei Filterbedingungen zwingend erforderlich ?
naja ich compiliere mit /W . Dort werden auch Alias angemechert wenn
die fehlen.
henxl hat geschrieben: Obigen Fehler kann ich wiederholen, wenn ich diesen Vorgang ca. 50 mal wiederhole (also 50 mal schließen und wieder öffnen). Dann bekomme ich den Laufzeitfehler wie oben mit "DbCloseAll".
Ich bin mir sicher, dass kein fehlerhafter Zugriff auf ein Datenbankfeld stattfindet.
Ein "typischer" BUG von v1.9x. Die "Zeit" reicht nicht aus...

verwende deine eigene DBESYS.PRG und erhöhe die Werte
(bitte mal im Forum nach den Werten suchen) und erweitere
deine ErrorSys.PRG um festzustellen ob beim crash noch der
ALIAS vorhanden ist (oError:filename : ... ist Leer )

Alle BUGs die mit DbUseArea, DbSkip, DbGoto, DbClose etc. die
einen oError:genCode : 40 erzeugen sind davon betroffen.

gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

Nachtrag
henxl hat geschrieben: Laufzeitfehler wie oben mit "DbCloseAll".
In deinem Beispiel bist du "sicher" in der "richtigen" WorkArea,
aber oft kommt es bei "DbClose" schon zu einem Fehler wenn
man nicht in "der" WorkArea ist die man "close(n)" möchte.

schlecht :

Code: Alles auswählen

SELECT 1
USE TEST
SELECT 99
...
(TEST)->( DBCLOSE() )
besser :

Code: Alles auswählen

SELECT 1
USE TEST
SELECT 99
...
SELECT 1
(TEST)->( DBCLOSE() )
bei DbCloseAll kann aber genau das "Problem" auftauchen ...

Workaround :

Code: Alles auswählen

   aWSL := WorkSpaceList()
   nWSL := LEN(aWSL)
   FOR j = 1 TO nWSL
      SELECT ( aWSL[j] )
      CLOSE
   NEXT
gruss by OHR
Jimmy
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Martin und Jimmy,

Jimmy: vielen Dank für Deinen Hinweis ( Select()... ). Das habe ich schon so gemacht. Die Fehler treten aber trotzdem auf.

Martin: konsequent!! Wie verwendest Du denn die Aliasoperatoren in Filterbedingungen ?
Ich habe bisher eine PUBLIC-Variable definiert, bswp. cAKDt:="DB", dann die Filterbedingung (keine leeren ak_eanr, Zeichen, Länge 5 ) berücksichtigen, so definiert:

Code: Alles auswählen

cFil:= '!EMPTY((cAKDt)->ak_eanr)'
Das führt in einer GUI-Anwendung zum Fehler (siehe unten) , in einer Hybridanwendung nicht.

Wenn ist die Filterbedingung so definiere:

Code: Alles auswählen

cFil:= '!EMPTY('+cAKDt+'->ak_eanr)'
tritt kein Fehler auf.

Ist die erste Definition unzulässig ?

Fehler (siehe oben):

Code: Alles auswählen

------------------------------------------------------------------------------
FEHLERPROTOKOLL     : 25.09.2006 13:34:39
*
Programm            : "D:\Gb\GB.EXE", Version 2.3.12 Build 301
*
Xbase++ Version     : Xbase++ (R) Version 1.90.331
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 2
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: C VALUE: 6/5012480.008
oError:canDefault   : J
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Interne Datenstrukturen beschädigt
oError:filename     : 
Alias()             : GB331AK
IndexOrd, IndexKey  : 1, ak_eanr+ak_aunr
Filter              : !EMPTY((cAKDt)->ak_eanr) .AND. (cAKDt)->ak_bart=="1"
oError:genCode      :         41
oError:operation    : DbSeek
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :          5
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von GB_AUOPEN(859)
Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Heinz,
ich denke mal, dass bei folgender Schreibweise (extra Klammerung) der Fehler nicht auftreten würde:

Code: Alles auswählen

( .not. EMPTY( (cAKDt)->ak_eanr ) ) .AND. ( (cAKDt)->ak_bart == "1" )
Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Martin,

leider tritt der Fehler auch dann auf:

Code: Alles auswählen

------------------------------------------------------------------------------
FEHLERPROTOKOLL     : 25.09.2006 14:53:05
*
Programm            : "D:\Gb\GB.EXE", Version 2.3.12 Build 302
*
Xbase++ Version     : Xbase++ (R) Version 1.90.331
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 2
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: C VALUE: 6/5000133.000
oError:canDefault   : J
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Interne Datenstrukturen beschädigt
oError:filename     : 
Alias()             : GB331AK
IndexOrd, IndexKey  : 1, ak_eanr+ak_aunr
Filter              : ( !EMPTY((cAKDt)->ak_eanr) ) .AND. ( (cAKDt)->ak_bart=="1" )
oError:genCode      :         41
oError:operation    : DbSeek
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :          5
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von GB_AUOPEN(859)
Aber nochmal meine Frage: wie machst Du es ?

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Martin,

ich nochmal ...

Verstehe ich Deinen Lösungsvorschlag richtig, dass Du glaubst, der Ausdruck (cAKDt) wäre zur Laufzeit nicht aufgelöst und der der Klammerung sollte er bei der Definition aufgelöst werden ?

Aber was für einen Unterschied besteht zwischen GUI- und Hybridmodus, denn im Hybridmodus tritt der Fehler nicht auf ?

grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Gerd König
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 193
Registriert: Fr, 09. Jun 2006 7:52
Wohnort: Nähe Sömmerda

Beitrag von Gerd König »

Hallo Heinz,

Klammer oder Nicht-Klammer führt zu völlig anderen Ergebnissen:

cAKDt->... Der Alias ist cAKDt
(cAKDt)-->--- Die Variable cAKDt enthält den Alias


Viele Grüße

Gerd
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Gerd,

das ist schon klar !

Martin hat doch vorgeschlagen, den Ausdruck nochmal zu umklammern:

Code: Alles auswählen

( .not. EMPTY( (cAKDt)->ak_eanr ) ) .AND. ( (cAKDt)->ak_bart == "1" )
...

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Heinz,
nun ich arbeite einfach mit dem Aliasnamen (nicht in einer Variablen).
Was mich wundert, ist die Zeile am Anfang Deines Errorlogs:

Code: Alles auswählen

-> VALTYPE: C VALUE: 6/5000133.000
Das ist eine Zeichenkette mit einer Division???
Das extra Klammern, das ich meinte, diente nur dem korrekten Gewichten bei der .AND.-Verkettung - da kommt es manchmal zu Problemen...

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo,

in Indexausdrücken oder Datenbankoperationen (z.B. dblocate() etc.), welche selbst mit Alias->(dbfunktion()) aufgerufen werden, verwende ich NIE nochmals den Alias, sondern field-> so ist eindeutig beschrieben, dass es ein FELD der aktuellen DBF ist. Wenn alles stimmt, ist das zwar kein Unterschied, aber wenn man später mal - warum auch immer - den Alias ändern muß, wird ein fest geschriebener Alias leicht übersehen und dann kracht es gewaltig, aber nicht immer mit Fehlermeldung.
Gruß
Hubert
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Martin und Hubert,

vielen Dank für Eure Antworten.

Der Ausdruck " VALTYPE: C VALUE: 6/5000133.000 " in der Fehlermeldung beinhaltet den Suchstring, nachdem in der Datenbank gesucht wurde. Das ist in Ordnung.

Hubert, Du hast Recht, FIELD-> bewirkt dassellbe wie in meinem Beispiel GB331AK-> (Name der Datenbank == Aliasname).
Wenn ich

Code: Alles auswählen

cAKDt := "GB331AK"
(cAKDt)-> 
verwende (cAKDt ist eine PUBLIC-Variable), so muss dieser Ausdruck doch jedesmal aufgelöst werden.
Diesen Ausdruck in einer Filterbedingung verwendet führt zu dem oben dargestellten Fehler, wenn ein DbSeek() ausführe.
Wie man an der Fehlermeldung ( Alias, IndexOrd, -Key ) sieht, ist die Datenbank nebst Index auch (noch) geöffnet.

Meiner Ansicht nach müsste die Variable immer sichtbar sein (da PUBLIC ) und der Ausdruck immer richtig aufgelöst werden. Scheinbar ist dem nicht so ???

Verwende ich den Aliasnamen direkt als Zeichenfolge im Filter: GB331AK-> , also keine Variable, dann tritt der Fehler nicht auf.

Und das alles nur in der GUI-Anwendung. In der Hybridanwendung funktionieren beide Versionen.

...

Zum Schluss: Hubert, gilt das oben bspw. zu DbLocate gesagte auch für Index- und Filterausdrücke. Verwendest Du Aliasoperatoren ( Field->, XX-> oder (cXX)-> ) in Index- und Filterausdrücken ?

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo Heinz,

ich verwende im Index NIE eine Variable, manchmal Funktionen. Mit Private und Public habe ich schon in Clipper abgeschlossen. Statt:

.... (PublicVar)->Feldname = PrivateSuchstring ...

nehme ich beim Rest local Variablen:

.... (LocalVar)->Feldname = '" + PrivateSuchstring + "'" ...
oder
.... field->Feldname = '" + PrivateSuchstring + "'" ...
wenn durch Alias->(dblocate()) etc. die DBF schon festgelegt ist.
Bei den " und ' muß man aufpassen, dass man nicht durcheinander kommt.
Beim Debuggen hilf folgendes:

cSuchbedingung := "Field->Feldname='" + alltrim(cTxt) + "'" // reiner Text kann man gut prüfen
if &(cSuchbedingung) ....

oder wenn ein Codeblock (oft) benutzt wird
cSuchbedingung := "{||Field->Feldname='" + alltrim(cTxt) + "'}" // reiner
bSuchbedingung := &(cSuchbedingung)
...
if eval(bSuchbedingung)
Gruß
Hubert
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Hubert,

vielen Dank für Deine Hilfe. ich habe heute das Programm wie folgt umgestellt:

Code: Alles auswählen


LOCAL cDt := "ALIASNAME", cFil, bFil
...
cFil:= '!EMPTY('+cDt+'->feldname)'
bFil:=&("{ || "+cFil+" }")
DBSETFILTER(bFil,cFil)
...

Ich verwende nun keine Variable mehr, sondern den Alias direkt.

Die Laufzeitfehler sind bei den ersten Tests nicht mehr aufgetreten.
Mal sehen, was der Einsatz in der Praxis bringt ...

Danke nochmals an alle !

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Beitrag von Tom »

Huhu.

Ich muß nochmals zum Ausgangspunkt dieses Threads zurückkommen. Wir kämpfen derzeit mit einer Massierung von Fehlermeldungen der Art "Betriebssystemfehler 1, unzulässige Funktion" bei DbSeek(), DbGoto(), DbCloseArea() und DbCloseAll(). Wie Heinz geschrieben hat, treten solche Fehler bei Wiederholung des exakt gleichen Prozesses sporadisch auf. Wir protokollieren im Fehlerreport alle geöffneten Datenbanken, die selektierte Datenbank und alle betroffenen Operationen - alles scheint in Ordnung zu sein. An diesem Code ist auch nichts geändert worden; mit der 1.82 haben wir diese Massierung nicht erlebt. Wir arbeiten mit DBFNTX (unsere ADS-Kunden haben solche Fehler naturgemäß nie), die DBE-Einstellungen sehen so aus:
DbeInfo(COMPONENT_DATA,DBFDBE_LOCKRETRY,1)
DbeInfo(COMPONENT_DATA,DBFDBE_LOCKDELAY,1)
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,2000000000)
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10)
Vereinzelt gab es das auch mit der 1.82, aber mein Support ist fast am Verzweifeln. Es gibt da zum Beispiel eine Routine, die in einem gesonderten Thread läuft und alle 3 Minuten auf eine Datei zugreift. Sie führt immer wieder eine sehr simple DbSeek-Operation aus. Das funktioniert auch meistens, aber gelegentlich crasht es eben. Kaum verstehbar. Alle Felder werden mit Alias-Operator angesprochen, und inzwischen stehen da auch so Abfragen wie IF Select('MyDB') > 0 und Used() im Code, hilft aber nix. Ein ähnlich gelagertes Problem betrifft DbCloseAll() am Ende eines in einem Thread laufenden Moduls. Alle Relationen und Scopes werden gelöst, trotzdem erhalten wir Fehler wie "Fehler beim Schließen einer Datei". Welcher verdammter Fehler?
Es sollen doch nur die Dateien geschlossen werden, in denen zuvor fehlerfrei gearbeitet werden konnte! :evil:

BTW: Das Problem mit der Energieverwaltung von Netzwerkkarten ("Computer kann Gerät ausschalten, um Energie zu sparen") ist es auch nicht. :lol:
Herzlich,
Tom
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Tom,
also - folgende Anregungen/Hinweise zur Eingrenzung:
  1. Bei allen Kunden, die das Problem haben, liegen die Daten/Indexdateien auf einem Server und nicht lokal?
  2. Haben alle, die das Problem haben, das selbe Betriebssystem (auf Client und/oder Server)?
  3. Die Wahrscheinlichkeit, dass der Index korrupt ist, ist auszuschließen?
  4. Du bist Dir 100% sicher, dass zu dem Zeitpunkt die Datei/der Index noch geöffnet ist?
  5. Deine Abfragen if select... und if used... betreffen ja nur Datenbanken - hast Du sowas auch für die Prüfung der Indexdatei ausprobiert?
Eine Datei zu schließen, die bereits geschlossen ist, kann durchaus den Effekt "Fehler beim Schließen einer Datei" erzeugen - habe ich auch schon erlebt...

Viele Grüße,
Martin
Zuletzt geändert von Martin Altmann am Do, 28. Sep 2006 21:03, insgesamt 1-mal geändert.
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Tom,

ich kam mir schon etwas "verrückt" vor ... Aber scheinbar ist es doch ein "echtes" Problem !

Es ist bei mir nur aufgetreten, wenn das Anwendungsfenster von XbpDialog abgeleitet wurde. Bei einem Hauptfenster von XbpCrt ist es nicht aufgetreten.

Ich hatte die Aliasnamen in einer Public-Variablen, dann in lokalen Variablen gespeichert. Der Aliasoperator sah dann so aus: (cVariable)->feldname.
Am häufigsten sind die Fehler im Zusammenhang mit DbGoto, DbClose oder DbSkip aufgetreten, wenn ich einen Filter definiert habe.

Ich habe nun konsequent alle Aliasoperatoren umgestellt auf den direkten Alias bspw. Datenbank->feldname, wie oben erläutert.

In den letzten beiden Tagen ist der Fehler bei umfangreichen Tests nicht mehr aufgetreten.

Vielleicht lassen sich die Fehler weiter eingrenzen ...

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Beitrag von henxl »

Hallo Tom und Martin,

bei mir handelt es sich um eine Einzelplatzanwendung, die Daten liegen lokal in einem Unterordner zum Programmordner. Nur diese eine Anwendung greift auf die Daten zu.
Die Datenbank und die Indexdatei sind mit Sicherheit noch geöffnet, wie meine oben dargestellte Fehlermeldung zeigt (Filename, IndexOrd, IndexKey).
Und die Indexdatei ist auch nicht korrupt, denn nach dem Programmneustart funktioniert sie wieder einwandfrei.

...

Grüße

Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Beitrag von Tom »

Hallo, Martin.
Bei allen Kunden, die das Problem haben, liegen die Daten/Indexdateien auf einem Server und nicht lokal?
Wir haben so gut wie ausschließlich Kunden, deren Daten- und Indexdateien auf einem Server liegen.
Haben alle, die das Problem haben, das selbe Betriebssystem (auf Client und/oder Server)?
Es scheint vornehmlich mit W2K- und W2003-Server aufzutreten.
Die Wahrscheinlichkeit, dass der Index korrupt ist, ist auszuschließen?
Absolut. Die gleiche Funktion läuft sofort im Anschluß wieder für einige Zeit völlig problemlos.
Du bist Dir 100% sicher, dass zu dem Zeitpunkt die Datei/der Index noch geöffnet ist?
Das tatsächlich nicht. Ich habe vorhin einige Fehlerprotokolle gesichtet, in denen das möglicherweise nicht der Fall war, beim überwiegenden Teil der problematischen Fälle waren Index und Datei jedoch definitiv geöffnet.
Deine Abfragen if select... und if used... betreffen ja nur Datenbanken - hast Du sowas auch für die Prüfung der Indexdatei ausprobiert?
Ich frage an einer Stelle, die immer wieder betroffen ist (Prüfung einer in einem gesonderten Thread geöffneten Nachrichtendatei alle x Minuten auf neue Nachrichten), sogar, ob der Indexausdruck stimmt. Alles scheint korrekt zu sein - trotzdem: Betriebssystemfehler 1, unzulässige Funktion, bei DbSeek() mit einem gültigen Suchbegriff auf einem gültigen Index einer geöffneten Datei. :oops:
Herzlich,
Tom
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Tom,
hmm - und was Heinz schreibt, hilft Dir nicht weiter? Also statt Variablen als Alaisoperator immer den echten Aliasnamen zu nehmen?
Das sollte in Deinem Fall ja zumindest mit der einen Datei gehen, die gsondert immer alle drei Minuten abgefragt wird...

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,
Tom hat geschrieben: DbeInfo(COMPONENT_DATA,DBFDBE_LOCKRETRY,1)
DbeInfo(COMPONENT_DATA,DBFDBE_LOCKDELAY,1)

DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,2000000000)
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10)
also mein (doppel) Schuss ins blaue ...

1.) COMPONENT_DATA ... 1 warum so ein "kleiner" Wert ?
2.) LOCKING_EXTENDED ... eins der "neuerungen" der v1.9x ...
Ich benutzte die DBF zusammen mit Cl*pper v5.2e, also muss mein
DBE_LOCKMODE auch Cl*pper v5.2e kompatible sein. Dies ist aber
nur bei LOCKING_STANDARD bei mir der Fall. (NW320 / W98se)

Was ich immer noch nicht verstehe :
Wird LOCKING_EXTENDED eingestellt, so erhöht sich die Performance
von Such- und Navigations-Operationen erheblich, da mit EXTENDED_LOCKING ein wechselseitiger Ausschluß von Index Operationen nur noch bei Schreibvorgängen notwendig ist.
für welches OS gilt das ? was ist mit NW-Servern ?
was heist "wechselseitiger Ausschluß" ?

gruss y OHR
Jimmy
Antworten