Hallo,
würde mir jemand erklären was oder ich genau einen Fehler mache? Ich gehe wie folgt für den DB-Split vor:
Starte DB --> Datenbanktools > Access-Datenbank --> Nach benamsung (QuartettDB_be.accdb) und Angabe des Speicherortes > Datenbank aufteilen. Das Frontendfile liegt im gleichen Verzeichnis wie das BE. Es lässt sich nach dem Split öffnen etc. Danach den Backendfile im Exklusive Modus öffnen --> Datei --> Mit Kennwort verschlüsseln.
Jetzt will ich den FE File öffnen und schwupps, da ist nichts mehr, sprich der file öffnet sich nicht mehr. Ich hätte erwartet, dass er zumindest öffnet und ich die Tabellen neu verlinken muss. Die Tabellen im FE muss ich doch nicht schon vor dem vergeben des PW im BE löschen, oder? Was genau läuft schief in meiner Vorgehensweise?
Gruß Andreas
PS: Ich kann mal im Web einen kleines Video ablegen, damit man die Steps sieht die ich mache.
Meines Wissens nach, kannst aus dem Frontend alle Tabellen löschen, dann müsste im Reiter wo man Daten importieren kann, dieses Symbol mit dem Accesslogo, jetzt im Assistent "Verknüpfung" auswählen und dann das Backend anwählen. Im Anschluss musste die Tabellen auswählen und das Passwort eintragen.
Fertig
Hi,
jo, das habe ich ja auch erwartet. Aber dahin komme ich ja nicht mehr. Der FE öffnet sich ja nicht mehr. Andreas ist etwas confused.
Gruß Andreas
Hallo,
starte das FE mit gedrückter (und festgehaltener) Shift-Taste.
Hi Steffen,
auch wenn ich das mache kommt nur das allgemeine Menü, wie wenn man Access startet und dann eine bestehende DB öffnen oder eine neue, leere DB öffnen will. Egal wie oft ich mir Videos anschaue wie es z.B. in YouTube gezeigt wird, bei mir geht es so nicht. Ich habe übrigens a365.
Gruß Andreas
Andreas,
das hatte ich versucht, Dir neulich zu erklären. :)
Die Tabellen sind ungeschützt verknüpft worden. Verschlüsselst Du jetzt im Nachhinein das Backend, so muss, ohne dass das Password im Klartext in den Systemtabellen erscheint soll, eine permanente Verbindung vor jeglichem Zugriff auf eine der verknüpften Tabellen angelegt werden. Diese Verbindung erlaubt es dann, alle verknüpften Tabellen zu nutzen.
Eine mögliche Vorgehensweise wäre, ein AutoExec-Makro anzulegen und in einem allgemeinen Modul eine Startup-Funktion einzurichten, die vom AutoExec-Makro aufgerufen wird. Entweder brauchst Du dann innerhalb der Funktion eine statische Variable vom Typ Object bzw. DAO.Database oder eine sinnvollerweise Private Variable im Modulkopf vom gleichen DatentTyp. In der Funktion selbst wird dann nur die Datenbank geöffnet, welche dann als Cache fungiert und ohne weitere Passwortangaben Zugriff auf die verknüpften Tabellen erlaubt. Set DeineVariable = OpenDatabase("PfadZumPasswortgeschuetztenBackend", False, False, _
";pwd=DeinPasswortHierEintragen")Es gilt nun immer alle Laufzeitfehler abzufangen, weil ansonsten die Variable ihren Wert verliert und der Cache nicht mehr wirkt.
Selbst wenn Du jetzt das VBA-Projekt im Frontend mit einem Passwort schützt, kann jedermann mit einem Hex-Editor die Stelle herausfinden, an der das Passwort zugewiesen wird. Ich vermute, dass das selbst in einem ACCDE-Frontend noch möglich ist - habe es aber selbst nicht untersucht.
Hi,
auf die Gefahr hin mich jetzt zu blamieren, aber wie gelingt das bei denen?
https://www.youtube.com/watch?v=OXrwumT3JUo (https://www.youtube.com/watch?v=OXrwumT3JUo)
https://www.youtube.com/watch?v=4tnDEN3NjwE (https://www.youtube.com/watch?v=4tnDEN3NjwE)
Splitting https://www.youtube.com/watch?v=50NSwFfCHF8 (https://www.youtube.com/watch?v=50NSwFfCHF8)
Secure the BE https://www.youtube.com/watch?v=zoOlakWXG3c&t=236s (https://www.youtube.com/watch?v=zoOlakWXG3c&t=236s)
Da habe ich nicht das Gefühl, dass hier zuvor irgendwelche schützenden Massnahmen getroffen wurden, sondern diese Beispiele eigentlich genau dem entsprechen, was bei mir vorliegt (vorletztes Video ist etwas anders, da es mit spezieller Freigabe und Userrechten zu tun hat). Aber das splitten an sich mit Password für das Backend ist eher "standard". Ich versteh es nicht wirklich, sorry.
Gruß und Danke
Andreas
Hallo,
mich würde zunächst mal interessieren was du genau vor hast und was du dir vom Passwort versprichst, dh. gegen welches Szenario/Personenkreis du die DB schützen willst.
Prinzipiell würde ich die BE/FE Aufteilung per Hand machen:
1) DB auf Dateiebene kopieren
2) eine DB als FE die andere als BE umbenennen.
3) im FE alle Tabellen löschen
4) im BE alles außer die Tabellen löschen
5) beide komprimieren
6) FE öffnen und die Tabellen aus dem BE per Externe Daten ... verknüpfen
Wenn alles funktioniert kann man über die "Passwortgeschichte" nachdenken
Hi,
die DB wird Spielkartensammlern zur Verfügung gestellt. Ich will lediglich den Code soweit schützen wie es möglich ist. Ich hatte die DB bisher nicht getrennt. Der bisherige Schutz funktioniert meines Erachtens gut. Bypassing (Shiftkey) habe ich alles abgestellt bekommen. Aber dann hat mir Lachtaube gezeigt, wie einfach es ist mit Excel via Import das ganze auszuhebeln. Das Szenario ist mir durch die Lappen gegangen, die ganze Zeit :(. Ergo besteht meines Erachtens nur noch die Möglichkeit des DB-Split und das BE mit einem PW zu verschlüsseln. Dies erweist sich aber als gar nicht so einfach. Die Aussage von Lachtaube .... "die Tabellen sind ungeschützt verknüpft worden" lässt mich verzweifeln. Wenn ich mir die aufgeführten Videos anschaue, dann machen die das doch genauso. Die splitten, encrypten das BE File, öffnen das FE und verknüpfen die Tabellen neu. Da müssen sie noch einmal das Passwort eingeben und los gehts. Hmmm.....
Gruß Andreas
Andreas,
ich habe mir nur das erste Video angesehen. Der Nachteil dieser Methode ist, dass nun im Frontend in der Systemtabelle MSyObjecsts für alle verknüpften Tabellen das Passwort im Klartext erscheint und selbstverständlich auch über z. Bsp. Excel eingesehen werden kann. Dann kann man auch gleich auf den Pawwortschutz verzichten. Siehe Bildanhang.
Hallo,
ich würde meine Ressourcen eher in die Qualität statt in den Schutz stecken.
BE/FE ist für deine Einzelplatzanwendung eigentlich nicht notwendig und macht die ganze Weitergabe/Installation nur kompliziert.
Also wenn deine DB nicht zum Brötchen verdienen gedacht ist, mach 'ne vernünftige Anwendung, liefere eine accde aus und lass die Schutz-"Krämpfe" die ohnehin nicht 100% funktionieren.
Btw:
Benutzername und Passwort (vom Loginformular) in der Tabelle verschlüsseln dann hilft Auslesen per Excel auch nicht.
Hi,
naja, es hat ja nicht nur Nachteile. Vorteil davon ist, dass du weiter "entwickeln" kannst und es tangiert den User nicht wirklich. Wenn man einen accde macht, kann der User die ganz normal nutzen, also Datensätze erstellen usw. aber an der Struktur nichts ändern?
Gruß Andreas
Hallo,
Zitatnaja, es hat ja nicht nur Nachteile
Zweifelsfrei, ist nur die Frage ob du das ganze beherrscht.
Je nach Situation würde ich hier eher auf einen "Updater" setzen das ist beim Kunden einfacher und universeller (Tabellenänderungen), aber evtl. schwieriger zu programmieren.
Hi,
Zitat von: Lachtaube am Januar 20, 2018, 21:19:08
Frontend in der Systemtabelle MSyObjecsts für alle verknüpften Tabellen das Passwort im Klartext erscheint und selbstverständlich auch über z. Bsp. Excel eingesehen werden kann.
Hmmm, du sprichts von ... bei der Methode. Ist es aber nicht so, dass wenn die DB encrypted ist, dass wenn du mit Excel importieren möchtest, dann erst die PW gefragt wird? Da komme ich nicht mehr einfach so ran. Ich habe hier eine Beispiel-DB (be und fe), da komme ich nicht ran an die Tabellen mit Excel, da muss ich das Passwort zum decrypten haben.
Also ich würde das gerne mal hinbekommen wie in den Videos, damit ich das beurteilen kann. Warum das bei mir nicht geht wie bei den Vorführungen ist mir immer noch ein Rätsel.
Gruß Andreas
Eine ACCDE verhindert nur das Ändern, Hinzufügen und Löschen von Formularen, Berichten und VBA-Modulen und ihre Einsicht im Entwurfsmodus - Tabellen (egal ob verknüpft, unverknüpft, versteckt oder Systemtabellen), Abfragen und Makros unterliegen keinem besonderen Schutz.
Ist das Frontend auch passwortgeschützt, ist ein externer Zugriff ohne Passwort-Kenntnis natürlich nicht möglich.
Teste in Excel den Zugriff mittels AbfrageSELECT * FROM MSysObjectsauf das Frontend und das Blendwerk gerät in den Fokus.
Hi,
Zitat von: steffen0815 am Januar 20, 2018, 21:44:51
Zweifelsfrei, ist nur die Frage ob du das ganze beherrscht.
Je nach Situation würde ich hier eher auf einen "Updater" setzen das ist beim Kunden einfacher und universeller (Tabellenänderungen), aber evtl. schwieriger zu programmieren.
Okay, da ist schon was dran. Ich schau mir mal das an, welchen Benefit ich durch die accde hätte.
Gruß Andreas
Hi,
Zitat von: Lachtaube am Januar 20, 2018, 21:48:37
Eine ACCDE verhindert nur das Ändern, Hinzufügen und Löschen von Formularen, Berichten und VBA-Modulen und ihre Einsicht im Entwurfsmodus - Tabellen (egal ob verknüpft, unverknüpft, versteckt oder Systemtabellen), Abfragen und Makros unterliegen keinem besonderen Schutz.
Danke für die Zusammenfassung. Wie gesagt, mich würde das trennen mal interessieren, wenn ich es dann mal hinbekommen würde :(.
Gruß Andreas