Satzsperren anzeigen

Auf dem Weg von Clipper, FoxPro u.ä. nach Xbase++

Moderator: Moderatoren

Satzsperren anzeigen

Beitragvon Eckhard Sallermann » Fr, 21. Okt 2011 7:10

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.
Benutzeravatar
Eckhard Sallermann
UDF-Programmierer
UDF-Programmierer
 
Beiträge: 88
Registriert: Fr, 29. Jun 2007 12:32
Wohnort: 33330 Gütersloh

Re: Satzsperren anzeigen

Beitragvon Rolf Ramacher » Fr, 21. Okt 2011 7:34

so kann es gehen.

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

123->(dbunlock())
Gruß Rolf

Mitglied der Gruppe XUG-Cologne
www.xug-cologne.de
Benutzeravatar
Rolf Ramacher
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1802
Registriert: Do, 09. Nov 2006 10:33
Wohnort: Bergheim

Re: Satzsperren anzeigen

Beitragvon Eckhard Sallermann » Fr, 21. Okt 2011 7:47

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 :wink:

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

Rolf Ramacher hat geschrieben:so kann es gehen.

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

123->(dbunlock())
Benutzeravatar
Eckhard Sallermann
UDF-Programmierer
UDF-Programmierer
 
Beiträge: 88
Registriert: Fr, 29. Jun 2007 12:32
Wohnort: 33330 Gütersloh

Re: Satzsperren anzeigen

Beitragvon Manfred » Fr, 21. Okt 2011 7:59

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
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 15834
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel

Re: Satzsperren anzeigen

Beitragvon Eckhard Sallermann » Fr, 21. Okt 2011 8:06

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
Benutzeravatar
Eckhard Sallermann
UDF-Programmierer
UDF-Programmierer
 
Beiträge: 88
Registriert: Fr, 29. Jun 2007 12:32
Wohnort: 33330 Gütersloh

Re: Satzsperren anzeigen

Beitragvon Markus Walter » Fr, 21. Okt 2011 8:09

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...
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
 
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 9:27

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
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: Satzsperren anzeigen

Beitragvon Jan » Fr, 21. Okt 2011 9:31

Hilft eventuell DbRLockList()?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
 
Beiträge: 11445
Registriert: Fr, 23. Sep 2005 17:23
Wohnort: 49328 Melle

Re: Satzsperren anzeigen

Beitragvon Manfred » Fr, 21. Okt 2011 9:33

Da steht nur drin welche(r) Satz(menge) gesperrt sind, nicht aber wer gesperrt hat. Und das war die Eingangsfrage, oder?
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 15834
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel

Re: Satzsperren anzeigen

Beitragvon Jan » Fr, 21. Okt 2011 9:39

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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
 
Beiträge: 11445
Registriert: Fr, 23. Sep 2005 17:23
Wohnort: 49328 Melle

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 9:42

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 ... :blob8:
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: Satzsperren anzeigen

Beitragvon brandelh » Fr, 21. Okt 2011 9:43

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 ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13195
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: Satzsperren anzeigen

Beitragvon Manfred » Fr, 21. Okt 2011 9:44

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.
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 15834
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel

Re: Satzsperren anzeigen

Beitragvon Jan » Fr, 21. Okt 2011 9:44

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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
 
Beiträge: 11445
Registriert: Fr, 23. Sep 2005 17:23
Wohnort: 49328 Melle

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 9:51

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 ... :D :wink:
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: Satzsperren anzeigen

Beitragvon Tom » Fr, 21. Okt 2011 10:05

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.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6656
Registriert: Do, 22. Sep 2005 22:11
Wohnort: Berlin

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 10:12

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
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: Satzsperren anzeigen

Beitragvon Tom » Fr, 21. Okt 2011 10:28

@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.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6656
Registriert: Do, 22. Sep 2005 22:11
Wohnort: Berlin

Re: Satzsperren anzeigen

Beitragvon Tom » Fr, 21. Okt 2011 10:39

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.


MyLock() kann immer benutzt werden und funktioniert mit Tabellen, die das Feld nicht haben, genauso wie für die anderen.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6656
Registriert: Do, 22. Sep 2005 22:11
Wohnort: Berlin

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 10:54

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 :wink: ) als Parameter übergeben. :-)
Aber bei dieser Vorgehensweise könnte es trotzdem zu "falschen Werten" kommen, oder?
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: Satzsperren anzeigen

Beitragvon Tom » Fr, 21. Okt 2011 11:06

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.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6656
Registriert: Do, 22. Sep 2005 22:11
Wohnort: Berlin

Re: Satzsperren anzeigen

Beitragvon Manfred » Fr, 21. Okt 2011 11:12

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>
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 15834
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 13:43

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
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: Satzsperren anzeigen

Beitragvon Tom » Fr, 21. Okt 2011 14:06

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).
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6656
Registriert: Do, 22. Sep 2005 22:11
Wohnort: Berlin

Re: Satzsperren anzeigen

Beitragvon UliTs » Fr, 21. Okt 2011 14:20

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
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2345
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Nächste

Zurück zu Migration

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast