Mögliche Fehlerursachen DSNloseVerbindung MSACCESS

Hallo zusammen,

aktuell versuche ich Datenbanken per ODBC DSNlos einzubinden. Dazu nutze ich das folgende Skript (Office Hilfe MS):


Function AttachDSNLessTable_ORACLE_alt(stLocalTableName As String, stRemoteTableName As String, stServer As String, Optional stUsername As String, Optional stPassword As String)
On Error GoTo AttachDSNLessTable_Err
Dim td As TableDef
Dim stConnect As String

For Each td In CurrentDb.TableDefs
If td.Name = stLocalTableName Then
CurrentDb.TableDefs.Delete stLocalTableName
End If
Next

If Len(stUsername) = 0 Then
'//Use trusted authentication if stUsername is not supplied.

stConnect = „ODBC;Driver={Microsoft ODBC for Oracle};Server=“ & stServer & „;“
Else
'//WARNING: This will save the username and the password with the linked table information.
stConnect = „Driver={Microsoft ODBC for Oracle};Server=“ & stServer & „;Uid=“ & stUsername & „; Pwd=“ & stPassword & „;“
End If
Set td = CurrentDb.CreateTableDef(stLocalTableName, dbAttachSavePWD, stRemoteTableName, stConnect)
CurrentDb.TableDefs.Append td
AttachDSNLessTable_ORACLE = True
Exit Function

AttachDSNLessTable_Err:

AttachDSNLessTable_ORACLE = False
MsgBox "AttachDSNLessTable encountered an unexpected error: " & Err.Description

End Function


Aufruf über:


Sub ODBCLLoseVerbindungUmstellen()
Dim strNeuerNameLokal As String
Dim strNameImDWH As String
Dim td As TableDef
For Each td In CurrentDb.TableDefs
If Left(td.Name, 7) = „PRÄFIX_“ Then
strName = Mid(td.Name, 8)
Debug.Print td.Name & " - Update erfolgreich?: " & DBTools.AttachDSNLessTable_ORACLE(td.Name, „PRÄFIX.“ & strName, Consts.SERVERNAME_str, Consts.BENUTZER_str, Consts.BENUTZER_PW_str)
End If
Next
Debug.Print „fertig.“
End Sub

Mehrere Nutzer haben Zugriffe auf unterschiedliche Tabellen. Die Tabellen von Nutzer A werden auch unproblematisch eingebunden. Nun kam ein neuer Nutzer B mit neuen Tabellen hinzu. Dort funktioniert es nicht mehr.

Fehlermeldung:
Jet Datenbankmodul konnte das Objekt „PRÄFIX.Tabellenname“ nicht finden.

Ich habe nun natürlich an Nutzernamen und Passwort gezweifelt. Jedoch folgender Code funktioniert:


Private Sub test()

Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim sqlstr As String

cn.ConnectionString = „Driver={Microsoft ODBC for Oracle};Server=“ & Consts.SERVERNAME_str & „;Uid=“ & Consts.BENUTZER_str & „:stuck_out_tongue_winking_eye:wd=“ & Consts.BENUTZER_PW_str & „;“

cn.Open

Set rs.ActiveConnection = cn

sqlstr = "SELECT * " _
& „FROM TABELLE“

rs.Open sqlstr, , adOpenStatic, adLockBatchOptimistic

Debug.Print rs!Datum

End Sub

Also an den Konstanten und am Connectionstring scheint es nicht zu liegen.
Wo liegen weitere Mögliche Fehlerquellen? Gib es Tabellenberechtigungen in Oracle die das VBA SKript verhindern?

Vielen Dank
Holger

Hallo Holger,

tut mir leid, zu Access, VB und ODBC kann ich Dir rein gar nicht weiterhelfen. Ein Tipp nur: Wenn Du Dich mit dem gleichen Benutzer direkt mit SQL*Plus bei der DB anmeldest - funktioniert der Zugriff dann?

Gruß
Martin

Hallo Holger,

tut mir leid, zu Access, VB und ODBC kann ich Dir rein gar nicht weiterhelfen. Ein Tipp nur: Wenn Du Dich mit dem gleichen Benutzer direkt mit SQL*Plus bei der DB anmeldest - funktioniert der Zugriff dann?

Gruß
Martin

Hallo Holger,

in Oracle gibt es schon userspezifische Tabellen, sprich, wenn Du als User A eine Tabelle angelegt hast, dann ein neuer User B angelegt wird, der zB keinen Grant Select auf User A-Tabellen hat, dann sieht User B diese Tabellen nicht. In Deinem Programm schlägt das dann so auf, daß das Jet-Modul, wenn Du Dich mit User B connectest, genau diese Tabellen nicht sieht bzw. keinen Zugriff darauf hat.

Gruß,
Markus Süße

Hallo Martin,

ich nutze den PL/SQL Developer und damit klappt alles wunderbar. Das ist ja das, wo mein Durchblick langsam aufhört.

Gruß
Holger

Hallo Markus,

User B greift auch auf seine eigenen Tabellen zu und nicht auf diejenigen von User A. Ich habe in der user_tab_privs nachgesehen und da hat der User B als Privileg „SELECT“ stehen.
Also eigentlich funktionieren die Zugriffe. Auch beim ersten Einbinden der Tabellen. Nur sobald das Passwort gespeichert werden soll, geht es schief.
(Keine ständigen Abfragen des Passworts, um z.B. Makros auszuführen)

Viele Grüße
Holger

Hallo,

sorry, geht momentahn völlig an meine Kenntnisse vorbei!

Ich kann Dir leider nicht helfen, habe das letzte mal solch ein script vor 6 jahren benutzt.

Sorry!

Hallo Holger,

versuch doch mal mit Deinem Test-Script als User B auf PRÄFIX.Tabellenname zu selecten.
Bei einem User/Passwort-Fehler würde bereits der Connect in die Hose gehen. Das ist nicht der Fall, das Modul findet nur bestimmte Tabellen nicht.

Gruß,
Markus

Hallo Holger,
kann Dir da leider nicht weiter helfen, sorry.
Gruß Klaus

Hi Holger,

sorry, das ist wirklich extrem schwer zu lesender Sourcecode.
Mein Tipp:
Sauber alles strukturieren (Zeilenumbrüche, Kommentare), normalerweise sieht man das dann sofort.
http://www.able-consulting.com/MDAC/ADO/Connection/O…

http://support.microsoft.com/search/default.aspx?Cat…

Ach ja, was meistens das Problem ist: Der Tabellenname ist immer schema.tabelle.
Wenn unter dem user (=Schema) keine Tabelle angelegt ist, dann findet er die nicht. Die muß dann explizit so angegeben werden.

Beste Grüße

Andreas

Hallo zusammen,

für die Allgemeinheit hier also der begrabene Hund:

Das Problem ist die DSNlose Verbindung selbst. Es ist bereits ein anderes Schema auf demselben Server eingebunden und beim Aufruf der Access Datenbank wird natürlich diese Verbindung hergestellt. Wenn ich dann neue Tabellen eines anderen Schemas einbinde, die auf demselben Server liegen, so kann ich mich nicht mit einem anderen Nutzer dort zeitgleich anmelden.

Liegen Tabellen auf unterschiedlichen Servern, ist das kein Problem.

Nun kann man sich fragen, warum das erste einhängen funktioniert und man normalerweise auf unterschiedliche ODBC Tabellen von unterschiedlichen Schemata auf demselben Server zugreifen kann. Nun, genau dafür gibt es DSN Verbindungen. SOmit wird für jede Verbindung eine eigene Entität angelegt.
Fazit: Unterschiedliche User und unterschiedliche Schemata auf einem SQL Server sollten mit DSN verbunden werden.

Vorsicht! Wenn mehrere Nutzer die Access Datenbank nutzen, ist es wichtig, dass die DSN Einstellung in der Systemsteuerung denselben Namen hat.
(Um das zu umgehen, hatte man schließlich die DSNlose Verbindung)

Ich hoffe es ist verständlich genug erklärt, falls mal wieder jemand vor so einem Probem steht.

Gruß
Holger

Hallo Holger,

ich habe leider überhaupt keine Erfahrung mit dem Zugriff von Access-Seite aus. Wenn du dich von Access aus mit dem Oracle-User „A“ verbinden kannst, sollte das genau so auch mit „B“ möglich sein. Wenn dieser neue User „B“ Tabellen hat, sollten die mit B. auch ansprechbar sein.

Sorry, keine große Hilfe.

lg,
Guido