Datenbanken/Indexe kontrolliert öffnen

[Manfred]

Hi,

ich grübel mal wieder seit längerer Zeit über eine "optimale" Lösung nach.

Ich habe eine Datenbankklasse geschrieben, die Datenbanken öffnet und etliche Dinge nebenebei erledigt. Aber irgendwie bin ich nicht richtig zufrieden damit. Habt ihr vielleicht eine richtig tolle Idee, wie man das folgende Problem lösen kann/sollte?

Es soll eine pauschale Methode in einer Klasse existieren, die alle DB incl. Index öffnen kann.

1) Vorher einen Merker/Parameter abfragen, ob evtl. die DB und Index gelöscht werden sollen (evtl. für temp.Dateien)
2) Dann prüfen, ob die DB und/oder Index vorhanden ist
3) Wenn Db nicht vorhanden, dann neu erstellen
4) Wenn Index nicht vorhanden, dann neu erstellen.

Das wäre auch nicht das Problem, der Störfaktor ist, dass eine Db ja Exclusive geöffnet werden muß für den Indexaufbau, dann wieder geschlossen und dann wieder geöffnet wird.

Ich habe schon eine Lösung, aber irgendwie erscheint die mir einfach zu umständlich.

Ich frage jetzt hier, um mal wieder meinen Knoten im Kopf zu lösen. Ich renne die ganze Zeit im Kreis und komme nicht weiter, bzw. bin unzufrieden mit meiner Lösung.

[Jan]

Hallo Manfred,

vorab eine Frage zum Detail: Du erwähnst ja extra das exklusive Öffnen zwecks Indexerstellung. Heißt das, Du öffnest normalerweise Shared weil Serverbetrieb?

Jan

[Manfred]

Hi Jan,

meine Programme sind ALLE für den Netzwerkbetrieb, sprich Mehrbenutzerbetrieb ausgelegt und deshalb werden die DB immer Shared oder Exclusive geöffnet. Da Windows ja Multitasking kann, hat man eigentlich IMMER ein Netzwerk, auf dass man achten muß.

[AUGE_OHR]

hi,

ich grübel mal wieder seit längerer Zeit über eine "optimale" Lösung nach.

gibt es die ?

bin unzufrieden mit meiner Lösung.

das kann ich nun wiederum verstehen

Das wäre auch nicht das Problem, der Störfaktor ist, dass eine Db ja Exclusive geöffnet werden muß für den Indexaufbau, dann wieder geschlossen und dann wieder geöffnet wird.

man könnte ja FLOCK() verwenden ...

allerdings frage ich mich gerade wann die Situation überhaupt auftritt?

1.) Wenn eine ge"shared" Index Datei "kaputt" ist (woran merkst du das?)
würde ich die für alle weiteren User Zugriffe sperren damit die nicht "noch
mehr kaputt machen"

2.) Wenn du im Netzwerk zur Laufzeit "Local"e Index Dateien erzeugen
willst reicht ja ein FLOCK() weil die ge"share"ten Indexe davon nicht
betroffen sind.

3.) Wenn du im Netzwerk zur Laufzeit öfter mal einen Teil Index benötigst
dann würde ich SUBINDEX mit FLOCK() verwenden

4.) Wenn du nur weist das du einen Index für bestimmte Situationen
brauchst aber der sich ändern kann oder der Inhalt sich erst zu Laufzeit
ergibt dann könnte man mit CUSTOM einen leeren Index anlegen und
den dann zur Laufzeit "füllen".

grundsätzlich kann ich nur sagen : lieber einen Index/Tag mehr als
weniger (für alle Zwecke) den man muss ja nicht mehr wie bei Cl*pper
mit den FILES so aufpassen.

gruss by OHR
Jimmy

[Manfred]

Hi,

jetzt weiß ich auch, warum ich letzte Nacht so schlecht geschlafen habe.....

Mir ist nachher noch jede Menge mehr eingefallen, was berücksichtigt werden muß.

Also hinzu kommen noch folgende Faktoren:

1) Bei jedem Öffnen einer DB prüfe ich anhand einer Struktur im Array, ob sich die derzeitige Struktur der DB geändert hat. Ich vergleiche halt einfach eine festverdrahtete im Quelltext mit der in der DB.

2) Das gleiche gilt für den Indexschlüssel.

Paßt irgendwas nicht, dann wird entweder der Index geschlossen, gelöscht und neu aufgebaut, bzw. die DB wieder geschlossen eine temporäre erzeugt, geöffnet und aus der derzeitigen appended und danach die alte gelöscht und die temporäre umbenannt. Die letzte Strukturanpassung in ein TExtfile geschrieben, welches immer vor der Anpassung auf Aktualität geprüft wird und somit verhindert, dass eine Rückwärtsanpassung passieren kann. Ein älteres Programm arbeiten zwar dann damit, könnte aber nicht die Struktur zurückschrauben. (Hatten wir hier schon mal, klappt auch prima. War die Sache mit den DLL, in der die Strukturdaten stehen.)

Die Prüfung innerhalb des Programmablaufes ob ein Index defekt ist, geht relativ simpel vonstatten. Es wird einfach nur der gefundene Wert mit dem gesuchten verglichen. Wenn er nicht stimmt, dann wird sofort das Programm gestoppt, eine Meldung generiert, die Db geschlossen, der Index gelöscht, bzw. ein Merkfile gesetzt, welches immer abgefragt wird und die anderen WS auch beenden läßt. Somit sollte ein Weiterarbeiten aller Programm verhindert werden. So war es bisher.....

[brandelh]

Das wäre auch nicht das Problem, der Störfaktor ist, dass eine Db ja Exclusive geöffnet werden muß für den Indexaufbau, dann wieder geschlossen und dann wieder geöffnet wird.

Hallo Manfred,

nach meinen Erfahrungen und dem Text der Onlinehilfe kann die DBF wohl auch geshared offen sein. NUR die neue Indexdatei muss logischerweise exclusive sein. Ein FLOCK() auf die DBF ist aber sicher ein MUSS, sonst könnte man ja Daten ändern, die gerade indiziert wurden. Ich meine bei Clipper war es noch anders.

Der Vorteil wäre, dass du die DBF nicht dauernd öffnen und schließen mußt. Allerdings eine schon offene DBF hat natürlich auch die Indexe offen und somit wird das ein Problem.

Ich persönlich bin aber eher altmodisch und öffne zum Indizieren auch immer EXCLUSIVE. Wenn dann ein neterr() auftritt gibt es eine Fehlermeldung ansonsten ist klar, dass die Indexe erzeugt werden können.
Ein Programm das jetzt einen neterr() erhält weiß dann, dass der Indexaufbau im Gange ist. Und was nützt einem Programm schon eine offene DBF wenn die Indexe fehlen.

[Manfred]

Hi Hubert,

es wird bei einem Indexneuaufbau ein Merker gesetzt, der wenn er nicht gelöscht werden kann, in Benutzung sein muß und somit jedem weiteren Programm mitteilt: Halt es geht jetzt nicht. Das gleiche gilt bei einer Strukturanpassung einer DB. Also somit wäre auch das Problem einer weiteren, in diesem Fall unerlaubten Öffnung Vorsorge getragen..

Was mich nur extrem nervt, ist die vernünftige Umsetzung in einen Code. Es wird ja irgendwie in einer Do While Schleife sein müssen. Und die entsprechenden Methoden werden sich wohl auch selbst immer wieder aufrufen, wenn es zu Wiederholungen bei Öffnungen kommt. Da bin ich mir jetzt nicht so sicher, ob dass speicher- und stackmäßig ohne Probleme geht!?

[Jan]

Manfred,

auch wenn ich alle anderen Beiträge gelesen habe, habe ich doch noch eine weitere grundsätzliche Frage.

Du schreibst, daß bei JEDEM öfnnen einer dbf kontrolliert wird, ob die Struktu noch mit der fest codierten übereinstimmt. Vielleicht habe ich etwas übersehen, aber mir kommt das unglaublich aufwändig vor. Denn eine Änderung im Code kann es ja nur beim Update einer der Programm-Komponenten (exe oder dll) geben. Warum also nicht "einfach" diese Kontrollabfrage nur bei einem erfolgten Update machen? Oder wenn schon denn nur bei einem neuen Programmstart?

Außerdem stellt sich mir die Frage ob es nicht besser wäre, immer nur einen Client das ganze machen zu lassen. Und zwar den, der nach einem Update der erste ist, der sich mit den dbf verbindet. Der könnte dann ja eine Datei erzeugen: Update nnn ist bereits erfolgt, und alle anderen schauen nur nach, ob nnn mit dem codierten nnn übereinstimmt bzw. ob sie selber vielleicht die ersten sind.

Dadurch, daß immer nur der Erste anmeldende Rechner das macht, müssen keine anderen Rechner zum Schließen animiert werden. Die hätten höchstens eine Wartemeldung "Updates werden durchgeführt, bitte einen Moment warten", und dann ginge es los. Vielleicht in einer Schleife, die alle x Sekunden nachschaut, ob die Updates noch immer laufen, und dann bei erledigung sofort selbsttätig das Programm komplett startet.

Das löst vielleicht nicht Deine Eingangsfrage, würde aber sicher einiges im Ablauf vereinfachen, Lockingprobleme minimieren, und die Performance hochschrauben.

Ich bin mir aber nicht wirklich sicher, ob das Dein Weg ist.

Jan

[Manfred]

Hi Jan,

es macht immer das erste Programm, das startet. Wie sollte es auch anders gehen? Eine Prüfschleife finde ich sehr gewagt, weil es ruckzuck in eine Endlosschleife ausarten kann, wenn etwas schiefläuft. Wenn Anpassungen laufen, dann soll und darf kein anderes Programm in Warteposition gehen.
Ansonsten verstehe ich Deine Frage nicht ganz, ein neues Programm erfordert auch Prüfungen, bzgl Updates usw. Ob ich nun wirklich Zeit spare, wenn ich nur einmal prüfe? Ich wage es zu bezweifeln, dass das hier wirklich ins Gewicht fallen würde. Außerdem wird kein Rechner zum Schließen animiert bei einer DB Anpassung (siehe oben), sondern nur bei einem defekten Index. Die Programme liegen zentral auf einem Dateiserver und können eh nur ausgewechselt werden, wenn keiner mehr drin ist.

[Manfred]

Hi,

ich habe mir die Sache mit dem FLOCK() einmal durch den Kopf gehen lassen. Das erscheint mir doch eine vernünftige Lösung zu sein. Ich erspare mir das Exklusive Öffnen, das nachfolgende Schließen und wieder Öffnen.

Aber wenn ich mir das jetzt so überlege, dann muß doch die DB danach eh wieder geschlossen werden, damit die FLOCK() Wirkung aufgehoben wird, oder sehe ich das jetzt falsch? Also spare ich mir eigentlich wenigstens 1 Vorgang, den mit der Exklusiven Öffnung.

Ist denn bei FLOCK() noch irgendwas zu beachten, was eventuell einem Schuß in den Rücken gleichkommen könnte, wenn man nicht aufpaßt?

Was passiert denn mit den WS, die die DB gerade auf haben, nebst dem Index und der wird gleichzeitig neu gemacht? Die können nur nicht vernünftig suchen? Wenn man keine Relationen benutzt, dann dürfte es doch auch keine Probleme geben, oder?

[AUGE_OHR]

hi,

Aber wenn ich mir das jetzt so überlege, dann muß doch die DB danach eh wieder geschlossen werden, damit die FLOCK() Wirkung aufgehoben wird, oder sehe ich das jetzt falsch?

UNLOCK

Was passiert denn mit den WS, die die DB gerade auf haben, nebst dem Index und der wird gleichzeitig neu gemacht? Die können nur nicht vernünftig suchen? Wenn man keine Relationen benutzt, dann dürfte es doch auch keine Probleme geben, oder?

Das geht eben nicht. Index kaputt ... bitte warten ...

Im Grunde müsste man im Errorblock mit OrdListAdd() arbeiten um
jeden Index einzeln hinzuzufügen/öffnen und wenn man dann einen
Error bekommt dann müssen die User eben warten bis alles repariert ist.

Was mich aber doch ein wenig wundert ist das du scheinbar mit Index
Dateien Probleme überhaupt hast bzw. die einplanst. Wäre es da nicht
die Frage woher dein eigendliches Problem mit defekten Index Dateien
kommt ?

Bei NTX Dateien hatte ich früher z.b. das Problem das ich noch keine
zentrale NET_USE() Funktion hatte und "irgendwo" die DBF geöffnet hab.
Leider hab ich dann z.t. einen Index vergessen mit zu öffnen ( 4 von 5)
und natürlich auch nur die aktuallisiert und wenn ich dann mal den 5st
brauchte gab es ein Problem ...
Da du ja eine zentrale NET_USE() Funktion hast sollten die Index Datein
doch kein Problem machen, oder ?

gruss by OHR
Jimmy

gruss by OHR
Jimmy

[Manfred]

Hi Jimmy,

ich habe keine Probleme mit dem Index (bisher jedenfalls nicht. Ich arbeite erst neuerdings mit CDX und nicht mehr mit NTX und da gab es welche). Ich gehe das Problem nur generell durch, weil ich gerne eine pauschale Lösung für alles haben möchte. Weiterhin möchte ich diese Routinen schreiben, für alle späteren Programme nutzen und vor allen Dingen nie wieder anfassen müssen. Es geht hier also nur rein ums Prinzip, die eierlegende Wollmilchsau so nahe wie möglich zu kreieren. Und vor allen Dingen dazuzulernen.

[Manfred]

Hi,

jetzt verstehe ich nichts mehr. Ich denke mit Dbunlock() wird nur der aktuelle Satz auf dem man steht wieder entsperrt? UNLOCK wirkt ja nur auf die aktuelle DB, während DbUnlock() mit Alias aufgerufen auf jede beliebige wirken kann. Also was bringe ich hier durcheinander?

[Martin Altmann]

Hallo Manfred,

Also was bringe ich hier durcheinander?

eigentlich nichts :?:

Viele Grüße,
Martin

[AUGE_OHR]

hi

jetzt verstehe ich nichts mehr. Ich denke mit Dbunlock() wird nur der aktuelle Satz auf dem man steht wieder entsperrt? UNLOCK wirkt ja nur auf die aktuelle DB, während DbUnlock() mit Alias aufgerufen auf jede beliebige wirken kann. Also was bringe ich hier durcheinander?

Ich gehe mal davon aus das du vorher ALIAS->(FLOCK()) hattes und
das nun wieder "loswerden" willst ?

wie wäre es mit ALIAS->( DbUnlock() ) oder ALIAS->( DbUnlockAll() )
Beide "entsperren" ein FLOCK() genauso wie UNLOCK oder CLOSE.

gruss by OHR
Jimmy

[Manfred]

Moin,

ein DbunlockAll() entfernt doch ALLE Sperren, in allen geöffneten DB gleichzeitig, oder lese ich das verkehrt?

Beschreibung

Die Datei-Funktion DbUnlockAll() löscht alle bestehenden Datensatz- und Dateisperren in allen Workareas. Die Funktion ist nur von Bedeutung, wenn Dateien im SHARED Modus geöffnet wurden.
Anstelle von DbUnlockAll() kann der Befehl UNLOCK ALL verwendet werden.

Das will ich aber gar nicht haben.... Sie entsperrt in allen geöffneten DB gleichzeitig alle Sätze. (verstehe ich jedenfalls so.)

Und was soll dass hier heißen?

Beschreibung

Die Datei-Funktion DbUnlock() löscht alle bestehenden Datensatz- und Dateisperren in einer Workarea. Wenn die Funktion ohne Aliasoperator verwendet wird, hebt sie die Sperren in der aktuellen Workarea auf. Die Funktion ist nur von Bedeutung, wenn Dateien im SHARED Modus geöffnet wurden.

Ich denke Dbunlock() entsperrt nur den Satz auf dem man gerade steht, oder den man explizit an die Funktion weitergibt.

[brandelh]

Hi Manfred,

ich weiß nicht, warum du glaubst, dass dbUnlock() nur den aktuellen Satz entsperrt. Laut Beschreibung verhält es sich genauso wie UNLOCK und das hat schon immer die aktuelle DATEI entsperrt, also alle Dateisperren aufgehoben. Man kann mit andereWorkarea->(dbUnlock()) allerdings auch eine andere DBF als die in der aktuellen Workarea unlocken, was mit dem Befehl nicht geht - wie bei anderen Funktionen/Befehlen auch.

[Manfred]

Hi Hubert,

ich habe es nicht nur geglaubt, ich war davon auch feste überzeugt. Aber was ist denn, wenn ich in einer Tabelle mehrere Sätze sperre, aber nicht alle auf einmal freigeben will? Ich habe es wirklich so verstanden, nur der Satz wieder freigegeben wird, auf dem man steht, bzw. der Satz, den man als Recno() an die Funktion weitergibt. Ich dachte so db->(dbunlock(x)).

Auf welcher Wolke schwebe ich eigentlich?

[Sören]

Hallo Manfred,

Ich denke Dbunlock() entsperrt nur den Satz auf dem man gerade steht, oder den man explizit an die Funktion weitergibt.

UNLOCK
UNLOCK ALL
dbUnlock()
dbUnlockAll()

machen alle dasselbe: Sie entsperren in der aktuellen Workarea alle Datensätze oder die gesamte Datei (falls diese mit FLock() gesperrt wurde).

Mit dbRUnlock( nRecNo ) hingegen kann in der aktuellen Workarea ein einzelner Datensatz entsperrt werden; bei allen anderen in der Workarea gesperrten Datensätze bleiben die Sperren erhalten.

[Manfred]

Hi Sören,

aha, ich glaube dieser Tag, bzw. wird die Zeit der Erkenntnis werden.....

Dann habe ich wohl irgendwas total verkehrt interpretiert. Naja, jetzt wissen es jedenfalls alle in diesem Forum, wie es klappt.

An alle:

Gebt es zu, war ich der einzige Dumme?

[brandelh]

den man als Recno() an die Funktion weitergibt. Ich dachte so db->(dbunlock(x)).

also in der Hilfe bis zur 1.90.331 gibt es keinen Parameter bei dbUnlock().

ABER es gibt eine neue Funktion passend zu der neuen Lockfunktion:

dbRUnlock() - diese verhält sich so wie du beschrieben hast. Passend zu:
dbRLock()

diese recht neuen Funktionen können das was du willst.

PS: die hatte ich schon wieder total vergessen da ich sie nicht brauche.

[Manfred]

wie schon erwähnt,

ich weiß nicht was ich da wieder wann und wo gelesen, oder interpretiert habe......

[Rolf Ramacher]

Hi Manfred,

ich mache das bei meiner Indexerstellung so.

Code: Alles auswählen

If !File(cHeimat+("\Spwatch.cdx")) 	
   If !Netz_Use(cHeimat+"\Spwatch.Dbf",.t.)
       Quit
   EndIf
   oStatic1:caption:=(cText+"SPWATCH")
   oStatic1:configure()
   Index on Artikelnr tag "Artikelnr" to (cHeimat+"\Spwatch.cdx")
EndIf

Function Netz_Use()
Local lJa:=.f.
PARAMETERS Datei, ex_use, cTitel, Info, Name

If Info="alias"
	If ex_use && exclusive
		Use &Datei New Exclusive Alias Name
	EndIf
Else
	If ex_use && exclusive
		Use &Datei New Exclusive
	EndIf
EndIf
If NetErr()
	lJa:=.f.
	Msgbox("Die Datenbank "+Datei+" ist in Benutzung"+CRLF+;
         "Das Programm an allen Stationen beenden und erneut starten",cTitel)
Else
	lJa:=.t.
EndIf
Return lJa

Vielleicht hilft es dir.

[Sören]

UNLOCK
UNLOCK ALL
dbUnlock()
dbUnlockAll()

machen alle dasselbe: Sie entsperren in der aktuellen Workarea alle Datensätze oder die gesamte Datei (falls diese mit FLock() gesperrt wurde).

Diese, meine Aussage muss ich berichtigen:

UNLOCK und dbUnlock()
entfernen alle Datensatz- und Dateisperren in der aktuellen Workarea.
Mit (cAlias)->( dbUnlock() ) kann natürlich auch eine andere als die aktuelle Workarea ausgewählt werden.

UNLOCK ALL und dbUnlockAll()
entfernen alle Datensatz- und Dateisperren in allen Workareas.