Re: Function name not found

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" <Brian@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7F3E1400-9B06-407B-96DF-25CD25AC91B2@xxxxxxxxxxxxxxxx
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.aspx?scid=kb;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?


.

Relevant Pages

  • Re: Correct Sequence?
    ... a reference to DAO by default. ... When you create a new mdb, ... Microsoft Access MVP ... Now try to create the MDE. ...
    (microsoft.public.access.security)
  • Re: Lock / Unlock VBA project
    ... "Alex Dybenko" wrote: ... make MDE? ... library MDB - create ne mdb, import forms/modules from your app, which ... have to make MDE of it and add reference to library MDE in order to make MDE ...
    (microsoft.public.access.modulesdaovba)
  • Re: creating external references
    ... The easiest way to implement this is with a referenced MDE. ... Then 'compile' it into an MDE and set a reference in your other ... deploy the frontends as MDBs (because an MDB will recompile against the new ... DLL, which means that all class GUIDs remain the same after a rebuild. ...
    (microsoft.public.access.modulesdaovba)
  • RE: Function name not found
    ... but shouldn't the MDB use the same references? ... something happen in the MDE compilation process that disallows the XP machine ... I have this startup methodology that provides a little more flexibility than ...
    (microsoft.public.access.modulesdaovba)
  • Re: expose class modules of a referenced mde
    ... Since I can't reference an .mdb from an .mde (which is what the final ... reference file and import the class objects as needed into the app. ...
    (comp.databases.ms-access)
Loading