CurrentUser() returns null

Hi All,

CurrentUser() returns null when called from a form event handler, at
least from Form_Open()!

However, it works fine in other forms!

Use Application.CurrentUser seem to work, but I'd rather get
CurrentUser() to work, since there are so many calls to it.

Thanks for reading,

Mourad

(re-posting, as my original reply hasn't appeared)

"Mourad" wrote in message
...
Hi All,

CurrentUser() returns null when called from a form event handler, at
least from Form_Open()!

However, it works fine in other forms!

Use Application.CurrentUser seem to work, but I'd rather get
CurrentUser() to work, since there are so many calls to it.


My guess is that you have something else named CurrentUser that is in scope
at the time you call it from this form's Open event. Do you have a control,
field, or variable named CurrentUser?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

Thanks Dirk,

Nop! There is no user defined CurrentUser() anywhere in the code.

The debugger even does not step into CurrentUser() function!

It still returns null!!

Thanks,

Mourad

"Mourad" wrote in message
...
Thanks Dirk,

Nop! There is no user defined CurrentUser() anywhere in the code.

The debugger even does not step into CurrentUser() function!


If the "CurrentUser" function you are referring to is the built-in one, I
wouldn't expect the debugger to step into it.

If you click Debug -Compile in the VB editor, are any compile errors found?

The fact that it works in other forms but not in one particular form
strongly suggests that there's something about that particular form that is
the problem. If you create a new database, import that form and any
necessary supporting tables, queries, and modules into it, does the call to
CurrentUser work on the form in that database?

If not, and if you want to send me a (zipped) copy of that database to look
at, you can send it to the address you get by removing "NO SPAM" and
".invalid" from the reply address of this message.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

"Mourad" wrote in message
...
Thanks Dirk,

Nop! There is no user defined CurrentUser() anywhere in the code.

The debugger even does not step into CurrentUser() function!

It still returns null!!


What happens if you type ?CurrentUser into the immediate window?

Keith.

"Mourad" wrote in message
...
Thanks Dirk,

Nop! There is no user defined CurrentUser() anywhere in the code.

The debugger even does not step into CurrentUser() function!

It still returns null!!

Thanks,

Mourad


The data type of the return value of the built-in CurrentUser() function is
String, which can never be Null, so if you have something called
CurentUser() that is returning Null, it is not the built-in function, it
can't be, as in order to return Null the data type of its return value has
to be Variant.

--
Brendan Reynolds

Thank you all,

It was found that the underlying query of the form has a column with
the same name, CurrentUser! It seems that Access refers to this one
when CurrentUser() function is called! So when the query returns no
rows, CurrentUser() returns NULL, but if there is one or more rows, it
returns a contents of some row (didn't verify which)

I doubt this is by design! I believe it is an Access bug!

Mourad

I don't believe it's not a bug.

If you mistaken choose to name something with a reserved name, Access will
try to respect your object. This allows you to override built-in
functionality (although realistically it's not a good idea).

For a comprehensive list of names to avoid, see what Allen Browne has at
http://www.allenbrowne.com/Ap****ueBadWord.html Note that there's also a
link at the top of the page to a utility that will help identify names
you've used by mistake.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Mourad" wrote in message
...
Thank you all,

It was found that the underlying query of the form has a column with
the same name, CurrentUser! It seems that Access refers to this one
when CurrentUser() function is called! So when the query returns no
rows, CurrentUser() returns NULL, but if there is one or more rows, it
returns a contents of some row (didn't verify which)

I doubt this is by design! I believe it is an Access bug!

Mourad

Darn double negatives!

I meant to say "I don't believe it's a bug"!

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Douglas J. Steele" wrote in message
...
I don't believe it's not a bug.

If you mistaken choose to name something with a reserved name, Access will
try to respect your object. This allows you to override built-in
functionality (although realistically it's not a good idea).

For a comprehensive list of names to avoid, see what Allen Browne has at
http://www.allenbrowne.com/Ap****ueBadWord.html Note that there's also a
link at the top of the page to a utility that will help identify names
you've used by mistake.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Mourad" wrote in message
...
Thank you all,

It was found that the underlying query of the form has a column with
the same name, CurrentUser! It seems that Access refers to this one
when CurrentUser() function is called! So when the query returns no
rows, CurrentUser() returns NULL, but if there is one or more rows, it
returns a contents of some row (didn't verify which)

I doubt this is by design! I believe it is an Access bug!

Mourad

On Oct 23, 3:50*pm, Mourad wrote:
Thank you all,

It was found that the underlying query of the form has a column with
the same name, CurrentUser! It seems that Access refers to this one
when CurrentUser() function is called! So when the query returns no
rows, CurrentUser() returns NULL, but if there is one or more rows, it
returns a contents of some row (didn't verify which)

I doubt this is by design! I believe it is an Access bug!

Mourad

When we preface a function with the Class of which it is a member
Access can often differentiate between objects with the same name.
Otherwise it uses the first one it comes to as it searches through all
the classes and pointers currently in scope; I believe this search is
ordered descending on creation time.
You may be able to help Access/VBA understand what you want with
Access.CurrentUser() or Application.CurrentUser(); this syntax will
tell Access/VBA where to look.
I often use VBA.Date() as, despite many warnings that the sky will
fall I like to call my Date fields, "Date", unless I call them
"Redhead" but that is another story. Works swimmingly!
There's no bug here. Access is not Aladdin's lamp. It cannot magically
decide which CurrentUser you want.
BTW, I recall only one genuine bug posted here in CDMA, (many years
ago).