Office: (Office 2016) Verbindung zu SQL-Server mittels VBA

Hallo Allerseits,

Anmerkung: Ich nutze Access 365.

Ich hab mittlerweile viele Stunden im Forum gesucht und gegoogelt, komme aber nicht weiter. Deshalb hier ein neues Thema.

Ich habe eine Access-Datenbank, mit der Daten von einem SQL-Server abgerufen werden sollen. Derzeit ist es so, dass ich Verbindungen zur Datenbank erstellt habe (Externe Daten > Neue Datenquelle > Aus Datenbank > Aus SQL-Server). Dann habe ich eine Verknüpfung erstellt. Die Verbindung zum Server wurde in einer DSN-Datei auf meinem Rechner gespeichert.

Problem: Wenn die Access-Datenbank neu geöffnet wird, muss das Passwort für die Verbindung neu eingegeben werden. Deshalb möchte ich die Verbindung jedesmal per VBA herstellen. Mir ist klar, dass das PW dann im Klartext im Code erscheint. Ist für mich ok, da ich die Access-Datenbank mit nem Passwort schützen kann.

Jetzt versuche ich, die Verbindung zum SQL-Server herzustellen, das klappt aber nicht. Es gibt da so viele Möglichkeiten und ich habe keine Ahnung, was ich da genau nutzen soll. Wie gesagt, die Tabellenverknüpfungen existieren bereits und sollen auch so bleiben. Der VBA-Code soll lediglich bewirken, dass man nicht jedesmal ein PW eingeben muss.

ODBC, DAO, ADODB ... kann ich nicht wirklich auseinanderhalten, ich bin eher ein "interessierter Laie".

Könnt Ihr mir weiterhelfen?

:)

 

Ist das nicht ein Widerspruch?

Gibt es nicht mehr die Option das Passwort bei der Tabellenverknüpfung zu speichern?

Du kannst per VBA eine Pass-Through-Abfrage auf dieselbe Datenquelle ausführen und dabei das irgendwo gespeicherte Passwort angeben. Danach solltest du für diese Datenquelle nicht mehr nach dem Passwort gefragt werden.

 

Ich habe da eine schöne Routine vor ein paar Jahren programmiert,
Wenn du magst dann sende ich dir eine ac2010 dB. Ich habe
Das sehr komplex ausgeführt, das heißt du brauchst nur mehr deine Instanz, Benutzer und Passwort sowie die einzubindenden Tabellen bequem in Stammdatenformular hinterlegen, der Rest funzt von alleine.

Sende mir per PN deine Mail bei interesse, ich gebe es dir gerne.

Lg Jimmy

 

Servus Jimmy_Star,
und wieso gibt es Dein Beispiel inkl. Code nicht hier im Forum, sondern nur für
Forumsmitglieder, welche sich per PN bei Dir melden?

 

Die Daten kommen aus verschiedenen Datenbanken, jeweils mit Nutzer und Passwort. Und die Berechtigungen kann ich nicht vergeben.

Die Access-Datenbank wird einfach mit nem Passwort geschützt. Es geht auch nicht darum, dass super sicher zu machen, es soll halt nur nicht jeder Mitarbeiter problemlos öffnen können.

 

Genau das funktioniert nicht. Ich kann den Haken zwar setzen, aber er fragt jedesmal wieder nach, wenn ich die Access-Datei öffne.

 

Hallo!

Wenn sich die Zugangsdaten je Anwender nicht unterscheiden, kannst du den Vorschlag von sonic8 umsetzen.
Du öffnest für jeden Zugang eine Pass-Through-Abfrage mit den Zugangsdaten. Dann werden auch die Tabellen für den Zugriff freigegeben.
Mir gefällt diese Variante besser, als die Zugangsdaten direkt mit den verknüpften Tabellen zu speichern, da damit die Zugangsdaten nicht von außen ausgelesen werden können.

Zum Testen:
Code:

Nach Ausführung dieses Codes sollte auf die verknüpften Tabellen zugegriffen werden können.

mfg
Josef

 

Das ist ein Irrtum. Wenn die Zugangsdaten in der FE-Datei stehen, egal wo, dann können sie auch ausgelesen werden. Es ist nur nicht ganz so einfach, wie in den verknüpften Tabellen.
Einziges Gegenmittel ist die FE-Datei mit Kennwort zu verschlüsseln. - Das hat aber Phulc ja sowieso vor.

 

Hallo!

Dann formuliere ich es so: .. damit die Zugangsdaten nicht so einfach ausgelesen werden können. *wink.gif*

Wenn die Kennwörter nur im Code stehen und die Anwendung eine accde ist, ist das Auslesen dieser Kennwörter bzw. der Datenzugriff schwieriger als der Zugriff über die verknüpften Tabelle mit gespeicherten Zugangsdaten.
Man kann zumindest nicht einfach über einen Import der verknüpften Tabelle in eine leere Access-Datei einen Zugriff auf die Daten kopieren.

Wenn die Client-Datei verschlüsselt wird, ist das natürlich noch besser.

Wenn man z. B. dem User die allgemeinen Zugangsdaten zu den DB-Servern (warum auch immer, man nur einen User im DBMS nutzt bzw. nutzen kann) nicht geben will - dieser aber das Kennwort der Client-Datei kennt, hat er mit einem einfachen Import der Tabellen vom Frontend den Zugriff auf die Daten der verknüpften Tabellen (die man vielleicht mittels Client-Umgebung schüzten möchte), falls das Kennwort in der verknüpften Tabelle gespeichert ist - und dafür muss er kein Access/Programmier-Profi sein.
Ist das Kennwort nicht in den verknüpften Tabellen gespeichert, kann man diese Tabelle gerne kopieren. Daher gefällt mir die Variante mit dem Freischalten per Code besser als die verknüpfte Tabelle mit den gespeicherten Zugangsdaten.

mfg
Josef

 

... ist zu groß und zu komplex, geht hier im Forum nicht zu posten,
ich werde dies jedoch im DB Wiki demnächst hochladen.

Lg Jimmy

 

Mit dem Code von Josef hab ich bissel rumprobiert, es aber dann gelassen.

Ich habe herausgefunden, dass sich das Passwort doch einfach speichern lässt. Ich muss nur die ganzen Verknüpfungen zu den Datenbanken neu machen, dann geht es. Keine Ahnung, weshalb er die ursprünglichen Passwörter weggeworfen hat.

Ich habe aber noch eine Frage dazu: Wenn ich die Verbindung speichere, warnt er mich, dass das PW im Klartext gespeichert wird und man das dann im Quelltext sieht. Jetzt hab ich mal geschaut. In der DNS-Datei ist das PW nicht gespeichert. Wenn die Access-Datei mit nem Editor öffne, ist das PW dort auch nicht zu finden. Die Datei selbst lässt sich ja wiederum ohne Passwort mit Access nicht öffnen.

Also wo kann das denn dann ausgelesen werden?

 

Wenn die Access-Datei mit einem Passwort verschlüsselt ist, dann ist auch das Passwort verschlüsselt. - Alles gut.

 

Hallo!

Wenn das DBMS-Kennwort nicht außerhalb des Clients bekannt sein soll, da nicht direkt auf den DBMS-Server zugegriffen werden soll, der Anwender aber das Access-Kennwort kennt, dann muss man das Kennwort extra absichern. Man kann mit dem Access-Kennwort die verknüpfte Tabelle in eine leere unverschlüsselte Access-Anwendung importieren und schon hat man bei einer verknüpften Tabelle mit gespeicherten Zugangsdaten diese Zugangsdaten sichtbar (Codedb.Tabledefs(...).Connect) - ob das gut oder nicht gut ist, ist Ansichtssache.
=> Abhilfe wäre eine extra Starteranwendung, die auch das Access-Kennwort schützt oder das Kennwort nicht in der verknüpften Tabelle speichern.

Es kann auch ausreichend sein, dass man davon ausgeht, dass niemand das Kennwort nach der oben beschriebenen Methode ausliest. *wink.gif*

mfg
Josef

 

Alles klar, vielen Dank für die Antworten.

Dann ist das Risiko sehr überschaubar.

 

Das ist das Matruschka-Prinzip. Wer oder was schützt dann die Starteranwendung? Eine Starterstarteranwendung? ;-)