SUSER_SNAME über ODBC geht nicht

Computer: Software & Programmierung Microsoft Access
#1

Hallo,

ich habe vor, eine Access Anwendung nur noch als Frontend zu benutzen und die Datenhaltung auf MS SQL Server 2005 auszulagern. Allerdings benötige ich den Login Namen des Nutzers, sodass ich nach einigem Suchen auf unten geschriebenen Code stieß. Leider bekomme ich immer nur das Resultat, dass die Routine mit der Meldung „Für mindestens einen erforderlichen Parameter wurde kein Wert angegeben“ abbricht:

Public Function AktuellerBenutzer() As String
On Error GoTo AktuellerBenutzer_Err

Dim rs As ADODB.Recordset

Const strSQL As String = „SELECT SUSER_SNAME“

Set rs = CurrentProject.Connection.Execute(strSQL)

AktuellerBenutzer = rs.Fields(0).Value

AktuellerBenutzer_Exit:
On Error Resume Next
rs.Close
Set rs = Nothing
Exit Function

AktuellerBenutzer_Err:
MsgBox Err.Number & " " & Err.Description, vbExclamation, „Error“
Resume AktuellerBenutzer_Exit
End Function

Setzt man an die Stelle des „SELECT SUSER_SNAME()“ eine beliebige andere Anfrage a la „SELECT a FROM b“, funktioniert alles einwandfrei. Was könnte hier das Problem sein?

#2

Sorry, aber die Fehlermeldung lautete in Wirklichkeit „…undefinierte Funktion ‚SUSER_SNAME‘“… Die runden Klammern hinter SUSER_SNAME sind bloß verloren gegangen. (Einfach noch mit hindenken.) Das Problem bleibt.

#3

Hallo Patrick,

Was könnte hier das Problem sein?

hmmm, da ich nicht weiß, welche Version du benutzt, vermute ich einfach mal, dass du eine bereits in Access vorhandene Funktion erneut definierst.

D.h. die Funktion AktuellerBenutzer() ist bereits in Access vorhanden.

Wenn du unbedingt deine eigene verwenden willst, verwende einen Unterstrich: z.B. Aktueller_Benutzer() oder A_Benutzer() …

Grüße aus Essen
Wolfgang
(Netwolf)

#4

Das kann ich ausschließen. Wenn ich den Code Zeile für Zeile durchlaufen lasse, dann kommt der Fehler („ungültige Funktion“)immer in folgender Zeile:

Const strSQL As String = „SELECT SUSER_SNAME()“

Theoretisch müsste die Funktion SUSER_SNAME() aber definiert sein. Muss ich da eventuell erst eine bestimmte Bibliothek freischalten? Wenn ja, welche?

#5

Hi,
SUSER_SNAME() ist eine TSQL Funktion des SQL Servers.
Access (bzw. die DB Treiber) versucht die Funktion auszuwerten bevor die Abfrage an den SQL Server geht. Das ist natürlich schlecht möglich, weil Access die Funktion nicht kennt.
Definiere eine Pass-Through Abfrage und öffne dieses dann als normales recordset.

Gruss
Quaser

#6

Hallo Patrik,

Das kann ich ausschließen.

was?

AktuellerBenutzer() ist eine interne Funktion von Access ab Version 2. Das Umbenennen deiner Funktion wäre also sinnvoll.

Wenn ich den Code Zeile für Zeile
durchlaufen lasse, dann kommt der Fehler („ungültige
Funktion“)immer in folgender Zeile:

Const strSQL As String = „SELECT SUSER_SNAME()“

Theoretisch müsste die Funktion SUSER_SNAME() aber definiert
sein.

ist das die Quelle?: http://www.codekabinett.com/page.php?Theme=14&Lang=1

Muss ich da eventuell erst eine bestimmte Bibliothek
freischalten? Wenn ja, welche?

Wie dort beschrieben:
Die hier erwähnten SQL-Server-Funktionen enstammen dem Funktionsumfang des SQL-Servers 8.0 (SQL 2000). In den vorigen Versionen des SQL-Servers sind evtl. nicht alle genannten Funktionen vorhanden.

d.h. die Funktion kommt vom Server.

Tipp: probier mal diese Art des Zugriffs.

SELECT result.*
FROM OPENROWSET(‚SQLOLEDB‘, ‚Trusted_Connection=yes;Data Source=IDCMUC;‘, 'SELECT SUSER_SNAME() ') as result

Quelle: http://www.itrain.de/knowhow/sql/admin/openrowset.asp

Grüße aus Essen
Wolfgang
(Netwolf)

#7

Werte Vorposter,

erst einmal vielen Dank für Eure Ratschläge. Leider war das Umbenennen der Funktion nicht von Erfolg gekrönt. Auch der verlinkte „Exploit“ dürfte bei dem von mir verwendeten MS SQL Server 2005 nicht mehr funktionieren. Um das Problem noch ein wenig besser einzugrenzen:
Die „select suser_sname()“ Anweisung funktioniert im SQL Management Studio wunderbar und liefert den angemeldeten Nutzer zurück. Wird ebenjene Anweisung in der Access Funktion durch eine beliebige Abfrage ersetzt, funktioniert (wie ich schon schrieb) auch diese einwandfrei - an der ODBC Verbindung kann es also eigentlich nicht liegen.
Für den Fall, dass das von Belang ist: Ich habe im VBA Editor Verweise auf die MS ActiveX Data Objects Recordset 2.8 Library, die MS ADO Ext. 2.8 for DDL and Security sowie die MS ActiveX Data Objects 2.8 Library gesetzt.
Kann es denn vielleicht sein, dass eine Transact-SQL Abfrage besondere Nutzerberechtigungen verlangt, die über jene für normale hinausgehen?

Weiterhin auf den zündenden Gedanken hoffend :smile: