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
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/
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
vielen Dank.
Das hat mich deutlich weiter gebracht. Nun funktioniert es so, wie ich
mir das vorgestellt habe.
Stefan
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/
> 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
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.
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? ;)
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
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.
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.