I have an FE/BE app that works fine on all PC's & a terminal server (a
mixture of Access and Access runtime) when run as an MDB, but but fails on
two PC's when distributed as an MDE. If I distribute it as an MDB and compile
to MDE on the workstation, the MDE works fine, though. My dev workstation is
Access 2003 (Office Pro with VB Tools), and at least one of the workstations
on which it fails is Access 2002 (full version). Here is the error:

The expression you entered has a function name that <my app name> can't find.

How can I locate this? I have error-trapping in every procedure on every
form, and this message is an indication that the error is not being trapped.

I have this startup methodology that provides a little more flexibility than
using startup options to open a form:

AutoExec Macro: RunCode - Function Startup()

The Startup function is in a standalone module (i.e. not behind a form)

Function Startup()
DataFileName = DFirst("[DataFileName]", "[Version]")
DemoVersion = False
DemoLength = 30
DoCmd.OpenForm "Login"
End Function

The three variables, DataFileName, DemoVersion, and DemoLength are all
public variables declared (one in in this module and the other two in another
module).

I do have a host of other functions in my app, but this is the most likely
candidate because, although my login form does call a couple of other
functions from other modules, this is the first one that runs on startup.

Any ideas? Or at least how to isolate the issue and why it would occur only
in the MDE?

It probably is a reference issue. 2003 uses 11.0 libraries and 2002 uses 10.0
One the offending machine, install the mbd open VBA editor, check Tools,
References. See if any are missing.

Here is a site that may be useful:
http://support.microsoft.com/default...b;en-us;283115

Also, you did not say where the error occured. Have you tried stepping
through in Debug mode to see if you can tell where it fails?

Looking at you Startup function, the first thing I see is a DFirst domain
aggregate function. I am not sure, but I think it is in the DAO library. It
is 3.6 for both Access versions, but I would check the offending Pc's to be
sure they have that DLL and it is in the path specified in the references.


"Brian" wrote:

> I have an FE/BE app that works fine on all PC's & a terminal server (a
> mixture of Access and Access runtime) when run as an MDB, but but fails on
> two PC's when distributed as an MDE. If I distribute it as an MDB and compile
> to MDE on the workstation, the MDE works fine, though. My dev workstation is
> Access 2003 (Office Pro with VB Tools), and at least one of the workstations
> on which it fails is Access 2002 (full version). Here is the error:
>
> The expression you entered has a function name that <my app name> can't find.
>
> How can I locate this? I have error-trapping in every procedure on every
> form, and this message is an indication that the error is not being trapped.
>
> I have this startup methodology that provides a little more flexibility than
> using startup options to open a form:
>
> AutoExec Macro: RunCode - Function Startup()
>
> The Startup function is in a standalone module (i.e. not behind a form)
>
> Function Startup()
> DataFileName = DFirst("[DataFileName]", "[Version]")
> DemoVersion = False
> DemoLength = 30
> DoCmd.OpenForm "Login"
> End Function
>
> The three variables, DataFileName, DemoVersion, and DemoLength are all
> public variables declared (one in in this module and the other two in another
> module).
>
> I do have a host of other functions in my app, but this is the most likely
> candidate because, although my login form does call a couple of other
> functions from other modules, this is the first one that runs on startup.
>
> Any ideas? Or at least how to isolate the issue and why it would occur only
> in the MDE?

Pardon my ignorance here, but shouldn't the MDB use the same references? Does
something happen in the MDE compilation process that disallows the XP machine
to use its own references as it would when using the MDB?

Before I saw your reply, I thought it might be a service pack issue, so I
installed Office XP SP3, and now the MDE says the DB is in an unrecognized
format (MDB is still fine) on the affected PC. This was in XP/2003 format and
compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on the
target PC, and it is just fine.

I just checked the references on the dev & target PC's, and the DLLs are in
the correct paths. The ONLY difference is the Office 10/Office 11 path for
the MS Access 10.0/11.0 Object Library, which appears correctly on each PC
when I open the MDB. Is there a way to check the pre-compiled MDE reference
on the target PC?

Just a note on Access: it is very frustrating spending hundreds of hours
developing an app like this, only to wind up with clients saying it doesn't
work due to some Access platform issue entirely unrelated to all my hard
work...

Thanks.

"Klatuu" wrote:

> It probably is a reference issue. 2003 uses 11.0 libraries and 2002 uses 10.0
> One the offending machine, install the mbd open VBA editor, check Tools,
> References. See if any are missing.
>
> Here is a site that may be useful:
> http://support.microsoft.com/default...b;en-us;283115
>
> Also, you did not say where the error occured. Have you tried stepping
> through in Debug mode to see if you can tell where it fails?
>
> Looking at you Startup function, the first thing I see is a DFirst domain
> aggregate function. I am not sure, but I think it is in the DAO library. It
> is 3.6 for both Access versions, but I would check the offending Pc's to be
> sure they have that DLL and it is in the path specified in the references.
>
>
> "Brian" wrote:
>
> > I have an FE/BE app that works fine on all PC's & a terminal server (a
> > mixture of Access and Access runtime) when run as an MDB, but but fails on
> > two PC's when distributed as an MDE. If I distribute it as an MDB and compile
> > to MDE on the workstation, the MDE works fine, though. My dev workstation is
> > Access 2003 (Office Pro with VB Tools), and at least one of the workstations
> > on which it fails is Access 2002 (full version). Here is the error:
> >
> > The expression you entered has a function name that <my app name> can't find.
> >
> > How can I locate this? I have error-trapping in every procedure on every
> > form, and this message is an indication that the error is not being trapped.
> >
> > I have this startup methodology that provides a little more flexibility than
> > using startup options to open a form:
> >
> > AutoExec Macro: RunCode - Function Startup()
> >
> > The Startup function is in a standalone module (i.e. not behind a form)
> >
> > Function Startup()
> > DataFileName = DFirst("[DataFileName]", "[Version]")
> > DemoVersion = False
> > DemoLength = 30
> > DoCmd.OpenForm "Login"
> > End Function
> >
> > The three variables, DataFileName, DemoVersion, and DemoLength are all
> > public variables declared (one in in this module and the other two in another
> > module).
> >
> > I do have a host of other functions in my app, but this is the most likely
> > candidate because, although my login form does call a couple of other
> > functions from other modules, this is the first one that runs on startup.
> >
> > Any ideas? Or at least how to isolate the issue and why it would occur only
> > in the MDE?

I believe that the problem is that while Access is capable of handling
certain Reference changes from version to version in MDBs, it can't in MDEs.

You can use code like the following to check the references in another
database:

Sub ListReferences()
Dim appAccess As Access.Application
Dim refCurr As Reference
Dim strDatabase As String

strDatabase = "full path to database"
Set appAccess = New Access.Application
appAccess.OpenCurrentDatabase strDatabase
For Each refCurr In appAccess.References
If refCurr.IsBroken = False Then
Debug.Print refCurr.Name & _
" (" & refCurr.Major & "." & refCurr.Minor & ")"
Else
Debug.Print "Broken reference: " & refCurr.Guid
End If
Next refCurr
appAccess.CloseCurrentDatabase
Set appAccess = Nothing

End Sub


If you're distributing to customers who are running on a different platform
that you use, you really should be at least testing the application on their
platform before distributing to them. Look into something like Virtual PC or
VMWare to eliminate the need for multiple pieces of hardware.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Brian" <(E-Mail Removed)> wrote in message
news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
> Pardon my ignorance here, but shouldn't the MDB use the same references?
Does
> something happen in the MDE compilation process that disallows the XP
machine
> to use its own references as it would when using the MDB?
>
> Before I saw your reply, I thought it might be a service pack issue, so I
> installed Office XP SP3, and now the MDE says the DB is in an unrecognized
> format (MDB is still fine) on the affected PC. This was in XP/2003 format
and
> compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on the
> target PC, and it is just fine.
>
> I just checked the references on the dev & target PC's, and the DLLs are
in
> the correct paths. The ONLY difference is the Office 10/Office 11 path for
> the MS Access 10.0/11.0 Object Library, which appears correctly on each PC
> when I open the MDB. Is there a way to check the pre-compiled MDE
reference
> on the target PC?
>
> Just a note on Access: it is very frustrating spending hundreds of hours
> developing an app like this, only to wind up with clients saying it
doesn't
> work due to some Access platform issue entirely unrelated to all my hard
> work...
>
> Thanks.
>
> "Klatuu" wrote:
>
> > It probably is a reference issue. 2003 uses 11.0 libraries and 2002
uses 10.0
> > One the offending machine, install the mbd open VBA editor, check Tools,
> > References. See if any are missing.
> >
> > Here is a site that may be useful:
> > http://support.microsoft.com/default...b;en-us;283115
> >
> > Also, you did not say where the error occured. Have you tried stepping
> > through in Debug mode to see if you can tell where it fails?
> >
> > Looking at you Startup function, the first thing I see is a DFirst
domain
> > aggregate function. I am not sure, but I think it is in the DAO
library. It
> > is 3.6 for both Access versions, but I would check the offending Pc's to
be
> > sure they have that DLL and it is in the path specified in the
references.
> >
> >
> > "Brian" wrote:
> >
> > > I have an FE/BE app that works fine on all PC's & a terminal server (a
> > > mixture of Access and Access runtime) when run as an MDB, but but
fails on
> > > two PC's when distributed as an MDE. If I distribute it as an MDB and
compile
> > > to MDE on the workstation, the MDE works fine, though. My dev
workstation is
> > > Access 2003 (Office Pro with VB Tools), and at least one of the
workstations
> > > on which it fails is Access 2002 (full version). Here is the error:
> > >
> > > The expression you entered has a function name that <my app name>
can't find.
> > >
> > > How can I locate this? I have error-trapping in every procedure on
every
> > > form, and this message is an indication that the error is not being
trapped.
> > >
> > > I have this startup methodology that provides a little more
flexibility than
> > > using startup options to open a form:
> > >
> > > AutoExec Macro: RunCode - Function Startup()
> > >
> > > The Startup function is in a standalone module (i.e. not behind a
form)
> > >
> > > Function Startup()
> > > DataFileName = DFirst("[DataFileName]", "[Version]")
> > > DemoVersion = False
> > > DemoLength = 30
> > > DoCmd.OpenForm "Login"
> > > End Function
> > >
> > > The three variables, DataFileName, DemoVersion, and DemoLength are all
> > > public variables declared (one in in this module and the other two in
another
> > > module).
> > >
> > > I do have a host of other functions in my app, but this is the most
likely
> > > candidate because, although my login form does call a couple of other
> > > functions from other modules, this is the first one that runs on
startup.
> > >
> > > Any ideas? Or at least how to isolate the issue and why it would occur
only
> > > in the MDE?

How would you recommend distributing an Access app, then, to customers that
are casual canned-software-only customers? I have an app that has just
outgrown my local client base; I have a significant number of potential
customers asking how they can purchase it, and they may well want to buy it
"off the shelf" with no involvement of mine on their systems. I suppose
that's a good problem to have, but I need to ensure that I don't lose control
of the security of my code anywhere along the way.

To this point, I have been simply setting AllowBypassKey to False for those
customers whose systems I manage, but I don't really want to distribute the
app to unknown customers that way when it is is easy to re-enable the bypass
key (as you are well aware, there are several tools out there that make this
quite easy).

So, I thought I would just use an MDE. For those clients not having Access,
I can distribute the runtime 2003, but now I'm stuck with the current problem
for those customers who already have a version of Access. The app works fine
with anything 2000 or newer, except for this reference.

"Douglas J Steele" wrote:

> I believe that the problem is that while Access is capable of handling
> certain Reference changes from version to version in MDBs, it can't in MDEs.
>
> You can use code like the following to check the references in another
> database:
>
> Sub ListReferences()
> Dim appAccess As Access.Application
> Dim refCurr As Reference
> Dim strDatabase As String
>
> strDatabase = "full path to database"
> Set appAccess = New Access.Application
> appAccess.OpenCurrentDatabase strDatabase
> For Each refCurr In appAccess.References
> If refCurr.IsBroken = False Then
> Debug.Print refCurr.Name & _
> " (" & refCurr.Major & "." & refCurr.Minor & ")"
> Else
> Debug.Print "Broken reference: " & refCurr.Guid
> End If
> Next refCurr
> appAccess.CloseCurrentDatabase
> Set appAccess = Nothing
>
> End Sub
>
>
> If you're distributing to customers who are running on a different platform
> that you use, you really should be at least testing the application on their
> platform before distributing to them. Look into something like Virtual PC or
> VMWare to eliminate the need for multiple pieces of hardware.
>
> --
> Doug Steele, Microsoft Access MVP
> http://I.Am/DougSteele
> (no e-mails, please!)
>
>
> "Brian" <(E-Mail Removed)> wrote in message
> news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
> > Pardon my ignorance here, but shouldn't the MDB use the same references?
> Does
> > something happen in the MDE compilation process that disallows the XP
> machine
> > to use its own references as it would when using the MDB?
> >
> > Before I saw your reply, I thought it might be a service pack issue, so I
> > installed Office XP SP3, and now the MDE says the DB is in an unrecognized
> > format (MDB is still fine) on the affected PC. This was in XP/2003 format
> and
> > compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on the
> > target PC, and it is just fine.
> >
> > I just checked the references on the dev & target PC's, and the DLLs are
> in
> > the correct paths. The ONLY difference is the Office 10/Office 11 path for
> > the MS Access 10.0/11.0 Object Library, which appears correctly on each PC
> > when I open the MDB. Is there a way to check the pre-compiled MDE
> reference
> > on the target PC?
> >
> > Just a note on Access: it is very frustrating spending hundreds of hours
> > developing an app like this, only to wind up with clients saying it
> doesn't
> > work due to some Access platform issue entirely unrelated to all my hard
> > work...
> >
> > Thanks.
> >
> > "Klatuu" wrote:
> >
> > > It probably is a reference issue. 2003 uses 11.0 libraries and 2002
> uses 10.0
> > > One the offending machine, install the mbd open VBA editor, check Tools,
> > > References. See if any are missing.
> > >
> > > Here is a site that may be useful:
> > > http://support.microsoft.com/default...b;en-us;283115
> > >
> > > Also, you did not say where the error occured. Have you tried stepping
> > > through in Debug mode to see if you can tell where it fails?
> > >
> > > Looking at you Startup function, the first thing I see is a DFirst
> domain
> > > aggregate function. I am not sure, but I think it is in the DAO
> library. It
> > > is 3.6 for both Access versions, but I would check the offending Pc's to
> be
> > > sure they have that DLL and it is in the path specified in the
> references.
> > >
> > >
> > > "Brian" wrote:
> > >
> > > > I have an FE/BE app that works fine on all PC's & a terminal server (a
> > > > mixture of Access and Access runtime) when run as an MDB, but but
> fails on
> > > > two PC's when distributed as an MDE. If I distribute it as an MDB and
> compile
> > > > to MDE on the workstation, the MDE works fine, though. My dev
> workstation is
> > > > Access 2003 (Office Pro with VB Tools), and at least one of the
> workstations
> > > > on which it fails is Access 2002 (full version). Here is the error:
> > > >
> > > > The expression you entered has a function name that <my app name>
> can't find.
> > > >
> > > > How can I locate this? I have error-trapping in every procedure on
> every
> > > > form, and this message is an indication that the error is not being
> trapped.
> > > >
> > > > I have this startup methodology that provides a little more
> flexibility than
> > > > using startup options to open a form:
> > > >
> > > > AutoExec Macro: RunCode - Function Startup()
> > > >
> > > > The Startup function is in a standalone module (i.e. not behind a
> form)
> > > >
> > > > Function Startup()
> > > > DataFileName = DFirst("[DataFileName]", "[Version]")
> > > > DemoVersion = False
> > > > DemoLength = 30
> > > > DoCmd.OpenForm "Login"
> > > > End Function
> > > >
> > > > The three variables, DataFileName, DemoVersion, and DemoLength are all
> > > > public variables declared (one in in this module and the other two in
> another
> > > > module).
> > > >
> > > > I do have a host of other functions in my app, but this is the most
> likely
> > > > candidate because, although my login form does call a couple of other
> > > > functions from other modules, this is the first one that runs on
> startup.
> > > >
> > > > Any ideas? Or at least how to isolate the issue and why it would occur
> only
> > > > in the MDE?
>
>
>

Why are you including the Office reference? Do you really need it?

Depending on what you're doing, you may be able to use Late Binding, and
eliminate the need for the reference, thus eliminating your problem.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Brian" <(E-Mail Removed)> wrote in message
news:E9ADE37E-C8B1-4AA1-A62B-(E-Mail Removed)...
> How would you recommend distributing an Access app, then, to customers
that
> are casual canned-software-only customers? I have an app that has just
> outgrown my local client base; I have a significant number of potential
> customers asking how they can purchase it, and they may well want to buy
it
> "off the shelf" with no involvement of mine on their systems. I suppose
> that's a good problem to have, but I need to ensure that I don't lose
control
> of the security of my code anywhere along the way.
>
> To this point, I have been simply setting AllowBypassKey to False for
those
> customers whose systems I manage, but I don't really want to distribute
the
> app to unknown customers that way when it is is easy to re-enable the
bypass
> key (as you are well aware, there are several tools out there that make
this
> quite easy).
>
> So, I thought I would just use an MDE. For those clients not having
Access,
> I can distribute the runtime 2003, but now I'm stuck with the current
problem
> for those customers who already have a version of Access. The app works
fine
> with anything 2000 or newer, except for this reference.
>
> "Douglas J Steele" wrote:
>
> > I believe that the problem is that while Access is capable of handling
> > certain Reference changes from version to version in MDBs, it can't in
MDEs.
> >
> > You can use code like the following to check the references in another
> > database:
> >
> > Sub ListReferences()
> > Dim appAccess As Access.Application
> > Dim refCurr As Reference
> > Dim strDatabase As String
> >
> > strDatabase = "full path to database"
> > Set appAccess = New Access.Application
> > appAccess.OpenCurrentDatabase strDatabase
> > For Each refCurr In appAccess.References
> > If refCurr.IsBroken = False Then
> > Debug.Print refCurr.Name & _
> > " (" & refCurr.Major & "." & refCurr.Minor & ")"
> > Else
> > Debug.Print "Broken reference: " & refCurr.Guid
> > End If
> > Next refCurr
> > appAccess.CloseCurrentDatabase
> > Set appAccess = Nothing
> >
> > End Sub
> >
> >
> > If you're distributing to customers who are running on a different
platform
> > that you use, you really should be at least testing the application on
their
> > platform before distributing to them. Look into something like Virtual
PC or
> > VMWare to eliminate the need for multiple pieces of hardware.
> >
> > --
> > Doug Steele, Microsoft Access MVP
> > http://I.Am/DougSteele
> > (no e-mails, please!)
> >
> >
> > "Brian" <(E-Mail Removed)> wrote in message
> > news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
> > > Pardon my ignorance here, but shouldn't the MDB use the same
references?
> > Does
> > > something happen in the MDE compilation process that disallows the XP
> > machine
> > > to use its own references as it would when using the MDB?
> > >
> > > Before I saw your reply, I thought it might be a service pack issue,
so I
> > > installed Office XP SP3, and now the MDE says the DB is in an
unrecognized
> > > format (MDB is still fine) on the affected PC. This was in XP/2003
format
> > and
> > > compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on
the
> > > target PC, and it is just fine.
> > >
> > > I just checked the references on the dev & target PC's, and the DLLs
are
> > in
> > > the correct paths. The ONLY difference is the Office 10/Office 11 path
for
> > > the MS Access 10.0/11.0 Object Library, which appears correctly on
each PC
> > > when I open the MDB. Is there a way to check the pre-compiled MDE
> > reference
> > > on the target PC?
> > >
> > > Just a note on Access: it is very frustrating spending hundreds of
hours
> > > developing an app like this, only to wind up with clients saying it
> > doesn't
> > > work due to some Access platform issue entirely unrelated to all my
hard
> > > work...
> > >
> > > Thanks.
> > >
> > > "Klatuu" wrote:
> > >
> > > > It probably is a reference issue. 2003 uses 11.0 libraries and 2002
> > uses 10.0
> > > > One the offending machine, install the mbd open VBA editor, check
Tools,
> > > > References. See if any are missing.
> > > >
> > > > Here is a site that may be useful:
> > > > http://support.microsoft.com/default...b;en-us;283115
> > > >
> > > > Also, you did not say where the error occured. Have you tried
stepping
> > > > through in Debug mode to see if you can tell where it fails?
> > > >
> > > > Looking at you Startup function, the first thing I see is a DFirst
> > domain
> > > > aggregate function. I am not sure, but I think it is in the DAO
> > library. It
> > > > is 3.6 for both Access versions, but I would check the offending
Pc's to
> > be
> > > > sure they have that DLL and it is in the path specified in the
> > references.
> > > >
> > > >
> > > > "Brian" wrote:
> > > >
> > > > > I have an FE/BE app that works fine on all PC's & a terminal
server (a
> > > > > mixture of Access and Access runtime) when run as an MDB, but but
> > fails on
> > > > > two PC's when distributed as an MDE. If I distribute it as an MDB
and
> > compile
> > > > > to MDE on the workstation, the MDE works fine, though. My dev
> > workstation is
> > > > > Access 2003 (Office Pro with VB Tools), and at least one of the
> > workstations
> > > > > on which it fails is Access 2002 (full version). Here is the
error:
> > > > >
> > > > > The expression you entered has a function name that <my app name>
> > can't find.
> > > > >
> > > > > How can I locate this? I have error-trapping in every procedure on
> > every
> > > > > form, and this message is an indication that the error is not
being
> > trapped.
> > > > >
> > > > > I have this startup methodology that provides a little more
> > flexibility than
> > > > > using startup options to open a form:
> > > > >
> > > > > AutoExec Macro: RunCode - Function Startup()
> > > > >
> > > > > The Startup function is in a standalone module (i.e. not behind a
> > form)
> > > > >
> > > > > Function Startup()
> > > > > DataFileName = DFirst("[DataFileName]", "[Version]")
> > > > > DemoVersion = False
> > > > > DemoLength = 30
> > > > > DoCmd.OpenForm "Login"
> > > > > End Function
> > > > >
> > > > > The three variables, DataFileName, DemoVersion, and DemoLength are
all
> > > > > public variables declared (one in in this module and the other two
in
> > another
> > > > > module).
> > > > >
> > > > > I do have a host of other functions in my app, but this is the
most
> > likely
> > > > > candidate because, although my login form does call a couple of
other
> > > > > functions from other modules, this is the first one that runs on
> > startup.
> > > > >
> > > > > Any ideas? Or at least how to isolate the issue and why it would
occur
> > only
> > > > > in the MDE?
> >
> >
> >

Good question. Maybe the reference was just set by default or residual from
something earlier in the development process. I don't recall that it was
intentional, but I will have to run the app after removing the reference to
see.

Thanks.

"Douglas J Steele" wrote:

> Why are you including the Office reference? Do you really need it?
>
> Depending on what you're doing, you may be able to use Late Binding, and
> eliminate the need for the reference, thus eliminating your problem.
>
> --
> Doug Steele, Microsoft Access MVP
> http://I.Am/DougSteele
> (no e-mails, please!)
>
>
> "Brian" <(E-Mail Removed)> wrote in message
> news:E9ADE37E-C8B1-4AA1-A62B-(E-Mail Removed)...
> > How would you recommend distributing an Access app, then, to customers
> that
> > are casual canned-software-only customers? I have an app that has just
> > outgrown my local client base; I have a significant number of potential
> > customers asking how they can purchase it, and they may well want to buy
> it
> > "off the shelf" with no involvement of mine on their systems. I suppose
> > that's a good problem to have, but I need to ensure that I don't lose
> control
> > of the security of my code anywhere along the way.
> >
> > To this point, I have been simply setting AllowBypassKey to False for
> those
> > customers whose systems I manage, but I don't really want to distribute
> the
> > app to unknown customers that way when it is is easy to re-enable the
> bypass
> > key (as you are well aware, there are several tools out there that make
> this
> > quite easy).
> >
> > So, I thought I would just use an MDE. For those clients not having
> Access,
> > I can distribute the runtime 2003, but now I'm stuck with the current
> problem
> > for those customers who already have a version of Access. The app works
> fine
> > with anything 2000 or newer, except for this reference.
> >
> > "Douglas J Steele" wrote:
> >
> > > I believe that the problem is that while Access is capable of handling
> > > certain Reference changes from version to version in MDBs, it can't in
> MDEs.
> > >
> > > You can use code like the following to check the references in another
> > > database:
> > >
> > > Sub ListReferences()
> > > Dim appAccess As Access.Application
> > > Dim refCurr As Reference
> > > Dim strDatabase As String
> > >
> > > strDatabase = "full path to database"
> > > Set appAccess = New Access.Application
> > > appAccess.OpenCurrentDatabase strDatabase
> > > For Each refCurr In appAccess.References
> > > If refCurr.IsBroken = False Then
> > > Debug.Print refCurr.Name & _
> > > " (" & refCurr.Major & "." & refCurr.Minor & ")"
> > > Else
> > > Debug.Print "Broken reference: " & refCurr.Guid
> > > End If
> > > Next refCurr
> > > appAccess.CloseCurrentDatabase
> > > Set appAccess = Nothing
> > >
> > > End Sub
> > >
> > >
> > > If you're distributing to customers who are running on a different
> platform
> > > that you use, you really should be at least testing the application on
> their
> > > platform before distributing to them. Look into something like Virtual
> PC or
> > > VMWare to eliminate the need for multiple pieces of hardware.
> > >
> > > --
> > > Doug Steele, Microsoft Access MVP
> > > http://I.Am/DougSteele
> > > (no e-mails, please!)
> > >
> > >
> > > "Brian" <(E-Mail Removed)> wrote in message
> > > news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
> > > > Pardon my ignorance here, but shouldn't the MDB use the same
> references?
> > > Does
> > > > something happen in the MDE compilation process that disallows the XP
> > > machine
> > > > to use its own references as it would when using the MDB?
> > > >
> > > > Before I saw your reply, I thought it might be a service pack issue,
> so I
> > > > installed Office XP SP3, and now the MDE says the DB is in an
> unrecognized
> > > > format (MDB is still fine) on the affected PC. This was in XP/2003
> format
> > > and
> > > > compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on
> the
> > > > target PC, and it is just fine.
> > > >
> > > > I just checked the references on the dev & target PC's, and the DLLs
> are
> > > in
> > > > the correct paths. The ONLY difference is the Office 10/Office 11 path
> for
> > > > the MS Access 10.0/11.0 Object Library, which appears correctly on
> each PC
> > > > when I open the MDB. Is there a way to check the pre-compiled MDE
> > > reference
> > > > on the target PC?
> > > >
> > > > Just a note on Access: it is very frustrating spending hundreds of
> hours
> > > > developing an app like this, only to wind up with clients saying it
> > > doesn't
> > > > work due to some Access platform issue entirely unrelated to all my
> hard
> > > > work...
> > > >
> > > > Thanks.
> > > >
> > > > "Klatuu" wrote:
> > > >
> > > > > It probably is a reference issue. 2003 uses 11.0 libraries and 2002
> > > uses 10.0
> > > > > One the offending machine, install the mbd open VBA editor, check
> Tools,
> > > > > References. See if any are missing.
> > > > >
> > > > > Here is a site that may be useful:
> > > > > http://support.microsoft.com/default...b;en-us;283115
> > > > >
> > > > > Also, you did not say where the error occured. Have you tried
> stepping
> > > > > through in Debug mode to see if you can tell where it fails?
> > > > >
> > > > > Looking at you Startup function, the first thing I see is a DFirst
> > > domain
> > > > > aggregate function. I am not sure, but I think it is in the DAO
> > > library. It
> > > > > is 3.6 for both Access versions, but I would check the offending
> Pc's to
> > > be
> > > > > sure they have that DLL and it is in the path specified in the
> > > references.
> > > > >
> > > > >
> > > > > "Brian" wrote:
> > > > >
> > > > > > I have an FE/BE app that works fine on all PC's & a terminal
> server (a
> > > > > > mixture of Access and Access runtime) when run as an MDB, but but
> > > fails on
> > > > > > two PC's when distributed as an MDE. If I distribute it as an MDB
> and
> > > compile
> > > > > > to MDE on the workstation, the MDE works fine, though. My dev
> > > workstation is
> > > > > > Access 2003 (Office Pro with VB Tools), and at least one of the
> > > workstations
> > > > > > on which it fails is Access 2002 (full version). Here is the
> error:
> > > > > >
> > > > > > The expression you entered has a function name that <my app name>
> > > can't find.
> > > > > >
> > > > > > How can I locate this? I have error-trapping in every procedure on
> > > every
> > > > > > form, and this message is an indication that the error is not
> being
> > > trapped.
> > > > > >
> > > > > > I have this startup methodology that provides a little more
> > > flexibility than
> > > > > > using startup options to open a form:
> > > > > >
> > > > > > AutoExec Macro: RunCode - Function Startup()
> > > > > >
> > > > > > The Startup function is in a standalone module (i.e. not behind a
> > > form)
> > > > > >
> > > > > > Function Startup()
> > > > > > DataFileName = DFirst("[DataFileName]", "[Version]")
> > > > > > DemoVersion = False
> > > > > > DemoLength = 30
> > > > > > DoCmd.OpenForm "Login"
> > > > > > End Function
> > > > > >
> > > > > > The three variables, DataFileName, DemoVersion, and DemoLength are
> all
> > > > > > public variables declared (one in in this module and the other two
> in
> > > another
> > > > > > module).
> > > > > >
> > > > > > I do have a host of other functions in my app, but this is the
> most
> > > likely
> > > > > > candidate because, although my login form does call a couple of
> other
> > > > > > functions from other modules, this is the first one that runs on
> > > startup.
> > > > > >
> > > > > > Any ideas? Or at least how to isolate the issue and why it would
> occur
> > > only
> > > > > > in the MDE?
> > >
> > >
> > >
>
>
>

On second thought, this is the MS Access Object Library (MSACC.OLB), not the
generic Office 11.0 Object Library. Pardon my ignorance here, but isn't the
Access Object Library rather fundamental to a lot of things that happen in
Access?

By default, this resides in the C:\Program FIles\Microsoft Office\OFFICE11
folder for Access 2003, including the runtime, but in the ...Office10 folder
for full versions of Access 2002 or 2000.

"Douglas J Steele" wrote:

> Why are you including the Office reference? Do you really need it?
>
> Depending on what you're doing, you may be able to use Late Binding, and
> eliminate the need for the reference, thus eliminating your problem.
>
> --
> Doug Steele, Microsoft Access MVP
> http://I.Am/DougSteele
> (no e-mails, please!)
>
>
> "Brian" <(E-Mail Removed)> wrote in message
> news:E9ADE37E-C8B1-4AA1-A62B-(E-Mail Removed)...
> > How would you recommend distributing an Access app, then, to customers
> that
> > are casual canned-software-only customers? I have an app that has just
> > outgrown my local client base; I have a significant number of potential
> > customers asking how they can purchase it, and they may well want to buy
> it
> > "off the shelf" with no involvement of mine on their systems. I suppose
> > that's a good problem to have, but I need to ensure that I don't lose
> control
> > of the security of my code anywhere along the way.
> >
> > To this point, I have been simply setting AllowBypassKey to False for
> those
> > customers whose systems I manage, but I don't really want to distribute
> the
> > app to unknown customers that way when it is is easy to re-enable the
> bypass
> > key (as you are well aware, there are several tools out there that make
> this
> > quite easy).
> >
> > So, I thought I would just use an MDE. For those clients not having
> Access,
> > I can distribute the runtime 2003, but now I'm stuck with the current
> problem
> > for those customers who already have a version of Access. The app works
> fine
> > with anything 2000 or newer, except for this reference.
> >
> > "Douglas J Steele" wrote:
> >
> > > I believe that the problem is that while Access is capable of handling
> > > certain Reference changes from version to version in MDBs, it can't in
> MDEs.
> > >
> > > You can use code like the following to check the references in another
> > > database:
> > >
> > > Sub ListReferences()
> > > Dim appAccess As Access.Application
> > > Dim refCurr As Reference
> > > Dim strDatabase As String
> > >
> > > strDatabase = "full path to database"
> > > Set appAccess = New Access.Application
> > > appAccess.OpenCurrentDatabase strDatabase
> > > For Each refCurr In appAccess.References
> > > If refCurr.IsBroken = False Then
> > > Debug.Print refCurr.Name & _
> > > " (" & refCurr.Major & "." & refCurr.Minor & ")"
> > > Else
> > > Debug.Print "Broken reference: " & refCurr.Guid
> > > End If
> > > Next refCurr
> > > appAccess.CloseCurrentDatabase
> > > Set appAccess = Nothing
> > >
> > > End Sub
> > >
> > >
> > > If you're distributing to customers who are running on a different
> platform
> > > that you use, you really should be at least testing the application on
> their
> > > platform before distributing to them. Look into something like Virtual
> PC or
> > > VMWare to eliminate the need for multiple pieces of hardware.
> > >
> > > --
> > > Doug Steele, Microsoft Access MVP
> > > http://I.Am/DougSteele
> > > (no e-mails, please!)
> > >
> > >
> > > "Brian" <(E-Mail Removed)> wrote in message
> > > news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
> > > > Pardon my ignorance here, but shouldn't the MDB use the same
> references?
> > > Does
> > > > something happen in the MDE compilation process that disallows the XP
> > > machine
> > > > to use its own references as it would when using the MDB?
> > > >
> > > > Before I saw your reply, I thought it might be a service pack issue,
> so I
> > > > installed Office XP SP3, and now the MDE says the DB is in an
> unrecognized
> > > > format (MDB is still fine) on the affected PC. This was in XP/2003
> format
> > > and
> > > > compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on
> the
> > > > target PC, and it is just fine.
> > > >
> > > > I just checked the references on the dev & target PC's, and the DLLs
> are
> > > in
> > > > the correct paths. The ONLY difference is the Office 10/Office 11 path
> for
> > > > the MS Access 10.0/11.0 Object Library, which appears correctly on
> each PC
> > > > when I open the MDB. Is there a way to check the pre-compiled MDE
> > > reference
> > > > on the target PC?
> > > >
> > > > Just a note on Access: it is very frustrating spending hundreds of
> hours
> > > > developing an app like this, only to wind up with clients saying it
> > > doesn't
> > > > work due to some Access platform issue entirely unrelated to all my
> hard
> > > > work...
> > > >
> > > > Thanks.
> > > >
> > > > "Klatuu" wrote:
> > > >
> > > > > It probably is a reference issue. 2003 uses 11.0 libraries and 2002
> > > uses 10.0
> > > > > One the offending machine, install the mbd open VBA editor, check
> Tools,
> > > > > References. See if any are missing.
> > > > >
> > > > > Here is a site that may be useful:
> > > > > http://support.microsoft.com/default...b;en-us;283115
> > > > >
> > > > > Also, you did not say where the error occured. Have you tried
> stepping
> > > > > through in Debug mode to see if you can tell where it fails?
> > > > >
> > > > > Looking at you Startup function, the first thing I see is a DFirst
> > > domain
> > > > > aggregate function. I am not sure, but I think it is in the DAO
> > > library. It
> > > > > is 3.6 for both Access versions, but I would check the offending
> Pc's to
> > > be
> > > > > sure they have that DLL and it is in the path specified in the
> > > references.
> > > > >
> > > > >
> > > > > "Brian" wrote:
> > > > >
> > > > > > I have an FE/BE app that works fine on all PC's & a terminal
> server (a
> > > > > > mixture of Access and Access runtime) when run as an MDB, but but
> > > fails on
> > > > > > two PC's when distributed as an MDE. If I distribute it as an MDB
> and
> > > compile
> > > > > > to MDE on the workstation, the MDE works fine, though. My dev
> > > workstation is
> > > > > > Access 2003 (Office Pro with VB Tools), and at least one of the
> > > workstations
> > > > > > on which it fails is Access 2002 (full version). Here is the
> error:
> > > > > >
> > > > > > The expression you entered has a function name that <my app name>
> > > can't find.
> > > > > >
> > > > > > How can I locate this? I have error-trapping in every procedure on
> > > every
> > > > > > form, and this message is an indication that the error is not
> being
> > > trapped.
> > > > > >
> > > > > > I have this startup methodology that provides a little more
> > > flexibility than
> > > > > > using startup options to open a form:
> > > > > >
> > > > > > AutoExec Macro: RunCode - Function Startup()
> > > > > >
> > > > > > The Startup function is in a standalone module (i.e. not behind a
> > > form)
> > > > > >
> > > > > > Function Startup()
> > > > > > DataFileName = DFirst("[DataFileName]", "[Version]")
> > > > > > DemoVersion = False
> > > > > > DemoLength = 30
> > > > > > DoCmd.OpenForm "Login"
> > > > > > End Function
> > > > > >
> > > > > > The three variables, DataFileName, DemoVersion, and DemoLength are
> all
> > > > > > public variables declared (one in in this module and the other two
> in
> > > another
> > > > > > module).
> > > > > >
> > > > > > I do have a host of other functions in my app, but this is the
> most
> > > likely
> > > > > > candidate because, although my login form does call a couple of
> other
> > > > > > functions from other modules, this is the first one that runs on
> > > startup.
> > > > > >
> > > > > > Any ideas? Or at least how to isolate the issue and why it would
> occur
> > > only
> > > > > > in the MDE?
> > >
> > >
> > >
>
>
>

And, of course, Access will not allow me to remove the reference to the
Access 11.0 Object Library (says it is in use).

"Douglas J Steele" wrote:

> Why are you including the Office reference? Do you really need it?
>
> Depending on what you're doing, you may be able to use Late Binding, and
> eliminate the need for the reference, thus eliminating your problem.
>
> --
> Doug Steele, Microsoft Access MVP
> http://I.Am/DougSteele
> (no e-mails, please!)
>
>
> "Brian" <(E-Mail Removed)> wrote in message
> news:E9ADE37E-C8B1-4AA1-A62B-(E-Mail Removed)...
> > How would you recommend distributing an Access app, then, to customers
> that
> > are casual canned-software-only customers? I have an app that has just
> > outgrown my local client base; I have a significant number of potential
> > customers asking how they can purchase it, and they may well want to buy
> it
> > "off the shelf" with no involvement of mine on their systems. I suppose
> > that's a good problem to have, but I need to ensure that I don't lose
> control
> > of the security of my code anywhere along the way.
> >
> > To this point, I have been simply setting AllowBypassKey to False for
> those
> > customers whose systems I manage, but I don't really want to distribute
> the
> > app to unknown customers that way when it is is easy to re-enable the
> bypass
> > key (as you are well aware, there are several tools out there that make
> this
> > quite easy).
> >
> > So, I thought I would just use an MDE. For those clients not having
> Access,
> > I can distribute the runtime 2003, but now I'm stuck with the current
> problem
> > for those customers who already have a version of Access. The app works
> fine
> > with anything 2000 or newer, except for this reference.
> >
> > "Douglas J Steele" wrote:
> >
> > > I believe that the problem is that while Access is capable of handling
> > > certain Reference changes from version to version in MDBs, it can't in
> MDEs.
> > >
> > > You can use code like the following to check the references in another
> > > database:
> > >
> > > Sub ListReferences()
> > > Dim appAccess As Access.Application
> > > Dim refCurr As Reference
> > > Dim strDatabase As String
> > >
> > > strDatabase = "full path to database"
> > > Set appAccess = New Access.Application
> > > appAccess.OpenCurrentDatabase strDatabase
> > > For Each refCurr In appAccess.References
> > > If refCurr.IsBroken = False Then
> > > Debug.Print refCurr.Name & _
> > > " (" & refCurr.Major & "." & refCurr.Minor & ")"
> > > Else
> > > Debug.Print "Broken reference: " & refCurr.Guid
> > > End If
> > > Next refCurr
> > > appAccess.CloseCurrentDatabase
> > > Set appAccess = Nothing
> > >
> > > End Sub
> > >
> > >
> > > If you're distributing to customers who are running on a different
> platform
> > > that you use, you really should be at least testing the application on
> their
> > > platform before distributing to them. Look into something like Virtual
> PC or
> > > VMWare to eliminate the need for multiple pieces of hardware.
> > >
> > > --
> > > Doug Steele, Microsoft Access MVP
> > > http://I.Am/DougSteele
> > > (no e-mails, please!)
> > >
> > >
> > > "Brian" <(E-Mail Removed)> wrote in message
> > > news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
> > > > Pardon my ignorance here, but shouldn't the MDB use the same
> references?
> > > Does
> > > > something happen in the MDE compilation process that disallows the XP
> > > machine
> > > > to use its own references as it would when using the MDB?
> > > >
> > > > Before I saw your reply, I thought it might be a service pack issue,
> so I
> > > > installed Office XP SP3, and now the MDE says the DB is in an
> unrecognized
> > > > format (MDB is still fine) on the affected PC. This was in XP/2003
> format
> > > and
> > > > compiled to MDE on my dev PC. I copied the MDB and compiled the MDE on
> the
> > > > target PC, and it is just fine.
> > > >
> > > > I just checked the references on the dev & target PC's, and the DLLs
> are
> > > in
> > > > the correct paths. The ONLY difference is the Office 10/Office 11 path
> for
> > > > the MS Access 10.0/11.0 Object Library, which appears correctly on
> each PC
> > > > when I open the MDB. Is there a way to check the pre-compiled MDE
> > > reference
> > > > on the target PC?
> > > >
> > > > Just a note on Access: it is very frustrating spending hundreds of
> hours
> > > > developing an app like this, only to wind up with clients saying it
> > > doesn't
> > > > work due to some Access platform issue entirely unrelated to all my
> hard
> > > > work...
> > > >
> > > > Thanks.
> > > >
> > > > "Klatuu" wrote:
> > > >
> > > > > It probably is a reference issue. 2003 uses 11.0 libraries and 2002
> > > uses 10.0
> > > > > One the offending machine, install the mbd open VBA editor, check
> Tools,
> > > > > References. See if any are missing.
> > > > >
> > > > > Here is a site that may be useful:
> > > > > http://support.microsoft.com/default...b;en-us;283115
> > > > >
> > > > > Also, you did not say where the error occured. Have you tried
> stepping
> > > > > through in Debug mode to see if you can tell where it fails?
> > > > >
> > > > > Looking at you Startup function, the first thing I see is a DFirst
> > > domain
> > > > > aggregate function. I am not sure, but I think it is in the DAO
> > > library. It
> > > > > is 3.6 for both Access versions, but I would check the offending
> Pc's to
> > > be
> > > > > sure they have that DLL and it is in the path specified in the
> > > references.
> > > > >
> > > > >
> > > > > "Brian" wrote:
> > > > >
> > > > > > I have an FE/BE app that works fine on all PC's & a terminal
> server (a
> > > > > > mixture of Access and Access runtime) when run as an MDB, but but
> > > fails on
> > > > > > two PC's when distributed as an MDE. If I distribute it as an MDB
> and
> > > compile
> > > > > > to MDE on the workstation, the MDE works fine, though. My dev
> > > workstation is
> > > > > > Access 2003 (Office Pro with VB Tools), and at least one of the
> > > workstations
> > > > > > on which it fails is Access 2002 (full version). Here is the
> error:
> > > > > >
> > > > > > The expression you entered has a function name that <my app name>
> > > can't find.
> > > > > >
> > > > > > How can I locate this? I have error-trapping in every procedure on
> > > every
> > > > > > form, and this message is an indication that the error is not
> being
> > > trapped.
> > > > > >
> > > > > > I have this startup methodology that provides a little more
> > > flexibility than
> > > > > > using startup options to open a form:
> > > > > >
> > > > > > AutoExec Macro: RunCode - Function Startup()
> > > > > >
> > > > > > The Startup function is in a standalone module (i.e. not behind a
> > > form)
> > > > > >
> > > > > > Function Startup()
> > > > > > DataFileName = DFirst("[DataFileName]", "[Version]")
> > > > > > DemoVersion = False
> > > > > > DemoLength = 30
> > > > > > DoCmd.OpenForm "Login"
> > > > > > End Function
> > > > > >
> > > > > > The three variables, DataFileName, DemoVersion, and DemoLength are
> all
> > > > > > public variables declared (one in in this module and the other two
> in
> > > another
> > > > > > module).
> > > > > >
> > > > > > I do have a host of other functions in my app, but this is the
> most
> > > likely
> > > > > > candidate because, although my login form does call a couple of
> other
> > > > > > functions from other modules, this is the first one that runs on
> > > startup.
> > > > > >
> > > > > > Any ideas? Or at least how to isolate the issue and why it would
> occur
> > > only
> > > > > > in the MDE?
> > >
> > >
> > >
>
>
>

MDEs aren't as forgiving as MDBs. You may have to produce a separate MDE for
each version of Access you're supporting.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Brian" <(E-Mail Removed)> wrote in message
news:0806212D-7037-4555-8FEE-(E-Mail Removed)...
> On second thought, this is the MS Access Object Library (MSACC.OLB), not
> the
> generic Office 11.0 Object Library. Pardon my ignorance here, but isn't
> the
> Access Object Library rather fundamental to a lot of things that happen in
> Access?
>
> By default, this resides in the C:\Program FIles\Microsoft Office\OFFICE11
> folder for Access 2003, including the runtime, but in the ...Office10
> folder
> for full versions of Access 2002 or 2000.
>
> "Douglas J Steele" wrote:
>
>> Why are you including the Office reference? Do you really need it?
>>
>> Depending on what you're doing, you may be able to use Late Binding, and
>> eliminate the need for the reference, thus eliminating your problem.
>>
>> --
>> Doug Steele, Microsoft Access MVP
>> http://I.Am/DougSteele
>> (no e-mails, please!)
>>
>>
>> "Brian" <(E-Mail Removed)> wrote in message
>> news:E9ADE37E-C8B1-4AA1-A62B-(E-Mail Removed)...
>> > How would you recommend distributing an Access app, then, to customers
>> that
>> > are casual canned-software-only customers? I have an app that has just
>> > outgrown my local client base; I have a significant number of potential
>> > customers asking how they can purchase it, and they may well want to
>> > buy
>> it
>> > "off the shelf" with no involvement of mine on their systems. I suppose
>> > that's a good problem to have, but I need to ensure that I don't lose
>> control
>> > of the security of my code anywhere along the way.
>> >
>> > To this point, I have been simply setting AllowBypassKey to False for
>> those
>> > customers whose systems I manage, but I don't really want to distribute
>> the
>> > app to unknown customers that way when it is is easy to re-enable the
>> bypass
>> > key (as you are well aware, there are several tools out there that make
>> this
>> > quite easy).
>> >
>> > So, I thought I would just use an MDE. For those clients not having
>> Access,
>> > I can distribute the runtime 2003, but now I'm stuck with the current
>> problem
>> > for those customers who already have a version of Access. The app works
>> fine
>> > with anything 2000 or newer, except for this reference.
>> >
>> > "Douglas J Steele" wrote:
>> >
>> > > I believe that the problem is that while Access is capable of
>> > > handling
>> > > certain Reference changes from version to version in MDBs, it can't
>> > > in
>> MDEs.
>> > >
>> > > You can use code like the following to check the references in
>> > > another
>> > > database:
>> > >
>> > > Sub ListReferences()
>> > > Dim appAccess As Access.Application
>> > > Dim refCurr As Reference
>> > > Dim strDatabase As String
>> > >
>> > > strDatabase = "full path to database"
>> > > Set appAccess = New Access.Application
>> > > appAccess.OpenCurrentDatabase strDatabase
>> > > For Each refCurr In appAccess.References
>> > > If refCurr.IsBroken = False Then
>> > > Debug.Print refCurr.Name & _
>> > > " (" & refCurr.Major & "." & refCurr.Minor & ")"
>> > > Else
>> > > Debug.Print "Broken reference: " & refCurr.Guid
>> > > End If
>> > > Next refCurr
>> > > appAccess.CloseCurrentDatabase
>> > > Set appAccess = Nothing
>> > >
>> > > End Sub
>> > >
>> > >
>> > > If you're distributing to customers who are running on a different
>> platform
>> > > that you use, you really should be at least testing the application
>> > > on
>> their
>> > > platform before distributing to them. Look into something like
>> > > Virtual
>> PC or
>> > > VMWare to eliminate the need for multiple pieces of hardware.
>> > >
>> > > --
>> > > Doug Steele, Microsoft Access MVP
>> > > http://I.Am/DougSteele
>> > > (no e-mails, please!)
>> > >
>> > >
>> > > "Brian" <(E-Mail Removed)> wrote in message
>> > > news:7F3E1400-9B06-407B-96DF-(E-Mail Removed)...
>> > > > Pardon my ignorance here, but shouldn't the MDB use the same
>> references?
>> > > Does
>> > > > something happen in the MDE compilation process that disallows the
>> > > > XP
>> > > machine
>> > > > to use its own references as it would when using the MDB?
>> > > >
>> > > > Before I saw your reply, I thought it might be a service pack
>> > > > issue,
>> so I
>> > > > installed Office XP SP3, and now the MDE says the DB is in an
>> unrecognized
>> > > > format (MDB is still fine) on the affected PC. This was in XP/2003
>> format
>> > > and
>> > > > compiled to MDE on my dev PC. I copied the MDB and compiled the MDE
>> > > > on
>> the
>> > > > target PC, and it is just fine.
>> > > >
>> > > > I just checked the references on the dev & target PC's, and the
>> > > > DLLs
>> are
>> > > in
>> > > > the correct paths. The ONLY difference is the Office 10/Office 11
>> > > > path
>> for
>> > > > the MS Access 10.0/11.0 Object Library, which appears correctly on
>> each PC
>> > > > when I open the MDB. Is there a way to check the pre-compiled MDE
>> > > reference
>> > > > on the target PC?
>> > > >
>> > > > Just a note on Access: it is very frustrating spending hundreds of
>> hours
>> > > > developing an app like this, only to wind up with clients saying it
>> > > doesn't
>> > > > work due to some Access platform issue entirely unrelated to all my
>> hard
>> > > > work...
>> > > >
>> > > > Thanks.
>> > > >
>> > > > "Klatuu" wrote:
>> > > >
>> > > > > It probably is a reference issue. 2003 uses 11.0 libraries and
>> > > > > 2002
>> > > uses 10.0
>> > > > > One the offending machine, install the mbd open VBA editor, check
>> Tools,
>> > > > > References. See if any are missing.
>> > > > >
>> > > > > Here is a site that may be useful:
>> > > > > http://support.microsoft.com/default...b;en-us;283115
>> > > > >
>> > > > > Also, you did not say where the error occured. Have you tried
>> stepping
>> > > > > through in Debug mode to see if you can tell where it fails?
>> > > > >
>> > > > > Looking at you Startup function, the first thing I see is a
>> > > > > DFirst
>> > > domain
>> > > > > aggregate function. I am not sure, but I think it is in the DAO
>> > > library. It
>> > > > > is 3.6 for both Access versions, but I would check the offending
>> Pc's to
>> > > be
>> > > > > sure they have that DLL and it is in the path specified in the
>> > > references.
>> > > > >
>> > > > >
>> > > > > "Brian" wrote:
>> > > > >
>> > > > > > I have an FE/BE app that works fine on all PC's & a terminal
>> server (a
>> > > > > > mixture of Access and Access runtime) when run as an MDB, but
>> > > > > > but
>> > > fails on
>> > > > > > two PC's when distributed as an MDE. If I distribute it as an
>> > > > > > MDB
>> and
>> > > compile
>> > > > > > to MDE on the workstation, the MDE works fine, though. My dev
>> > > workstation is
>> > > > > > Access 2003 (Office Pro with VB Tools), and at least one of the
>> > > workstations
>> > > > > > on which it fails is Access 2002 (full version). Here is the
>> error:
>> > > > > >
>> > > > > > The expression you entered has a function name that <my app
>> > > > > > name>
>> > > can't find.
>> > > > > >
>> > > > > > How can I locate this? I have error-trapping in every procedure
>> > > > > > on
>> > > every
>> > > > > > form, and this message is an indication that the error is not
>> being
>> > > trapped.
>> > > > > >
>> > > > > > I have this startup methodology that provides a little more
>> > > flexibility than
>> > > > > > using startup options to open a form:
>> > > > > >
>> > > > > > AutoExec Macro: RunCode - Function Startup()
>> > > > > >
>> > > > > > The Startup function is in a standalone module (i.e. not behind
>> > > > > > a
>> > > form)
>> > > > > >
>> > > > > > Function Startup()
>> > > > > > DataFileName = DFirst("[DataFileName]", "[Version]")
>> > > > > > DemoVersion = False
>> > > > > > DemoLength = 30
>> > > > > > DoCmd.OpenForm "Login"
>> > > > > > End Function
>> > > > > >
>> > > > > > The three variables, DataFileName, DemoVersion, and DemoLength
>> > > > > > are
>> all
>> > > > > > public variables declared (one in in this module and the other
>> > > > > > two
>> in
>> > > another
>> > > > > > module).
>> > > > > >
>> > > > > > I do have a host of other functions in my app, but this is the
>> most
>> > > likely
>> > > > > > candidate because, although my login form does call a couple of
>> other
>> > > > > > functions from other modules, this is the first one that runs
>> > > > > > on
>> > > startup.
>> > > > > >
>> > > > > > Any ideas? Or at least how to isolate the issue and why it
>> > > > > > would
>> occur
>> > > only
>> > > > > > in the MDE?
>> > >
>> > >
>> > >
>>
>>
>>