executing code on access forms on different pc's

[Patrick]

We have several access databases that we used without any problems for years.
All databases are in access2003 format and have forms with VB code behind it.

recently we are getting new PC's that cannot execute the forms in (MDE
version) databases. It reports missing references. Opening the MDB version is
no problem but then it cannot be opened on the older PC's anymore. Both old
and new PC's have Office 2003 installed and are running XPSP2. The missing
references are 3 files:
Comct232.ocx
Comdlg32.ocx
mscomct2.ocx

Does anyone know where these files come from? Could they belong to office97?
All old PC's migrated from office97 to 2003.

It's strange that running the same software on same platform can case this
behaviour.

Patrick Delisse

 

[Douglas J. Steele]

We have several access databases that we used without any problems for
years.
All databases are in access2003 format and have forms with VB code behind
it.

recently we are getting new PC's that cannot execute the forms in (MDE
version) databases. It reports missing references. Opening the MDB version
is
no problem but then it cannot be opened on the older PC's anymore. Both
old
and new PC's have Office 2003 installed and are running XPSP2. The missing
references are 3 files:
Comct232.ocx
Comdlg32.ocx
mscomct2.ocx

Does anyone know where these files come from? Could they belong to
office97?
All old PC's migrated from office97 to 2003.

It's strange that running the same software on same platform can case this
behaviour.

Actually, it's not that surprising. Whoever developed the application chose
to use references over and above the basic ones associated with Access.
Whenever you do that, you run the risk of incurring problems with the
References collection, as you are. The probability of problems increases
significantly if differently software gets installed.

The three controls you mention are actually part of the operating system,
although you technically need a Developer product (VB, Office Developer or
something else) in order to add them to an application.

Are you saying that opening the MDBs on the new machines works? If so,
simply create new versions of the MDEs. Your application should be split
into a front-end (containing the queries, forms, reports, macros and
modules), linked to a back-end (containing the tables and relationships).
Only the back-end should be on the server: each user should have his/her own
copy of the front-end, ideally on his/her hard drive. In that way, you
simply have to ensure that each user has whichever version of the front-end
works for his/her machine.

 

[Patrick]

Actually, it's not that surprising. Whoever developed the application chose
to use references over and above the basic ones associated with Access.
Whenever you do that, you run the risk of incurring problems with the
References collection, as you are. The probability of problems increases
significantly if differently software gets installed.

The three controls you mention are actually part of the operating system,
although you technically need a Developer product (VB, Office Developer or
something else) in order to add them to an application.

Are you saying that opening the MDBs on the new machines works? If so,
simply create new versions of the MDEs. Your application should be split
into a front-end (containing the queries, forms, reports, macros and
modules), linked to a back-end (containing the tables and relationships).
Only the back-end should be on the server: each user should have his/her own
copy of the front-end, ideally on his/her hard drive. In that way, you
simply have to ensure that each user has whichever version of the front-end
works for his/her machine.

Doug,
Thanks for the quick reply.
The databases where build by me years ago and are used on a daily basis.
With the migration from access 97 to 2003 we had no problems.
The databases are set-up as you indicated, with a front-end and a back-end
part.
Both front-end and back-end are on the server. This way I can update the
front-end MDE and don't have to bother with getting the new front-end version
distributed to the users (approx. 65 PC's)
Is there a way to analyze what control/command uses witch reference?
Because all of the commands are as far I can tell basic access functions. I
might be able to get rid of all non-access references.

Patrick Delisse
DutchAero

 

[Douglas J. Steele]

If you have the MDB, you can try removing the three references and then
compiling to see what code breaks.

Your logic, though, for having the front-end on the server is faulty.
Sharing a front-end database is a good way to cause corruption. You also
cause significantly more network traffic if the front-end is on the server.

Take a look at the free Auto FE Updater Tony Toews has at
http://www.granite.ab.ca/access/autofe.htm That provides you with a way to
ensure that each user has a copy of the current front-end in place on
his/her hard drive.

 

[Patrick]

Thanks,
That helped. Found out that the references where not used at all !!!
For the front-end to local I used the method descibed in
http://www.databasejournal.com/features/msaccess/article.php/3286111
Got a few done now and it's looking good.

Patrick Delisse