LibreOffice-Forum

Hallo zusammen,

ich habe mit Base eine kleine einfache Datenbank für einen Kollegen "gebastelt".
Nun möchte ich gern die von mir erstellten Formulare und Tabellen so schützen, dass der Kollege
zwar damit arbeiten, aber die Formulare selber weder löschen noch verändern kann.

Ich habe schon ein wenig gegoogelt doch finde ich keine für mich verständliche
Aussage darüber. Ich suche im Grunde vereinfacht gesagt die Möglichkeit das ich
bspw. die Formulare und Tabellen vor einer Bearbeitung oder vor Löschen mit einem Passwort
schützen kann.

Gibt es da eine Möglichkeit? Ich danke schon mal für eure Hilfe!

Jordi

Hallo Jordi,

einen Schutz der Tabellen und Formulare innerhalb einer Base-Datei (mit der internen Datenbank) kannst Du nicht gewährleisten. Eine Base-Datei ist keine Serverdatenbank mit Formularen, die ebenfalls unerreichbar sind. Jede(r), der/die die Datenbankdatei in die Hände bekommt, kann alles in dieser Datei löschen und nach Herzenslust ändern. Jeglicher Schutz ist nur als Schutz vor versehentlichen Änderungen gedacht - z.B. der Schutz der Größe und Position der Elemente in einem Formular.

Gruß

Robert

Das hätte mich auch interressiert.

Ich muss selbst höllisch aufpasse, dass ich nicht Daten versehentlich lösche oder ändere. Ich habe da eher wenig Vertrauen anderen gegenübe. Nicht dass sie Daten mutwillig verändern sondern eher aus Unachtsamkeit. So nach dem Motto "upps, du bernd kannst du nicht mal schnell schauen ich finde den eintrag xy nicht mehr..... Mit all den katastrophalen Folgen weil keine Ahnung was alles gelöscht wurde. Ich würde aber gerne haben, dass trotzdem Formulare und Berichte genutzt werden können.

@Robert:
Ist die Bibliotheksverwaltung aus dem Handbuch ein fiktives Projekt oder ist die im Einsatz. Wie ist das dort gelöst?

gruss bernd

Hallo Bernd,

die Bibliotheksverwaltung aus dem Handbuch ist tatsächlich fiktiv. Das Im Einsatz befindliche Projekt hat in etwa die gleiche Struktur von den Tabellen her, ist aber mit MySQL, PHP und Apache gelöst.
Den Schutz bekommt niemand mit der internen Datenbank rein. Die Tabellen stehen frei jedem Nutzer zur Verfügung. Es geht also auch um Sicherheitskopien und die Vorgabe, nicht alle Löschwege zu einfach zu machen. Wäre schon peinlich, wenn die Datenbank so konstruiert ist, dass z.B. jemand auf den Gedanken kommt, das Feld "Buch" aus den Medientypen zu entfernen und die Datenbankkonstruktion gibt dann vor, dass alle Medien, die sich auf dieses Feld beziehen, gelöscht werden sollen ... - plötzlich gibt es nahezu keine Medien mehr zu verleihen.

Diese Einstellungen kann aber eben auch der Nutzer der internen Datenbank machen und damit den GAU erzeugen. Das zu umgehen funktioniert nur mit einer externen Datenbank, wie bei mir z.B. der Konstruktion mit MySQL.

Aber auch interne Datenbanken laufen in der Regel recht reibungslos, wenn die Nutzer bewusst mit der Sache umgehen. So habe ich auf Basis der internen Datenbank eine Vereinsdatenbank zusammengestellt, die die Adressverwaltung, die Verwaltung des Vereinsgeländes usw. beinhaltet. Die ist zum Jahresbeginn in andere Hände gegangen und wird ohne Probleme weiter genutzt. Sicherheitskopien sind natürlich ratsam, obwohl ich in den Jahren der Nutzung dieser DB noch nie auf eine Sicherheitskopie zurückgreifen musste. Die Kopien habe ich nur dann benötigt, wenn ich eine neue Funktion ausprobierte und dann nicht umständlich auf einen vorherigen Stand wieder zurück wollte.

Sollen auch Formulare geschützt werden, so ist dies nur möglich, wenn die Formulare als externe Formulare existieren. Dies ist ja machbar im Writer, ebenso der Schreibschutz eines Dokumentes. Aber Vorsicht: Bitte das Passwort merken, denn in den Mailinglisten kommen dann die Anfragen, wenn jemand das Passwort vergessen hat - und der Nutzer ärgert sich, dass das Passwort seinen Zweck erfüllt.

Gruß

Robert

Cool, besten Dank. Klar in den Tabellen hat niemand etwas zu suchen, dass kann man deutlich komunizieren.

Ich glaube dann muss ich einfach die Formulare etwas sicherer gestalten. Eben genau so, dass versehentliches Löschen kaum möglich ist.


einen schönen abend bernd

Guten Tag,

ich hole den alten Thread mal wieder vor. Meine Datenbank hat x Abfragen, einige Formulare und einige Berichte. Einige sind nur zu Testzwecken einige nutzte ich produktiv. Ich würde nun gern wirklich auch andere Leute die Datenbank bearbeiten lassen. Zum Schutz und der Übersichtlichkeit wegen hätte ich folgende Idee.

Eine Workdatenbank nur mit den nötigsten Formularen und Abfragen zum Bearbeiten für andere und eine Entwicklerdatenbank für mich mit all denen Testabfragen und Testformularen. Ich kann einfach kommunizieren, dass in den Tabellen niemand etwas zu suchen hat, das funktioniert. Nun stellt sich einzig noch die Frage wie ich die Datenbestände der Workdatenbank mit meiner Entwicklerversion abgleichen kann?

Ist folgendes vorstellbar?
Alle Tabelleninhalte aus der Workdatenbank per sql exportieren. In der Entwicklerdatenbank per SQL erst alle Tabelleninhalte löschen und dann die exportierten Tabelleninhalte per SQL einlesen.

Gruss Bernd

Hallo Bernd,

prinzipiell kannst Du eine Tabelle exportieren mit Dadurch wird in dem Heimatverzeichnis der *.odb-Datei eine *.csv-Datei der Tabelle. So etwas muss dann natürlich für alle Tabellen gemacht werden. Das könnte gegebenenfalls mit einem Makro so erfolgen, dass die Tabellennamen ausgelesen und die Abfrage automatisch gestellt würde. Eine einzelne Datei erhältst Du daraus nicht - wie z.B. bei einem MySQLdump.
Das Löschen des Inhaltes aus Deiner Testdatenbank funktioniert dann einwandfrei, wenn Du durch entsprechende Verknüpfung mit "On delete cascade" das kaskadierende Löschen einsetzt. Dann kann das Makro wieder einfach mit einer schleife durch alle Tabellen löschend durchgehen.
Das Einfügen der Backupdaten ist etwas schwieriger, da jetzt zuerst die Tabellen eingefügt werden müssen, die für andere die Fremdschlüssel her geben. Da muss also detailliert vorgegeben sein, welche *.csv-Tabelle in welche interne Tabelle eingelesen wird. Das ging bei MySQL einfacher, weil die Standardtabelle dort nicht für Relationen erstellt wurde. Da ist es dann egal, welche Tabelle zuerst gefüllt wird.
Automatisieren kannst Du hier natürlich wieder über ein Makro, so dass, grob gesagt, ein Button in der abgebenden Datenbank und ein Button in der aufnehmenden Datenbank ausreichend wären.

Gruß

Robert

Mhh, Danke Robert für Deine ausführliche Antwort. Bisher habe ich mich immer um Macros herumgemogelt und will dies auch wieder hier versuchen. Ich suche eine möglichst einfache Möglichkeit ohne Macros. Deine Infos haben mich ein wenig überlegen lassen. Grundsätzlich habe ich zwei Möglichkeiten des Vorgehens. Dein letztes Posting betrachtet nur Variante 1. Was hältst Du von Variante 2?

Gruss Bernd


Variante 1:
Entwicklerversion kopieren und alle überflüssigen Formulare, Abfragen und Berichte löschen. Dies ist die workversion zum Daten eingeben. Die in die workversion eingegebenen Daten werden in die Entwicklerversion übertragen. Wenn ich neue Formulare oder Berichte oder Tabellen in die Workversion haben will kopiere ich wieder die Entwicklerversion und lösche alle überflüssigen Formulare, Abfragen und Berichte. usw. usw. usw.

Variante 1:
Entwicklerversion kopieren und alle überflüssigen Formulare, Abfragen und Berichte löschen. Dies ist die workversion zum Daten eingeben. Die in die workversion eingegebenen Daten werden NICHT (oder nur bei Bedarf teilweise zum testen) in die Entwicklerversion übertragen. Wenn ein neues Formular oder neue Tabellen in die Workversion übernommen werden sollen, müssen diese dann von der entwicklerversion in die workversion übertragen werden. Dies funktioniert für Abfragen und Formulare ganz gut (copy and paste) aber wie ist es mit neuen Tabellen und vor allem deren Beziehungen. Bei dieser Variante spielt mir der Datenbestand in der Entwicklerversion eine sehr untergeordnete Rolle, da ich zum Testen genügend Daten habe.

Hallo Bernd,

irgendwie fällt es mir schwer, den Unterschied zwischen den Versionen zu erkennen.
Prinzipiell kannst Du jede einzelne Abfrage, jeden einzelnen Bericht und jedes einzelne Formular kopieren - davon sind die Daten und die dort definierten Beziehungen ja nicht berührt.
Änderst Du allerdings Tabellen, so musst Du sehr darauf achten, dass die Formulare, Berichte und Abfragen, die darauf zugegriffen haben, entsprechend ersetzt werden. Das wird Dein Problem sein, wenn Du eine andere Datenstruktur aufbaust, als sie bisher in den Tabellen der Arbeitsversion existiert. Zusätzliche Felder sind weniger das Problem, zusätzliche Tabellen mit Beziehungen zu anderen Tabellen aber sehr schwierig zu lösen.
Du kannst also, um den aktuellen Datenstand mit den neuesten Formularen zu versehen, ruhig Abfragen, Formulare und Berichte aus der Entwicklerversion kopieren. Du musst Dir nur klar sein, an welcher Stelle Du Änderungen an der Tabellenkonstruktion vorgenommen hast, damit alles schlüssig bleibt.
Falls Du in Formularen Bilder als Hintergrund eingebunden hast solltest Du auf folgendes Phänomen hingewiesen sein: Mit dem Löschen eines Formulars verschwindet zwar das Formular aus der *.odb-Datei, nicht aber das verknüpfte Bild. Das bleibt sozusagen als verwaister Restmüll in dem Container liegen. Und falls Du dann häufiger so ein Formular löscht und neu einfügst kann das natürlich die *.odb-Datei entsprechend aufblähen.

Gruß

Robert

Hallo Robert,
besten Dank für Deine hilfreichen Tipps. Betreffs

RobertG hat geschrieben:... irgendwie fällt es mir schwer, den Unterschied zwischen den Versionen zu erkennen. ...

Variante 1. --> Aus der Entwicklerversion wird immer wieder eine Workversion.
Variante 2. --> Die Workversion bleibt die Workversion und die Entwicklerversion bleibt die Entwicklerversion.

Aber ich glaube das ergibt sich von selbst, ich tendiere zu zweiten. Ich habe mir jetzt genügend Ideen und Möglichkeiten wie es funktionieren kann. Das wollte ich erreichen, nicht das ich da in eine Richtung fahre mich festbeisse und gar nicht weiss, das bestimmte Dinge mega einfach sind. Ich wusst gar z.BSP nicht, dass man Formular einfach per copy and paste in eine andere Datenbank übertragen kann.

Ich werde dann in einiger Zeit mal eine Rückmeldung geben.

Gruss Bernd