Functions lost with MDE

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

A database created in Access 2000 has a query using the TRIM function. An
MDE is created and ported to an XP environment running Access 2002. The
query fails with "Function not available in expressions in query expression".
However, the mdb file ported to the same environment works fine. I think it
has to do with a missing reference. However, with an MDE I can't open a
module to get to the References menu item. How do I fix this?
 
The simple solution was to convert the 2000 front end mdb to 2002 on the 2002
machine and then create the MDE. It works with the 2000 BE MDE's (there is
just a small amount of code in the BE's to protect). The application is
created in the lowest common denominator (Access 2000) and then deployed out.
I don't always have access to a machine with 2002 installed so I'm looking
for a solution where I don't have to have multiple versions of the front end
MDE. Does anyone know if I will have another problem with machines
containing Access 2003 and have to have 3 versions of the front end MDE?
 
Hi Terry,

First, make sure that you are not including any references unless they are
absolutely required. I have personally seen databases with lots of checked
references that were not required. In one extreme case, a database I helped
another individual with had over 30 checked references! This person's
database only required 3 references in order for the code to compile.

Do you have any version specific references, such as the "Microsoft Excel
9.0 Object Library" or the "Microsoft Outlook 9.0 Object Library"? If so,
try converting early bound code into late bound code, so that you do not need
to include the checked reference.

Try using the References Wizard to document the full path of each required
reference on the PC with Access 2000, which you consider the lowest common
denominator. Then try to ensure that the same files are placed in exactly the
same locations on the other PC's. You may need to re-register a .DLL file if
you move it.

http://www.mvps.org/access/modules/mdl0022.htm

If my answer has helped you, please answer yes to the question that reads
"Did this post answer the question?" at the bottom of the message thread.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

The simple solution was to convert the 2000 front end mdb to 2002 on the 2002
machine and then create the MDE. It works with the 2000 BE MDE's (there is
just a small amount of code in the BE's to protect). The application is
created in the lowest common denominator (Access 2000) and then deployed out.
I don't always have access to a machine with 2002 installed so I'm looking
for a solution where I don't have to have multiple versions of the front end
MDE. Does anyone know if I will have another problem with machines
containing Access 2003 and have to have 3 versions of the front end MDE?
 
Thanks for the suggestions. I'll try them to see if they solve the problem.
Not too keen on re-registering DLL's since I want to keep the deployment as
simple as possible. Since the error is in the TRIM function, I believe the
problem is in one of the main VB libraries that is somehow "frozen" when the
Access 2000 MDE is created but "resets" itself when the Access 2000 MDB file
is ported to environment running Access 2002.
 
Hi Terry,
Since the error is in the TRIM function....
Apparently the TRIM function is the first one encountered in your code. I
willing to bet that if your code used the LEFT or MID function first, or just
about any other VBA function that you would encounter an error on that
function instead.

Have you seen these two articles that deal with references?

Solving Problems with Library References (Allen Browne)
http://allenbrowne.com/ser-38.html

Access Reference Problems (Doug Steele)
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

It's been a while since I've looked at either one of these articles,
although I frequently give these links in my answers to others. Doug's
article includes a procedure for determining the path of all checked
references programmatically. He mentions to check that the version is the
same. I missed including that piece of advice in my initial reply (although I
hinted at it with the version specific references).
Not too keen on re-registering DLL's since I want to keep the deployment
as simple as possible.
Doug's article also includes instructions, at the end of the article, for
how to use REGSVR32.EXE to reregister a file. You should only need to do this
one time on each machine that is currently presenting a problem. You're not
talking hundreds of PC's are you?


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

Thanks for the suggestions. I'll try them to see if they solve the problem.
Not too keen on re-registering DLL's since I want to keep the deployment as
simple as possible. Since the error is in the TRIM function, I believe the
problem is in one of the main VB libraries that is somehow "frozen" when the
Access 2000 MDE is created but "resets" itself when the Access 2000 MDB file
is ported to environment running Access 2002.
__________________________________________

:

Hi Terry,

First, make sure that you are not including any references unless they are
absolutely required. I have personally seen databases with lots of checked
references that were not required. In one extreme case, a database I helped
another individual with had over 30 checked references! This person's
database only required 3 references in order for the code to compile.

Do you have any version specific references, such as the "Microsoft Excel
9.0 Object Library" or the "Microsoft Outlook 9.0 Object Library"? If so,
try converting early bound code into late bound code, so that you do not need
to include the checked reference.

Try using the References Wizard to document the full path of each required
reference on the PC with Access 2000, which you consider the lowest common
denominator. Then try to ensure that the same files are placed in exactly the
same locations on the other PC's. You may need to re-register a .DLL file if
you move it.

http://www.mvps.org/access/modules/mdl0022.htm

If my answer has helped you, please answer yes to the question that reads
"Did this post answer the question?" at the bottom of the message thread.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

The simple solution was to convert the 2000 front end mdb to 2002 on the 2002
machine and then create the MDE. It works with the 2000 BE MDE's (there is
just a small amount of code in the BE's to protect). The application is
created in the lowest common denominator (Access 2000) and then deployed out.
I don't always have access to a machine with 2002 installed so I'm looking
for a solution where I don't have to have multiple versions of the front end
MDE. Does anyone know if I will have another problem with machines
containing Access 2003 and have to have 3 versions of the front end MDE?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top