468,247 Members | 1,324 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,247 developers. It's quick & easy.

Null Values or Wierd Behavior based on a user's profile

I need some help. Here is a little background, I support a MS Access 2k
DB (SQL Server 2k backend) that has courses and students. The problem
form lets the user pick a course from a drop down and opens a report of
the students attending the course in the dropdown. A user can't view on
1 course in the dropdown list. He can view other courses but not this
one. Other users on other computers can view the course just fine.
Furthermore, I was able to view the course when I logged into his
computer. (FYI all users are using the same mdb from a network file
share.) I set a breakpoint in the code behind and the id the course
record in the combo box is returning a null but for others it isn't and
opens the report just fine. I opened the query for the combo box and
the problem course isn't returning a null value in any of it's columns.

I think is must have something to do with this user's profile in MS
Office or Access 2000. Is there some setting or bug in MS Access that
can make Nulls return erroneously or just cause crazy behavior? Thanks
in advance for any help.

Nov 13 '05 #1
2 1547
everyone is using the same database on the network share? Ooooh...
dont do that. split and distribute the front end. You're asking for
trouble.

Tools->Split Database.
Put the Backend on the server (will be suffixed with _BE usually)
then distribute the front end. And move all the static tables to the
front end.

Nov 13 '05 #2
Selecting based on a combo box can be problematic, but
I've never seen it associated with a user profile before.

The normal problem is that combo boxes sometimes return
garbage values. You can sometimes see this by doing a
copy and paste: from a cbo with this problem, you will
copy a garbage value. The garbage value is the same
that a query will see, so of course it won't match correctly.

There are several theories about why this might be
so: it might also be confused by the problems parameter
queries sometimes have with field type in A2K.

In my case, I solved my problem by changing the
CBO data source so that it did not need to use
"DISTINCT" (unique values/unique records).

(david)

<gi*****@medsch.ucsf.edu> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
I need some help. Here is a little background, I support a MS Access 2k
DB (SQL Server 2k backend) that has courses and students. The problem
form lets the user pick a course from a drop down and opens a report of
the students attending the course in the dropdown. A user can't view on
1 course in the dropdown list. He can view other courses but not this
one. Other users on other computers can view the course just fine.
Furthermore, I was able to view the course when I logged into his
computer. (FYI all users are using the same mdb from a network file
share.) I set a breakpoint in the code behind and the id the course
record in the combo box is returning a null but for others it isn't and
opens the report just fine. I opened the query for the combo box and
the problem course isn't returning a null value in any of it's columns.

I think is must have something to do with this user's profile in MS
Office or Access 2000. Is there some setting or bug in MS Access that
can make Nulls return erroneously or just cause crazy behavior? Thanks
in advance for any help.

Nov 13 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by dmcconkey | last post: by
102 posts views Thread by junky_fellow | last post: by
99 posts views Thread by Mikhail Teterin | last post: by
9 posts views Thread by Eric Falsken | last post: by
1 post views Thread by ashish | last post: by
1 post views Thread by kpg* | last post: by
1 post views Thread by shapper | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kermitthefrogpy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.