Strange problem loosing data based on physical machine

[E]

I have encountered a very strange problem that is hard to describe, but
hope someone has run across it.

I have a form that shows a number of columns from a single table in the
upper portion of the form in a datasheet layout. The user can then
choose a category from a dropdown list, and based on that category will
see further data in the bottom part of the screen. They can choose one
of 2 categories, but both show data FROM THE SAME TABLE FOR THE SAME
ROW - just different columns based on the category.

This is treated as a parent child relationship in a form-subform
arrangement, but in reality the data is in the same row. The link
between the "parent" and "child" is built using VBA in a load module
and works fine most of the time.

Here is my problem:

On a computer for one of my users, when they choose the category, no
data is displayed in the subform. It doesn't matter who is logged in
to that computer, it never shows the data in the subform. It's like it
can't find the related record to display the child information and in
fact the keys are empty - but they shouldn't be because it is the same
record that currently has focus on the master form. It can't be a
programming error because the application works fine on 3 other
computers that it is installed on. All machines are XP machines
running Access 2003. The application has a UI MDB and a back end DB
which resides on the network. It uses an MDW file for security.

I am at a total loss - any ideas anyone?

Eric

[Keith Wilby]

"E" <ej*****@telusplanet.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I have encountered a very strange problem that is hard to describe, but
hope someone has run across it.

running Access 2003. The application has a UI MDB and a back end DB
which resides on the network. It uses an MDW file for security.

It's my guess that user-level security hasn't been implemented correctly and
that, on the other machines, the default "system.mdw" workgroup file has
been modified but on the problem machine it hasn't. This scenario would
make it possible for the users group to have permissions to all objects on
the modified machines but not on the problem one.

Then again I could be completely wrong but it's worth checking.

Regards,
Keith.
www.keithwilby.com

[E]

Thanks Keith for the pointer. The application uses a custom MDW and
that is specified in the shortcut used to launch the application. The
custom MDW is on the network with the backend mdb. Would the
default.mdw still be an issue somehow?

[Steve]

I don't know anything about .mdw files, but couldn't you just
rename/remove the default.mdw? Then you could run your database and
eliminate this conflict as a possibility. If the same problem exists,
you can just move your default.mdw back to where it is now.

[salad]

E wrote:

I have encountered a very strange problem that is hard to describe, but
hope someone has run across it.

I have a form that shows a number of columns from a single table in the
upper portion of the form in a datasheet layout. The user can then
choose a category from a dropdown list, and based on that category will
see further data in the bottom part of the screen. They can choose one
of 2 categories, but both show data FROM THE SAME TABLE FOR THE SAME
ROW - just different columns based on the category.

This is treated as a parent child relationship in a form-subform
arrangement, but in reality the data is in the same row. The link
between the "parent" and "child" is built using VBA in a load module
and works fine most of the time.

Here is my problem:

On a computer for one of my users, when they choose the category, no
data is displayed in the subform. It doesn't matter who is logged in
to that computer, it never shows the data in the subform. It's like it
can't find the related record to display the child information and in
fact the keys are empty - but they shouldn't be because it is the same
record that currently has focus on the master form. It can't be a
programming error because the application works fine on 3 other
computers that it is installed on. All machines are XP machines
running Access 2003. The application has a UI MDB and a back end DB
which resides on the network. It uses an MDW file for security.

I am at a total loss - any ideas anyone?

Eric

On thing you might try, besides the other comments if that doesn't help,
is to open the form in design mode on that users' machine and copy the
SQL code for the recordsource to your clipboard. Then create a new
query, don't add tables, go to View/SQL on the menu, and paste the code
into it. Now try to run the sql. Does it run or does it give you an error?

[Keith Wilby]

"E" <ej*****@telusplanet.net> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...

Thanks Keith for the pointer. The application uses a custom MDW and
that is specified in the shortcut used to launch the application. The
custom MDW is on the network with the backend mdb. Would the
default.mdw still be an issue somehow?

As long as the shortcut is in the format

"Full path to MSACCESS.exe" "Full path to your app.mdb" /wrkgrp "Full path
to your WIF.mdw"

then the default system .mdw shouldn't enter into it. Could it be a drive
(letter) mapping issue?

Keith.

[E]

Okay,

I solved this one, so I thought I would post my solution in case anyone
runs into the same problem.

Further investigation led to these 2 VBA lines of code as the lines
that stopped working:

SubData.LinkMasterFields = "txtLink, txtLink2, txtLink3"
SubData.LinkChildFields = "[Map Number], [Weld Number], [Location
Number]"

On the one computer I mentioned, they caused the sub form to not find
the related record that was in fact there. Commenting out those 2
lines had the subform bring back all records with no filtering criteria
as you would expect.

Looking at the way this application was developed (don't you love
maintaining someone else's code?) the subform was not in fact a "True"
subform. There was no subform object on the main form. What happened
was custom VBA code was written to execute when the user chose a
category and then create those links above, then open another form and
resize the main form so you could see the new one below. The point is,
I could not just set the LinkChildFields and LinkMasterFields in the
design view, cause it was all done at runtime.

I knew this code worked on other machines, so I didn't want to
redevelop the application to have an actual subform, so I checked
version numbers. The machine where it did not work had Access 2003
version 11.5614.5606. One of the machines where is did work had
version 11.6355.6408 SP1. So I updated them both to SP2 and voila! -
problem went away. Guess I should have checked version numbers first
thing. Would have saved myself 2 hours of grief. Makes me mad though
that it worked in Access 2000, then not in older versions of 2003, but
again in newer 2003.

Eric

[salad]

E wrote:

Okay,

I solved this one, so I thought I would post my solution in case anyone
runs into the same problem.

Further investigation led to these 2 VBA lines of code as the lines
that stopped working:

SubData.LinkMasterFields = "txtLink, txtLink2, txtLink3"
SubData.LinkChildFields = "[Map Number], [Weld Number], [Location
Number]"

On the one computer I mentioned, they caused the sub form to not find
the related record that was in fact there. Commenting out those 2
lines had the subform bring back all records with no filtering criteria
as you would expect.

Looking at the way this application was developed (don't you love
maintaining someone else's code?) the subform was not in fact a "True"
subform. There was no subform object on the main form. What happened
was custom VBA code was written to execute when the user chose a
category and then create those links above, then open another form and
resize the main form so you could see the new one below. The point is,
I could not just set the LinkChildFields and LinkMasterFields in the
design view, cause it was all done at runtime.

I knew this code worked on other machines, so I didn't want to
redevelop the application to have an actual subform, so I checked
version numbers. The machine where it did not work had Access 2003
version 11.5614.5606. One of the machines where is did work had
version 11.6355.6408 SP1. So I updated them both to SP2 and voila! -
problem went away. Guess I should have checked version numbers first
thing. Would have saved myself 2 hours of grief. Makes me mad though
that it worked in Access 2000, then not in older versions of 2003, but
again in newer 2003.

Eric

Thanks for sharing your solution.