#name ocurring on clients PC but not the development PCs

[stevehaley]

I am suddenly getting problems with an application generating #Name?
errors in some forms on the clients desktop but not on any of my
development PCs.
The errors all occur in text boxs on various forms & subforms with
formulas in them
eg
=parent!txtosver
="Primary " & LCase(Forms!Masterform!geotypetxt)

These are working fine on my boxes which have Access 2003 patched to
SP3 (bld 8166) but not on the clients version of 2003 - currently
trying to get a build no for these.

Anyone have any ideas - I really dont want to have to recode all these
forms

Many Thanks
Stephen

 

[Douglas J. Steele]

Any time an application works on one machine but not on another (or
previously worked on one machine but stops working on that machine), the
first thing to check is whether the References collection is messed up.

References problems can be caused by differences in either the location or
file version of certain files between the machine where the application was
developed, and where it's being run (or the file missing completely from the
target machine). Such differences are common when new software is installed.

On the machine(s) where it's not working, open any code module (or open the
Debug Window, using Ctrl-G, provided you haven't selected the "keep debug
window on top" option). Select Tools | References from the menu bar. Examine
all of the selected references.

If any of the selected references have "MISSING:" in front of them, unselect
them, and back out of the dialog. If you really need the reference(s) you
just unselected (you can tell by doing a Compile All Modules), go back in
and reselect them.

If none have "MISSING:", select an additional reference at random, back out
of the dialog, then go back in and unselect the reference you just added. If
that doesn't solve the problem, try to unselect as many of the selected
references as you can (Access may not let you unselect them all), back out
of the dialog, then go back in and reselect the references you just
unselected. (NOTE: write down what the references are before you delete
them, because they'll be in a different order when you go back in)

For far more than you could ever want to know about this problem, check out
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html, or check my
December, 2003 "Access Answers" column in Pinnacle Publication's "Smart
Access" (you can download the column, and sample database, for free at
http://www.accessmvp.com/DJSteele/SmartAccess.html)

 

[stevehaley]

Thanks for the reply but I have a reasonably sophisticated system for
automatic checking of dll & com addins and those were all identical
with the exception of MDAC where vista was using a much newer version
(6 vs 2.8). I also have a debug dump that puts all the dll/add-in/App
vers/environment/system variables etc etc into a text file that helps
with remote debugging and again all the info was largely identical the
main exception being that the client was on build 6566 which is sp2 I
think as opposed to my sp3 (8166).

Problem went away when the client applied latest service patches so it
was an Access Build bug/incompatablility by the look of it.
Not sure why it suddenly raised its head but suspect it may be
something to do with a recent patch to my PC as the client doesnt keep
their patches up to date and certainly hadnt changed theirs recently.

rgds
Stephen

 

[Douglas J. Steele]

Glad you got it working.

You might want to add in code that loops through the References collection
and determines whether there are any problems.