Access app does not run under access runtime

[MusMou]

Hi,
I developed a serial COM application it runs under access 2000, 2002, 2003
but not under access runtime version 10 (Access Runtime version 2002).
The application is compiled to an MDE file.
What shall I do to solv the problem?

thanks a lot
mumose

 

[Albert D. Kallal]

Does the apcpation work on your machine when you use the /runtime switch?

if yes, then, it does mean that it should be able to run on a target
machine.

however, you don't mention if you are in fact using activeX com control, and
if you don't install it on the target machine, it will not work...

So, have you tired use the /runtime switch on them machine that works?

The application should work, but it not clear what serial communications
object your using....

Further, are you using automation in your application? You can NOT launch a
2nd copy of ms-access (via automaton). The reason for this is that the
runtime version requires you supply a mdb (or mde) file for the runtime to
open, and you CAN NOT do this via automaton, and thus you can NOT use
ms-access as a automaton object in runtime mode.....

So, if you have some other program (like VB), and you automating ms-access,
you can't do this in the runtime.

 

[MusMou]

Hi,
the app. runs on my machime on both access 2000 and access 2003 with the
runtime opption.
I´m using MSCOMM32.OCX, the app. has an installation program witch registers:
VBE6.DLL, msacc9.olb, dao360.dll, MSCOMM32.ocx and msado21.tlb

the machine on witch the app. does not work has Access Runtime version 2002

Is it a referens error or... something else?

I would like to know what do you mean with automation? an ex. if possible

/mumose

 

[David W. Fenton]

I?m using MSCOMM32.OCX

It's a huge mistake to use that library, which is so incredibly
changeable in all its versions that you can never be sure anything
with it will work. It's much easier to just use straight Windows API
calls for file open/save dialogs (if that's what you're using it
for).

 

[Albert D. Kallal]

Hi,
the app. runs on my machime on both access 2000 and access 2003 with the
runtime opption.
I´m using MSCOMM32.OCX, the app. has an installation program witch
registers:
VBE6.DLL, msacc9.olb, dao360.dll, MSCOMM32.ocx and msado21.tlb

Are you sure you using the right version of mscomm32.ocx? You do realize
that ocx controls have licensing built in, and you can' t just copy the ocx
control, and execute a regsvr32 on it. (that is NOT enough). You have to use
the correct version, and a developers edition of the ocx control, else it
will not work.

the machine on witch the app. does not work has Access Runtime version
2002

Is it a referens error or... something else?

Well, my car is broken? How is that? It very little to go on here.

You just going to have to work you way through this stuff. There is no magic
answer...

Have you tried installing the full version on that machine?

Have you setup a test machine, and tried it on that?

Have you tired the /runtime switch on your machine as I suggested...did that
work?

Is this problem on one machine, or only on a test machine with the runtime.
Did you try installing the full version of ms-access on that garget
machine..and did that work?

I would like to know what do you mean with automation? an ex. if possible

Well, obviously if you don't what it is, then not likely your problem!!!

However, all automaton means is are you launching, or running another
application.

For example, to launch word, and open a document from ms-access code, you
can go:

Dim wordApp As Object ' running instance of word
dim strDocName as string

strDocName = "c:\my docs\myword.doc"
Set wordApp = CreateObject("Word.Application")

Set WordDoc = wordApp.Documents.Open(strDocName)
wordApp.Visible = True
wordApp.Activate

So, the above is what we call automaton. And word, or excel, (or vb) can
automate ms-access in much the same way. However, as I mentioned, the
runtime DOES NOT permit you to use automaton to launch a copy of ms-access
as above.

You need to setup some test machines here. Even better then test machines
is to use virtual pc, and it is free.....

 

[MusMou]

I´m using the library for a serial com. application with a device.
is there any ather stable library wicth I can use instead?

 

[MusMou]

but it work on machines witch has access installed 2000, 2002 and maby later
versions why not on access runtime?

 

[Albert D. Kallal]

but it work on machines witch has access installed 2000, 2002 and maby
later
versions why not on access runtime?

Well, we don't know why yet, and that is why I suggestion to try some of
those things. If you not willing to try anything, then how on earth are we
going to track down and resolve this problem? I can tell you where the
toilet paper is,, but I not going to wipe the crap off of your butt for you.

We simply don't know if this is a runtime issue, or something else on those
machines.

The fist thing I suggested to you to check is does the /runtime switch
prevent this from working
on machines with the full version that are *known* to work just fine.

does that work, or does it make your application fail? the reason for asking
this is

a) if it fails on your machine, then we know it something to do with the
runtime
b) if it works on your machine, then either

a) the runtime is missing something on that target machine
b) the fuller version of ms-access installs something you need
c) this switch also tells us that we *can* likely get this to
work *if*
it runs ok with the runtime swtich. If it don't work, then
know right
away!!!

I also suggest that there are some things that the runtime can't do (such as
be automaton). There are a few other features, but they are not likely eh
cause (but, using the runtime switch would tell us that also).

Now, if you not going to try any of he above suggestions, then I can't help
you.

further, does installing the full version that machine that don't work fix
this?

however, each of the suggestions I made are harder to test in ascending
order. The runtime switch is the first thing I would try. maybe your ocx
control is not reigned correctly on that machine. I simply don't know, but
CAN ONLY SUGGEST things for you to try,a nd those answers will bring us down
he path of finding the answer. That is how trouble shooting works (in case
you did not know!!).

Testing the runtime switch will instant tell us if the runtime can't work.
If it runs on your machine, then the problem is more difficult to track
down, but it means the runtime edition *will* work on your machine..but not
on those target machines (then, this means we looking for something that the
full version installs,, or perhaps some references issue, or perhaps as I
mention, the automaton issue).

So, try the runtime switch. If it don't work, then we found our answer. If
it does work, then as mentioned, then we have to track down, and try other
ideas but if you don't try any of them, then I can't be of any help....

 

[Chris Mills]

<heh-heh>

the more diplomatic response, Albert, might be
"I can lead a horse to water, but I can't make it drink!"
GUFFAW!!!

I don't remember this being mentioned, but somewhere in the stuff you get with
Developers Edition or equivalent, is a list of the files which you are
"licensed" to distribute with Access Runtime.

If the file is on the list, then you should reasonably expect to be able to
distribute it.

If the file is not on the list, then you would need some sort of "special
arrangement"

The "special arrangements" Albert suggested (the right version, regsvr32,
other possible technical "licensing"), all sound like traps to me. If you say
it already works on some machines and not others, then what is the difference?
(you say the obvious difference is just "Runtime", but for all I know there
could be something besides)

It is true, that sometimes I've read someone thinking it was just easier to a)
have them all get full Access b) use a more professional installer than PDW
Setup, such as www.sagekey.com.

It is also true, that anytime you mention something like MSCOMM32.OCX, you
will get responses that extra references are best avoided! There is a reason
for that! (eg your own post).

This is not to say whether your particular concern can be done without that
ocx.

But I would think that Albert has pointed to the common reasons (and all the
ones I know about) why an ocx would not work on that machine. It surely would
work with Access Runtime, but it seems you are assuming it is INSTALLED with
Access Runtime. I doubt that very much.

Run one of your working machines with /Runtime on the command line. Then, on
that machine, remove Access and install Runtime Access, the assumption being
that the ocx is already adequately registered on that machine. All this takes
forever at $100/hr of course, but I have to do things like that so why not
you? In the end, I would likely find it was not registered properly in some
way, as Albert suggested in the first place!

Of course, I've learnt just enough to be dangerous, in this case to never
contemplate that ocx in the first place! (replace it with equivalent direct
Windows system calls, which is hardly more difficult)

HTH
Chris

 

[David W. Fenton]

I?m using the library for a serial com. application with a device.
is there any ather stable library wicth I can use instead?

There are surely direct API calls, since that's usually what an OCX
is a wrapper around. I'd Google for VB and "serial" and see what I
came up with.

 

[RHutcheson via AccessMonster.com]

If you do still need to use the OCX you mentioned, you can try having a copy
of the one that works installed in the same directory that your app is
installed in. The OS should use that version by default for your application
before it goes off looking for the OCX somewhere else. This method assures
that the "right" version is used by your app and that it won't get "updated"
to a different version by some future service pak and then your app would no
longer work correctly. See if this fixes your current problem.

RHutcheson

 

[MusMou]

I have a copy of the working version in the app. directory.

thanks to all of you especialy Albert.
I could not try some of the suggestions because the installation is at a
site of a customer (demo). I developed the app. but never had the
opportiunity to test it in a pure access runtime enviroment, but it works
when running with the /runtime opption.