max. 15 mögliche NTX-Index - gilt das noch?
Moderator: Moderatoren
max. 15 mögliche NTX-Index - gilt das noch?
Hallo
gilt bei den NTX Index-Files noch die Maximalanzahl von 15?
Habe die Sache aus den Augen verloren...
gilt bei den NTX Index-Files noch die Maximalanzahl von 15?
Habe die Sache aus den Augen verloren...
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: max. 15 mögliche NTX-Index - gilt das noch?
wenn ich das richtig erinnere ist mit Cl*pper v5.x die Grenze gefallen ( OrdListAdd() )
Code: Alles auswählen
PROCEDURE MAIN
LOCAL i
LOCAL cIndex
IF !FILE("TEST.DBF")
CRE_DBUSETUP("TEST.DBF")
ENDIF
USE TEST.DBF EXCLUSIVE
WAIT "100 NTX anlegen. press any key ..."
FOR i := 1 TO 100
? cIndex := "TEST"+STRZERO(i,4)
INDEX ON FIELD->TEXT TO &(cIndex)
CLOSE INDEX
NEXT
WAIT "100 OrdListAdd(). press any key ..."
FOR i := 1 TO 100
? cIndex := "TEST"+STRZERO(i,4)
OrdListAdd(cIndex)
NEXT
WAIT "100 DbSetOrder(i). press any key ..."
FOR i := 1 TO 100
DbSetOrder(i)
? IndexOrd()
NEXT
WAIT "Ende ... press any key ..."
RETURN
FUNCTION CRE_DBUSETUP( cFile )
LOCAL aStruct := { { "TEXT" , "C", 30, 0 }, ;
{ "NUMBER", "N", 7, 0 }, ;
{ "DATE" , "D", 8, 0 }, ;
{ "LOGIC" , "L", 1, 0 } }
DBCREATE( cFile, aStruct, "DBFNTX" )
USE (cFile) VIA "DBFNTX" EXCLUSIVE
APPEND BLANK
REPLACE FIELD->TEXT WITH Replicate("A",30)
REPLACE FIELD->NUMBER WITH 1000000
REPLACE FIELD->DATE WITH DATE()
REPLACE FIELD->LOGIC WITH .T.
CLOSE
RETURN NIL
gruss by OHR
Jimmy
Jimmy
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: max. 15 mögliche NTX-Index - gilt das noch?
Ich habe DBFNTX-Anwendungen gesehen, wo eine dbf weit mehr als 20 NTX gleichzeitig offen hielt. Ohne Probleme.
Habe ich dann allerdings recht schnell auf FOXCDX umgeschrieben ...
Jan
Habe ich dann allerdings recht schnell auf FOXCDX umgeschrieben ...
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Klaus Schuster
- Foren-Administrator
- Beiträge: 367
- Registriert: Do, 24. Jan 2008 10:01
- Wohnort: 90762 Fürth
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 9 Mal
Re: max. 15 mögliche NTX-Index - gilt das noch?
bei sovielen Indexdateien solltest Du unbedingt DBE_LOCKMODE beachten und auf LOCKING_EXTENDED setzen, sonst kann es beim Arbeiten mit mehreren Rechnern schnell zu Stillständen kommen.
In der Hilfe steht:
DBE_LOCKMODE
This constant determines the locking mode used to manage implicit locks. Whenever an index is accessed, the NTX DatabaseEngine locks the NTX file to ensure data consistency. By default DBE_LOCKMODE is set to LOCKING_STANDARD - which ensures Clipper and/or FoxPro compatible behaviour. However this standard locking concept is not effective in modern network environments. Using LOCKING_EXTENDED does increase performance in network environments since mutual exclusion of applications accessing the same index file only is needed, whenever a write operation takes place.
Falls Du noch gleichzeit mit Clipper auf die Dateien zugreifen willst, ist dieser Wert relevant:
NTXDBE_LOCKOFFSET
By default the offset for implicit locking is 1.000.000.000 (~1GB) which is compatible to all Clipper versions. Using the constant NTXDBE_LOCKOFFSET the offset can be changed to any value between 0 and 0xFFFFFFFF.
To handle index files larger than 1GB Clipper 5.2 and Clipper 5.3 come with a special object file NTXLOCK2.OBJ. Using this object file when linking a DOS Clipper application increases the locking offset from ~1GB to 0xFFFFFFFF (~4GB) for NTX files. To ensure compatibility with that type of Clipper NTX files the constant NTXDBE_LOCKOFFSET must be used to re-configure the offset of implicit locking of the NTX DatabaseEngine as shown in the code below:
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
In der Hilfe steht:
DBE_LOCKMODE
This constant determines the locking mode used to manage implicit locks. Whenever an index is accessed, the NTX DatabaseEngine locks the NTX file to ensure data consistency. By default DBE_LOCKMODE is set to LOCKING_STANDARD - which ensures Clipper and/or FoxPro compatible behaviour. However this standard locking concept is not effective in modern network environments. Using LOCKING_EXTENDED does increase performance in network environments since mutual exclusion of applications accessing the same index file only is needed, whenever a write operation takes place.
Falls Du noch gleichzeit mit Clipper auf die Dateien zugreifen willst, ist dieser Wert relevant:
NTXDBE_LOCKOFFSET
By default the offset for implicit locking is 1.000.000.000 (~1GB) which is compatible to all Clipper versions. Using the constant NTXDBE_LOCKOFFSET the offset can be changed to any value between 0 and 0xFFFFFFFF.
To handle index files larger than 1GB Clipper 5.2 and Clipper 5.3 come with a special object file NTXLOCK2.OBJ. Using this object file when linking a DOS Clipper application increases the locking offset from ~1GB to 0xFFFFFFFF (~4GB) for NTX files. To ensure compatibility with that type of Clipper NTX files the constant NTXDBE_LOCKOFFSET must be used to re-configure the offset of implicit locking of the NTX DatabaseEngine as shown in the code below:
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
Gruß Klaus
Re: max. 15 mögliche NTX-Index - gilt das noch?
Hallo
Danke für die Infos - dann kann man inzwischen also über die 15er Grenze gegen. Ich brauche es (noch) nicht, ist aber für die Planung zukünftiger Vorgehensweisen wichtig.
@Werner
guter Hinweis - was es alles für (versteckte) Dinge gibt...
Wie stellt man das dann "richtig" ein für heutige Netzwerke?
#include "DbfDbe.ch"
#include "DMLB.ch"
DbeInfo( COMPONENT_DATA , DBF_LOCKMODE , LOCKING_EXTENDED )
DbeInfo( COMPONENT_DATA , DBFDBE_LOCKMODE , LOCKING_EXTENDED )
vermutlich nach DBELOAD()
und noch ne Frage:
Und wie ist das ganze beim ADS?
Danke für die Infos - dann kann man inzwischen also über die 15er Grenze gegen. Ich brauche es (noch) nicht, ist aber für die Planung zukünftiger Vorgehensweisen wichtig.
@Werner
guter Hinweis - was es alles für (versteckte) Dinge gibt...
Wie stellt man das dann "richtig" ein für heutige Netzwerke?
#include "DbfDbe.ch"
#include "DMLB.ch"
DbeInfo( COMPONENT_DATA , DBF_LOCKMODE , LOCKING_EXTENDED )
DbeInfo( COMPONENT_DATA , DBFDBE_LOCKMODE , LOCKING_EXTENDED )
vermutlich nach DBELOAD()
und noch ne Frage:
Und wie ist das ganze beim ADS?
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: max. 15 mögliche NTX-Index - gilt das noch?
ADS ist ADSDBE, die Infos von oben sind DBFDBE, evtl. auch FOXDBE, da bin ich mir nicht sicher.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: max. 15 mögliche NTX-Index - gilt das noch?
Roland,
im ADS darf eine dbf max. 20 ntx haben - bei mehr geht dann kein Weg an FOXCDX vorbei, da gibt es diese Begrenzung nicht. Und alle Aliasse dürfen max. 10 Zeichen haben.
Jan
im ADS darf eine dbf max. 20 ntx haben - bei mehr geht dann kein Weg an FOXCDX vorbei, da gibt es diese Begrenzung nicht. Und alle Aliasse dürfen max. 10 Zeichen haben.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: max. 15 mögliche NTX-Index - gilt das noch?
oh je ... solche Einstellungen in der DBESYS sollte man NICHT "so" haben
wenn man eine DATA Komponente "verstellt"
gehört meistens eine ORDER Komponente dazu
mit Fox
sowie
dito muss man
den selben Wert einstellen wenn man
verwendet
wenn man eine DATA Komponente "verstellt"
Code: Alles auswählen
DBFDBE (DATA-Komponente)
DbeInfo(COMPONENT_DATA,DBFDBE_LOCKMODE,xxx)
Code: Alles auswählen
NTXDBE (ORDER-Komponente)
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,xxx)
Code: Alles auswählen
FOXDBE (DATA-Komponente)
DbeInfo(COMPONENT_DATA,FOXDBE_LOCKMODE,xxx)
Code: Alles auswählen
CDXDBE (ORDER Komponente)
DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,xxx)
Code: Alles auswählen
DBFDBE (DATA-Komponente) -> DBFDBE_LOCKOFFSET
Code: Alles auswählen
NTXDBE (ORDER-Komponente) -> NTXDBE_LOCKOFFSET
gruss by OHR
Jimmy
Jimmy
Re: max. 15 mögliche NTX-Index - gilt das noch?
Das Rumprobieren mit der DbeInfo() lasse ich erst einmal, bis jetzt läuft ja noch alles.
Also doch wieder eine NTX-Grenze beim ADS - bis 20 habe ich aber noch ein wenig Luft.
Vor vielen Jahren hatte ich schon einmal angefangen alles auf CDX umzustellen. Da gab es dann neue, andere Probleme und ich habe die Umstellung verworfen.
Nur mal so - es kann doch aber nicht mehr an der Technik liegen, dass die Anzahl Index immer noch begrenzt ist...
Wenn es die Kompatibilität mit Altprogrammen ist sollte die optional abschaltbar sein wenn das der Weiterentwicklung im Wege steht.
Also doch wieder eine NTX-Grenze beim ADS - bis 20 habe ich aber noch ein wenig Luft.
Vor vielen Jahren hatte ich schon einmal angefangen alles auf CDX umzustellen. Da gab es dann neue, andere Probleme und ich habe die Umstellung verworfen.
Nur mal so - es kann doch aber nicht mehr an der Technik liegen, dass die Anzahl Index immer noch begrenzt ist...
Wenn es die Kompatibilität mit Altprogrammen ist sollte die optional abschaltbar sein wenn das der Weiterentwicklung im Wege steht.
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: max. 15 mögliche NTX-Index - gilt das noch?
Roland,
das liegt an der Kompatibilität. Wenn DBFNTX so gebaut ist, dann kann da nicht einer alleine was gegen machen. Und niemand wird da mehr was dran machen. das DBF-System läuft stabil, wird immer mehr von anderen Formaten verdrängt - warum also sollte irgend ein Hersteller da noch Zeit rein investieren?
Und die Umstellung von DBFNTX auf FOXCDX lief bei mir und meinen Kunden generell komplett reibungslos ab. hinterher waren immer alle glücklich, weil das eben doch stabiler, schneller, weniger fehleranfällig ist. Und eben im ADS auch den Vorteil der Nicht-Indexbegrenzung hat. Klar steckt da Arbeit drin, je nachdem wie der Code momentan aussieht. Aber das ist gegen die Vorteile in meinen Augen vollkommen zu vernachlässigen.
Jan
das liegt an der Kompatibilität. Wenn DBFNTX so gebaut ist, dann kann da nicht einer alleine was gegen machen. Und niemand wird da mehr was dran machen. das DBF-System läuft stabil, wird immer mehr von anderen Formaten verdrängt - warum also sollte irgend ein Hersteller da noch Zeit rein investieren?
Und die Umstellung von DBFNTX auf FOXCDX lief bei mir und meinen Kunden generell komplett reibungslos ab. hinterher waren immer alle glücklich, weil das eben doch stabiler, schneller, weniger fehleranfällig ist. Und eben im ADS auch den Vorteil der Nicht-Indexbegrenzung hat. Klar steckt da Arbeit drin, je nachdem wie der Code momentan aussieht. Aber das ist gegen die Vorteile in meinen Augen vollkommen zu vernachlässigen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Re: max. 15 mögliche NTX-Index - gilt das noch?
Servus Jan
prima dass es bei Deinen Projekten mit der Umstellung von DBFNTX auf FOXCDX gut gelaufen ist.
Damit hat es sich aber schon mit meiner Zustimmung zu Deinen Aussagen.
Alle "Umstellungen! sind unnötige Zeitaufwendungen und nicht kalkulierbare Risiken. Keine Frage - das mache ich nicht.
Ich habe unzählige Anforderungen von Kunden für neu benötigte Programmfunktionen. Denen soll ich sagen, dass jetzt erst einmal auf CDX der sogar SQL umgestellt werden muss und alles andere auf unabsehbare Zeit liegenbleibt? Das binde ich mir vorerst nicht ans Bein. Und wer bezahlt die Zeit?
Mein Hauptprojekt gibt es seit > 30 Jahren - willst Du die Hand ins Feuer legen und dafür garantieren dass der Kunde von der Umstellung nichts merkt?
Ich hätte kein Problem damit wenn bei Xbase++ (Alaska) und ADS (SAP) ein Schnitt gemacht wird un das "Alte" (z.B. Clipper-Kompatibilität) eingestampft wird. Das brauche ich schon seit Jahrzehnten nicht mehr!
Wenn Alaska oder/und SAP noch lange die "ewig Gestrigen" unterstützen gibt das früher oder später Probleme. Wie eben die Sache mit der Begrenzung der Anzahl möglicher NTX-Dateien pro Workarea...
prima dass es bei Deinen Projekten mit der Umstellung von DBFNTX auf FOXCDX gut gelaufen ist.
Damit hat es sich aber schon mit meiner Zustimmung zu Deinen Aussagen.
Alle "Umstellungen! sind unnötige Zeitaufwendungen und nicht kalkulierbare Risiken. Keine Frage - das mache ich nicht.
Ich habe unzählige Anforderungen von Kunden für neu benötigte Programmfunktionen. Denen soll ich sagen, dass jetzt erst einmal auf CDX der sogar SQL umgestellt werden muss und alles andere auf unabsehbare Zeit liegenbleibt? Das binde ich mir vorerst nicht ans Bein. Und wer bezahlt die Zeit?
Mein Hauptprojekt gibt es seit > 30 Jahren - willst Du die Hand ins Feuer legen und dafür garantieren dass der Kunde von der Umstellung nichts merkt?
Ich hätte kein Problem damit wenn bei Xbase++ (Alaska) und ADS (SAP) ein Schnitt gemacht wird un das "Alte" (z.B. Clipper-Kompatibilität) eingestampft wird. Das brauche ich schon seit Jahrzehnten nicht mehr!
Wenn Alaska oder/und SAP noch lange die "ewig Gestrigen" unterstützen gibt das früher oder später Probleme. Wie eben die Sache mit der Begrenzung der Anzahl möglicher NTX-Dateien pro Workarea...
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: max. 15 mögliche NTX-Index - gilt das noch?
mal eine andere Sache
nach dem Datenschutz Gesetz muss man ja bestimmte Daten schützen z.b. durch Verschlüsselung
Frage : was ist mit NTX Index
der NTX Index ist ja nicht komprimiert d.h. man "sieht" alles im Klartext ...
nach dem Datenschutz Gesetz muss man ja bestimmte Daten schützen z.b. durch Verschlüsselung
Frage : was ist mit NTX Index
der NTX Index ist ja nicht komprimiert d.h. man "sieht" alles im Klartext ...
gruss by OHR
Jimmy
Jimmy
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: max. 15 mögliche NTX-Index - gilt das noch?
Roland,
ADS heißt nicht automatisch moderne Technologien. Wenn Du Deinen Code nicht groß umschreiben möchtest, dann bliebt Dir nur, im ADS die dbf weiter zu benutzen. Egal ob als DBFNTX oder als FOXCDX. Möchtest Du wirklich auf moderne Datenbanken umsteigen dann mußt Du Deine Software auf SQL umschreiben - und DAS ist dann wirklich eine Lebensaufgabe bei Deinen großen Projekten! Dagegen ist das Umschreiben auf das stabiliere, schnellere, flexiblere FOXCDX ein Klacks.
Und warum sollte Dein Kunde etwas von der Umstellung merken? Der merkt gar nichts davon. Jedenfalls nichts negatives. Mein Hauptkunde hatte DBFNTX. Das habe ich ohne wirklich großen Aufwand umgeschrieben auf FOXCDX. Außer das es schneller und stabiler läuft hat der nichts davon mitbekommen. Und nach dem Umstieg auf den ADS war das Staunen groß, wie schnell einige Module damit geworden sind.
Abgesehen davon hat der ADS den Vorteil, das die Daten sicherer liegen. Ich mach das mit proprietärem Zugriff. Da kommt also niemand von außen ran an die Daten. Kein Diebstahl, kein Löschen, nichts ist möglich ohne die Zugangsdaten. Soviel dann zum Datenschutz.
Jan
ADS heißt nicht automatisch moderne Technologien. Wenn Du Deinen Code nicht groß umschreiben möchtest, dann bliebt Dir nur, im ADS die dbf weiter zu benutzen. Egal ob als DBFNTX oder als FOXCDX. Möchtest Du wirklich auf moderne Datenbanken umsteigen dann mußt Du Deine Software auf SQL umschreiben - und DAS ist dann wirklich eine Lebensaufgabe bei Deinen großen Projekten! Dagegen ist das Umschreiben auf das stabiliere, schnellere, flexiblere FOXCDX ein Klacks.
Und warum sollte Dein Kunde etwas von der Umstellung merken? Der merkt gar nichts davon. Jedenfalls nichts negatives. Mein Hauptkunde hatte DBFNTX. Das habe ich ohne wirklich großen Aufwand umgeschrieben auf FOXCDX. Außer das es schneller und stabiler läuft hat der nichts davon mitbekommen. Und nach dem Umstieg auf den ADS war das Staunen groß, wie schnell einige Module damit geworden sind.
Abgesehen davon hat der ADS den Vorteil, das die Daten sicherer liegen. Ich mach das mit proprietärem Zugriff. Da kommt also niemand von außen ran an die Daten. Kein Diebstahl, kein Löschen, nichts ist möglich ohne die Zugangsdaten. Soviel dann zum Datenschutz.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: max. 15 mögliche NTX-Index - gilt das noch?
die Umstellung von NTX auf CDX klingt einfach aber es gibt schon einigen Sachen zu bedenken.
ein NTX Index darf eine KEY Länge von 512 bytes haben
ein CDX Index darf nur 240 bytes haben und wenn Collation dazu kommt nur 120 bytes
es kann also sein das ein NTX KEY nicht in einen CDX TAG passt ...
ein NTX Index darf eine KEY Länge von 512 bytes haben
ein CDX Index darf nur 240 bytes haben und wenn Collation dazu kommt nur 120 bytes
es kann also sein das ein NTX KEY nicht in einen CDX TAG passt ...
gruss by OHR
Jimmy
Jimmy
Re: max. 15 mögliche NTX-Index - gilt das noch?
der ADS macht scheinbar ab 15 Indizes nicht mehr mit
Habe es gerade mit 17 probiert.
Das hinzufügen der 17 Index macht er noch mit, wenn man sich die Indexliste anschaut ist aber der Indexkey von Index 16 und 17 gleich dem IndexKey 1.
Die Indexe 16 und 17 funktionieren auch nicht und bei DbCloseArea() ond DbCloseAll() stürzt das Programm ab.
Auch der Advantage Data Architect meckert ab 16.
So ein Mist...
Habe es gerade mit 17 probiert.
Das hinzufügen der 17 Index macht er noch mit, wenn man sich die Indexliste anschaut ist aber der Indexkey von Index 16 und 17 gleich dem IndexKey 1.
Die Indexe 16 und 17 funktionieren auch nicht und bei DbCloseArea() ond DbCloseAll() stürzt das Programm ab.
Auch der Advantage Data Architect meckert ab 16.
So ein Mist...
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten: