ODBC-Datenquelle Einrichtung

[magic_halli]

Hi,

ich habe auf dem Domino eine ODBC-Datenquelle als System-DSN für eine SQL-Datenbank konfiguriert. Die hinterlegte Anmeldung ist 'SQL-Server Authentifizierung' und Username/Pass sind hier auch hinterlegt.
...als System-DSN auf dem Domino deshalb, weil diese in einem triggered Agent verwendet wird.
Wenn ich nun im Script die Connection aufbaue, reicht es nicht einfach nur, wenn ich den DSN-Name angebe. Ich MUSS außerdem auch Username/Pass mit angeben, da sonst jedesmal bei Agentausführung auf dem Dominoserver ein Fenster zur Eingabe von Username/Pass erscheint!!!

Code

' nur so funktioniert es:
Call con.ConnectTo("myDominoSystemDSN","User","Pass")

Das ist großer Mist! Was geschieht bspw. bei Passwortänderung etc...?!

Warum könnte das so sein (normalerweise sollte doch der DSN-Name reichen)? Wie könnte ich das lösen?


Danke und Gruß

Rico.

[m3]

Die Foruumssuche ist Dein Freund: http://atnotes.de/index.php/topic,44809.0.html

[magic_halli]

Mh...
Also heißt das, dass es nur reinweg mit DSN-Name funktionieren kann, wenn ich die DSN mit Windows-Authentifizierung einrichte? Dazu müsste dann der entsprechend angegebene Windows-User der DSN auf dem SQL-Datenbankserver hinzugefügt werden (mit bspw. db_owner Berechtigung auf die spezielle Datenbank)?
Hab ich das richtig verstanden? (Deine 1. Aussage in dem verlinkten Post)

Rico.

[pram]

Du könntest auch ADO verwenden, wenn du Hilfe hierzu brauchst, dann schau ich mal nach wie ich das letztens genau gemacht habe (und ob da das Problem nicht auftritt)
Hab mich die letzten Tage intensiv mit LSDO und ADO beschäftigt

ADO hat folgende Vorteile gegenüber LSDO
1. es ist schneller
2. man kann anstatt der DSN auch einen ConnectionString angeben (siehe http://www.connectionstrings.com/)
3. Es kommen etwas detailiertere Fehlermeldungen als "LS:DO could not complete operation"

Gruß
Roland

[magic_halli]

Hallo,

mal noch eine Frage, reineweg zum Verständnis:

Eine System-DSN richte ich auf dem DominoServer ein, um bspw. triggered Agents auszuführen, die auf eine DB zugreifen.
Eine Benutzer-DSN richte ich auf dem NotesClient ein, wenn ich bspw. Datenbankzugriffe im Datenbankscript implementiert habe, da dieses in der jeweiligen Maildatenbank der Nutzer ausgeführt wird.
Soweit meine fundierte und getestete Erkenntnis.

Frage:
Gesetz der Fall, dass der NotesClient auf dem gleichen Rechner wie der DominoServer installiert ist...
Brauche ich dann eine Benutzer-DSN oder System-DSN, wenn im Datenbankscript Datenbankzugriffe passieren sollen?

Ich habe diesen Fall aktuell als Testszenario und habe festgestellt, dass mittels einer Benutzer-DSN hierbei keinerlei DB-Zugriffe aus dem Datenbankscript erfolgen! Stelle ich jedoch auf System-DSN um, funktionieren die DB-Zugriffe aus dem Datenbankscript.
Dieses Verhalten kann ich mir nur so erklären, weil Server und Client auf einem Rechner installiert sind. Liege ich hierbei richtig mit meiner Vermutung?

Danke und Gruß

Rico.

PS: Bitte keine Wertung über Sinn/Unsinn dieser Installationsvariante abgeben. 

[pram]

AFAIK sind Benutzer-DSN nur für den angemeldeten Benutzer verfügbar (bzw. für den Benutzeraccount unter dem der entsprechende Prozess läuft)
System-DSN sind hingegen für jeden Benutzeraccount verfügbar. Evtl gibt es aber hier Unterschiede bei der Authentifizierung gegenüber dem DB-Server (hab ODBC bisher nur in Verbindung mit DBF/XLS-Dateien verwendet und da funktionierte eine System-DSN auch im Client)
System-DSN + Benutzer-DSN sollten aber nicht gleich heißen (da müsste man mal schauen, ob eine Benutzer-DSN eine System-DSN überschreibt oder umgekehrt)

Gruß
Roland

[BigWim]

AFAIK sind Benutzer-DSN nur für den angemeldeten Benutzer verfügbar (bzw. für den Benutzeraccount unter dem der entsprechende Prozess läuft)
System-DSN sind hingegen für jeden Benutzeraccount verfügbar. Evtl gibt es aber hier Unterschiede bei der Authentifizierung gegenüber dem

Ja, weil Benutzer-DSN in HKCU gespeichert werden, während System-DSN in HKLM gespeichert werden. Falls beides nicht passen sollte, gibt es noch die "Datei"-DSN, die nicht in der Registry gespeichert wird, sondern "irgendwo" als File vorliegt.

Markus