Format() and Command() causing compile errors in Access 97

I have many databases that use the format() and command() functions for various common purposes...for instance format for creating error/activity logs and I use command along with the /cmd switch to send my database into developer mode.

I've been using these for some time now without any problems, but recently one computer has given me fits.  Everytime I try to run one of my apps on her computer I get a lot of compile errors.  She had a full version of Access 97, so I tried running it with Access Runtime.  Same problems.  Any ideas?

Urgency is kinda high on this one.  I would like to have this fixed before my user returns from her vacation....thus the 500 points.
holleringAsked:
Who is Participating?
 
Arthur_WoodCommented:
are you using Common Controls 6 in your app?  If not,then it is not needed at all, and you can simply unselect the entry, and click ok.  I don't know if Common Controls 6 is compatible with Win 98 (which begs the question- why are they still on Win 98, which is now an unsupported OI/S from MS???) - YOu might suggest that they should seriously consider upgrading their O/S to something newer.

AW
0
 
phileocaCommented:
see if you have any missing references
0
 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
Define 'command()' function.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
GreymanMSCCommented:
Jimhorn, VBA.Interaction.Command() is the function used to return the command line arguments used to open the application session.
 
This., along with VBA.Strings.Format(...), should be available from the Visual Basic For Applications library, which is a a non-dereferencable reference.   However, as phileoca mentions, you should check to see if any other references may be missing,  hollering.  These often cause the compiler to be "tripped up" when trying to determine the scope of library functions.
 
You could also try using explicit scope referencing instead of implicit to avoid this problem.  That is, VBA.Interaction.Command() rather than just Command().
 
Another possibility might simply be a version issue on the problem machine.  Ensure that it has the latest installation of the VBA library files.  These are usually located in subdirectories of C:\Program Files\Microsoft Shared\VBA\.
0
 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
Learn something new every day.  So is it possible to shell open an Access app, with command-line arguments, and then in Access' startup code use VBA.Interaction.Command() to read the command-line arguments?

(I had an EE question on that a week ago...)
0
 
Arthur_WoodCommented:
yes, jim that is precisely what thew Command() function does.  It returns, as its value, whatever was on the command line, AFTER the identifier of the executable

Access.Exe CommandString

will result in CommandString to be returned as the value of Command() { or Command$} in the Open Event of the StartUp form of the APP.  look up Command$ in the Access online Help system.

AW
0
 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
Thanks for the explanation.  I will remember that one...
0
 
holleringAuthor Commented:
Yeah this is extremely handy. Using command() I've been successfully able to lock up my apps good and tight, with no shift bypass key and all custom menus.  Then when I want to work in the database, I have a database maintenance interface that uses shell to open the databases with "/cmd devmode" attached to the end...which tells my opening form to cancel and reenable everything. Then it shuts down the database and reopens it with "/cmd postdevmode" which restores all the lock-down settings (which don't get applied until the next time the database is opened).  So it has similar effects to the shift bypass key...only my users don't know about it.  They have a habit of trying to go behind the scenes to manipulate data directly rather than telling me that they need a certain functionality built in.  

That said, I checked references.  There is a reference missing to mscomctl.ocx..."Microsoft Windows Common Controls 6"...however, I was unable to find this file on the client computer, who is running Win 98 (I develop in Win 2k).  Is it safe to distribute the ocx with the database?  It's just a plug-in right?  Please advise.
0
 
holleringAuthor Commented:
We are slowly migrating users to XP as their machines are upgraded...at a rate of about one every two weeks.  For now it is a necessary evil to have 3 different operating systems among the user base.  

In reply to your suggestion.  I dereferenced Common Controls and it compiled fine on my machine.  I'm heading over to see if the client's computer does better now that the unnecessary reference has been removed.
0
 
holleringAuthor Commented:
Well...that worked...sort of.  The user I was having trouble with has both Access 97 and the Access 97 runtime installed.  The runtime worked once I removed the reference to mscomctl.  The full version gave me an error when it started up saying that it could not find the VBA dll.  So everything should be fine once I reinstall Access.  Worst case scenario...the user gets stuck using runtime, which will work fine anyway.

I'm a little bent over the point scenario.  Arthur, your post was a direct answer to my question, but it came after phileoca made the suggestion to check references.  I'm going to split up the points.  Thanks to all of you for helping!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.