|
| |
VB & Datenbanken| Welcher User ist im System angemeldet | |  | | Autor: caramba | | Datum: 09.05.13 08:40 |
| Hallo,
gibt es eine Möglichkeit festzustellen, welcher User im System angemeldet ist? Noch toller wäre es,
wenn man noch zeigen könnte, welches Programm der angemeldete Benutzer ausführt .... das ist aber wohl Wunschdenken?!
Danke
Rainer | |
| Re: Welcher User ist im System angemeldet | | | | Autor: effeff | | Datum: 10.05.13 14:41 |
| Moin,
was meinst Du mit "am System angemeldet"? Den momentan aktiven Windows-Nutzer? Den erhältst Du mit
Dim Username As String
Username = Environ("username")
MsgBox ("Der Benutzername lautet: " & Username)Und welches Programm der Benutzer ausführt, ist so eine Sache. Immerhin kann man eine ganze Menge Programme gleichzeitig öffnen. Du kannst z. B. per API alle Programme mit Fenstern auflisten oder Du kannst alle Prozesse auflisten. Was davon möchtest Du denn?
EALA FREYA FRESENA | |
| Re: Welcher User ist im System angemeldet | | | | Autor: caramba | | Datum: 12.05.13 08:12 |
| Hallo,
danke für Deine Antwort. Ich habe programmseitig eine Lösung gefunden, bei welcher ich jede Anmeldung im Programm mit Username, Datum und Zeit protokolliere. Bei einer Abmeldung setze ich das Abmeldedatum und die Abmeldezeit. Somit habe ich Übersicht, wer angmeldet ist.
Ein anderes Problem ist jedoch viel wichtiger. Mir wird gemeldet, dass Benutzer sich zeitweise blockieren wenn sie auf den gleichen Vorgang (Reisebuchung) buchen. Dabei kann es sicher vorkommen, dass ein Benutzer eine Tabelle öffnet und dann vom Platz verschwindet und einen Kaffee holt (Beispiel). Der Satz ist dann gesperrt.
Kann man programmseitig feststellen, ob eine Row gesperrt ist und wenn ja, von wem?
Ich möchte dann gern eine entsprechende Fehlermeldung ausgeben. Der SELECT siehr wie folgt aus:
sSQL = "SELECT * FROM tblreiseSitzplan WHERE SitFID = '" & PrüfBus & "' AND" & _
"SitNr = '" & SearchSitz & "'"
cRs.CursorLocation = adUseClient
cRs.Open sSQL, oConn, adOpenKeyset, adLockOptimisticDanke für jeden Rat.
Rainer | |
| Re: Welcher User ist im System angemeldet | | | | Autor: Franki | | Datum: 14.05.13 01:25 |
| Hallo Rainer,
welche Datenbank verwendest du?
Das Öffnen selbst ist ja eigentlich unschädlich.
Also User A setzt das SQL Statement ab, bekommt das entsprechende Ergebnis in einer Liste, Grid oder was auch immer angezeigt, aber sofort wird das RS geschlossen. Dann kann er Kaffee trinken gehen, in Urlaub fahren usw. solange er möchte. Da ist dann keine Tabelle der DB blockiert.
Erst wenn dieser User wieder schreiben möchte in die DB kontrollierst du, ob der Datensatz noch aktuell ist oder zwischenzeitlich bearbeiten worden ist durch einen anderen User. Wenn nein, dann speichern, wenn ja, dann halt neu einlesen und entsprechenden Hinweis geben.
Der Code nach deinem RS.Open wäre auch wichtig bis zum RS.Close bzw. was dazwischen passiert und wann.
Gruß
Frank
| |
| Re: Welcher User ist im System angemeldet | | | | Autor: caramba | | Datum: 15.05.13 06:54 |
| Hallo Franki,
Du hast mich auf eine Idee gebracht. Der Recordset wird eben nach dem Lesen nicht gleich
geschlossen. Ich war (und bin) der Meinung; dass dieser SELECT keine Rows sperrt - aber
diese Ansicht kann natürlich falsch sein.
Ich arbeite mit MySQL (INNODB).
Gruss
Rainer | |
| Re: Welcher User ist im System angemeldet | | | | Autor: Franki | | Datum: 19.05.13 01:22 |
| Hallo Rainer,
wie genau das technisch bei MySQL abläuft weiß ich nicht.
Aber andererseits ist das ja auch völlig richtig, dass zwei User nicht gleichzeitig auf ein und den selben Vorgang lesen und dann schreibend zugreifen dürfen.
Grade bei begrenzten Mengen wie z.B. in der von dir angesprochenen Reisebranche ist es ja völlig egal, ob die DB das selbst blockiert oder du das per Programmcode erledigen musst.
Beispiel: Hotel A hat noch genau ein Zimmer frei, zwei User zeigen einem Kunden das Zimmer auf dem Bildschirm, beide Kunden sagen, "will ich haben", beide User klicken auf die Schaltfläche "Buchen" Und dann?
Unabhängig von den eigenen Mechanismen der jeweiligen DB mußt du sowieso kontrollieren, dass verschiedene User nicht den gleichen Datensatz schreibend bearbeiten dürfen. Ich persönlich fahre damit gut, das selbst zu kontrollieren und das nicht der jeweiligen DB zu überlassen.
Gruß
Frank
| |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
TOP! Unser Nr. 1 
Neu! sevDataGrid 3.0
Mehrspaltige Listen, mit oder ohne DB-Anbindung. Autom. Sortierung, Editieren von Spalteninhalten oder das interaktive Hinzufügen von Datenzeilen sind ebenso möglich wie das Erstellen eines Web-Reports. Weitere InfosTipp des Monats TOP Entwickler-Paket 
TOP-Preis!!
Mit der Developer CD erhalten Sie insgesamt 24 Entwickler- komponenten und Windows-DLLs. Die Einzelkomponenten haben einen Gesamtwert von 1605.50 EUR...
Jetzt nur 599,00 EURWeitere Infos
|
| |
|
Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|
Mai 2024
Sie sind aktuell nicht angemeldet.