Re: Function name not found

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" <Brian@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E9ADE37E-C8B1-4AA1-A62B-5F35C33453DB@xxxxxxxxxxxxxxxx
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" <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: Function name not found
    ... Make installation as intuitive as possible for the customer. ... Doug Steele, Microsoft Access MVP ... eliminate the need for the reference, ... I have this startup methodology that provides a little more ...
    (microsoft.public.access.modulesdaovba)
  • Re: Function name not found
    ... Make installation as intuitive as possible for the customer. ... Doug Steele, Microsoft Access MVP ... eliminate the need for the reference, ... I have this startup methodology that provides a little more ...
    (microsoft.public.access.modulesdaovba)
  • Re: Function name not found
    ... Make installation as intuitive as possible for the customer. ... Doug Steele, Microsoft Access MVP ... eliminate the need for the reference, ... I have this startup methodology that provides a little more ...
    (microsoft.public.access.modulesdaovba)
  • Re: Function name not found
    ... Doug Steele, Microsoft Access MVP ... eliminate the need for the reference, ... If you're distributing to customers who are running on a different ... I have this startup methodology that provides a little more ...
    (microsoft.public.access.modulesdaovba)
  • Re: Program Files/Microsoft Works/Wkdetect.exe
    ... Have solved the problem - neither Startup Insp or Reg Mech make any reference ... Bob Deb hunted and pecked: ...
    (microsoft.public.windowsxp.general)
Loading