A2k lookup field corrupt on some machines

[Alex]

Hello,
Hoping someone can help because haven't been able to find info online,
and it's driving me crazy, and please bear with me thru the background
info, as I'm trying to cover as much background info as possible.

An access table was setup so that everyone (5 or 6 users) was opening the
same mdb, via a shared folder on a server, and they had 2003 on their
machines but were connecting to and opening an A2k mdb file.
The problem started with 1 machine and spread to 1 other, but had not
affected all others, yet.

The problem was that users would open a table, and there was a
lookup/dropdown, with a query string to another table, pulling approx 4
or 5 fields. One day the bound field was just blank. The other fields
and all other data in the db shows up fine, but just not this one field.
The field is there, but it's blank.

I did a repair, but no effect. I loaded 2003 on the server, ran the
latest Jet update, created a blank mdb and turned off things like auto
correct, etc. and imported all of the objects. I didn't split the db, per
say, but I went to the client machines and created a blank db, turned off
the reccomended default settings, and imported all of the queries and
reports, and linked the tables.

The client machines with the corrupt or missing lookup still showed the
same problem. Instead of a query string, I created a query and changed
the order of the fields, and pointed the lookup at this query - this time
the field did not even show up, in the dropdown fields

Again, some machines are fine, but the machines with the original problem
still exhibited this problem.

Is there any info stored in cache on the client? should I delete the
page.file?

Should I have actually split the db, or was creating a new mdb and
brining everything in, and linking the tables the same? I didn't split
it because I wanted to turn off the default settings, and thought that
importing everything and linking would have the same effect.

Has anyone every seen or heard of such a persistent problem?

Any help or info greatly appreciated.
Thanks,
Ax

 

[Allen Browne]

What you are describing sounds like a known problem with Access 2003 Service
Pack 3. Details:
http://allenbrowne.com/bug-Access2003SP3.html

As the article explains, you will want to download this fix from Microsoft:
http://support.microsoft.com/kb/945674

If different users are opening the database at the same time, you may want
to consider splitting it so everyone has their own separate front end, but
tehy link to the same shared data. If that's a new concept, see:
http://allenbrowne.com/ser-01.html

 

[Ax]

Hello Allen,
Thank you for the link. As for each having own front end, I mentioned I
did not split the db, per se, but rather created a blank db and imported
queries and reports, and then linked the tables to the main mdb, on the
server, and gave each client a copy of this "manual" front end - will
this not suffice? Is there a difference between this and the access
created split db or front end?

Also, the really really perplexing thing is why some clients show this
behaviour and others don't, even after the changes. Is something held in
cache somewhere, on the client?

Thanks,
Ax

 

[Allen Browne]

When you created the blank db, linked the tables, and imported the other
objects, you gave each user a separate copy of this front end? If so, the
result is the same as splitting using the Wizard. (In fact, that's the way I
do it rather than use the wiz.)

I'm guessing that the A2003 SP3 machines are the ones that have the problem.
The A2000 users the A2003 users who are on previous service packs probably
don't exhibit the issue.

 

[Ax]

Hello Allen,
Yes for the manual split, and thanks for that tip, too (manual vs. wiz)!

All clients are 2003, but they were connecting to and sharing the same
Access 2000 mdb.

The 2003 clients didn't see this problem right away: 1 showed it with one
table, then a week later the second client showed it with the same table,
then the first client had a problem with another table, and then that's
when I created and gave each their own client, and upgraded the main mdb
to 2003. Now I'll go back and do the hotfix.

But the really strange part is that I changed the lookup query string to
use a query, but rearranged the columns for the the output, but the
corrupt clients now don't show that blank lookup field, at all...which
makes me think the corruption maybe in some sort of cache or temp file in
the client? Just for my own curiosity I may try a scan of the hard drive
using something like win-hex - using different strings to search
for...maybe useless but it'd be interesting to see if anything turns up.

Thanks, again!
Ax

 

[Allen Browne]

There's another valid reason why a combo might display as blank, even though
there is a value in the underlying field.

Say a combo has 2 columns: ClientID and ClientName.
ClientID is zero-width, so it shows the client name.
Now you set the RowSource to:
SELECT ClientID, ClientName
FROM tblClient
WHERE (tblClient.Inactive = False);

Now consider a row where the ClientID is an inactive record. In this case,
the ClientName is not in the RowSource query (because of the WHERE clause.)
So there is nothing for Access to display, even though there is a valid
ClientID.

Is that kind of thing possible in your database?

 

[Ax]

Hello Allen,
I don't think this is possible, as the query is just a straight "select
x, y, z from abc"

As well, data is returned in that column, by the clients who were not
"bitten by the bug" and still continue to show the info in that column,
even with my new client mdb - it's just that the clients who suddenly
lost showing that info, continue to not show it. I will apply the hotfix
and let you know if it reappears, but it's just so strange...

Thanks, again!
Ax