Inoffizielles deutsches Xbase-Forum

Noch eine Frage, gibt es Funktionen, um Satzsperren anzuzeigen ?
Es gibt für Clipper die Novlib, damit geht das, allerdings auch nur, wenn die DBF´s auf einem Novellserver liegen.
Die sollen bei uns dann aber auch vom Novellserver auf einen Windowsserver "umziehen"

Sind eigentlich noch irgendwelche Einstellungen an der Workstation ( XP / WIN7 ) bzw. am Windowsserver vorzunehmen, wenn dort die DBF´s liegen ?

Viel später sollen die DBF´s dann eh durch SQL ersetzt werden.

so kann es gehen.

do while 123->(!rlock())
enddo
--- anweisung

123->(dbunlock())

Hi Rolf, danke dir, aber du hast meine Frage nicht richtig verstanden

Ich wollte folgendes wissen: User 1 sperrt einen Datensatz, User xy versucht ebenfalls diesen Datensatz zu sperren, was natürlich dann nicht gehen wird.
Meine Frage war nun, wie bzw. ob User xy angezeigt werden kann, wer diesen Datensatz gesperrt hat

Klar, kann ich dazu extra eine Datenbank anlegen, in der die Sperren verwaltet werden, wenn es aber auch durch eine Funktion geht, wäre mir das lieber



Interessant übrigens, wie jeder seine Statement anderes formuliert

Ich würde schreiben: while !123->(rlock())

Rolf Ramacher hat geschrieben:so kann es gehen.

do while 123->(!rlock())
enddo
--- anweisung

123->(dbunlock())

Hi Eckhard,

ich habe meine DBF um Felder erweitert, in denen z.b steht, wer von wo zu welcher Zeit gesperrt hat. Und wenn der Satz nicht zu sperren geht, dann wird ausgelesen, was in den Feldern steht und am Bildschirm angezeigt. Ist sicherlich nicht jedermanns Sache, aber mir gefällt es. Sobald der Satz wieder freigegeben wurde, werden die Felder geleert

Hmmm, okay, das geht natürlich auch

Manfred hat geschrieben:Hi Eckhard,

ich habe meine DBF um Felder erweitert, in denen z.b steht, wer von wo zu welcher Zeit gesperrt hat. Und wenn der Satz nicht zu sperren geht, dann wird ausgelesen, was in den Feldern steht und am Bildschirm angezeigt. Ist sicherlich nicht jedermanns Sache, aber mir gefällt es. Sobald der Satz wieder freigegeben wurde, werden die Felder geleert

Hi,

es gibt leider keine solche Funktionalität. Der Ansatz von Manfred kann durchaus vernüftig funktionieren, wenn man den korrekt umsetzt (füllen und leeren der/des entsprechenden Felder). Hier bietet sich natürlich eigene Funktionen zum Sperren und Entsperren der Datensätze an, die die Zusatzinformationen verwalten. Problematisch wäre das in erster Linie bei Einsatz von 3rdParty-Sachen, da diese die Informationen nicht in der DBF ablegen würden...

Markus Walter hat geschrieben:Der Ansatz von Manfred kann durchaus vernüftig funktionieren, wenn man den korrekt umsetzt (füllen und leeren der/des entsprechenden Felder).

Also, dass würde ja nur unnötig die Datenbank aufblähen...
Schließlich müßte man für JEDE Tabelle solche Felder einführen!
Das finde ich Eckhards Ansatz schon wesentlich einfacher: nur eine Extra Tabelle, in der die Satzsperren eingetragen werden.

Viel einfacher wäre es natürlich mit dem ADS

Uli

Hilft eventuell DbRLockList()?

Jan

Da steht nur drin welche(r) Satz(menge) gesperrt sind, nicht aber wer gesperrt hat. Und das war die Eingangsfrage, oder?

Manfred,

naja, die ursprüngliche Eingangsfrage hat das noch nicht aufgezeigt. Aber Du hast Recht, in dem Nachtrag wird das erklärt.

Wir haben das übrigens in meiner letzten Firma ähnlich gelöst wie Du es beschreibst: Jede Datenbank hat 3 Felder zusätzlich: Welcher Anmeldename hat auf welchem PC wann (Date/Time-Feld) diesen Satz gesperrt? Das wurde eingetragen beim Sperren, und entfernt beim Verlassen. Bei einem Versuch, einen gesperrten Satz schreibend zu öffnen gab es eine Meldung, die diese drei Infos beinhaltete.

Jan

Jan hat geschrieben:Jede Datenbank hat 3 Felder zusätzlich: Welcher Anmeldename hat auf welchem PC wann (Date/Time-Feld) diesen Satz gesperrt? Das wurde eingetragen beim Sperren, und entfernt beim Verlassen.

Wie umständlich ...
Uli

Man sollte auch bei ausgefüllten Feldern immer mit rlock() versuchen den Satz zu sperren.
Sonst kann es passieren, dass ein abgestürzter Rechner Datensätze endgültig sperrt

Tja Uli,

aber es funktioniert. Und außerdem wollte Eckhard was wissen bzgl. xbase++ und DBF und nichts zu ADS. Dann paßt es doch wieder, oder? Und eine extra DBF zu verwalten finde ich aufwändiger als Extrafelder in der DBF.

Uli,

nun ja, das hatte sich mein Vor-Vorgänger an dem Projekt so ausgedacht, und es funktionierte einwandfrei. Daher gab es nie Grund, das zu ändern. Vielleicht sollte ich erwähnen, das es ein MS-Access-Projekt war ...

Jan

Manfred hat geschrieben:aber es funktioniert. Und außerdem wollte Eckhard was wissen bzgl. xbase++ und DBF und nichts zu ADS. Dann paßt es doch wieder, oder? Und eine extra DBF zu verwalten finde ich aufwändiger als Extrafelder in der DBF.

Tja Manfred,
bezüglich ADS war es auch nur ein Hinweis, das man so etwas genau wie früher nur unter Netware auch unter Windows oder Linux machen kann
Und eine Tabelle mehr zu verwalten als Extrafelder in vielen Tabellen soll mehr Aufwand sein? Das ist doch wohl nicht Dein Ernst ...
Uli

Manfreds Ansatz, den ich übrigens auch an einigen Stellen benutze, funktioniert wenigstens mit allen DBEs, und übrigens auch mit der ADS. Und man will das ja nicht in allen Tabellen machen, sondern nur in einigen - etwa, wenn Kundendaten für die Bearbeitung gesperrt sind o.ä. Davon abgesehen spielt keine Rolle, ob es fallweise nicht gelingt, die Daten wieder zu löschen, da sie ja nur mit jedem erfolgreichen Lock gesetzt werden - und nur im Fall eines scheiternden gelesen (sie entscheiden nicht über das Locking!). Für andere Systematiken, die sich nicht an einzelnen Datensätzen festmachen lassen, läuft bei uns ein SOAP-Server mit (Xb2.Net), über den man u.a. auch Auskunft darüber erhält, wer gerade angemeldet ist und vieles mehr. Die App kommuniziert im Hintergrund ständig mit dem Server (inhouse selbstverständlich, jeder Kunde hat den, ist aber kein Must - sondern eine Option). Wenn der ADS läuft, werden dessen Funktionalitäten genutzt, aber unser SOAP-Server ist tatsächlich verlässlicher.

Tom hat geschrieben:Und man will das ja nicht in allen Tabellen machen, sondern nur in einigen - etwa, wenn Kundendaten für die Bearbeitung gesperrt sind o.ä. Davon abgesehen spielt keine Rolle, ob es fallweise nicht gelingt, die Daten wieder zu löschen, da sie ja nur mit jedem erfolgreichen Lock gesetzt werden

Wie meinst Du das? Die extra Tabelle bzw. auch die extra Felder müssen beim Locking in jedem Fall beschrieben werden, oder? Wenn es nun zu einem Programmabsturz kommt, bleiben die "falschen" Werte in der extra Tabelle bzw. den Extra Feldern stehen.
Wir haben im Normalfall ja keine Transaktionen, mit denen man so etwas verhindern könnte .
Uli

@Uli: Nicht in einer Extra-Tabelle, sondern in der (Kopf-)Tabelle, die auch betroffen ist, also z.B. in einer "KUNDEN.DBF". Die getrennte Verwaltung einer Tabelle für derlei führt nur zu Unbill. Wie gesagt, für komplexere Dinge (Vorgang sperrt bestimmte Programmteile) verwende ich den SOAP-Server.

Technisch läuft das übrigens so ab: MyLock() kann immer benutzt werden und funktioniert mit Tabellen, die das Feld nicht haben, genauso wie für die anderen.

Tom hat geschrieben:MyLock() kann immer benutzt werden und funktioniert mit Tabellen, die das Feld nicht haben, genauso wie für die anderen.

Fast genauso würde ich es auch mit einer Extra Tabelle machen, nur die Tabelle würde ich (natürlich ) als Parameter übergeben.
Aber bei dieser Vorgehensweise könnte es trotzdem zu "falschen Werten" kommen, oder?
Uli

Hallo, Uli.

Wozu eine getrennte Tabelle? Mit diesem simplen Verfahren kann man immer davon ausgehen, dass die Informationen stimmen, da Satzsperre und Speicherung der Benutzer-ID zugleich stattfinden (analog entfernt MyUnlock() diese Information, aber das ist eigentlich überflüssig). Und nur, wenn auch bereits eine Satzsperre vorliegt, werden die Daten angezeigt. Ich sehe da kein mögliches Konsistenzproblem ("falsche Werte") - und habe auch noch keines erlebt. Eine zusätzliche Tabelle wäre nur eine zusätzliche Fehlerquelle. Okay, man könnte diese zu Wartungs- oder Informationszwecken anzeigen, aber mehr Sinn kann ich in dieser Variante nicht erkennen.

Edit: Die reale Fassung dieser Funktion macht übrigens noch einiges mehr. Da wir tatsächlich nur in solchen Momenten sperren, in denen auch geschrieben wird, sind Lock-Failures sehr selten. Es gibt u.a. einen Timer (parametrisierbar) und eine Funktionalität, die auf Wunsch veränderte Datensätze vorher spiegelt und/oder in Backup-Dateien schreibt.

Tom hat geschrieben:
Edit: Die reale Fassung dieser Funktion macht übrigens noch einiges mehr. Da wir tatsächlich nur in solchen Momenten sperren, in denen auch geschrieben wird, sind Lock-Failures sehr selten. Es gibt u.a. einen Timer (parametrisierbar) und eine Funktionalität, die auf Wunsch veränderte Datensätze vorher spiegelt und/oder in Backup-Dateien schreibt.

Ah,

interessante Idee.. =D>

Tom hat geschrieben:Mit diesem simplen Verfahren kann man immer davon ausgehen, dass die Informationen stimmen, da Satzsperre und Speicherung der Benutzer-ID zugleich stattfinden

Tom, du verwirrst mich. Was meinst Du denn jetzt mit Benutzer-Id?
Und das ganze macht doch nur Sinn, wenn du MEHRERE Schreibvorgänge hast:
1) GESP_Durch wird geschrieben
2) Die eigentlichen Daten des Datensatzes werden geschrieben
3) GESP_Durch wird wieder mit dem ursprünglichen Wert geschrieben
Wenn es z.B. zwischen 1) und 3) zu einem Rechnerabsturz kommt, steht doch der "Falsche Wert" in GESP_Durch.

Und wie wird FLock() behandelt? Da müßte ja in ALLE Datensätze in GESP_Durch etwas eingetragen werden. Oder?

Uli

Hallo, Uli.

Diese Funktion übernimmt das Sperren des Datensatzes und schreibt ausschließlich das Feld "GESP_DURCH". Es ist bei uns so, dass alle Schreib- und Löschoperationen unmittelbar dem RLock() folgen (es gibt aber eine ähnliche Funktion noch für DbAppend). Mit dem Unlock wird die Information zwar wieder gelöscht, aber das spielt eigentlich keine Rolle, da sie nur abgerufen wird, wenn auch ein RLock() vorliegt, und dem muss ja unmittelbar anschließend das Setzen der Info gefolgt sein. Jeder Absturz führt schließlich zur Freigabe aller Locks, wodurch dann egal wird, was in diesem Feld steht, verstehst Du? Und FLocks gibt's bei uns nicht. Ausschließlich in Serviceroutinen werden Dateien exclusiv angefasst, und dort ist dafür gesorgt, dass niemand zugleich mit den Daten arbeiten kann. Ansonsten gibt es exclusive Zugriffe nur bei temporären Hilfsdateien, aber auch die sind wir inzwischen weitgehend los (durch Arrays ersetzt).

Tom hat geschrieben:Jeder Absturz führt schließlich zur Freigabe aller Locks, wodurch dann egal wird, was in diesem Feld steht, verstehst Du?

Ok, es können also falsche Werte drin stehen. Aber Du hast natürlich Recht, das macht ja nichts
Uli