Office: Sperrung einzelner Eingabefelder im Formular

Hallo, ich hab mal wieder ein Problem mit Access.

Seither war ich immer alleiniger Bearbeiter der Datenbank, aber nun wollen/sollen auch andere Leute im Betrieb Eintragungen in bestimmten Formularen vornehmen können.

Ich bin mir fast 100%ig sicher, dass es eine Möglichkeit gibt, gewisse (für die anderen Benutzer nicht relevanten) Eingabefelder zu sperren, wobei man vorher wohl Benutzergruppen anlegen muss.
Oder liege ich da falsch?

Wenn es irgendwie geht, kann ich das für eine bereits vorhandene Datenbank noch entsprechend anpassen?

Oder gibt es eine Möglichkeit, z.B. eine Abfrage oder sowas zu erstellen, die NICHT in der Datenbank hängt, die aber Beziehung dazu hat und Änderungen in bestimmten Feldern in die ursprüngliche Datenbank übernimmt?

Ich hab Bedenken, dass meine mühevolle Arbeit ratzfatz hin ist, wenn jeder in der Datenbank "rumfummeln" kann, so ala "wozu braucht man diese oder jene Abfrage, das lösche ich mal kurz" :evil:

Viele Grüße und tausend Dank für Hilfe!

 

Die Sorge ist sicher berechtigt... ;-)

Die Grundlage für eine Multi-User-Nutzung ist eine Aufteilung in Front- und Back-End. Das bedeutet:
Back-End: Enthält nur die Tabellen / Beziehungen und liegt als Datei auf einem zentral erreichbaren Netzwerk-Pfad.
Front-Ent: Enthält Formulare, Abfragen, Berichte usw., eben alles, was die Funktionalität ausmacht, aber eben nicht die Daten. Hier liegt eine Kopie auf jedem lokalen Rechner der Benutzer, die damit arbeiten können sollen.
Ein "Master" Front-End kann dann noch prima (schreibgeschützt) auf dem Server neben dem Back-End liegen und über eine passende Routine für automatische Updates oder Reparaturen der lokalen Kopie sorgen.

Der nächste Schritt wäre dann aber auch noch die Benutzung der Autostart-Möglichkeiten im Front-End, insbesondere das Öffnen eines Formulars und das Ausblenden des Datenbank-Fensters beim Start. Die einzelnen Formulare und Berichte sollten dann nur noch über definierte Wege (Buttons usw.) erreichbar sein - Stichwort Menüführung.

Je nach betriebenem Aufwand kann man eine Access-Anwendung optisch so kaschieren, daß man von Access selbst überhaupt nichts mehr sieht und es für eine stinknormale Windows-Anwendung hält.

Gruß, Michael

 

Hallo Michael,

genau so hatte ich mir das vorgestellt, aber ich habe die Befürchtung, dass meine PC-Kenntnisse hier nicht ausreichen werden.

Muss ich mir das so vorstellen, dass es zwei Dateien gibt, die eine enthält alle Datensätze, die andere die Formulare und Abfragen (oder auch nicht, es reicht eigentlich ein einziges Eingabeformular, DA müssen aber bestimmte Felder UNBEDINGT gesperrt sein, es darf keine Eingabe, Änderung, Löschung möglich sein) und diese zweite ist dann mit der ersten verknüpft?

Wenn ja, wie gehe ich vor?

Sorry, für die "blöden" Fragen, aber siehe oben... man hat mich da einfach reingeschubst, ich musste mir alles mühevoll mit Handbuch erarbeiten, nix mit Schulung oder so...

Viele Grüße
Susa

 

Ja, im Prinzip richtige Vorstellung...

Es geht irgendwie auch mit einem Assistenten, aber da ich denen noch nie so recht vertraut habe, hier der auch nicht viel aufwändigere Weg "zu Fuß":

Du nimmst Dir eine Datei, z.B. "Datenbank.mdb" und kopierst sie auf z.B. "Anwendung_Daten.mdb" und nochmal auf "Anwendung.mdb". Die Original-Datei versiehst Du jetzt mit Schreibschutz, daß damit nichts mehr passieren kann. (Alternativ kannst Du die natürlich auch direkt umbenennen und Dir die Kopie sparen. Je nach Risiko-Bereitschaft... ;-) )

Jetzt schnappst Du dir die "Anwendung_Daten.mdb" und löscht alles über das Datenbank-Fenster, was nicht nach Tabelle aussieht. Es bleiben also nur noch die Tabellen und die über "Extras - Beziehungen" darüber gestülpten Verknüpfungen übrig. Komprimiere diese mdb ruhig noch einmal und dann raus da.

Als nächstes jetzt die "Anwendung.mdb": Lösche dort alle Tabellen (und ggf. vorher die Beziehungen). Als nächstes verknüpfst Du die Tabellen über "Datei - Externe Daten... - Tabellen verknüpfen...". Du wählst dort einfach im Dateidialog die "Anwendung_Daten.mdb" aus und danach wählst Du alle Tabellen aus.

Tip bei Netzwerken: Benutze nicht die Map-Laufwerke, sondern gehe direkt über den Server-Namen auf die Pfade. Also z.B. \\server\freigabe\pfad\datei.ext und nicht n:\pfad\datei.ext. Warum? Der Server-Pfad ist immer gleich, aber verschiedene Benutzer könnten diesen auf unterschiedlichen Buchstaben verknüpft haben. Was bei Dir N: ist, kann beim Nachbarn V: sein. Und wenn die Datenbank dann die Verknüpfung auf N: sucht...

Jetzt hast Du im Front-End "Anwendung.mdb" die gleiche Funktionalität wie vorher, nur daß der eigentliche Datenbestand jetzt in einer anderen Datei ausgelagert ist. Das Front-End ändert sich jetzt i.a. auch nicht mehr, während der Datenbestand ja bei jeder Bearbeitung geändert wird.

Um die Abarbeitung zu beschleunigen und die Netzwerk-Last zu verringern, kopierst Du Dir jetzt die "Anwendung.mdb" auf Deine lokale Festplatte. Und das machst Du bei jedem Arbeitsplatz, der mit dieser Datenbank arbeiten soll. Zum Schluß setzt Du noch 'n Schreibschutz auf die "Anwendung.mdb" auf dem Server. Noch besser vielleicht: Verschieb sie, zusammen mit der "Datenbank.mdb", also Deiner Ur-Datenbank, in einen sicheren Ordner, wo die anderen User sie nicht sehen.

Wenn jetzt jemand eine Abfrage löscht, dann tut er das nur in seiner lokalen Kopie der Anwendung. Das läßt sich also jederzeit ganz fix über die "Master"-Kopie, also die "Anwendung.mdb", die (schreibgeschützt) auf dem Netzwerk liegt, reparieren. Selbst eine komplette Tabelle könnte er gefahrlos löschen, denn... er löscht nur die Verknüpfung, nicht aber die Tabelle selbst!

Soweit die eigentliche Aufteilung. Hat gar nicht weh getan, oder? ;-)

Der Rest ist jetzt nicht mehr ganz so allgemein zu erledigen. Das kommt dann schon recht speziell auf Deine Bedürfnisse an. Aber zumindest mal ganz pauschal:

In Back-End "Anwendung_Daten.mdb" würde ich über den Autostart dafür sorgen, daß das Datenbank-Fenster nicht angezeigt und die Datenbank gleich wieder geschlossen wird. Das verhindert zumindest Unbedarften den Zugriff direkt auf die Tabellen. Wer allerdings weiß, wie man eine Datenbank unter Umgehung des Autostarts öffnet, der... Hmtja...

Im Front-End wiederum würde ich ebenfalls das Datenbank-Fenster ausblenden und ein Formular als quasi "Hauptmenü" öffnen. Von diesem aus müßten die einzelnen Funktionen (Formulare) der Anwendung erreichbar sein. Ein Schließen der Formulare führt zur Rückkehr ins Hauptmenü. Schließen des Hauptmenüs sollte dann Access direkt beenden. (Der Unterschied ist ein einzelnes Wort im VBA-Source: "docmd.quit" statt "docmd.close"). Diese Navigation läßt sich i.a. sehr gut über den Button-Wizard erledigen.

Wenn es darum geht, daß einzelne Benutzer unterschiedliche Rechte innerhalb eines Formulars haben sollen, dann wird's aber noch eine Ecke haariger. Da könnte man dann per VBA einzelne Elemente ausblenden (oder zumindest deaktivieren), je nach Userrechten abhängig vom Benutzernamen. Also wenn z.B. der Techniker nicht den Verkaufspreis, andererseits der Preisbilder nicht die Abmessungen des Teils ändern darf.

Gruß, Michael

 

An dieser (und ggf. einigen weiteren Stellen) habe ich mich auf die Vorgehensweise bei dem hier benutzen Access 2000 bezogen. Bei Deinem Access 2007 ist das tlw. etwas anders, da liegen wohl viele Sachen im Arg... ähm... in Ribbons.

Gruß, Michael

 

Michael, Du bist ja unglaublich!!!!

Ich drucke mir das aus und legs ein paar Tage unters Kopfkissen, vllt, hilfts...

Ne, im Ernst, ich klau mir ein paar ruhige Minuten (oder Stunden) und schaffe mich nach Deiner Anleitung durch.

Ähm, wenn ich die Tabelle lösche, verschwinden doch auch die Formulare, die auf diesen Tabellen basieren, oder nicht?
Oder kann ich als Quelle die Tabelle aus einer anderen Datenbank angeben?

Erst mal tausend Dank für Deine super ausführliche Beschreibung, das probiere ich aus und schreie dann sicher noch mal nach Hilfe ;-)

 

Ich hoffe, daß sie das, wie zumindest in Access 2000, nicht tun. ;-) Wäre ja fatal... Allerdings würden sich die Formulare beim Öffnen dann zu recht über die fehlende Datenquelle beschweren.

Die Datenquelle stellst Du ja aber (unter gleichem Namen) durch die Verknüpfung in das Back-End wieder zur Verfügung. Das Formular merkt den Unterschied nicht mal.

Aber bevor Du in die Richtung weiter machst, noch ein ganz wichtiger Tip:

Arbeite nie nicht direkt mit den Tabellen in den Formularen! Versuche immer, Abfragen zu benutzen! Im einfachsten Fall besteht eine Abfrage einfach aus den gleichen Feldern wie die Tabelle.

Das Umstellen auf Abfragen bereitet im ersten Schritt zwar etwas zusätzliche Arbeit, erspart Dir aber in der Folge dafür umso mehr Aufwand und bietet auch noch bedeutend mehr Möglichkeiten, von der schnellereren Verarbeitung mal ganz abgesehen.

Als Ablauf mal ganz grob:
a) Tabelle erstellen:
- DatentraegerId - Autowert/Zufall
- DatentraegerName - Text
- Entwurf beenden, speichern unter "tbl_Datentraeger"
b) Abfrage erstellen:
- Tabelle "tbl_Datentraeger" auswählen
- in dem kleinen weißen Feld der Reihe nach Doppelklick auf jede Zeile (das Datenfeld erscheint in dem Abfrageentwurf darunter)
- Entwurf beenden, speichern unter "qry_Datentraeger"
c) Formular erstellen
- Datenquelle "qry_Datentraeger" wählen
- Datenfelder auf dem Formular platzieren
- Entwurf beenden, speichern unter "frm_Datentraeger"
Mit diesem Formular kannst Du jetzt "Datenträger" erfassen, also z.B. Partitionen der Festplatten, CD-ROMs, USB-Sticks oder was auch immer.

Mit diesem Grundgerüst kannst Du jetzt die Datenquelle jederzeit problemlos anpassen. Im einfachsten Fall kannst Du im Abfrageentwurf z.B. nach "DatentraegerName" aufsteigend sortieren oder so.

Wichtig wird der Spaß, wenn man einen Schritt weiter geht und Tabellen miteinander in Beziehung setzt:
d) Tabelle erstellen:
- DokumentId - Autowert/Zufall
- DatentraegerRef - Zahl/Long
- DokumentName - Text
- Entwurf beenden, speichern unter "tbl_Dokument"
e) analog zu oben Abfrage "qry_Dokument" erstellen (sortiert nach "DokumentName")
f) analog zu oben Formular "frm_Dokument" erstellen
Jetzt kannst Du (fast, noch nicht ganz) Dokumente erfassen, wie z.B. wichtige Word-Dokumente, Excel-Tabellen oder so.

Der Kasus Knacktus liegt ja darin, zu wissen, welches Dokument denn eigentlich wo abgespeichert wurde. Schließlich will man die ja auch irgendwann mal wiederfinden.

Und jetzt das hüpfende Komma:
g) Extras - Beziehungen - beide Tabellen einblenden - 1:n Beziehung zwischen DatentraegerId und DatentraegerRef herstellen

h) Dann eine neue Abfrage erstellen:
- zuerst "tbl_Datentraeger" auswählen
- dann noch "tbl_Dokument" auswählen
(Du wirst diese Verbindungslinie wiedersehen, wie sie auch schon bei den Beziehungen war.)
Jetzt zuerst im 1, danach im 2. Feld, auf jeder Zeile (Datenfeld) einen Doppelklick
- Entwurf beenden, speichern unter "qry_Datentraeger_Dokumente"

Platziere auf "frm_Dokumente" noch eine ComboBox mit Datenherkunft "SELECT DISTINCTROW DatentraegerId, DatentraegerName FROM tbl_Datentraeger ORDER BY DatentraegerName", 2 Spalten, Spaltenbreiten 0;5 gebundener Spalte 1 und gebundenem Feld "DatentraegerRef" et voila. Jetzt kannst Du ein Dokument erfassen und über die ComboBox auswählen, wo es gespeichert ist.

Jetzt hast Du ein Formular zur Erfassung der Datenträger und eins zur Erfassung der Dokumente. Wozu jetzt die kombinierte Abfrage? Na, z.B. für einen Bericht...

i) Bericht erstellen
- Datenquelle "qry_Datentraeger_Dokumente"
- Menü Ansicht - Sortieren und Gruppieren
Sortierung nach "DatentraegerName" - Gruppenkopf und -Fuß anzeigen
- Datenfelder zum Datenträger in den Gruppenkopf, zum Dokument in den Detailbereich einfügen
- Entwurf beenden, speichern unter "rpt_Datentraeger_Dokumente"

(Und, um die Sammlung komplett zu machen: Analog zu eben auch einen "rpt_Datentraeger" und einen "rpt_Dokumente" erstellen, die aber ohne Gruppierung, nur Sortierung.)

Die nächste Stufe wäre jetzt, ein weiteres
j) Formular erstellen:
- kopiere dazu am besten "frm_Datentraeger" in das neue Formular "frm_Datentraeger_Hf"
k) Formular erstellen:
- kopiere dazu am besten "frm_Dokumente" in das neue Formular "frm_Datentraeger_Uf"
- Setze den Typ "Endlos-Forumlar"

Jetzt bearbeite mal das Hf und platziere das Uf als Unterformular darin. Über z.B. den Wizard kannst Du dann DatentraegerId und DatentraegerRef miteinander verbinden.

Jetzt hast Du ein Formular, in dem Du im Kopf (Hf) den Datenträger siehst, während im Listenfeld (Uf) alle erfaßten Dokumente (auf ebendiesem Datenträger) aufgelistet sind.

Das ist jetzt ein kleiner Rundumschlag, bedeutend mehr, als ich eigentlich ursprünglich dazu sagen wollte. Aber naja, was soll's... ;-) Aber versuch, Dir die Schritte a) bis c) immer direkt hintereinander abzuverlangen, dann hast Du später immer eine saubere, leicht erweiterbare Plattform für Deine Daten. Also immer
a) Tabelle erstellen, um überhaupt erstmal einen Container für die Daten zu haben
b) Abfrage über die Tabelle erstellen, um die Daten in geordnete Bahnen zu lenken
c) Formular auf der Abfrage erstellen, um die Daten sauber erfassen und verändern zu können
(Ggf. auch direkt danach einen Bericht erstellen, um die erfaßten Daten wieder geordnet ausgeben zu können)

Nur vergiß nicht: Wenn Du später ein neues Datenfeld in Deine Tabellen einbaust, mußt Du es auch in alle Abfragen mit einbauen, die darauf zugreifen sollen. Sonst "sieht" Dein Formular das neue Datenfeld nicht. Andererseits: Die Abfrage muß ja auch nicht immer zwingend alle Datenfelder der Tabelle enthalten. Kleinere Auszüge mit nur den benötigten Feldern beschleunigen die Abarbeitung nur noch weiter.

Gruß, Michael

 

:shock:


Ich glaube, Dein letztes Post habe ich verstanden.. ich handhabe das nach den ersten missglückten Gehversuchen eigentlich immer so.


So, nun aber zu Deiner ersten ausführlichen Anleitung:

Ich habe mir die Original-DB geholt, hab sie zweimal kopiert (einfach mal zu Testzwecken), die eine habe ich "Admin-Adressen" genannt, die andere "User 1-Adressen".

In "Admin-Adressen" habe ich alles ausser die Tabellen gelöscht (es sind mehrere drin, nach Rubriken der Adressaten gegliedert, ist hoffentlich kein Problem?), in "User 1-Adressen" habe ich alle Tabellen gelöscht.

In der letzt genannten habe ich dann eine Verknüpfung erstellt auf die Tabellen der "Admin-Adressen", was auch angezeigt wird mit einem kleinen Pfeilchen..

Ja und jetzt fängt das Problem an: ich habe in "User 1-Adressen" mal versuchsweise in einer Tabelle etwas geändert, die DB gespeichert und die "Admin-Adressen" geöffnet.
In der entsprechenden Tabelle war die Änderung auch drin!!!
Das darf doch nicht sein, oder?
Da wäre ja der ganze Gag hin...

Hätte ich womöglich die DB "Admin-Adressen" zuerst schreibschützen müssen?


Bis dahin hats wirklich nicht sehr weh getan :mrgreen: den Rest muss ich mir mal später vornehmen, da ich mir noch nicht so ganz darüber im Klaren bin, ob ich das so ausführlich machen will/muss.

 

Ich werd noch wahnsinnig!!! :evil:


Nun hab ich auf "User 1-Adressen" versucht, die Formulare anzupassen...
Hab schön brav eine Abfrage gemacht (Bezug auf die verknüpfte Tabelle in dieser Datei), davon ein Formular und was passiert? Ich kann gar nichts mehr eingeben im Formular... Hilfe!
Warum ist das so? War die Arbeit umsonst mit der schönen Splittung?

 

hihi... ;-)

Also... Ich hab den Eindruck, da liegt noch ein kleines, nichstdestotrotz grundlegendes, Mißverständnis vor:

Die Aufteilung in Front- und Back-End hat in erster Linie die Aufgabe, das Bearbeiten der Datensätze von mehreren Benutzern und Rechnern zu ermöglichen. Ein zweiter Punkt ist, daß das Programm verändert werden kann, ohne daß in der Zeit der Datenbestand aus dem laufenden Betrieb gesperrt werden muß.

Aber: Jeder Benutzer, der auf den Daten arbeiten kann, hat auch pauschal erstmal alle Möglichkeiten, diese Daten zu bearbeiten. Dazu gehört das Verändern einzelner Datenfelder, genauso wie das Anfügen, aber auch das Löschen, kompletter Datensätze.

Deine ursprüngliche Frage ging in die Richtung, daß die Benutzer den Datenbank-Entwurf (Abfragen usw.) durch z.B. Löschen verändern können. Dagegen ist mit der Aufteilung (und kleinen weiteren Maßnahmen wie dem Ausblenden des Datenbank-Fenster) Abhilfe geschaffen.

Aber woher soll Access wissen, ob ein User den Datensatz nun löschen darf oder nicht? Das läßt sich nur mit individuell vergebenen User-Rechten realisieren. Diese Rechte müssen dann aber auch in den Formularen entsprechend ausgewertet werden. Das führt dann dazu, daß einzelne Steuerelemente (wie z.B. ein "Löschen"-Button) deaktiviert oder ausgeblendet werden müssen.

Das ist aber ein grundlegendes Problem, um daß man sich immer mit als erstes kümmern muß: Wer darf was ändern, wer darf was lesen? Mal so als Beispiel:

Jeder Benutzer kann im firmenweiten Adressbuch neben den Namen auch die Abteilung und die Telefonnummer der Mitarbeiter einsehen. Nur die IT-Abteilung hat aber die Rechte, diese Daten auch zu verändern. Die jeweiligen Vorgesetzten können für ihre Mitarbeiter dort auch sehen, ob sie anwesend sind. Bei allen anderen wird das Feld nicht angezeigt.

Oder: Ein Preisbilder kann alle Details eines Artikels einsehen. Während er auch den Verkaufspreis ändern kann, darf er aber an den technischen Details (Gewicht, Größe, ...) nichts ändern. Das wiederum dürfte aber ein Lager-Mitarbeiter, der allerdings natürlich wiederum nichts am Preis ändern darf. Ein kfm. Mitarbeiter sieht ebenfalls alle technischen Details, wird aber Einkaufs-Preis und Kalkulation nicht mal unbedingt einsehen dürfen.

Dieses ganze Geraffel muß per Listen ausgewertet werden, in denen detailliert steht, welcher Benutzer zu welcher Gruppe gehört und welche Gruppe in welchen Fällen wenigstens Lese- und ggf. sogar Änderungs-Rechte hat.
Kein Lese-Recht: Das Steuerelement wird ausgeblendet
Nur Lese-Recht: Das Steuerelement wird angezeigt, aber deaktiviert
Änderungs-Recht: Das Steuerelement wird angezeigt und ist aktiv

Und das betrifft nur einzelne Felder auf den Formularen. Inwiefern diese Rechte auch dazu führen, daß ganze Menüpunkte (Buttons, die ein Formular öffnen) beeinflußt werden, kommt ja noch dazu.

Und dann muß, um das ganze auch noch nutzen zu können, ein regelrechtes User-Login auf die Datenbank geschaffen werden. Denn wenn man Access normal öffnet, ist man (jeder!) mal eben so ganz pauschal als User "Admin" angemeldet.

Eine Möglichkeit ist das Rechte-System von Access selbst. Aber das fand ich schon seit Access 2.0 Zeiten unübersichtlich, unhandlich und unflexibel. Sehr viel flexibler ist es, über System-Funktionen den Benutzer-Namen von Windows zu benutzen und eine eigene Rechte-Verwaltung zu implementieren. Aber der Aufwand ist, wenn man nicht schon ein generisches Grundgerüst dafür hat, nicht ganz ohne...

Es läuft grob darauf hinaus, daß im "Öffnen"-Ereignis jedes Formulars der Benutzer ermittelt werden muß. Seine Rechte müssen dann ermittelt werden. Und davon abhängig werden dann Elemente auf dem Formular ein-/ausgeblendet bzw. (de-)aktiviert.

Ist die Frage, ob Du Dir den Aufwand antun willst oder lieber doch mit doppelten und dreifachen Sicherheits-Abfragen

Gruß, Michael

 

Das ist durchaus möglich! ;-)

Genau aus diesem Grund und weil das meine PC-Fähigkeiten bei weitem übersteigt, möchte ich das am liebsten über das Rechte-System von Access lösen.
Kannst Du mir noch nen kleinen Tip geben, wo ich die entsprechenden Funktionen finde?

Es wird wohl drauf raus laufen, dass ich die Datenbank doch "offen" lasse und verscheidene Formulare erstelle, die jeden Nutzer einzeln bestimmt sind. Da muss ich eben drauf vertrauen, dass jeder nur das anklickt, was für ihn bestimmt ist, auch wenn das manchen Leuten sicher schwer fallen wird.

Dass das so aufwändig wird, hätte ich mir zu Beginn nie träumen lassen... :roll:

 

Mach Dich auf umfangreichere und schwerere Lektüre gefaßt... ;-)

Ein guter Anlaufpunkt für allgemeine Fragen ist immer wieder die Access-FAQ von Karl Donaubauer, in Deinem Fall jetzt wären es speziell die Punkte 1.17 und 1.18.

Gruß, Michael

 

Tausend Dank für den Tip und Deine ausführliche Hilfe! ;-)

Kann Dich ja mal zu nem Kaffee einladen :mrgreen: