Inoffizielles deutsches Xbase-Forum

Hi,

muß eigentlich eine DBF exclusive geöffnet sein, wenn man mit der ADSDBE einen Index aufbauen will, oder genügt es die DBF mit Flock() zu sperren?

Ok, hier noch eine weitere Info, weshalb ich frage. Das ist die Fehlermeldung die ich erhalte über OrdCreate()

Ich denke, exklusiver Zugriff ist bei Verwendung einer DBE immer nötig, wenn man einen Index erzeugt.

Das hier ist die Erläuterung zum Fehlercode:

Errors in the 8000 range are returned when the Advantage server makes a direct call to an OS API, and that function returns a failure. If you receive an error in the 8000 range, retry the database operation. If the error condition persists, please send a small re-creation to Advantage Technical Support demonstrating the problem so that Advantage R&D can investigate the issue.

Hi Tom,

unter Xbase++ direkt genügt ein Flock(). So mache ich das aus Sicherheitsgründen. Aber es ging bisher auch ohne. Was aber nicht ratsam ist, aber trotzdem klappt. technisch meine ich jetzt.

Manfred,

der 6. Parameter von OrdCreate() gibt an, ob bei offenen Index-Dateien geschlossen werden sollen oder geöffnet bleiben. Das hat aber nichts damit zu tun, ob die dbf exklusiv oder shared geöffnet ist. Meines Wissens muß eine dbf in einer Multiuser-Umgebung zum indizieren immer exklusiv geöffnet sein. Was auch Sinn macht - ansonsten könnten andere User mitten während des Indizierens Werte ändern oder hinzufügen, und dann passt der gerade zu erstellende Index nicht mehr.

Jan

Jan,

nochmal. Es geht hier nicht darum was sollte, sondern was geht. Und es geht im Shared Modus. Diese Diskussion hatten wir schon mal. Ich habe es mit Flock() angepaßt bei mir geht es. Meine Frage war nur, ob der ADS das auch so akzeptiert. Aber ich meine es probiert zu haben und die Meldung kommt trotzdem.

Manfred,

mir ist egal was geht oder nicht. Es mag sein, das eine Indexerstellung unter Xbase++ pur im Shared Betrieb gehen könnte. Auch wenn ich das nicht glauben kann. Aber wir reden hier von ADS. Und die Engine kommt von SAP, nicht von Alaska. Die DBE ist Alaska, aber wenn der ADS sagt, Indexerstellung geht nur im Exklusiv-Modus, dann kann Alaska ansonsten noch so tolerant sein - es geht eben nicht.

Jan

Die Dokumentation (zumindest der 1.90) ist da nicht eindeutig.
Bei INDEX steht es nicht, bei DbCreateIndex() schon !
OrdCreate() enthält dazu nichts ...

Die Funktion DbCreateIndex() besteht aus Gründen der Kompatibilität. Anstelle von DbCreateIndex() sollte die Funktion OrdCreate() verwendet werden.
...
Vor dem Aufruf von DbCreateIndex() muß sichergestellt sein, daß die DBF-Datei in der gewünschten Workarea exklusiv geöffnet ist.

Von Clipper her kannte ich auch nur VOR INDEX use EXCLUSIV ... wie Manfred sagt funktioniert FLOCK() auch, was auch nicht so verwunderlich ist, denn ...

1. FLOCK() verhindert Schreibvorgänge, somit kann sich in der DBF nix ändern.
2. INDEX etc. öffnen die Indexdatei exclusiv, somit kann der Schreibprozess dort nicht gestört werden ...
3. Für temporäre Indexe muss die DBF im normalen Modus geöffnet sein, sonst machen die keinen Sinn ... DAHER geht es wohl heute auch (unter Clipper meine ich nicht !).

ABER wie TOM schon ausführte ist die ADS sensibler

Möglich, dass diese es NICHT mag und die Beschreibung zu DbCreateIndex() genau genommen hat, oder gleich bei Clipper abgeschrieben hat !

Macht es Sinn ? Bei temporären Indexdateien mag das sein, aber nicht bei den normalen.
Eine Anwendung die Indexe nutzt, darf eine DBF nicht einfach ohne diese öffnen, solange mehr als nur gelesen wird.

Manfred hat geschrieben:... Es geht hier nicht darum was sollte, sondern was geht. Und es geht im Shared Modus.

gut wenn es GEHT, gibts ja keine Probleme

PS: wenn eines meiner Programme den Hauch eines Verdachtes hat, dass eine Indexdatei nicht akzeptabel ist, werden die gelöscht und das Programm beendet.
Beim Neustart wird dann festgestellt, dass eine oder mehrere fehlen. Das Programm öffnet die DBFs exclusiv, wenn das fehlschlägt, baut ein anderer im Netz die Indexe auf, ansonsten der aktuelle PC !

Der exclusive Zugriff ist der einzig sichere Weg zu erkennen ob eine Datei schon offen ist.

Ich habe es jetzt ausprobiert: Exclusive bringt in dem Fall nichts.

Manfred hat geschrieben:Ich habe es jetzt ausprobiert: Exclusive bringt in dem Fall nichts.

nö.. . . Ein 8026 kommt in 99,9999999999% der Fälle daher, dass der Server nichts von einer verwendeten Freigabe weiß. Prüfe mal die Berechtigungen des Freigabenamens am Server - ich vermute, die Gruppe SYSTEM darf das nicht lesen.

Das war das erste was ich vermutete hatte. Ich habe erstmal für jeder ALLE Rechte vergeben. System hat auch alle Rechte.

Da es aber ein Testserver hier bei mir ist, will ich natürlich nicht ausschließen, dass ich irgendwas falsch konfiguriert habe. Aber was?

Asche auf mein Haupt.

Ich habe so ziemlich alles verwurstet, was man verwursten kann. Es scheint jetzt zu klappen. Au man.

Die Konfiguration ist folgende:

1) Programm wird von einem "lokalen" Rechner aus gestartet (das ist ja noch normal)
2) Ein Teil der DBF Tabellen liegt auf dem lokalen Rechner und ein Teil auf dem Server, auf dem der ADS läuft. (das ist auch ok)

Aber jetzt kommt es, ich war der Meinung, dass der ADS durch das ADD weiß, wo die DBF steht und automatisch auch da den Index rein erzeugen wird.

dem ist aber dann doch nicht so. Ich habe nur den Namen beim Aufbau angegeben und da hat der ADS natürlich versucht über die Leitung auf meinem lokalen Rechner im Programmverzeichnis zu erzeugen. Aber da hat der keinen Zugriff drauf. Also war es doch ein Rechteproblem, aber auf anderer Ebene.

Ich glaube Joachim hat bei seinem Vortrag und der Kombination von mehreren ADS Servern o.ä. auf verschiedenen Maschinen irgendwie das Thema angesprochen!? Jetzt klingelt es wieder bei mir....
Tja, Stunden verheizt und unbezahlbare Erfahrungen gesammelt.

Das hatte ich auch im Hinterkopf, war aber zu beschäftigt für die Antwort. Der Fehlercode, den ich gepostet habe, enthielt aber einen Hinweis.

Wenn man eine Anwendung auf ADS umstellt, jedoch parallel mit (lokalen) Tabellen arbeitet, die nicht mit dem ADS verwendet werden sollen/müssen/können, muss man daran denken, dass die Standard-Engine ab diesem Augenblick üblicherweise die ADSDBE ist, so dass bei allen Versuchen, auf Tabellen zuzugreifen, sie zu verändern usw. usf. der ADS bzw. die ADSDBE zum Einsatz kommt (oder zu kommen versucht). Deshalb sollte a) die vorherige Standardengine geladen bleiben/werden und b) bei solchen Tabellen mit VIA (bei USE ...) bzw. Angabe der ehemaligen Standardengine in DbUseArea() (zweiter Parameter) gearbeitet werden, sonst kracht's andauernd. Schwierig ist das in Szenarien, bei denen diese Mischung von Tabellenorten frei wählbar oder auf andere Weise uneindeutig ist.

Anyway. Der ADS kann nur mit Tabellen und Indexen operieren, die in seinem Zugriffsbereich sind. Bei allen anderen muss die vorherige DBE verwendet werden. Auch bei DbImport() und DbExport() (APPEND FROM/COPY TO) und ähnlichen Operationen muss man auf derlei achten.

Das hatte ich schon berücksichtigt. Bei jedem DBF Zugriff wird immer die Engine angegeben. Aber wie es halt so ist......

Mal sehen, was mir noch so alles passiert. Aber besser jetzt beim Testen bei mir zuhause als später beim Kunden

Die lokalen Tabellen dürfen natürlich nicht im ADD verzeichnet sein.

nochmal geprüft, per FLOCK() klappt es auch. Nur so zur Info.