Satzsperren anzeigen
Moderator: Moderatoren
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9390
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 363 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
@Uli: Ach so, das hatte ich übersehen. "nBenutzerId" ist ein interner Wert, der jeden Benutzer im Programm eindeutig identifiziert. GetUserFromId() liefert zu dieser ID den Klarnamen. Beides liegt natürlich in einer Tabelle und wird beim Programmstart oder Benutzerwechsel gesetzt/ausgelesen. Danach ist diese Tabelle zu.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15703
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
Hi,
eine zweite Datei ist von der Zeit und Verwaltung problematisch, wenn man es aber so macht wie ich es geschrieben habe
und ein Satz die ganze Bearbeitungszeit gesperrt bleiben soll, kostet es weder Zeit noch ist es unsicher !
1. Jeder Datensatz hat ein Zeichenfeld mit dem Benutzernamen oder der Benutzer-ID, die paar Byte spielen keine Rolle bei Festplatten.
2. Jeder der einen Datensatz bearbeiten will, versucht eine Sperrung (egal ob das Feld ausgefüllt ist oder nicht).
2a. Wenn RLOCK() fehlschlägt, ist der Satz noch in Bearbeitung und der Feldinhalt zeigt den Benutzer an.
2b. Wenn RLOCK() erfolgreich ist, war der Satz nicht in Bearbeitung, die Benutzer-ID wird mit der eigenen überschriebenen und nun kann man arbeiten.
3. Der Satz bleibt gesperrt bis die Änderung durch ist ...
4. Replace der Daten und Löschen der Benutzer-ID
5. Unlock
Keine unnötigen Sperren, sicheres erkennen eines bereits gesperrten Datensatzes, auch nicht zurückgesetzte Sätze können bearbeitet werden.
Natürlich wäre es schön, wenn man eine Funktion wie IsDbLock() hätte, aber man hat sie nicht und jedes unnötige dbrlock() kostet unnötig Zeit.
eine zweite Datei ist von der Zeit und Verwaltung problematisch, wenn man es aber so macht wie ich es geschrieben habe
und ein Satz die ganze Bearbeitungszeit gesperrt bleiben soll, kostet es weder Zeit noch ist es unsicher !
1. Jeder Datensatz hat ein Zeichenfeld mit dem Benutzernamen oder der Benutzer-ID, die paar Byte spielen keine Rolle bei Festplatten.
2. Jeder der einen Datensatz bearbeiten will, versucht eine Sperrung (egal ob das Feld ausgefüllt ist oder nicht).
2a. Wenn RLOCK() fehlschlägt, ist der Satz noch in Bearbeitung und der Feldinhalt zeigt den Benutzer an.
2b. Wenn RLOCK() erfolgreich ist, war der Satz nicht in Bearbeitung, die Benutzer-ID wird mit der eigenen überschriebenen und nun kann man arbeiten.
3. Der Satz bleibt gesperrt bis die Änderung durch ist ...
4. Replace der Daten und Löschen der Benutzer-ID
5. Unlock
Keine unnötigen Sperren, sicheres erkennen eines bereits gesperrten Datensatzes, auch nicht zurückgesetzte Sätze können bearbeitet werden.
Natürlich wäre es schön, wenn man eine Funktion wie IsDbLock() hätte, aber man hat sie nicht und jedes unnötige dbrlock() kostet unnötig Zeit.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9390
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 363 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
@Hubert: Genau so macht es die Funktion, die ich weiter oben skizziert habe. Und sie funktioniert sogar für Tabellen, denen diese Felder fehlen. Sie ersetzt RLock(). Ein Ersetzen des Infofelds beim Entsperren ist eigentlich überflüssig.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15703
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
Für obige Änderung ja, aber wenn man z.B. eine Meldung anzeigen möchte ("In Bearbeitung durch ...") ist es sinnvoll es zu leeren und es kostet ja nichts, da es noch im LOCK ist.Tom hat geschrieben:Ein Ersetzen des Infofelds beim Entsperren ist eigentlich überflüssig.
Code: Alles auswählen
If ! empty(cSperrID)
Meldung "in Bearbeitung durch ..."
else
Meldung löschen
endif
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
Das könntest Du aber relativ einfach durch ein vorsorgliches RLock() durchführen, wenn etwas in GESP_Durch steht:brandelh hat geschrieben:Für obige Änderung ja, aber wenn man z.B. eine Meldung anzeigen möchte ("In Bearbeitung durch ...") ist es sinnvoll es zu leeren und es kostet ja nichts, da es noch im LOCK ist.Tom hat geschrieben:Ein Ersetzen des Infofelds beim Entsperren ist eigentlich überflüssig.
RLock() erfolgreich: GESP_Durch leeren und nix anzeigen (und UnLock()
RLock() nicht erfolgreich: GESP_Durch anzeigen
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- brandelh
- Foren-Moderator
- Beiträge: 15703
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
Hallo Uli,
genau diese unnötigen rlock() möchte ich ja vermeiden, man stelle sich vor wenn 200 Rechner
dauern locken und unlocken nur zu zu erfragen ob eventuell ein Satz gesperrt ist
genau diese unnötigen rlock() möchte ich ja vermeiden, man stelle sich vor wenn 200 Rechner
dauern locken und unlocken nur zu zu erfragen ob eventuell ein Satz gesperrt ist
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Satzsperren anzeigen
Es muss ja NUR dann ein RLock() aufgerufen werden, wenn tatsächlich etwas in GESP_Durch steht!brandelh hat geschrieben:genau diese unnötigen rlock() möchte ich ja vermeiden, man stelle sich vor wenn 200 Rechner
dauern locken und unlocken nur zu zu erfragen ob eventuell ein Satz gesperrt ist
Selbst das könnte man noch einschränken, wenn GESP_Durch den Zeitpunkt des Satzsperre enthält. z.B. nur dann prüfen, wenn die Sperre länger als 1 Minute her ist .
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- AUGE_OHR
- Marvin
- Beiträge: 12912
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Satzsperren anzeigen
welche NovLib Function meinst du jetzt ... ? klar im "Monitor" des Server kann ich mir den User ansehen und welche Dateien er geöffnet hatEckhard Sallermann hat geschrieben: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.
... aber da steht doch kein "Offset" an welcher Stelle der User den RLock() gemacht hat, oder ?
Systemsteuerung -> Verwaltung -> Computerverwaltung -> Freigegebene Ordner -> geöffnete Dateien
gibt dir die User und Dateien genauso wie im "Monitor" am NW Server.
für die Tasten Freak´s empfehle ich http://technet.microsoft.com/en-us/libr ... 90961.aspx
wenn man dann mittels "Dependency Walker" sich ansieht welche DLL aufgerufen werden kommt man zu dem API Befehlen die verwendet werden.
gruss by OHR
Jimmy
Jimmy
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Satzsperren anzeigen
Hi Tom,Tom hat geschrieben:Technisch läuft das übrigens so ab:Code: Alles auswählen
FUNCTION MyLock(lShowMessage) DEFAULT lShowMessage TO .F. IF RLock() IF IsFieldVar('GESP_DURCH') FieldPut('GESP_DURCH',nBenutzerId) ENDIF RETURN .T. ENDIF IF lShowMessage MsgBox('Datensatz gesperrt'+IF(IsFieldVar('GESP_DURCH').AND.!Empty(GESP_DURCH),' durch '+GetUserFromId(GESP_DURCH),'')) ENDIF RETURN .F.
eine Anmerkung: Du must hinter dem FieldPut aber zumindest ein dbcommit() stehen haben, sonst ist der Schreibvorgang für andere Prozesse nicht lesbar...
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz