Public functions and changed option group names not working 1

[Gastrifitis]

I have a computer running Access XP. It works fine. There is another computer that also runs Access XP that I need to bring around to accomplishing the tasks I can do with my computer. But the second computer is a monster. It refuses to recognize publicly declared functions when I call them, always returning the Name error. This other computer will recognize the value an option group returns, but only if I leave the default name of the option group, like Frame12, alone. If I change the default name to something else that I can recognize and use, it stops working. I try using the new name in macros, code, and SQL, and the referrence never goes through. It took me days just to figure out that this is where the problem occured.

I know it's possible for Access to work the way I expect it to, since I already have these things up and running on my computer. Both Access files are working with ANSI92. The only difference I can see between the two computers is mine is running Windows 2000, and the other one is running Windows XP. Could this cause the problem, or is there something I missed?

 

[psemianonymous]

Could be a references issue. On the 'non-working' Access XP computer, hit CTRL-G (will bring up VB environment), Tools->References and see if there is anything missing. References issues are unfortunately common.


Other than that, I'm stumped.

 

[Gastrifitis]

Well, I checked it out, and I still don't think I have the answer. On both computers we have Visual Basic for Applications, Microsoft Access 10.0 Object Library, and OLE Automation checked. On my computer (the one that works) I also have Microsoft ActiveX Data Objects 2.1 Library.

On the computer that's not working right, it has the 2.5 Library instead. It also has Microsoft Office XP Web Components checked. Web components don't actually interfere with other references, do they? And would reverting to an earlier ActiveX Library be considered helpful?

 

[psemianonymous]

I don't know specifically--I was hoping you'd see something more obvious, like a "MISSING: " reference. If there isn't a MISSING reference, then my theory is shot.


To attempt to answer your question: Web components--probably no interference. Reverting your ADO library version: I honestly don't know.


Sorry.


Pete

 

[vbajock]

Have you applied Service Pack 3 to the XP machine? This has all the XP fixes. If haven't your going to have bugs.

 

[vbajock]

Also, are these machines on a network and are they accessing remote tables? If your using linked tables your links may be out of whack on the XP machine. That would explain a NAME? error.

 

[Gastrifitis]

SP3 is for Office 2000, not XP. At least, that's what Microsoft's site is telling me. I'm not sure if one of the service packs is an equivalent for XP, but that's a fun part too.

The computer in question is a secure station. No network or internet connection, and they even yanked the floppy drive. Fun, huh?

 

[vbajock]

Sorry, I misread your post - if you are using Office XP, sp2 is here:

http://www.microsoft.com/office/ork/xp/journ/Oxpsp2a.htm

If I were you, I would create a blank database on the XP machine and import all the objects from a good mdb into it. I would then open a code module and run a compile to see if it pops any errors. I've got hundreds of PC's in all kinds of operating systems running Access apps and haven't seen the kind of errors you are describing, so I suspect you've got a corruption issue.
"It refuses to recognize publicly declared functions when I call them, always returning the Name error" - can you elaborate on that? Where is the function, in the control source of the text box or in code somewhere? Can you post the function?

 

[Gastrifitis]

Thanks for all the advice, I'll see what compiling does. Since I'm currently in the process of setting up the app, I haven't done it yet. The code I'm testing the problem on is short enough, it is based on the fact that the company works on an 8-week cycle for part of its work. So the function takes a date and returns the week number for that date. It looks like this:

Public Function GetCustWeek(CurrentWeek As Date) As Byte
    Dim intX As Integer
    intX = Int((CurrentWeek - #11/30/2003#) / 7)
    GetCustWeek = intX + 1 - 8 * Int(intX / 8)
End Function

This is short enough that I could spell it out long hand in a calculated field. But that's a pain, since I need the code in different places, and it won't help for longer, more complicated code elsewhere. The code seems to work like it's supposed to on my machine, returns good old name error on the one where I need it.

 

[vbajock]

Ok, so we have compile errors covered, next modify your function as shown to see if you can pop a runtime

Public Function GetCustWeek(CurrentWeek As Date) As Byte
====>ON ERROR GOTO err_h

Dim intX As Integer
intX = Int((CurrentWeek - #11/30/2003#) / 7)

instead try:
intX = Int((format(CurrentWeek,"SHORT DATE&quot- #11/30/2003#) / 7)



GetCustWeek = intX + 1 - 8 * Int(intX / 8)
====>Exit Function

====>err_h:
====>Msgbox Error$
End Function
Also, if you are declaring your return value as byte so you can return a true/false value, you might want to try changing it to Boolean

 

[Gastrifitis]

OK, I solved the problem. I found a thread on a different forum where someone had a problem that sounded similar to mine. What they did was make a new user account, not admin, and log on and run Access. The only reason I can see why that would make a difference is that you briefly get that "preparing to install" dialog box on the screen when Access runs. But everything works fine now. I hate it what head-scratching problems get solved with what amounts to a Zen shrug, but whadya gonna do?