Re: Function name not found

I have found it very common on the internet for a site to ask what OS I'm
running before I download.

Why not for Access?


On Thu, 30 Mar 2006 22:12:02 -0800, Brian <Brian@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

OK. So I am trying to do two things:

1. Protect my application. Any way other than MDE to keep the 99% of casual
pirates out? Never mind the other 1% that are serious hackers; if I plan for
them, I will never get a product to market.
2. Make installation as intuitive as possible for the customer. If I were
the customer purchasing an application online, I would personally feel that
its presentation is far from professional if I had to tell the programmer
what version of Access I had before I could download my copy. Is it feasible
to simply push out an Access 2003 runtime with EVERY implementation, or will
this mess up existing settings or file associations when installed on systems
that have Access 2000 or 2002 full version installed? Could I even guarantee
that the runtime would be used for my app if I did it this way? (Yes, I do
have the VB Tools for Office and thus the developer tools).

Thanks again.

"Douglas J. Steele" wrote:

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" <Brian@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0806212D-7037-4555-8FEE-579840A6418E@xxxxxxxxxxxxxxxx
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
    ... 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: Function name not found
    ... generic Office 11.0 Object Library. ... eliminate the need for the reference, ... Doug Steele, Microsoft Access MVP ... Looking at you Startup function, the first thing I see is a DFirst ...
    (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