XBase und Visual FoxPro - Defekte Indexdateien.

[andreas]

Hallo Leute,

seit der Umstellung auf die Version 1.9 haben wir viele Probleme mit den Indexdateien.

Kurz zur Umgebung:

Wir haben ein fremdes ERP-Programm, das in VFP geschrieben ist und FOXCDX-Dateien benutzt.

Unser Xbase-PRogramm greift auf die Dateien des oben genannten Programms zum Lesen und Schreiben der Daten. Sobald unser Programm in die Datenbanken schreibt, müssen wir mehrmals am Tag im ERP die Indexreparatur anstossen, damit beide Programme wieder richtig funktionieren und alle Daten finden können.

Unter XBase verwende ich die Default-Einstellungen (ich habe keine Einstellungen für FOXCDX geändert).

Unter FoxPro habe ich gerade mit dem Befehl

Code: Alles auswählen

? sys(2029, 1) 

den Typ der Tabellen abgefragt, die von ERP benutzt werden.
Das ist Typ 245 und laut Dokumentation

Frühere FoxPro-Versionen mit einem Memofeld

.

Kennt sich jemand mit den Einstellungen für FoxCdx?
Was und wie muss ich da einstellen, um diese Probleme los zu werden?

[UliTs]

Hallo Andreas,

ich meine, bei xBase 1.90.331 gelesen zu haben, daß die Indexdateien nicht kompatibel zur Vorgängerversion (1.8x) sind. Folglich muß es sicher auch Probleme z.B. mit FoxPro geben. Ich würde mal bei Alaska nachfragen.

Uli

[AUGE_OHR]

hi,

seit der Umstellung auf die Version 1.9 haben wir viele Probleme mit den Indexdateien.

Kurz zur Umgebung:

Wir haben ein fremdes ERP-Programm, das in VFP geschrieben ist und FOXCDX-Dateien benutzt.

verwendest du eine eigene DBESYS.PRG ?

Auch wenn in den Help File steht das es "kompatible" zu "Visual FoxPro,
FoxPro 2.x, Comix und SIX Clipper" wäre stimmt meine Meinung nach
der "Lockmode" nicht. Versuche mal direkt FOXDBE_LOCKMODE zu
setzten.

gruss by OHR
Jimmy

[andreas]

Hallo Jimmy,

ich verwende die von Alaska gelieferte DBESYS.PRG.

Mit dem Lockmode habe ich das so verstanden, dass XBase es automatisch erkennen muss. Allerdings habe ich mit den Standarteinstellungen aus der Beschreibung in der Dokumentation nichts verstanden.
Was ist den die Standarteinstellung:

Konstanten für Verfahren zur Datensatzsperre

Konstante Beschreibung

FOXDBE_LOCKMODE_AUTO *) Xbase++ erkennt das anzuwendende

Sperrverfahren automatisch.

FOXDBE_LOCKMODE_2X Verwende nur das Verfahren von FoxPro 2.x

FOXDBE_LOCKMODE_VISUAL Verwende nur das Verfahren von Visual FoxPro

FOXDBE_LOCKMODE_CLIPPER Verwende nur das Verfahren von Clipper Comix or Six

*) Standardwert

oder

// Mittels der nachfolgenden zwei DbeInfo() Einstellungen wird die FOXDBE

// veranlaßt Visual FoxPro kompatible Dateien zu erzeugen und das Visual

// FoxPro kompatible Sperrverfahren anzuwenden. (Voreinstellung der FOXDBE)

//

DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .F. )

DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDFBE_LOCKMODE_VISUAL )

Was für Lockmode soll ich setzen, wenn man meine Angaben in der Fehlerbeschreibung oben beachtet?

[andreas]

Hallo Jimmy,

noch mal über die DBESYS.PRG.

Deine Frage mit der Dateierweiterung .PRG hat mich beim Antworten etwas verwirt. Ich verwende eigene Procedure, die ich irgend wann aus den Beispielen zusammengestellt habe, die folgend aussieht:

Code: Alles auswählen

PROCEDURE DBESYS()

	IF ! DbeLoad( "FOXDBE", .t.)
		ConfirmBox(,"Database-Engine FOXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	IF ! DbeLoad( "CDXDBE" ,.t.)
		ConfirmBox(,"Database-Engine CDXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	IF ! DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
		ConfirmBox(,"FOXCDX does not create!","Error",XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	DbeLoad( "ODBCDBE" )

	DbeSetDefault( "ODBCDBE" )
	

RETURN

[Martin Altmann]

Hallo Andreas,
lass' Dich nicht verwirren
Das war so schon richtig, da Du die normalerweise genutzte und automatisch eingebundene DBESYS.PRG hier findest: ALASKA\XPPW32\SOURCE\SYS
Hast Du natürlich eine eigene DBESYS.PRG in Deinem Projectfile (oder in einer Deiner PRGs eine eigene PROCEDURE DBESYS() ), dann wird stattdessen Deine Prozedur verwendet.

Viele Grüße,
Martin

[AUGE_OHR]

hi,

ich verwende die von Alaska gelieferte DBESYS.PRG.

Mit dem Lockmode habe ich das so verstanden, dass XBase es automatisch erkennen muss. Allerdings habe ich mit den Standarteinstellungen aus der Beschreibung in der Dokumentation nichts verstanden.

im Prinzip ja ... allerdings bin ich der Meinung das es nicht korrekt
erkennt "was" für eine DBF er nun hat. ich vermute mal das er am
"header" meint zu erkennen was es wäre und das stimmt meistens
nicht wenn es sich um "FOX" Typen handelt.

FOXDBE_LOCKMODE_2X Verwende nur das Verfahren von FoxPro 2.x

FOXDBE_LOCKMODE_VISUAL Verwende nur das Verfahren von Visual FoxPro

FOXDBE_LOCKMODE_CLIPPER Verwende nur das Verfahren von Clipper Comix or Six

das sind die verschiedenen Type die Xbase++ kennt

DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .F. )
DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDFBE_LOCKMODE_VISUAL )

damit setzt du die auf "Visual FoxPro" kompatible Daten ( =DBF)

Was für Lockmode soll ich setzen, wenn man meine Angaben in der Fehlerbeschreibung oben beachtet?

je nachdem was für DBF du nun hast (Hexeditor Header der DBF ansehen)

du benutzt bisher aber "nur" COMPONENT_DATA für den "Datentyp"
der DBF, es fehlt komplett "dein Problem" die Index Componenten.

siehe 2 Antwort

gruss by OHR
Jimmy

[AUGE_OHR]

hi,

Code: Alles auswählen

PROCEDURE DBESYS()

	IF ! DbeLoad( "FOXDBE", .t.)
		ConfirmBox(,"Database-Engine FOXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	IF ! DbeLoad( "CDXDBE" ,.t.)
		ConfirmBox(,"Database-Engine CDXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	IF ! DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
		ConfirmBox(,"FOXCDX does not create!","Error",XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	DbeLoad( "ODBCDBE" )

	DbeSetDefault( "ODBCDBE" )
	

RETURN

das ist eine "modifizierte" DBESYS.PRG. Wie man "erkennt" wird nur
"standart" FOX geladen. füge erstmal den "richtigen" DBF Type hinzu.

nun zu deinen Index (was so nicht geht mit "Fox") :

DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY, 100000 )
DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY, 20 )

DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY, 100000 )
DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY, 20 )

damit "erhöchst" du sowohl die COMPONENT_DATA als auch die
COMPONENT_ORDER was bei mir, vorallem im Netzwerk, deutlich
besser läuft und die Index "stabil" lässt.

gruss by OHR
Jimmy
p.s. das ganze VOR ODBC...

[andreas]

Hallo Jimmy,

ich habe versucht, deine Vorschläge zu verwenden.

Code: Alles auswählen

PROCEDURE DBESYS()

	IF ! DbeLoad( "FOXDBE", .t.)
		ConfirmBox(,"Database-Engine FOXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF


	IF ! DbeLoad( "CDXDBE" ,.t.)
		ConfirmBox(,"Database-Engine CDXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	IF ! DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
		ConfirmBox(,"FOXCDX does not create!","Error",XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY, 20 )

	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY, 20 )

	DbeLoad( "ODBCDBE" )

	DbeSetDefault( "ODBCDBE" )

RETURN

Beim Programmstart kommt das Programm in die Prozessliste mit grosser CPU-Last. Das Fenster kommt aber nicht.
Ich habe dann nur immer nur eine Zeile aktiviert und getestet.
z.B.

Code: Alles auswählen

PROCEDURE DBESYS()

	IF ! DbeLoad( "FOXDBE", .t.)
		ConfirmBox(,"Database-Engine FOXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF


	IF ! DbeLoad( "CDXDBE" ,.t.)
		ConfirmBox(,"Database-Engine CDXDBE not loaded", "Error" ,XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

	IF ! DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
		ConfirmBox(,"FOXCDX does not create!","Error",XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

        msgbox("test 1")

	*DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY, 100000 )
	*DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY, 20 )

	*DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY, 20 )

        msgbox("test 2")

	DbeLoad( "ODBCDBE" )

	DbeSetDefault( "ODBCDBE" )

RETURN

Die Meldung 1 kommt. Die Meldung 2 kommt garnicht. D.h., dass das Programm bei der DbeInfo(...) - Zeile hängen bleibt.
Was soll denn das bedeuten?

[Martin Altmann]

Hallo Andreas,
wieso kommentierst Du die ersten drei DbeInfo()-Zeilen nach der ersten MsgBox() aus?
Die müssen auch sein!

Viele Grüße,
Martin

[andreas]

Hallo Martin,

ich habe die Zeilen zu Testzwecken auskommentiert, um festzustellen, wo das Programm stehen bleibt. Dies ist bei allen 4 Zeilen der Fall (auch einzeln).
Der Letzte Code war nur mein Testbeispiel, wie ich es getestet habe.

[AUGE_OHR]

hi,

Hallo Jimmy,
ich habe versucht, deine Vorschläge zu verwenden.

Code: Alles auswählen

	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY, 20 )

	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY, 20 )

	DbeLoad( "ODBCDBE" )

	DbeSetDefault( "ODBCDBE" )

RETURN

Beim Programmstart kommt das Programm in die Prozessliste mit grosser CPU-Last. Das Fenster kommt aber nicht.

...

Die Meldung 1 kommt. Die Meldung 2 kommt garnicht. D.h., dass das Programm bei der DbeInfo(...) - Zeile hängen bleibt.
Was soll denn das bedeuten?

hm ... nun bin ich erstaunt den das hab ich noch nie "gesehen". Das
einzige was ich nicht benutzte ist ODBC, ansonsten hab ich die DbInfo
Zeile aus meiner DbeSys.PRG kopiert ...

Schon mal, nur für Test, die ODBC rausgenommen ?

Hast du auch die Zeile von Wolfgang aus der Alaska-Newsgroup mal
mit übernommen ?

DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE,FOXDBE_LOCKMODE_VISUAL)
DbeInfo( COMPONENT_ORDER,CDXDBE_MODE,CDXDBE_FOXPRO2X)

danach dann "meine" DbInfo Enstellungen.

Ansonsten fällt mit nur noch der F6 "DB Info" von Gernot Trautmann
ein mit dem man zur Laufzeit die DBF und die Einstellungen "sehen"
kann.

gruss by OHR
Jimmy

[andreas]

Hallo Leute,

ich habe jetzt das Problem gefunden, wieso ich die Einstellungen nicht setzen konnte.
Es gab 2 Punkte, die nicht erfüllt waren:
1. Fehlende Header-Dateien

#include "foxdbe.ch"
#include "cdxdbe.ch"

2. Defalt-DBE muss vorher festgelegt sein:

DbeSetDefault( "FOXCDX" )

Mein Programm hat die Fehlermeldungen nicht angezeigt, bis ich es mit einem Testprogramm getestet habe.

Ich habe aber trotzt der Einstellungen einen Unterschied in der Grösse der Indexdateien gefunden.

Jetzt habe ich erstmal die Einstellungen in meinen Programmen geändert und muss abwarten, ob die Indexdateien immer noch zerstört werden.

Hier ist mein funktionierender Testcode:

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Appevent.ch"
#include "Font.ch"
#include "foxdbe.ch"
#include "cdxdbe.ch"

PROCEDURE DBESYS()

	? DbeLoad( "FOXDBE", .t.)

	? DbeLoad( "CDXDBE" ,.t.)

	IF ! DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
		ConfirmBox(,"FOXCDX does not create!","Error",XBPMB_OK,XBPMB_SYSMODAL,)
	ENDIF

        DbeLoad( "ODBCDBE" )

	DbeSetDefault( "FOXCDX" )

	? DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE)
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE,FOXDBE_LOCKMODE_VISUAL)
	? DbeInfo(COMPONENT_ORDER,CDXDBE_MODE)
	DbeInfo(COMPONENT_ORDER,CDXDBE_MODE, CDXDBE_VFOXPRO)

	? DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY )
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY, 100000 )
	? DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY )
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY, 20 )

	? dbeinfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY, 100000 )
	? dbeinfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY, 20 )

	? var2char(DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE))
	dbeinfo( COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED )

RETURN

proc main()

	? "drin"
	? DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE)
	? DbeInfo(COMPONENT_ORDER,CDXDBE_MODE)

	? DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY )
	? DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY )
	? dbeinfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY )
	? dbeinfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY )

	? var2char(DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE))
	wait

return

[andreas]

Hallo Leute,

ich habe nach den vorgenommenen Einstellungen das ganze mit den Indexdateien beobachtet und habe festgestellt, dass die Indexdateien trotzdem kaputt gehen.

Ich habe mein Testprogramm (Quellcode oben) um das Öffnen einer Tabelle mit Indexdatei erweitert und die reindexieren lassen.
Die DBF-Datei ist 50 Mb gross.

Ergebnis daraus ist, dass die Indexdatei unterschiedlich gross ist, wenn ich die mit VFP oder mit XBase reindexiere. Und zwar nach dem Reindex mit XBase ist die Datei um fast 2 Mb grösser. Das ist bestimmt auch dass Problem, wieso diese Dateien dann nicht richtig in VFP erkannt bzw. als defekt eingestufft werden.

Was ist dann eigentlich mit der Komprimierung der Indexdateien in XBase los? Muss es vielleicht noch irgendwie eingestellt werden?

Meine aktuelle Einstellungen:

Code: Alles auswählen

	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKDELAY, 20 )
	DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .F. )
	DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE, FOXDBE_LOCKMODE_VISUAL )

	dbeinfo( COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKRETRY, 100000 )
	DbeInfo( COMPONENT_ORDER, CDXDBE_LOCKDELAY, 20 )
	DbeInfo( COMPONENT_ORDER, CDXDBE_MODE, CDXDBE_VFOXPRO)

Ich habe aber auch schon mit anderen Einstellungen versucht, was nichts gebracht hat.

[Martin Altmann]

Hallo Andreas,
ich nutze NTX, habe also mit CDX keine Erfahrung.
In der Newsgroup stand aber, dass ein reindex die CDX/Datei immer größer werden lässt, da die Datei nicht jedesmal komplett neu geschrieben wird, sondern nur die Änderungen reinkommen (analog dem Schnellspeichern-Problem bei Winword...)
Wenn Du also ein "echtes" reindex willst, mußt Du löschen und createn...

Viele Grüße,
Martin

[andreas]

Hallo Martin,

ich habe zuerst reindex in VFP gemacht. Danach sofort mit meinem Testprogramm, ohne irgend welche Änderungen durchzuführen. Und genau daraus kommt der Unterschied von fast 2 Mb Dateigrösse. Ich habe es schon in unterschiedlichen reihenfolgen versucht.
Es gibt immer die gleiche Ergebnisse: Die XBase-Indexdatei ist grösser.

[Martin Altmann]

Hallo Andreas,
darauf wollte ich ja auch hinaus.
Erst löschen, dann create - kein reindex!
Einfach mal probieren, ob das dann klappt.

Viele Grüße,
Martin

[Manfred]

Hi Andreas,

Du machst CDX mit Foxpro!?

Hm, ich sage mal ich mache CDX indem ich nur CDXDBE nehme.
Vor jedem Indexaufbau wird die aktuelle Indexdatei gelöscht. Danach klappt alles prima.

Falls Dir das weiterhilft.....

[andreas]

Hallo Mafred,

Du machst CDX mit Foxpro!?

Nein. Wie ich es schon oben erwähnt habe, greife ich auf die VFP-Datenbanken von einem ERP-PRogramm zu.

Sonst mache ich es genau so wie du.

[andreas]

Mein Chef hat das Problem jetzt an Alaska gemeldet.
Vielleicht finden die was.

[Martin Altmann]

Hallo Andreas,
mein Hinweis hat nicht geholfen?
Was ist denn, wenn Du unter Xbase++ statt eines Reindex die CDX-Datei löscht und dann mit create komplett neu erzeugst?

Viele Grüße,
Martin

[andreas]

Hallo Martin,

die Datenbanken gehören einem fremden Programm. Wenn ich die Indexreperatur aus dem Programm starte, funktioniert es einige Zeit. Die Dateien sind dann repariert. Manchmal muss ich es aber mehrmals am Tag durchführen. Und die ganzen User sind natürlich damit nicht zufrieden.
Reindex unter XBase habe ich nur zu Testzwecken durchgeführt. Normalerweise werden die Daten von dem XBase-Programm nur gelesen oder geschrieben.

[Manfred]

Hi Andreas,

jetzt nur mal so eine blöde Frage am Rande:
Stimmt der Indexschlüssel in Deinem Xbase Programm überein mit dem von dem Fremdprogramm? Sind vielleicht irgendwelche Funktionen drin, die jedesmal etwas durcheinanderhauen? Das sollte zwar schon Probleme beim Öffnen geben, aber ein Versuch wäre es mal wert.

[AUGE_OHR]

hi,

... dass die Indexdatei unterschiedlich gross ist ...

das ist aber unter Cl*pper/Xbase++ und DBFNTX auch so ...

Code: Alles auswählen

dbeinfo( COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED )

Ich verwende LOCKING_EXTENDED nicht, aber mal "anders rum"
gedacht ist die Frage ob VFP damit zurecht kommt ???

Ich gehe mal davon aus das der "Fehler" nur auftritt wenn beide
Applicationen auf die DBF zugegriffen haben, also beide "Stand alone"
produzieren keinen "Fehler".
Wenn dem so ist solltest du mal FOXDBE_LIFETIME auf 0 setzten
(default 50/100) wie es für Threads empfohlen wird um den Cache
zu "umgehen".

Noch eine Frage : was für ein Netzwerk verwendest du ?

gruss by OHR
Jimmy

[andreas]

Hallo Jimmy,

du hst es genau richtig verstanden. Das Problem taucht auf, wenn beide Applicationen darauf zugreifen. Mit FOXDBE_LIFETIME habe ich gestern schon den Standartwert von 50 auf 10 runtergesetzt. Jetzt muss ich es erstmal testen, ob es hilft. Der Wert 0 wäre dann der nächste schritt.