Hilfe bei sporadischen Problemen
Moderator: Moderatoren
Hilfe bei sporadischen Problemen
Hallo liebe Xbase Gemeide,
ich habe ein Problem, welches ich nicht selbst gelöst bekomme. Habe schon die Newsgroups durchkämmt, aber irgenwie ohne befriedigenden Erfolg. Doch nun zu meinem Problem:
- Xbase++ aktuellste Version
- Betriebsystem der Anwendung: unterschiedlich i.d.R. XP
- Multithreading Anwendung aus Clipper portiert
- Teilweise Netzwerkumgebungen
- DBE: ohne Tricks:
SET COLLATION TO GERMAN
SET DATE TO GERMAN
******* and are combined to the abstract database engine DBFNTX
IF ! DbeLoad( "DBFDBE", .T.)
khMsg("Database engine DBFDBE not loaded")
ENDIF
IF ! DbeLoad( "NTXDBE",.T.)
khMsg("Database engine NTXDBE not loaded")
ENDIF
IF ! DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
khMsg("DBFNTX database engine could not be created")
ENDIF
Die Anwendung stürzt ab und gibt folgende Fehlermeldung, die - meiner Meinung und eigentlich auch meiner Erfahrung nach - nicht logisch sind:
Hier zwei Quellcodeauszüge:
------------------------------------------------------------------------------
Fehlerprotokoll von: D:\hvw-win\hvw-win.exe Datum: 02.04.07 17:10:49
Xbase++ Version : Xbase++ (R) Version 1.90.331
Betriebsystem : Windows XP 05.01 Build 02600 Service Pack 2
Programmversion : Version 5.0.067
Parameter : /tab2/maxi/master
Speicher VIRT_AVAIL : 807361
Speicher VIRT_TOTAL : 1128448
Speicher RAM_AVAIL : 318464
Speicher RAM_TOTAL : 491520
Speicher PROC_TOTAL : 815620
------------------------------------------------------------------------------
oError:args :
-> VALTYPE: C VALUE: xx_NK612.NTX
-> VALTYPE: C VALUE: NAME
-> VALTYPE: B VALUE: {|| NAME}
-> VALTYPE: U VALUE: NIL
oError:canDefault : J
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCreateIndex
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 6
oError:tries : 1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von CHECKIN(198)
-------------------- CHECKIN -----------------------------
197: Temp2 := khTempFile() -> something like XX_1234
198: index on NAME to &Temp2
199: set index to &Temp2
200: goto top
-------------------- End CHECKIN -------------------------
######### Anderes Beispiel ##################
------------------------------------------------------------------------------
Fehlerprotokoll von: C:\Programme\HVW\hvw-win.exe Datum: 25.03.07 07:10:55
Xbase++ Version : Xbase++ (R) Version 1.90.331
Betriebsystem : Windows XP 05.01 Build 02600 Service Pack 2
Programmversion : Version 5.0.067
Parameter :
Speicher VIRT_AVAIL : 807230
Speicher VIRT_TOTAL : 1128448
Speicher RAM_AVAIL : 147456
Speicher RAM_TOTAL : 490496
Speicher PROC_TOTAL : 815620
------------------------------------------------------------------------------
oError:args :
oError:canDefault : J
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCloseAll
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 4
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von VERWALTUNG(729)
-------------------- Verwaltung -----------------------------
729: close databases
-------------------- Ende Verwaltung ------------------------
Ich bin für jeden Hinweis dankbar, da die Fehler sporadisch auftreten und nicht reproduzierbar sind.
Ich verfolge gerade Hinweise auf EXTENDED_LOCKING, aber die gibt es wohl nur für CDXDBE - oder ist es sinnvoll die DBE zu wechseln....???
Danke im voraus!
Karl Heinz Hammelrath
ich habe ein Problem, welches ich nicht selbst gelöst bekomme. Habe schon die Newsgroups durchkämmt, aber irgenwie ohne befriedigenden Erfolg. Doch nun zu meinem Problem:
- Xbase++ aktuellste Version
- Betriebsystem der Anwendung: unterschiedlich i.d.R. XP
- Multithreading Anwendung aus Clipper portiert
- Teilweise Netzwerkumgebungen
- DBE: ohne Tricks:
SET COLLATION TO GERMAN
SET DATE TO GERMAN
******* and are combined to the abstract database engine DBFNTX
IF ! DbeLoad( "DBFDBE", .T.)
khMsg("Database engine DBFDBE not loaded")
ENDIF
IF ! DbeLoad( "NTXDBE",.T.)
khMsg("Database engine NTXDBE not loaded")
ENDIF
IF ! DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
khMsg("DBFNTX database engine could not be created")
ENDIF
Die Anwendung stürzt ab und gibt folgende Fehlermeldung, die - meiner Meinung und eigentlich auch meiner Erfahrung nach - nicht logisch sind:
Hier zwei Quellcodeauszüge:
------------------------------------------------------------------------------
Fehlerprotokoll von: D:\hvw-win\hvw-win.exe Datum: 02.04.07 17:10:49
Xbase++ Version : Xbase++ (R) Version 1.90.331
Betriebsystem : Windows XP 05.01 Build 02600 Service Pack 2
Programmversion : Version 5.0.067
Parameter : /tab2/maxi/master
Speicher VIRT_AVAIL : 807361
Speicher VIRT_TOTAL : 1128448
Speicher RAM_AVAIL : 318464
Speicher RAM_TOTAL : 491520
Speicher PROC_TOTAL : 815620
------------------------------------------------------------------------------
oError:args :
-> VALTYPE: C VALUE: xx_NK612.NTX
-> VALTYPE: C VALUE: NAME
-> VALTYPE: B VALUE: {|| NAME}
-> VALTYPE: U VALUE: NIL
oError:canDefault : J
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCreateIndex
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 6
oError:tries : 1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von CHECKIN(198)
-------------------- CHECKIN -----------------------------
197: Temp2 := khTempFile() -> something like XX_1234
198: index on NAME to &Temp2
199: set index to &Temp2
200: goto top
-------------------- End CHECKIN -------------------------
######### Anderes Beispiel ##################
------------------------------------------------------------------------------
Fehlerprotokoll von: C:\Programme\HVW\hvw-win.exe Datum: 25.03.07 07:10:55
Xbase++ Version : Xbase++ (R) Version 1.90.331
Betriebsystem : Windows XP 05.01 Build 02600 Service Pack 2
Programmversion : Version 5.0.067
Parameter :
Speicher VIRT_AVAIL : 807230
Speicher VIRT_TOTAL : 1128448
Speicher RAM_AVAIL : 147456
Speicher RAM_TOTAL : 490496
Speicher PROC_TOTAL : 815620
------------------------------------------------------------------------------
oError:args :
oError:canDefault : J
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCloseAll
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 4
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von VERWALTUNG(729)
-------------------- Verwaltung -----------------------------
729: close databases
-------------------- Ende Verwaltung ------------------------
Ich bin für jeden Hinweis dankbar, da die Fehler sporadisch auftreten und nicht reproduzierbar sind.
Ich verfolge gerade Hinweise auf EXTENDED_LOCKING, aber die gibt es wohl nur für CDXDBE - oder ist es sinnvoll die DBE zu wechseln....???
Danke im voraus!
Karl Heinz Hammelrath
Beste Grüße
Karl Heinz
Karl Heinz
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1931
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Hallo Karl-Heinz,
also ich arbeite nicht mit NTX. Dabei muß man für jeden index eine neue ntx-Datei erstellen. Deshalb arbeite ich mit cdx, da hierbei mehrere cdx-Tags in einer Datei verwendet werden können.
Hier ist mein Quellcode aus der dbesys.prg. Hiermit habe ich keine Probleme. Vielleicht hilft es dir.
PROCEDURE DbeSys
#include "DbfDbe.ch"
#include "Dmlb.Ch"
IF ! DbeLoad( "DBFDBE", .T.) // Engine für DBF-Dateien laden
ALERT( "Database Engine DBFDBE nicht geladen" , {"OK"} )
ENDIF
IF ! DbeLoad( "CDXDBE" , .T.) // Engine für CDX-Dateien laden
ALERT( "Database Engine CDXDBE nicht geladen" , {"OK"} )
ENDIF
// Engines für Datensatz- und
// Index-Management zusammenfügen
IF ! DbeBuild( "DBFCDX", "DBFDBE", "CDXDBE" )
ALERT( "Database Engine DBFCDX nicht erzeugt" , {"OK"} )
ENDIF
DbeSetDefault("DBFCDX")
RETURN
also ich arbeite nicht mit NTX. Dabei muß man für jeden index eine neue ntx-Datei erstellen. Deshalb arbeite ich mit cdx, da hierbei mehrere cdx-Tags in einer Datei verwendet werden können.
Hier ist mein Quellcode aus der dbesys.prg. Hiermit habe ich keine Probleme. Vielleicht hilft es dir.
PROCEDURE DbeSys
#include "DbfDbe.ch"
#include "Dmlb.Ch"
IF ! DbeLoad( "DBFDBE", .T.) // Engine für DBF-Dateien laden
ALERT( "Database Engine DBFDBE nicht geladen" , {"OK"} )
ENDIF
IF ! DbeLoad( "CDXDBE" , .T.) // Engine für CDX-Dateien laden
ALERT( "Database Engine CDXDBE nicht geladen" , {"OK"} )
ENDIF
// Engines für Datensatz- und
// Index-Management zusammenfügen
IF ! DbeBuild( "DBFCDX", "DBFDBE", "CDXDBE" )
ALERT( "Database Engine DBFCDX nicht erzeugt" , {"OK"} )
ENDIF
DbeSetDefault("DBFCDX")
RETURN
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Hallo Karl-Heinz,
ich vermute, der Fehler 8999 hängt mit dem Zugriff auf die Dateien zusammmen. Falls der Fehler reproduzierbar ist, versuche es mal
mit den Dateien auf einem lokalen Rechner. Falls da der Fehler ebenfalls kommt, bau die Indexdateien neu auf. Klappt es dann?
Uli
P.S. Falls der Aufwand gering ist, würde ich auf CDX-Indexdateien umsteigen. Damit soll xBase wesentlich stabiler laufen.
ich vermute, der Fehler 8999 hängt mit dem Zugriff auf die Dateien zusammmen. Falls der Fehler reproduzierbar ist, versuche es mal
mit den Dateien auf einem lokalen Rechner. Falls da der Fehler ebenfalls kommt, bau die Indexdateien neu auf. Klappt es dann?
Uli
P.S. Falls der Aufwand gering ist, würde ich auf CDX-Indexdateien umsteigen. Damit soll xBase wesentlich stabiler laufen.
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Karl Heinz,
normalerweise hast Du recht. Die Umstellung ist einfach. Einfach die neuen Indizee erstellen, fertig. Es gibt aber in der Tat ein paar Punkte zu beachten:
Du kannst (musst nicht) bei CDX mit Tags arbeiten. Also mehrere Indizee in eine Datei packen. Das nutze ich sehr, weil dann zu jeder dbf immer genau ein Indexdatei existiert, die genau gleich lautet. In dem Fall musst Du dann nach Öffnen den richtigen Tag über OrdSetFocus() bestimmen. Das wäre dann in der Tat etwas Umschreib-Arbeit für Dich.
Und kontrolliere bitte, ob beim neu indizieren immer die alte Indexdatei erst gelöscht wird. Es kann unter NTX sonst manchmal Probleme geben, wenn der Index irgendwo korrupt ist. Unter CDX wächst in jedem Fall die Datei mit jedem mal indizieren an.
Jan
normalerweise hast Du recht. Die Umstellung ist einfach. Einfach die neuen Indizee erstellen, fertig. Es gibt aber in der Tat ein paar Punkte zu beachten:
Du kannst (musst nicht) bei CDX mit Tags arbeiten. Also mehrere Indizee in eine Datei packen. Das nutze ich sehr, weil dann zu jeder dbf immer genau ein Indexdatei existiert, die genau gleich lautet. In dem Fall musst Du dann nach Öffnen den richtigen Tag über OrdSetFocus() bestimmen. Das wäre dann in der Tat etwas Umschreib-Arbeit für Dich.
Und kontrolliere bitte, ob beim neu indizieren immer die alte Indexdatei erst gelöscht wird. Es kann unter NTX sonst manchmal Probleme geben, wenn der Index irgendwo korrupt ist. Unter CDX wächst in jedem Fall die Datei mit jedem mal indizieren an.
Jan
- Bertram Hansen
- Foren-Moderator
- Beiträge: 1020
- Registriert: Di, 27. Sep 2005 8:55
- Wohnort: 51379 Leverkusen
- Hat sich bedankt: 28 Mal
- Danksagung erhalten: 20 Mal
- Kontaktdaten:
Karl Heinz,
hier ein Auszug aus der Fehler Code Liste von Andreas Gehrs-Pahl (gepostet in public.xbase++.bugreport am 3. November 2005 15:05)
Vielleicht hilft Dir das weiter.
hier ein Auszug aus der Fehler Code Liste von Andreas Gehrs-Pahl (gepostet in public.xbase++.bugreport am 3. November 2005 15:05)
Code: Alles auswählen
899x - General Database Errors ?:
---------------------------------
8999 - [BASE] - Multipurpose SubCode for most Database Errors ?
Associated with: "10:Numeric overflow"
Caused by: "DbGoto()"
Associated with: "62:Invalid data type for database field"
Caused by: ???
Associated with: "64:Invalid length of index key"
Caused by: ???
Associated with: "70:File can not be created"
Caused by: "OrdCreate()"
Associated with: "71:File can not be opened"
Caused by: "DbUseArea()", "OrdListAdd()"
Associated with: "73:Error while reading a file"
Caused by: "DbUseArea()", "OrdListAdd()", "DbSkip()", "DbSeek()"
Associated with: "79:Record lock failed"
Caused by: "OrdListAdd()", "DbSkip()", "DbSeek()", "DbGoTop()", "DbAppend()"
Associated with: "903:Database header invalid"
Caused by: "DbUseArea()"
Associated with: "940:Memo file is missing on use"
Caused by: "DbUseArea()"
Gruß Bertram
http://www.tobax.de
Mitglied der XUG Cologne
Mitglied der XUG Osnabrück
Beisitzer des Deutschsprachige Xbase-Entwickler e.V.
Solange Kakaobohnen an Bäumen wachsen ist Schokolade Obst!
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Hi,
Fehlermeldung wie Overlaydatei nicht gefunden (noch zu Clipperzeiten) oder während des Betriebs fehldende DBF NTX Dateien konnten meist auf Netzwerkprobleme (Überlastungen) eingegrenzt werden. Seit wir Citrix haben und somit nur 3 Rechner im Backbone auf den DBF Fileserver zugreifen trat sowas nicht mehr auf.
Es gibt zu den erwähnten Unterschieden von DBFNTX zu FOXCDX (DBFCDX wäre auch noch eine Möglichkeit) noch weitere eventuell wichtige Unterschiede:
ANSI im Index, OEM in der DBF (je nach Einstellung bei Create) könnte bei einigen Suchbegriffen Probleme bereiten.
Auf jeden Fall sucht ein CDX immer vergleichbar mit upper(xxx) - also unabhängig von Groß-/Kleinschreibung. Man kann somit nicht nach allen mit Kleinbuchstaben beginnenden Namen suchen
Nichts schlimmes, aber man muss es wissen.
Sehr vorteilhaft beim FOXCDX sind die wesentlich kleineren Memodateien.
Fehlermeldung wie Overlaydatei nicht gefunden (noch zu Clipperzeiten) oder während des Betriebs fehldende DBF NTX Dateien konnten meist auf Netzwerkprobleme (Überlastungen) eingegrenzt werden. Seit wir Citrix haben und somit nur 3 Rechner im Backbone auf den DBF Fileserver zugreifen trat sowas nicht mehr auf.
Es gibt zu den erwähnten Unterschieden von DBFNTX zu FOXCDX (DBFCDX wäre auch noch eine Möglichkeit) noch weitere eventuell wichtige Unterschiede:
ANSI im Index, OEM in der DBF (je nach Einstellung bei Create) könnte bei einigen Suchbegriffen Probleme bereiten.
Auf jeden Fall sucht ein CDX immer vergleichbar mit upper(xxx) - also unabhängig von Groß-/Kleinschreibung. Man kann somit nicht nach allen mit Kleinbuchstaben beginnenden Namen suchen
Nichts schlimmes, aber man muss es wissen.
Sehr vorteilhaft beim FOXCDX sind die wesentlich kleineren Memodateien.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Hilfe bei sporadischen Problemen
hi,
man sollte den ganzen String aus der Errorlog kopieren und dann im
Alaska Forum danach suchen also z.b. :
- XP ... freigegebene Ordner auf dem PC ? wenn ja Op´s lock settings ?
- Multitreading - Workspacelist(). bist du auch immer im richtigen Thread
- Netzwerk : bei einem XP PC ist default der "SERVER" Dienst aktive d.h
du musst auch die Op´s lock auf Server & Workstation configurieren.
p.s. ich hoffe kein peer-to-peer Netzwerk ...
-DBE ohne weitere _LOCK Parameter nicht in Griff zu bekommen.
p.s. ist "Temp2" ein PRIVATE ?
warum Macro und nicht "index on FIELD->NAME to (Temp2)
oder besser über WorkSpaceList() abarbeiten.
Ich würde auch die ErrorSys.PRG erweitern damit du z.b. siehst ob die
DBF überhaupt noch offen ist, auf welche RECNO() du stehst etc.
gruss by OHR
Jimmy
Frage wie sucht du ?kallecux hat geschrieben: ich habe ein Problem, welches ich nicht selbst gelöst bekomme. Habe schon die Newsgroups durchkämmt, aber irgenwie ohne befriedigenden Erfolg.
man sollte den ganzen String aus der Errorlog kopieren und dann im
Alaska Forum danach suchen also z.b. :
also inclusive aller Leerzeichen"oError:genCode : 8999"
- Hotfix 1-5 sollte man verwenden (hat aber nicht mit dem Problem zu tun)kallecux hat geschrieben: - Xbase++ aktuellste Version
- Betriebsystem der Anwendung: unterschiedlich i.d.R. XP
- Multithreading Anwendung aus Clipper portiert
- Teilweise Netzwerkumgebungen
- DBE: ohne Tricks:
- XP ... freigegebene Ordner auf dem PC ? wenn ja Op´s lock settings ?
- Multitreading - Workspacelist(). bist du auch immer im richtigen Thread
- Netzwerk : bei einem XP PC ist default der "SERVER" Dienst aktive d.h
du musst auch die Op´s lock auf Server & Workstation configurieren.
p.s. ich hoffe kein peer-to-peer Netzwerk ...
-DBE ohne weitere _LOCK Parameter nicht in Griff zu bekommen.
typisches DBE _LOCK Problem.kallecux hat geschrieben: oError:args :
-> VALTYPE: C VALUE: xx_NK612.NTX
-> VALTYPE: C VALUE: NAME
-> VALTYPE: B VALUE: {|| NAME}
-> VALTYPE: U VALUE: NIL
oError:canDefault : J
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCreateIndex
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 6
oError:tries : 1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von CHECKIN(198)
-------------------- CHECKIN -----------------------------
197: Temp2 := khTempFile() -> something like XX_1234
198: index on NAME to &Temp2
199: set index to &Temp2
200: goto top
-------------------- End CHECKIN -------------------------
p.s. ist "Temp2" ein PRIVATE ?
warum Macro und nicht "index on FIELD->NAME to (Temp2)
bekanntest Problem, immer zuerst in den niedriegsten SELECT() schaltenkallecux hat geschrieben: ------------------------------------------------------------------------------
Fehlerprotokoll von: C:\Programme\HVW\hvw-win.exe Datum: 25.03.07 07:10:55
Xbase++ Version : Xbase++ (R) Version 1.90.331
Betriebsystem : Windows XP 05.01 Build 02600 Service Pack 2
Programmversion : Version 5.0.067
Parameter :
Speicher VIRT_AVAIL : 807230
Speicher VIRT_TOTAL : 1128448
Speicher RAM_AVAIL : 147456
Speicher RAM_TOTAL : 490496
Speicher PROC_TOTAL : 815620
------------------------------------------------------------------------------
oError:args :
oError:canDefault : J
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCloseAll
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 4
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von VERWALTUNG(729)
-------------------- Verwaltung -----------------------------
729: close databases
-------------------- Ende Verwaltung ------------------------
oder besser über WorkSpaceList() abarbeiten.
Ich würde auch die ErrorSys.PRG erweitern damit du z.b. siehst ob die
DBF überhaupt noch offen ist, auf welche RECNO() du stehst etc.
gruss by OHR
Jimmy
Code: Alles auswählen
// DBESYS.PRG
#include "DBFDBE.CH"
#include "NTXDBE.CH"
#include "FOXDBE.CH"
#include "CDXDBE.CH"
// Text-Konstanten
#define MSG_DBFDBE_NOT_LOADED "Database-Engine DBFDBE nicht geladen"
#define MSG_NTXDBE_NOT_LOADED "Database-Engine NTXDBE nicht geladen"
#define MSG_DBFNTX_NOT_CREATED "DBFNTX Database-Engine;konnte nicht erzeugt werden"
PROCEDURE dbeSys()
/*
* Setzen der Sortierfolge und des Datumformates
*/
SET COLLATION TO GERMAN
* SET DATE TO GERMAN
* SET COLLATION OFF // CDX mit Clipper zusammen !!!
* SET COLLATION TO ASCII // „”
Hallo Jimmy,
vielen Dank für die ausführlichen Antwort, kannst Du mir bitte Hinweise auf Deine folgenden Bemerkungen geben:
"- Netzwerk : bei einem XP PC ist default der "SERVER" Dienst aktive d.h
du musst auch die Op´s lock auf Server & Workstation configurieren.
p.s. ich hoffe kein peer-to-peer Netzwerk ... "
Op's lock?
"-DBE ohne weitere _LOCK Parameter nicht in Griff zu bekommen. "
Ich lade die DBE nun mit folgenden Einstellungen:
IF ! DbeLoad( "DBFDBE", .T.)
khMsg("Database engine DBFDBE not loaded")
ENDIF
IF ! DbeLoad( "NTXDBE",.T.)
khMsg("Database engine NTXDBE not loaded")
ENDIF
IF ! DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
khMsg("DBFNTX database engine could not be created")
ENDIF
// Hier kommt ein experimenteller Teil, der sporadisch auftretende
// Fehler beheben soll. 24.08.2007
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED) // 24.08.2007 ab 5.0.075
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,20000000) // 24.08.2007 ab 5.0.075
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10) // 24.08.2007 ab 5.0.075
// ------------- Ende experimenteller Teil ----------------------------------
"typisches DBE _LOCK Problem.
p.s. ist "Temp2" ein PRIVATE ?
warum Macro und nicht "index on FIELD->NAME to (Temp2) "
Werde hier auf () umstellen - warum die Frage nach PRIVATE?
"bekanntest Problem, immer zuerst in den niedriegsten SELECT() schalten
oder besser über WorkSpaceList() abarbeiten. "
Soll ich statt close databases in allen Selectbereichen einzeln die Datenbanken schließen?
Freundliche Grüße
Karl Heinz
vielen Dank für die ausführlichen Antwort, kannst Du mir bitte Hinweise auf Deine folgenden Bemerkungen geben:
"- Netzwerk : bei einem XP PC ist default der "SERVER" Dienst aktive d.h
du musst auch die Op´s lock auf Server & Workstation configurieren.
p.s. ich hoffe kein peer-to-peer Netzwerk ... "
Op's lock?
"-DBE ohne weitere _LOCK Parameter nicht in Griff zu bekommen. "
Ich lade die DBE nun mit folgenden Einstellungen:
IF ! DbeLoad( "DBFDBE", .T.)
khMsg("Database engine DBFDBE not loaded")
ENDIF
IF ! DbeLoad( "NTXDBE",.T.)
khMsg("Database engine NTXDBE not loaded")
ENDIF
IF ! DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
khMsg("DBFNTX database engine could not be created")
ENDIF
// Hier kommt ein experimenteller Teil, der sporadisch auftretende
// Fehler beheben soll. 24.08.2007
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED) // 24.08.2007 ab 5.0.075
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,20000000) // 24.08.2007 ab 5.0.075
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10) // 24.08.2007 ab 5.0.075
// ------------- Ende experimenteller Teil ----------------------------------
"typisches DBE _LOCK Problem.
p.s. ist "Temp2" ein PRIVATE ?
warum Macro und nicht "index on FIELD->NAME to (Temp2) "
Werde hier auf () umstellen - warum die Frage nach PRIVATE?
"bekanntest Problem, immer zuerst in den niedriegsten SELECT() schalten
oder besser über WorkSpaceList() abarbeiten. "
Soll ich statt close databases in allen Selectbereichen einzeln die Datenbanken schließen?
Freundliche Grüße
Karl Heinz
Beste Grüße
Karl Heinz
Karl Heinz
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
ein "white paper" von Steffen F. Pirsig über "Opportunistic locking".
Allerdings ist es auf dem Stand NT d.h. du brauchst auch die neueren
für W2K / XP / Vista.
dann auch mal versuchen. siehe auch hier im Forum unter "Installation
und Redistribution" dort gibt es 2 "Tools" zu prüfen/setzten von OP´s lock
Ordnung lege, sowas muss ich gleich "aufräumen"
dem SELECT() Bereich wo du gerade bist eine DBF nicht (mehr) geöffnet
ist. Also entweder mit USED() prüfen oder meine FUNCTION WSLclose()
benutzen.
gruss by OHR
Jimmy
schau mal bei Alaska-Software im ASCN Download Bereich. Dort solltekallecux hat geschrieben: Op's lock?
ein "white paper" von Steffen F. Pirsig über "Opportunistic locking".
Allerdings ist es auf dem Stand NT d.h. du brauchst auch die neueren
für W2K / XP / Vista.
das ist doch schon mal ganz gut für den Index. Für die DBF solltest du eskallecux hat geschrieben: // Hier kommt ein experimenteller Teil, der sporadisch auftretende
// Fehler beheben soll. 24.08.2007
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED) // 24.08.2007 ab 5.0.075
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,20000000) // 24.08.2007 ab 5.0.075
DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10) // 24.08.2007 ab 5.0.075
// ------------- Ende experimenteller Teil ----------------------------------
dann auch mal versuchen. siehe auch hier im Forum unter "Installation
und Redistribution" dort gibt es 2 "Tools" zu prüfen/setzten von OP´s lock
ich habe lediglich das & gesehen. Auch wenn ich sonst nicht viel Wert aufkallecux hat geschrieben: Werde hier auf () umstellen - warum die Frage nach PRIVATE?
Ordnung lege, sowas muss ich gleich "aufräumen"
Im Prinzip sollte es ja gehen nur manchmal geht es eben nicht wenn inkallecux hat geschrieben: Soll ich statt close databases in allen Selectbereichen einzeln die Datenbanken schließen?
dem SELECT() Bereich wo du gerade bist eine DBF nicht (mehr) geöffnet
ist. Also entweder mit USED() prüfen oder meine FUNCTION WSLclose()
benutzen.
gruss by OHR
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Hilfe bei sporadischen Problemen
Auch ich hatte eben auf einem neuen Web-Server diese Probleme mit der Indexerzeugung.
Kurze Lösung: DBFCDX statt DBFNTX und die (CDX) Indexe wurden wieder erzeugt. Warum ? Keine Ahnung ...
Kurze Lösung: DBFCDX statt DBFNTX und die (CDX) Indexe wurden wieder erzeugt. Warum ? Keine Ahnung ...
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Hilfe bei sporadischen Problemen
Und nun den Grund, warum es gekracht hat:
auf dem neuen Server hatte ich in PLESK nur das Recht "schreiben" zusätzlich angeklickt.
Um eine Datei löschen zu können muss aber auch "bearbeiten" erlaubt werden.
Scheinbar wird die CDX anders angelegt als eine NTX, beim Löschen bemerkte ich aber dass keine Dateien gelöscht werden ...
Schlagworte: WEB-Server, Schreibrechte
auf dem neuen Server hatte ich in PLESK nur das Recht "schreiben" zusätzlich angeklickt.
Um eine Datei löschen zu können muss aber auch "bearbeiten" erlaubt werden.
Scheinbar wird die CDX anders angelegt als eine NTX, beim Löschen bemerkte ich aber dass keine Dateien gelöscht werden ...
Schlagworte: WEB-Server, Schreibrechte
Gruß
Hubert
Hubert
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2945
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Hilfe bei sporadischen Problemen
Ja, bei CDX wird hinten angehängt, NTX wird neu erzeugt, daher nicht vergessen bei CDX, vorher die Datei zu löschen, sonst gibt es irgendwann Probleme mit der Dateigröße.
Viele Grüße
Wolfgang
Wolfgang