TRUSTED_CONNECTION = NO geht nicht bei eingebundenen Tabellen
Rainer Venema
ich kämpfe schon seit einigen Tagen mit dem folgenden Problem.
In meiner Access-Applikation möchte ich mich wahlweise mit
verschidenen SQL-Server DB´s verbinden. Dabei soll auch wahlweise die
Windows Authentifizierung und die SQL-Server Authentifizierung
angewendet werden.
Ich bastele mir also den Connection string entsprechend zusammen und
erstelle eine passende TableDef. Nur: kaum ist die TableDef erstellt,
verändert sich wie von Geisterhand die Einstellung TRUSTED_CONNECTION
= NO auf YES.
Folgender Code:
'----------------------------------------
Dim mytable As TableDef
Set mytable = db.CreateTableDef("temp")
mytable.SourceTableName = "tblTest"
Debug.Print "1: "; strdb
mytable.Connect = strdb
Debug.Print "2: "; mytable.Connect
db.TableDefs.Append mytable
Debug.Print "3: "; mytable.Connect
'----------------------------------------
Ergibt folgendes Ergebnis:
1: ODBC;DRIVER=SQL Server;SERVER=Server
\MS_SQL_2008;Trusted_Connection=NO;Database=Database;
2: ODBC;DRIVER=SQL Server;SERVER=Server
\MS_SQL_2008;Trusted_Connection=NO;Database=Database;
3: ODBC;DRIVER=SQL Server;SERVER=Server
\MS_SQL_2008;UID=Admin;PWD=;APP=Microsoft Office
2003;WSID=Workstation;DATABASE=Database;Trusted_Connection=Yes
Hat jemand ne Idee, was hier falsch läuft? HEute morgen ging es
übrigens ein-/zweimal, und dann war wieder Schluss.
Vielen Dank,
Rainer
Lutz Uhlmann
UID=Nutzer;PWD=Passwort;
Rainer Venema
> Gib mal bei deinem Connection-String noch den SQL-Nutzer mit an:
> UID=Nutzer;PWD=Passwort;
Hi Lutz,
vielen Dank, das habe ich schon versucht...
Aber jetzt auch noch mal - es ändert sich nichts am Verhalten, leider.
Danke trotzdem,
Rainer
Peter Doering
Rainer Venema wrote:
> In meiner Access-Applikation m�chte ich mich wahlweise mit
> verschidenen SQL-Server DB�s verbinden. Dabei soll auch wahlweise die
> Windows Authentifizierung und die SQL-Server Authentifizierung
> angewendet werden.
>
> Ich bastele mir also den Connection string entsprechend zusammen und
> erstelle eine passende TableDef. Nur: kaum ist die TableDef erstellt,
> ver�ndert sich wie von Geisterhand die Einstellung TRUSTED_CONNECTION
> = NO auf YES.
>
> Folgender Code:
>
> '----------------------------------------
> Dim mytable As TableDef
>
> Set mytable = db.CreateTableDef("temp")
> mytable.SourceTableName = "tblTest"
> Debug.Print "1: "; strdb
> mytable.Connect = strdb
> Debug.Print "2: "; mytable.Connect
> db.TableDefs.Append mytable
> Debug.Print "3: "; mytable.Connect
> '----------------------------------------
>
> Ergibt folgendes Ergebnis:
> 1: ODBC;DRIVER=SQL Server;SERVER=Server
> \MS_SQL_2008;Trusted_Connection=NO;Database=Database;
> 2: ODBC;DRIVER=SQL Server;SERVER=Server
> \MS_SQL_2008;Trusted_Connection=NO;Database=Database;
> 3: ODBC;DRIVER=SQL Server;SERVER=Server
> \MS_SQL_2008;UID=Admin;PWD=;APP=Microsoft Office
> 2003;WSID=Workstation;DATABASE=Database;Trusted_Connection=Yes
>
> Hat jemand ne Idee, was hier falsch l�uft? HEute morgen ging es
> �brigens ein-/zweimal, und dann war wieder Schluss.
Wiederhol mal den Connect als letzten Befehl:
1. CreateTableDef
2. .Connect = ...
3. .Append
4. .Connect = ...
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Rainer Venema
vielen Dank für den Tipp (da hätte ich Dich ja auch am Wochenende
fragen können...).
Aber, leider, das ändert nichts.
Ich weiss aber inzwischen, warum es manchmal geht. Anscheinend ist es
so, dass so bald einmal eine "Trusted" Connection vom Client zur
fraglichen Server-Instanz (unabhängig von der DB) bestand, diese
weiterhin verwendet wird, auch wenn man im Connection String das
anders verlangt hat. Das gilt auch dann, wenn man vorher alle
verknüpften Tabellen aus der Access-DB löscht, das hatte ich nämlich
schon vorher versucht.
"Cient" bedeutet in diesem Fall die Access-Applikation, denn wenn
diese beendet und neu gestartet wird, dann beginnt das Spiel von Neuem
und man kann auch eine Verbindung mit SQL-Server Authentifizierung
aufbauen.
Frage also: weiss jemand wo diese "versteckte" Verbindung vorgehalten
wird?
Viele Grüße,
Rainer
On 3 Nov., 10:22, Peter Doering <nos...@doering.org> wrote:
> Hallo,
>
>
>
> RainerVenemawrote:
> > In meiner Access-Applikation möchte ich mich wahlweise mit
> > verschidenen SQL-Server DB´s verbinden. Dabei soll auch wahlweise die
> > Windows Authentifizierung und die SQL-Server Authentifizierung
> > angewendet werden.
>
> > Ich bastele mir also den Connection string entsprechend zusammen und
> > erstelle eine passende TableDef. Nur: kaum ist die TableDef erstellt,
> > verändert sich wie von Geisterhand die Einstellung TRUSTED_CONNECTION
> > = NO auf YES.
>
> > Folgender Code:
>
> > '----------------------------------------
> > Dim mytable As TableDef
>
> > Set mytable = db.CreateTableDef("temp")
> > mytable.SourceTableName = "tblTest"
> > Debug.Print "1: "; strdb
> > mytable.Connect = strdb
> > Debug.Print "2: "; mytable.Connect
> > db.TableDefs.Append mytable
> > Debug.Print "3: "; mytable.Connect
> > '----------------------------------------
>
> > Ergibt folgendes Ergebnis:
> > 1: ODBC;DRIVER=SQL Server;SERVER=Server
> > \MS_SQL_2008;Trusted_Connection=NO;Database=Database;
> > 2: ODBC;DRIVER=SQL Server;SERVER=Server
> > \MS_SQL_2008;Trusted_Connection=NO;Database=Database;
> > 3: ODBC;DRIVER=SQL Server;SERVER=Server
> > \MS_SQL_2008;UID=Admin;PWD=;APP=Microsoft Office
> > 2003;WSID=Workstation;DATABASE=Database;Trusted_Connection=Yes
>
> > Hat jemand ne Idee, was hier falsch läuft? HEute morgen ging es
> > übrigens ein-/zweimal, und dann war wieder Schluss.
Peter Doering
Rainer Venema wrote:
>
> vielen Dank f�r den Tipp (da h�tte ich Dich ja auch am Wochenende
> fragen k�nnen...).
;-)
> Aber, leider, das �ndert nichts.
>
> Ich weiss aber inzwischen, warum es manchmal geht. Anscheinend ist es
> so, dass so bald einmal eine "Trusted" Connection vom Client zur
> fraglichen Server-Instanz (unabh�ngig von der DB) bestand, diese
> weiterhin verwendet wird, auch wenn man im Connection String das
> anders verlangt hat. Das gilt auch dann, wenn man vorher alle
> verkn�pften Tabellen aus der Access-DB l�scht, das hatte ich n�mlich
> schon vorher versucht.
>
> "Cient" bedeutet in diesem Fall die Access-Applikation, denn wenn
> diese beendet und neu gestartet wird, dann beginnt das Spiel von Neuem
> und man kann auch eine Verbindung mit SQL-Server Authentifizierung
> aufbauen.
Ich hab jetzt ein bisserl damit rumgespielt und kann das Verhalten
bestaetigen. Allerdings tritt es bei mir nur auf, wenn ich mich am lokalen
Rechner bewege. Liegt der Server auf einem anderen Rechner, wird nach
Trusted bzw. SQL-Login unterschieden.
> Frage also: weiss jemand wo diese "versteckte" Verbindung vorgehalten
> wird?
Es ist das gleiche Verhalten, das dafuer verantwortlich ist, dass eine
Access-Session nach (auch voruebergehendem) Ausfall der Serververbindung
neu gestartet werden muss. Das Problem ist mir bekannt, ein Workaround
dagegen nicht. :-(
Gruss - Peter
--
Siegfried Schmidt
> Es ist das gleiche Verhalten, das dafuer verantwortlich ist, dass eine
> Access-Session nach (auch voruebergehendem) Ausfall der
> Serververbindung neu gestartet werden muss. Das Problem ist mir
> bekannt, ein Workaround dagegen nicht. :-(
Netzwerkverbindung ï¿œber ein (dummy-)VPN erstellen.
Siegfried
Henry Habermacher
Peter Doering wrote:
> Ich hab jetzt ein bisserl damit rumgespielt und kann das Verhalten
> bestaetigen. Allerdings tritt es bei mir nur auf, wenn ich mich am lokalen
> Rechner bewege. Liegt der Server auf einem anderen Rechner, wird nach
> Trusted bzw. SQL-Login unterschieden.
Schalte mal den lokalen SQL Server auf SQL Server Authentication um, also
Windows Authentication deaktivieren und versuche es dann nochmals. Soweit
ich beobachtet habe, wird Access/ODBC immer die Windows Authentication
benutzen, wenn diese aktiviert ist. Ist jedoch mal auf SQL Server
Authentication umgeschaltet, dann bleibt es normalerweise auch dabei, auch
wenn die Windows Authentication wieder aktiviert wird.
Gruss
Henry
--
Microsoft MVP Office Access
Keine E-Mails auf Postings in NGs. Danke.
Access FAQ www.donkarl.com
Lutz Uhlmann
> deaktivieren und versuche es dann nochmals. Soweit ich beobachtet habe, wird Access/ODBC immer die
> Windows Authentication benutzen, wenn diese aktiviert ist. Ist jedoch mal auf SQL Server
> Authentication umgeschaltet, dann bleibt es normalerweise auch dabei, auch wenn die Windows
> Authentication wieder aktiviert wird.
Ich glaub man kann nur zwischen Windows Authentication und dem Mixed Mode w�hlen - einen Modus nur
mit SQL-Server Authentication gibt es meines Wissens nach nicht.
Man kann aber nat�rlich �ber die Nutzerrechte daf�r sorgen, da� die Windows-Nutzer per se keinen
Zugriff haben.
Es mu� aber auch so funktionieren - bei mir tut es das n�mlich ;)
Mein ConnectionString sieht dabei so aus:
"ODBC;DRIVER=SQL
Server;SERVER=SQLDEV;DATABASE=xxxdata;APP=Anwendung;Trusted_Connection=No;Network=DBMSSOCN;;UID=Nutzer;PWD=passwort;"
Hier meine Funktion die sich aus einer Abfrage heraus die zu verkn�pfenden Objekte holt und die
Tabellenverkn�pfungen anlegt:
Public Function RecreateOdbcTdf() As Boolean
On Error GoTo Err_
Dim dbs As DAO.Database
Dim tdf As DAO.TableDef
Dim rs As DAO.Recordset
Dim sql As String, sPkIndexName As String
Dim sLocalName As String, sSrcName As String, sSrcSchema As String
Dim nSrcType As Integer, sSrcPrimary As String, sSrcPath As String
Dim sConnect As String
Dim nNr As Long, nCount As Long, nStep As Long
RecreateOdbcTdf = False
sConnect = GetDBMS.dbConnection.OdbcConnectionString
sql = "SELECT * FROM DB_CLIENTOBJ WHERE AppID=3" & _
" ORDER BY ObjSchema,ObjName"
Set rs = GetDBMS.dbConnection.CurrentDaoDbBe.OpenRecordset(sql, dbOpenDynaset)
Set dbs = CurrentDbC
If rs.EOF Then GoTo Exit_
Do Until rs.EOF
sSrcSchema = Nz(rs!ObjSchema, "")
sSrcName = Nz(rs!ObjName, "")
sLocalName = Nz(rs!ObjAlias, "")
nSrcType = Nz(rs!ObjType, acTable)
sSrcPrimary = Nz(rs!ObjPK, "") ' ID,Nr
If sLocalName = "" Then
If sSrcSchema = "schSystem" Then
sLocalName = "SYS_" & sSrcName
Else
sLocalName = sSrcName
End If
End If
sSrcPath = sSrcSchema & "." & sSrcName
sPkIndexName = "PK_UI_" & sLocalName
dbs.TableDefs.delete sLocalName
Set tdf = dbs.CreateTableDef(sLocalName, 0&, sSrcPath, sConnect)
dbs.TableDefs.Append tdf
'Pseudo-Index zur Sicht erzeugen
If nSrcType = acQuery Then
If Len(Trim(sSrcPrimary)) > 0 Then
sql = "CREATE UNIQUE INDEX " & sPkIndexName & " ON " & _
sLocalName & "(" & Trim(sSrcPrimary) & ") WITH PRIMARY"
dbs.Execute sql, dbFailOnError
End If
End If
rs.MoveNext
Loop
RecreateOdbcTdf = True
Exit_:
On Error Resume Next
rs.Close
Set rs = Nothing
Set tdf = Nothing
Exit Function
Err_:
Select Case Err
Case 3011:
Resume Next
Case 3265:
Resume Next
Case Else:
Call ErrorHandler("dbmsSqlServer", "RecreateOdbcTdf")
End Select
Resume Exit_
End Function
Funktioniert recht zuverl�ssig!!!
Henry Habermacher
Lutz Uhlmann wrote:
>> Schalte mal den lokalen SQL Server auf SQL Server Authentication um,
>> also Windows Authentication deaktivieren und versuche es dann nochmals.
>> Soweit ich beobachtet habe, wird Access/ODBC immer die Windows
>> Authentication benutzen, wenn diese aktiviert ist. Ist jedoch mal auf
>> SQL Server Authentication umgeschaltet, dann bleibt es normalerweise
>> auch dabei, auch wenn die Windows Authentication wieder aktiviert wird.
>
> Ich glaub man kann nur zwischen Windows Authentication und dem Mixed Mode
> w�hlen - einen Modus nur mit SQL-Server Authentication gibt es meines
> Wissens nach nicht.
Ja, da hatte ich wohl was falsches im Kopf. Also dem Benutzer die
Berechtigung wegnehmen, wenn auf Mixed Mode umgestellt ist.
> Man kann aber nat�rlich �ber die Nutzerrechte daf�r sorgen, da� die
> Windows-Nutzer per se keinen Zugriff haben.
Genau.
> Es mu� aber auch so funktionieren - bei mir tut es das n�mlich ;)
Ich weiss, dass es tut, aber das auf die andere Seite zu kriegen ist nicht
ganz so einfach.
Peter Doering
Siegfried Schmidt wrote:
> Peter Doering schrieb:
>
>> Es ist das gleiche Verhalten, das dafuer verantwortlich ist, dass eine
>> Access-Session nach (auch voruebergehendem) Ausfall der
>> Serververbindung neu gestartet werden muss. Das Problem ist mir
>> bekannt, ein Workaround dagegen nicht. :-(
>
> Netzwerkverbindung �ber ein (dummy-)VPN erstellen.
Und warum wuerde sich Access dabei anders verhalten? Wenn die Verbindung
mal weg war, wird sie nicht mehr gefunden, ob ueber lokale Verbindung, VPN
oder sonst wie. Schliessen/Oeffnen der mdb hilft ebenfalls nichts, nur der
Neustart von Access.
Siegfried Schmidt
> Und warum wuerde sich Access dabei anders verhalten?
Weil das virtuelle Interface vom Zustand des physikalischen Links
entkoppelt ist. Ausserdem hat Access selbst gar keinen Verbindung zum
Netzwerk, sondern spricht nur mit den CIFS- oder ODBC-Clients, d.h. wenn
diese stillhalten tut es Access wie jedes andere ï¿œhnlich Programm auch.
> Wenn die
> Verbindung mal weg war, wird sie nicht mehr gefunden, ob ueber lokale
> Verbindung, VPN oder sonst wie.
Bei einem UDP-basierendem Transport gibts keine logische Verbindung, ergo
kann durch einen Linkverlust auch nichts weg sein. Selbst ein IP-Wechsel
wï¿œre mï¿œglich.
> Schliessen/Oeffnen der mdb hilft
> ebenfalls nichts, nur der Neustart von Access.
Ich habs grad ausprobiert, eine mdb auf einem Netzlaufwerk ï¿œber openVPN
ï¿œber LAN gestartet und wï¿œhrend einer laufenden Abfrage den LAN-Stecker
gezogen. Nach dem Anstecken macht Access brav weiter als wenn nichts
gewesen wï¿œre. War auch nicht anders zu erwarten.
Siegfried