Office: (Office 2007) DoCmd.RunCommand acCmdLinkedTableManager

\@Thomas Möller : das ist exakt was ich brauche., In Kombination mit einer Pfadauswahl bin ich jetzt für eine RT Implementierung gerüstet.

@Alle: vielen Dank,

Lg Ralf

 

Hallo!

Interessehalber nachgefragt:

Gibt es eigentlich eine Möglichkeit, dass das Passwort nicht im TableDef gespeichert wird?
(.. wie wenn man per ODBC eine Tabelle verknüpft und das Passwort nicht speichern lässt.)

mfg
Josef

 

Hallo Josef,

mir ist da keine Möglichkeit bekannt.

Ich könnte mir aber folgendes vorstellen:
Du erstellst eine Anwendung komplett ohne eingebundene Tabellen. Wenn Du Zugriff auf Daten im BackEnd brauchst regelst Du das per Recordset mit der IN-Klausel.
Ich stell mir das erstaunte Gesicht vor wenn jemand alle Mechanismen, die verhindern sollen, dass er da FrontEnd in der Entwurfsansicht öffnet, überwunden hat um dann festzustellen, dass es keine Tabellen gibt. *mrcool

CU

 

Hallo!

Dass das Passwort gespeichert wird, hat mir irgendwie keine Ruhe gelassen. *wink.gif*
=> Mit folgendem Ablauf nähert man sich der ODBC-Variante ohne gespeichertem Passwort.

1. Passwort aus BE entfernen
2. Tabellen ohne Passwortangabe verknüpfen
3. Passwort im BE wieder einstellen

Code-Beispiel:
Code:

Ab nun ist ohne vorhergehende Angabe des Passworts kein Zugriff auf die Datensätze der verknüpften Tabellen möglich.
Der Zugriff wird möglich, sobald man eine Verbindung mit Passwort auf das BE öffnet und diese Verbindung offen lässt.

Prinzip:
Code:

Sobald diese Verbindung steht, können auch die verknüpften Tabellen verwendet werden.

mfg
Josef

 

Hallo Josef,

Dein Vorschlag gefällt mir gut. Du hast auf diesem Weg eine Lösung analog zu ODBC-Tabellen hergestellt. Cool!

Ich habe den Code jetzt nicht ausprobiert - ich habe aber folgende Frage: Geht das auch im Mehrbenutzerbetrieb?
Ich stelle mir vor, dass ein oder mehrere User eine Verbindung zum BackEnd unterhalten. Funktioniert dann der Code, der die Datenbank öffnet und das Passwort entfernt? Dazu muss das BackEnd ja exclusiv geöffnet werden.

CU

 

Ich gehe davon aus, dass das nicht funktionieren wird. Bei dieser Variante müsste man für die Vorbereitung des Frontend einen exklusiven Zugriff auf das BE haben. Je nach Entwicklungsumgebung könnte es vielleicht auch ausreichen, wenn man den Netzlaufwerksbuchstaben z. B. mit subst ersetzt und damit dem FE eine anderes BE unterschieben kann.

Irgend etwas müsste man sich imo einfallen lassen. Denn die Standardvariante von Access, das Passwort mitzuspeichern gefällt mir überhaupt nicht. Da kann man dann gleich das BE-Passwort weglassen und das Verzeichnis zum BE verstecken. ... das ist ungefähr gleich sicher. *biggrin.gif*


Um noch mal deinen Vorschlag mit den Abfragen aufzugreifen:
Wenn man diese Abfragen wie die Tabellen benennt, dann könnte das sogar die einfachste Variante werden.
Gespeicherte Abfrage tabXYZ:
Code:

oder
Code:

Damit wäre der Zugriff auch erst möglich, wenn man die Verbindung zum Backend per VBA-Code öffnet.


Das "Neuverknüpfen" wird allerdings etwas lustiger, da man dann den Ausdruck in der Abfrage anpassen muss.
Machbar ist das aber sicher. *Smilie

mfg
Josef

 

Hallo Josef,

ich hatte heute morgen unter der Dusche noch eine Idee. *Smilie , d.h. eigentlich habe ich nur Deine Idee etwas abgewandelt. *mrcool

1. Schritt:
Das Backend wird erstellt. Alle Tabellen werden angelegt. Das BackEnd hat keinen Passwortschutz.

2. Schritt:
Die Tabellen aus dem BackEnd werden in das FrontEnd verknüpft. Dabei wird kein Passwort gespeichert.

3. Schritt:
Für das BackEnd wird ein Passwort festgelegt.

4. Schritt:
In der Startroutine des FrontEnd (AutoExec, oder Form_Open-Ereignis des Startformulars) wird das BackEnd mit Passwort geöffnet.

Code:

5. Fertig
Ab jetzt kann auf die Daten im BackEnd zugegriffen werden. Der Effekt ist ähnlich wie bei einer ODBC-Tabelle. Es wird kein Passwort gespeichert. Der Zugriff auf die Tabellen ist erst möglich, wenn eine Verbindung zum BackEnd geöffnet wird. Dabei wird das Passwort per Code übergeben. Wenn die Anwendung als *.mde ausgeliefert wird ist das Passwort also für den Enduser nicht ersichtlich.

Eine kleine Beispieldatenbank zum ausprobieren habe ich angehängt.

Viel Spass beim Ausprobieren!

 

Hallo Thomas!

Die von dir vorgeschlagen Abfragen-Variante fand ich allerdings auch interessant, daher erlaubte ich mir, deine Beispiel-Anwendung auf diese Variante umzubauen. *Smilie

Der Reiz an dieser Variante: das BE darf immer ein Passwort haben. Somit ist ein "Verknüpfen" zu jeder Zeit möglich - was dann wiederum den Wechsel zw. Test-BE und Produktiv-BE erleichtert.

mfg
Josef

 

sehr interessant, bei einer in die RT expotierte BE kann man zwar das PW nicht herauslesen, aber trotzdem eine äußerst interessante Diskussion.

 

Bist du dir sicher? *wink.gif*
Sobald das Passwort in der verknüpften Tabelle gespeichert ist, kann man es auslesen.

 

ist das so einfach? Der Otto Normalanwender macht das sicherlich nicht, und wenn er es kaputt macht, da erlischt das Serfvicesangebot , bzw. er muß für den Schaden aufkommen, wenn er sich seine Daten kaputt macht.

 

Ja. *Smilie

Der Otto-Normalverbraucher wird auch die Daten nicht über die Tabellen ändern - warum vergibst du dann ein Passwort? *wink.gif*

Der hat aber sicher nie die Daten über die Tabellen verändert sondern immer nur die Formulare genutzt. Das Problem muss also in den Formularen liegen. ... so ähnlich könnte ich mir dann die Antwort vorstellen, falls du danach fragst, ob die Daten direkt über die Tabelle verändert wurden, weil die DB nicht mehr funktioniert, weil aus einer Tabelle plötzlich alle DS verschwunden sind.

Natürlich ist es es für eine irrtümliche Änderung ausreichen, wenn du beim Starten der Anwendung dafür sorgst, dann das Datenbankfenster ausgeblendet ist.
Bezüglich "in eine RT exportierten": Ich nehme an, du meinst damit die Erstellung einer mde. Wenn du auch bei einer mdb nicht dafür sorgst, dass das Datenbankfenster ausgeblendet wird, kann man mit der Access-Vollversion ohne Probleme auf die Tabellen zugreifen.

Was übrigens auch möglich ist:
Sobald ein Frontend existiert, in dem das Passwort in der verknüpften Tabelle gespeichert ist, musst du nur mit der Access-Vollversion eine neue mdb erstellen und kannst die Tabelle aus dem FE in deine neue mdb importieren. Das Passwort wird dann ebenso importiert.

 

Ich wunder mich etwas über den Tiefgang dieser Disskussion, da ein Access-Passwort imho i.d.R. keine drei Mausklicks überlebt *frown.gif* oder wurde in dieser Hinsicht in A2007/A2010 etwas verbessert?

 

Hallo Josef,

ich spreche von eine RT in der FE nicht mit PW geschützt ist , die BE ist mit Pw geschützt, das der User aber nicht eingibt , sondern die Anwahl erfolgt im Hintergrund der FE + BE, in einer RT FE kann er nicht den dahinterliegenden und ablaufenden Code einsehen. NAtürlich kann er zusätzlich die FE nach belieben mit einem Pw versehen, dies ermöglicht eine seltgeschriebene Routine. Wie lange dauert es bei Access DB das Pw zu cracken?

"weil aus einer Tabelle plötzlich alle DS verschwunden sind." - immer schön sichern.

 

Das könnte der Reiz an der Sache generell gewesen sein. *Smilie

Man muss dafür allerdings ein Hilfswerkzeug verwenden und kann nicht die Access eingebauten Methoden einsetzen. Sobald du im Frontend das Passwort speicherst, reicht Access aus, um das Passwort auszulesen.

Das ist vor allem bei verknüpften ODBC-Tabellen wichtig, da damit eine riesige Lücke im Sicherheitssystem einer aktiven DBMS entstehen kann, wenn man das Passwort in der verknüpften Tabelle im Frontend speichert.
Aus diesem Grund fand ich es einmal ganz interessant, wie man das gleiche Konzept auch mit einem Access-Backend umsetzen könnte, dass per Datenbankpasswort gesichert ist.

Ich bilde mir ein, dass ich mal irgendwo gelesen haben, dass mit Ac07 der Passwortschutz besser geworden ist, geprüft habe ich das bisher allerdings noch nie.
Falls du Lust hast, das zu prüfen: eine mit Ac2010 gesicherte accdb *Smilie

Wenn das Frontend nicht per Passwort geschützt ist und du im Frontend verknüpfte Tabellen zum Passwortgeschützten Backend gespeichert hast, dann probiere bitte einmal das aus einer beliebigen VBA-Umgebung (am einfachsten mit Access) aus:

DBEngine.OpenDatabase("D:\er\Pfad\zum\Frontend.mdb").TableDefs("DieVerknüpfteTabelle").Connect

BTW: So etwas betrachte ich noch nicht als "Knackanleitung" sondern als Hinweis, dass man als Anwendungsersteller so etwas nicht als sicher betrachten darf.
Es spielt nämlich keine Rolle mehr, wie sicher das Passwort im BE ist, wenn man es jederzeit ohne "Spezialsoftware" lesbar aus dem Frontend abrufbar ist.

Mit dem richtigen "Werkzeug" .. geschätzt: 30 Sekunden (wenn man sich Zeit lässt)? *Smilie

mfg
Josef