Re: Function name not found



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: Breaking a reference via code
    ... I'm not sure if you can break a reference or if you need to or want to. ... Have you simply tried removing the reference using the References collection ... > On startup of the app I need to: ...
    (microsoft.public.access.modulesdaovba)
  • Re: How do I find the Path for Win.Word?
    ... For example, Bryan's reply to your original message was bottom-posted, meaning he quoted your message and wrote his reply UNDER what he quoted. ... You *should* be OK with a reference to Word 10 and your app being run on a system with Word 11 installed. ... I've written many little apps and even quite large apps that use Automation with various Office products and I've had VERY few problems with those apps working when a different version of Office is installed. ... However, in almost all of these, it's because they've developed using a later version of Office and uses features specific to that version, and then the app doesn't work with an earlier version of Office. ...
    (microsoft.public.vb.general.discussion)
  • Re: Trying to use unmanaged with C#
    ... And you're doing this from an ASP.NET app? ... It only became the need to be a .NET object when I "imported" it into my ... The object houses all the protocol for clients. ... if you *do* need to pass a reference of some .NET class to a COM ...
    (microsoft.public.dotnet.framework.interop)
  • Re: OpenVMS.org: Marvel article and HPs press release for Marveland Alpha Retain Trust Alpha Retain
    ... >> The 28% improvement from the VMS upgrade is just a side issue that you ... In an effort to show that there are happy customers that I could talk ... >that you are correct and that is what the reference refers to. ... >> except bland, experimental, generic benchmarks. ...
    (comp.os.vms)
  • Re: Visual Basic Ver 6.0 - Word 2003
    ... able to reference the 9.0 object library (on your dev PC if it has Word 2000 ... installed) and your app should work on a target PC even if Office 2003 is ... installed on the target PC. ... I think you need to pinpoint the line of code causing the error. ...
    (microsoft.public.vb.general.discussion)