PDA

Vollständige Version anzeigen : 1 Frontend für Lese-Modus, 1 FE für Änderungen?


Tinus Lorvalds
24.03.2006, 09:34
EDIT: Was ist mit dem letzten Beitrag passiert? :entsetzt:


Hallo Leute!

Ich habe eine Datenbank mit Frontend und Backend, jeder User darf jederzeit die DB öffnen und Änderungen vornehmen. Das ist so gewünscht, es ist aber meiner Meinung nach sehr problematisch. Was ist, wenn ein wichtiges Feld versehentlich mit einem "xxxxx" ersetzt wird? Ich muss mir was einfallen lassen. Könnte man mit einem Frontend die DB im "Nur-Lese-Modus" und mit einem anderen Frontend im Änderungsmodus öffnen? Oder was würdet ihr empfehlen?

Tinus

racoon0506
24.03.2006, 09:43
prinzipiell geht es schon, ein FE lediglich für lesenden Zugriff auf die Tabellendaten zu gestalten....

Die Frage ist doch eher, unter welchen Umständen kann es "versehentlich" dazu kommen, dass wichtige Felder überschrieben werden und lässt sich das nicht abfangen?

Tinus Lorvalds
24.03.2006, 10:00
Na ja, ich möchte niemanden zu nahe treten, aber wenn ich mir einige Anwender anschaue...ich weiß nicht, ich traue denen nicht. Und abfangen geht nur schlecht. Der Anwender schläft ein und knallt mit dem Kopf auf die Tastatur. Das Feld Beruf wird mit "Fdsgr<ttrhtr76rtz" gefüllt. Anwender steht auf, macht die DB zu, bestätigt evtl. eine Rückfrage vor dem Schließen, da er nicht sieht, was er angerichtet hat...und schon sind die Daten 'putt. :(

Tinus Lorvalds
24.03.2006, 10:04
Was ist jetzt los???

KHS
24.03.2006, 10:19
Na du hast ja 'heiße' Anwender! :)
Du könntest z.B. per AllowEdits, etc. bestimmen, ob ein Formular bearbeitbar ist, und per Buttons entsprechend sperren oder freigeben.
Oder du arbeitest mit ungebundenen Formularen.

KHS
24.03.2006, 10:21
:eek: Hey, was ist denn da los, da hat es irgendwie die Beiträge vermischt!

KHS
24.03.2006, 10:22
[Gelöscht]
(Da hat was gesponnen)!?

Arne Dieckmann
24.03.2006, 10:23
Keine Panik, Leute.

Wenn man "<" ohne folgendes Leerzeichen einsetzt, sollte das mit &amp;lt; maskiert werden. Ansonsten deutet der Browser das als HTML-Tag.

Anne Berg
24.03.2006, 10:47
Zum Thema: ;)
Kannst du die Anwender in "nur lesen" und "ändern erlaubt" gruppieren? Hast du schon mal über den Einsatz der Benutzerberechtigen nachgedacht?

Von der Trennung in zwei Datenbanken und damit doppelten Pflege der Formulare und Funktionen etc. kann ich nur abraten.

Tinus Lorvalds
24.03.2006, 11:15
Hallo!

Ja, daran habe ich schon gedacht und die Anwender befragt. Sogar der "fitteste" von denen möchte auch'ne "nur Lesen"-Version.

Mir fällt nur noch die Möglichkeit mit 2 Frontends ein. Aber wie könnte man das realisieren?

Anne Berg
24.03.2006, 11:21
Eine einfache Methode wäre z.B. beim Öffnen eines Formulars den Benutzer-Account abzufragen und die Formulareigenschaften entsprechend einzustellen:

RecordsetType: Dynaset/Snapshot oder
AllowEdits: True/False

Tinus Lorvalds
24.03.2006, 11:58
Hm, AllowEdits war'ne gute Idee, ich habe einen Knopf eingebaut:

Private Sub cmdEditieren_Click()
'Umschalten zwischen Editieren und Sperren
If Me.AllowEdits = False Then
Me.AllowEdits = True
Me.cmdEditieren.Caption = "Sperren"
Else
SendKeys "+{Enter}"
Me.AllowEdits = False
Me.cmdEditieren.Caption = "Editieren"
End If
End Sub

Klappt ganz gut, aaaaber...wenn man zwischen "Sperren" und "Editieren" hin und her springt, ist die Änderung noch nicht wirksam bis der Datensatz nicht gespeichert ist. Und DS speichern, wenn frm gesperrt ist, geht wohl nicht. :(

Anne Berg
24.03.2006, 12:21
Was machst du denn mit dem Sendkeys-Befehl? Kann ich nur von abraten, den überhaupt einzusetzen. Es gibt da eigentlich immer unproblematischere Alternativen...

(z.B. DoCmd.RunCommand acCmdSaveRecord)

Lia
24.03.2006, 12:22
Versuch mal, das beim Öffnen des Forms einzubauen.

Oder sollen die Felder nach dem Klicken auf den Button wieder editieren lassen?

Anne Berg
24.03.2006, 12:23
Das ist wohl nicht ganz das, was er da haben will, Julia. ;)

Tinus Lorvalds
24.03.2006, 12:26
Das bringt auch nix, da der Anwender immer noch versehentlich Änderungen vornehmen kann - und das im "Gesperrt"-Modus. Wäre schön, wenn man zwischen "Gesperrt" und "Edit" umschalten könnte ohne den DS zu speichern.

Lia
24.03.2006, 12:27
@Anne

Hast Recht, aber dein Kommentar kam gleichzeitig mit meiner Editierung. ;)

Lia
24.03.2006, 12:29
Eine Alternative wäre eine Schleife, die alle Felder durchläuft und sie inaktiviert/wieder aktiviert. Ich weiß allerdings nicht, wie es sich hier mit dem Speichern verhält.

Anne Berg
24.03.2006, 12:51
Wäre schön, wenn ... ohne den DS zu speichern.Das verstehe ich jetzt nicht. :confused:
Wenn die Bearbeitung frei ist und du willst den Modus wechseln, musst du doch die letzte Änderung speichern, wenn du sie nicht verlieren willst. Oder du fragst ab "Speichern Ja/Nein?", dann kannst du den RunCommand-Befehl gezielt einsetzen (Undo/SaveRecord).

JörgG
24.03.2006, 16:40
Hallo Tinus,

Alle Eventualitäten kannst Du sowieso nicht abfangen, zB wenn der User entsperrt und dann auf der Tastatur in seinen wohlverdienten Büroschlaf fällt.... :biggrinl: Den Schreibschutz realisiere ich so, wie es die Damen vorgeschlagen haben, mit einer Umschaltfläche. Setze dazu für alle zu sperrenden Steuerelemente die Marke auf "X" (Eigenschaftsfenster - Register - Andere):
Private Sub UFNurLesen_Click()
On Error Resume Next 'nicht alle Steuerelemente haben die Eigenschaft
Dim Ctl As Control
If Me.UFNurLesen = True Then
Me.UFNurLesen.Caption = "E D I T" 'Beschriftung ändern
Me.UFNurLesen.ForeColor = 8421376 'Farbe ändern
Me.UFNurLesen.ControlTipText = "Schreibschutz aktivieren" 'Tipptext ändern
Else
Me.UFNurLesen.Caption = "Nur" & vbCrLf & "Lesen"
Me.UFNurLesen.ForeColor = 255
Me.UFNurLesen.ControlTipText = "Schreibschutz aufheben"
End If
For Each Ctl In Me.Controls 'sperren/entsperren
If InStr(1, Ctl.Tag, "X", 1) > 0 Then 'falls Tag zB "XYZ" ist
Ctl.Locked = IIf(Me.UFNurLesen = True, False, True)
Ctl.BackColor = IIf(Me.UFNurLesen = True, -2147483643, 15660535)
End If
Next Ctl
Me.IrgendeinFeld.SetFocus
End Sub
Wie Lia schon schreibt im Form_Open/_Current setzen, bzw für's Anfügen, Löschen & Co:
Private Sub Form_Open(Cancel As Integer)
Me.UFNurLesen = False
Call UFNurLesen_Click
End Sub
Vielleicht hilft's Dir weiter. :dance:

Tinus Lorvalds
28.03.2006, 08:48
@ Anne Berg

Na ja, ich wollte die Daten speichern, bevor der DS "aktualisiert" wird, deswegen der Versuch mit Shift+Enter über SendKeys. Aber wenn's nicht geht...

@ Jörg G

Die Form_Open verursacht einen Laufzeitfehler '438': Objekt unterstützt diese Eigenschaft oder Methode nicht.

Ich bedanke mich, denke mal, dass die Lösung mit AllowEdits ausreichend ist. Die Kollegen sind zufrieden und haben mir versichert, dass sie nicht doof sind. :blabla:

Anne Berg
28.03.2006, 08:53
LZF 438:
wie sieht denn bei dir das Control "UFNurLesen" aus? (--> Umschaltfläche?!)

... und dann sollten die Steuerelemente grundsätzlich mit "Me!..." angesprochen werden (Einsatz von Punkt und Ausrufezeichen siehe Access-FAQ 6.3!)

Tinus Lorvalds
28.03.2006, 09:08
Ist eine normale Schaltfläche.

Anne Berg
28.03.2006, 09:14
Hast du meinen "Wink mit dem Zaunpfahl" nicht verstanden?!

Jörg schrieb doch, dass er eine Umschaltfläche dafür einsetzt. Nur die kennt den Status True/False - eine Standardschaltfläche nicht!

PS: der Fehler muss aber wohl doch an anderer Stelle liegen! Kannst du das bitte mal austesten?

Tinus Lorvalds
28.03.2006, 12:56
Jaaa, sorry, mit'ner Umschaltfläche kommt keine Fehlermeldung mehr. :redface:

Allerdings wird auch nix umgeschaltet. :(

Tinus Lorvalds
28.03.2006, 13:19
Hab' mich wieder vertan (ich sage lieber nicht wo :redface: ). Jetzt läuft's einwandfrei, nach dem Umschalten sind die Felder gesperrt. Was meint ihr, sollte der "Knopf" den aktuellen Zustand anzeigen (EDIT, wenn Felder frei) oder lieber die Auswirkung eines Klicks (EDIT, wenn Felder gesperrt)?

Lia
28.03.2006, 13:26
Normalerweise erhält das Ding die Beschriftung mit der Auswirkung. Dafür muss man dann aber auch nicht den Status "gesperrt" oder "entsperrt" als Beschriftung wählen, sondern "sperren" oder "entsperren" - praktisch als Befehl. Das ist etwas übersichtlicher.

Den Status fände ich persönlich unübersichtlich. Aber das ist Ansichtssache.

Anne Berg
28.03.2006, 13:48
Auch wenn das jetzt grade mal - und mit einiger Mühe :D - funktioniert, ich würde es am liebsten noch anders machen:

separate Schaltflächen für "Ändern", "Speichern" u. "Abbrechen" und die jeweils De-/Aktivieren abh. vom aktuellen Status. :)

Beispiel:
- bei Klick auf Ändern wird Speichern und Abbrechen aktiviert, Ändern deaktiviert, Felder werden freigegeben
- bei Klick auf Speichern oder Abbrechen wird beides deaktiviert, Ändern aktiviert, Felder deaktiviert und natürlich die gewünschte Aktion (RunCommand acCmdSaveRecord oder acCmdUndo) ausgeführt.

Tinus Lorvalds
29.03.2006, 06:22
Ähh, das ist viel zu kompliziert! Die aktuelle Lösung ist super, mehr brauche ich nicht. Danke!

Wie kommt es aber, dass mit JörgGs Lösung eine sofortige "Speicherung" VOR Aktualisierung des Datensatzes möglich ist?

Anne Berg
29.03.2006, 07:09
Was meinst du damit? :confused:

Bei "Jörgs Lösung" wird weder gespeichert noch aktualisiert, das muss dann wohl an deinem Code liegen.

Tinus Lorvalds
29.03.2006, 07:29
Nee, pass auf... ;)

Mit AllowEdits hat's auch geklappt, aber nach dem Klick auf "Sperren" oder "Editieren" war die Änderung erst nach Aktualisierung des Datensatzes wirksam, z.B. wenn man zum nächsten Datensatz springt o.ä. Beispiel: Klick auf "Editieren", jetzt können Daten eingegeben werden, Klick auf "Sperren", die Sperrung ist aber erst nach Aktualisierung wirksam.

Bei JörgGs Lösung kann ich problemlos zwischen "Sperren" und "Editieren" hin und her springen, der DS ist SOFORT frei oder gesperrt, ich kann die DB auch "mitten im Datensatz" schließen etc., alles funktioniert einwandfrei.

JörgG
29.03.2006, 08:20
Hallo Tinus,

dass das Sperren/Entsperren sofort aktiv wird hat nichts mit dem Speichern zu tun.

AllowEdits hab ich nicht eingesetzt, weil alles weggesperrt wird und das ist ja nicht immer erwünscht.

Was Anne's Vorschlag mit diversen Schaltflächen betrifft, das ist doch gar nicht so kompliziert. Du brauchst lediglich die Sub UFNurLesen in eine Funktion mit Boolean-Argument zu ändern (zB FktNurLesen(Byval NurLesen As Boolean)) und Me!UFNurLesen im Code durch das Argument NurLesen zu ersetzen. Aufruf erfolgt dann mit Call FktNurLesen(True/False) :cool:

Tinus Lorvalds
29.03.2006, 10:21
Seltsam aber, dass die Speicherung so gut klappt, ich habe nichts am Code geändert.

Ist jetzt egal, Hauptsache es funktioniert. Danke und bis später. Habe schon wieder was Kniffliges. :D :redface: