Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Umgebungsvariablen auch in Abfrage benutzen [Environ("Username")]

886 views
Skip to first unread message

Stefan Paesch

unread,
Dec 8, 2010, 7:37:00 AM12/8/10
to
Moin zusammen,

bisher ist es mir nicht gelungen, den "Benutzer" mit einer Funktion in
einer klassischen Abfrage zu benutzen (wie z.B. DomMax).
Momentan löse ich das über eine selbstgebaute Funktion.

so funktioniert es nicht (Fehler: Undefenierte Funktion):
UPDATE tbl_AbrgNr SET tbl_AbrgNr.Benutzer = Environ("Username");

Gibt es da etwas Anderes ?

Danke Stefan

WinXP SP2
ACC 2010

Josef Poetzl

unread,
Dec 8, 2010, 8:28:52 AM12/8/10
to
Hallo!

Stefan Paesch schrieb:


> so funktioniert es nicht (Fehler: Undefenierte Funktion):
> UPDATE tbl_AbrgNr SET tbl_AbrgNr.Benutzer = Environ("Username");

Environ wird durch die Sandboxeinstellung (SandBoxMode = 3) gesperrt.

Abhilfe:
Eine eigene Environ in einem allgemeinen Modul erstellen
| Public Function Environ(ByVal Expression As Variant) As Variant
| Environ = VBA.Environ(Expression)
| End Function

... oder die Sandboxeinstellung auf 2 setzen.
(FAQ 2.28 Sicherheitsmeldungen in A03 - www.donkarl.com?FAQ2.28 )

mfg
Josef

--
Code-Bibliothek für Access-Entwickler: http://access-codelib.net/
AccUnit - Access-Anwendungen testen: http://access-codelib.net/accunit
Access-FAQ von Karl Donaubauer: http://www.donkarl.com/

Karl Donaubauer

unread,
Dec 8, 2010, 8:32:27 AM12/8/10
to
Stefan Paesch wrote:
> bisher ist es mir nicht gelungen, den "Benutzer" mit einer Funktion in
> einer klassischen Abfrage zu benutzen (wie z.B. DomMax).
> Momentan löse ich das über eine selbstgebaute Funktion.
>
> so funktioniert es nicht (Fehler: Undefenierte Funktion):
> UPDATE tbl_AbrgNr SET tbl_AbrgNr.Benutzer = Environ("Username");

An sich sollte das funktionieren.
Kontrolliere deine Verweise: www.donkarl.com?FAQ7.1

> Gibt es da etwas Anderes ?

Klar. Ich verwende statt Environ() immer API-Funktionen, um
den Windows-Benutzernamen auszulesen.
s. www.donkarl.com?FAQ2.24
Den Funktionsnamen kannst du dann auch in Abfragen verwenden.

--
Servus
Karl
*********
Access-FAQ: http://www.donkarl.com
4. SQL Server-Entwickler-Konferenz, 12./13.2.2011, Nürnberg


Stefan Paesch

unread,
Dec 8, 2010, 12:03:01 PM12/8/10
to
Hallo Josef, hallo Karl,

vielen Dank.
Das hat mich deutlich weiter gebracht. Nun funktioniert es so, wie ich
mir das vorgestellt habe.

Stefan


Lupus Goebel

unread,
Dec 8, 2010, 2:27:21 PM12/8/10
to
Tach,

Am 08.12.2010 14:32 schrieb Karl Donaubauer:

> Klar. Ich verwende statt Environ() immer API-Funktionen, um
> den Windows-Benutzernamen auszulesen.

Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf? Also wenn
es nur um den Benutzernamen geht.


--
MfG - Lupus Goebel
Der Sumpf- Morasthobbybastler und Anfaenger mit
Wissensdurst (http://www.lupusdw.de http://foto.lupusdw.de)
Urlaub macht man in Irland: http://www.eaglesnest-bb.com/

Winfried Sonntag

unread,
Dec 8, 2010, 2:49:52 PM12/8/10
to
Am 08.12.2010 schrieb Lupus Goebel:

> Am 08.12.2010 14:32 schrieb Karl Donaubauer:
>
>> Klar. Ich verwende statt Environ() immer API-Funktionen, um
>> den Windows-Benutzernamen auszulesen.
>
> Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf? Also wenn
> es nur um den Benutzernamen geht.

Hat Karl doch geschrieben:


| Den Funktionsnamen kannst du dann auch in Abfragen verwenden.

Wenn Du viel mit einem Benutzernamen arbeitest, ist es schon von
Vorteil den auch *immer* benutzen zu können.

Servus
Winfried
--
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
Access-FAQ: http://www.donkarl.com/AccessFAQ.htm
Access-Stammtisch: http://www.access-muenchen.de

Lupus Goebel

unread,
Dec 8, 2010, 3:15:10 PM12/8/10
to
Abend,

Am 08.12.2010 20:49 schrieb Winfried Sonntag:
> Am 08.12.2010 schrieb Lupus Goebel:
>
>
>> Am 08.12.2010 14:32 schrieb Karl Donaubauer:
>>
>>> Klar. Ich verwende statt Environ() immer API-Funktionen, um
>>> den Windows-Benutzernamen auszulesen.
>>
>> Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf? Also wenn
>> es nur um den Benutzernamen geht.
>
> Hat Karl doch geschrieben:
> | Den Funktionsnamen kannst du dann auch in Abfragen verwenden.

Das geht doch auch aber so (jedenfalls in A2007):
\\\
Function UserLogin()
CurrentDb.Execute ("UPDATE tbl_Auswahl " & _
" SET Mitarbeiter = fncUsername();")
End Function

Function fncUsername() As String
fncUsername = Environ("USERNAME")
End Function
///

Was haben denn die API's dem gegenüber für Vorteile?

> Wenn Du viel mit einem Benutzernamen arbeitest, ist es schon von
> Vorteil den auch *immer* benutzen zu können.

Zweifelsohne, daher habe ich mir ja auch das kleine fncUsername()
geschrieben.

Winfried Sonntag

unread,
Dec 8, 2010, 3:46:14 PM12/8/10
to
Am 08.12.2010 schrieb Lupus Goebel:

> Am 08.12.2010 20:49 schrieb Winfried Sonntag:
>> Am 08.12.2010 schrieb Lupus Goebel:
>>
>>
>>> Am 08.12.2010 14:32 schrieb Karl Donaubauer:
>>>
>>>> Klar. Ich verwende statt Environ() immer API-Funktionen, um
>>>> den Windows-Benutzernamen auszulesen.
>>>
>>> Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf? Also wenn
>>> es nur um den Benutzernamen geht.
>>
>> Hat Karl doch geschrieben:
>> | Den Funktionsnamen kannst du dann auch in Abfragen verwenden.
>
> Das geht doch auch aber so (jedenfalls in A2007):
> \\\
> Function UserLogin()
> CurrentDb.Execute ("UPDATE tbl_Auswahl " & _
> " SET Mitarbeiter = fncUsername();")
> End Function
>
> Function fncUsername() As String
> fncUsername = Environ("USERNAME")
> End Function
> ///
>
> Was haben denn die API's dem gegenüber für Vorteile?

Du hast dafür eine eigene Tabelle und pflegst das. Mit der API kann
man sich das sparen.

>> Wenn Du viel mit einem Benutzernamen arbeitest, ist es schon von
>> Vorteil den auch *immer* benutzen zu können.
>
> Zweifelsohne, daher habe ich mir ja auch das kleine fncUsername()
> geschrieben.

Ist ja auch vollkommen in Ordnung. Aber warum muß ich selbst etwas
schreiben/erstellen, wenn ich es OnBoard geliefert bekomme? ;)

Karl Donaubauer

unread,
Dec 8, 2010, 5:05:06 PM12/8/10
to
Lupus Goebel wrote:
> schrieb Karl Donaubauer:
>
>> Klar. Ich verwende statt Environ() immer API-Funktionen, um
>> den Windows-Benutzernamen auszulesen.
>
> Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf?
> Also wenn es nur um den Benutzernamen geht.

Das ist eine alte Glaubensfragen, die schon öfter diskutiert wurde.
Ich neige halt aus zwei Gründen mehr zur API-Lösung:

Zum einen gab es in den NGs ein paar Mal Anfragen, weil Environ in
manchen Umgebungen nicht funktionierte. Zum anderen ist es relativ
leicht manipulierbar. s. z.B.
http://groups.google.com/group/microsoft.public.de.access/browse_frm/thread/61eb8319afc00fa5

--
Servus
Karl
****************
http://www.donkarl.com Access-FAQ

Lupus Goebel

unread,
Dec 9, 2010, 8:39:39 AM12/9/10
to
Tach,

Am 08.12.2010 23:05 schrieb Karl Donaubauer:
> Lupus Goebel wrote:
>> schrieb Karl Donaubauer:
>>
>>> Klar. Ich verwende statt Environ() immer API-Funktionen, um den
>>> Windows-Benutzernamen auszulesen.
>>
>> Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf? Also
>> wenn es nur um den Benutzernamen geht.
>
> Das ist eine alte Glaubensfragen, die schon öfter diskutiert wurde.
> Ich neige halt aus zwei Gründen mehr zur API-Lösung:
>
> Zum einen gab es in den NGs ein paar Mal Anfragen, weil Environ in
> manchen Umgebungen nicht funktionierte. Zum anderen ist es relativ
> leicht manipulierbar.

Das überzeugt sogar mich :-)

Ich danke Dir für die neuen Erkenntnisse.

Lupus Goebel

unread,
Dec 9, 2010, 8:44:58 AM12/9/10
to
Tach auch,

Am 08.12.2010 21:46 schrieb Winfried Sonntag:

>>>> Am 08.12.2010 14:32 schrieb Karl Donaubauer:
>>>>
>>>>> Klar. Ich verwende statt Environ() immer API-Funktionen, um
>>>>> den Windows-Benutzernamen auszulesen.
>>>>
>>>> Was hat das denn für Vorteile, wenn ich mal Dumm fragen darf? Also wenn
>>>> es nur um den Benutzernamen geht.
>>>
>>> Hat Karl doch geschrieben:
>>> | Den Funktionsnamen kannst du dann auch in Abfragen verwenden.
>>
>> Das geht doch auch aber so (jedenfalls in A2007):
>> \\\
>> Function UserLogin()
>> CurrentDb.Execute ("UPDATE tbl_Auswahl "& _
>> " SET Mitarbeiter = fncUsername();")
>> End Function
>>
>> Function fncUsername() As String
>> fncUsername = Environ("USERNAME")
>> End Function
>> ///
>>
>> Was haben denn die API's dem gegenüber für Vorteile?
>
> Du hast dafür eine eigene Tabelle und pflegst das. Mit der API kann
> man sich das sparen.

Mit meinem Beispiel wollte ich nur zeigen das auch ohne API die variable
in Abfragen zu verwenden geht.

>>> Wenn Du viel mit einem Benutzernamen arbeitest, ist es schon von
>>> Vorteil den auch *immer* benutzen zu können.
>>
>> Zweifelsohne, daher habe ich mir ja auch das kleine fncUsername()
>> geschrieben.
>
> Ist ja auch vollkommen in Ordnung. Aber warum muß ich selbst etwas
> schreiben/erstellen, wenn ich es OnBoard geliefert bekomme? ;)

Na ja, das API muss auch erst geschrieben werden und
\\\


Function fncUsername() As String
fncUsername = Environ("USERNAME")
End Function
///

sind nur 3 Zeilen. Das API hingegen hat so einige mehr.

Übrigens hat Karl Donaubauer in MID: <8madon...@mid.individual.net>
meine Frage bereits beantwortet. Und daher kann ich nur sagen: "Finger
weg von meiner Lösung. Macht das bitte zu Hause nicht nach!"

Danke Dir dennoch.

0 new messages