UCase not working in A97 runtime installation...

[MLH]

Have had a runtime installation up for 4 months. Upgraded
today with new ver 0.07 from 0.06. On launch, error reported...

Err in fn Initialize, module AutoExec, function isnt available in
query expression ... 'UCase([SerialNum])

This expression has been in all rev's of the app for 4 months.
I did not touch the runtime executable today. I merely copied
a new mde to the app dir. Got this error launching twice (am
launching remotely, not sitting at the console). Suspicions?

[Steve Jorgensen]

If the version of any referenced library on either machine has changed,
sometimes a database created on one machine won't work on the other. Usually,
you can fix this by installing windows updates on the failing machine or by
removing and recreating the reference on the failing machine, then using that
as the new master copy.

More than half the time when this happens, if you open the VB Editor on the
failing machine, and go to Tools -> References, one of them will say MISSING.
You need to remove that reference, close the References window, reopen the
window, and re-add the reference that was removed.

One really counterintuitive aspect to all of this is that if -any- reference
is broken, -none- of the references work.

On Wed, 14 Sep 2005 02:01:22 -0400, MLH <CR**@NorthState.net> wrote:

Have had a runtime installation up for 4 months. Upgraded
today with new ver 0.07 from 0.06. On launch, error reported...

Err in fn Initialize, module AutoExec, function isnt available in
query expression ... 'UCase([SerialNum])

This expression has been in all rev's of the app for 4 months.
I did not touch the runtime executable today. I merely copied
a new mde to the app dir. Got this error launching twice (am
launching remotely, not sitting at the console). Suspicions?

[MLH]

Thx, Steve. I'll have to go to the client's business, install Access
and open the VB Editor, giving your theory a test. Last night, I
remotely logged in, copied the most recent earlier app rev (0.06)
back into the app dir and launched - the problem does NOT occur
when it is run. I cannot think of anything I added during build of
rev 0.07 that resulted in the inclusion of an additional reference,
but you never know. I have been having some super strange
problems in my dev copy of 0.07 here - that's for sure. Have a look
at my recent post entitled...

"A97 closes down each time I open a particular report"

....and you'll see what I mean.

If the version of any referenced library on either machine has changed,
sometimes a database created on one machine won't work on the other. That's a bummer, huh? Users can cause this to happen without realizing
that it may cause something else on their machine not to work (IE, my
app!%$*&!!!). In your experience, is this a common occurrence?
Usually,
you can fix this by installing windows updates on the failing machine or by
removing and recreating the reference on the failing machine, then using that
as the new master copy.

More than half the time when this happens, if you open the VB Editor on the
failing machine, and go to Tools -> References, one of them will say MISSING.
You need to remove that reference, close the References window, reopen the
window, and re-add the reference that was removed.

One really counterintuitive aspect to all of this is that if -any- reference
is broken, -none- of the references work.

On Wed, 14 Sep 2005 02:01:22 -0400, MLH <CR**@NorthState.net> wrote:

Have had a runtime installation up for 4 months. Upgraded
today with new ver 0.07 from 0.06. On launch, error reported...

Err in fn Initialize, module AutoExec, function isnt available in
query expression ... 'UCase([SerialNum])

This expression has been in all rev's of the app for 4 months.
I did not touch the runtime executable today. I merely copied
a new mde to the app dir. Got this error launching twice (am
launching remotely, not sitting at the console). Suspicions?

[MLH]

I did this on my development box. Here are the available references
I found there...

Visual Basic For Applications
Microsoft Access 8.0 Object Library
Microsoft DAO 3.51 Object Library
Microsoft Calendar Control 8.0
driveList ActiveX Control module
Microsoft Windows Common Controls-2...
MMFWCtrl ActiveX Control module

The first 4, I believe I need. Am unsure about the next 2. But the
last one - honestly, I have no idea how it got there. Apparently its
located in c:\program files\musicmatch\musicmatch jukebox\mmfwctrl.ocx
Directory of c:\program files\musicmatch\musicmatch jukebox

02/10/2003 12:38 AM 81,920 MMFWCtrl.ocx
1 File(s) 81,920 bytes
0 Dir(s) 8,335,253,504 bytes free

Is it trash? I should uncheck it from my references, right?

[MLH]

Oh, and BTW...

The girl got in this morning and started running the app - UCase is
not the only built-in command that's failing. Others are occurring it
seems.

[Steve Jorgensen]

On Wed, 14 Sep 2005 09:31:22 -0400, MLH <CR**@NorthState.net> wrote:

I did this on my development box. Here are the available references
I found there...

Visual Basic For Applications
Microsoft Access 8.0 Object Library
Microsoft DAO 3.51 Object Library
Microsoft Calendar Control 8.0
driveList ActiveX Control module
Microsoft Windows Common Controls-2...
MMFWCtrl ActiveX Control module

The first 4, I believe I need. Am unsure about the next 2. But the
last one - honestly, I have no idea how it got there. Apparently its
located in c:\program files\musicmatch\musicmatch jukebox\mmfwctrl.ocx
Directory of c:\program files\musicmatch\musicmatch jukebox

02/10/2003 12:38 AM 81,920 MMFWCtrl.ocx
1 File(s) 81,920 bytes
0 Dir(s) 8,335,253,504 bytes free

Is it trash? I should uncheck it from my references, right?

Yup. It's a safe bet that's your problem reference.

[Steve Jorgensen]

On Wed, 14 Sep 2005 09:33:11 -0400, MLH <CR**@NorthState.net> wrote:

Oh, and BTW...

The girl got in this morning and started running the app - UCase is
not the only built-in command that's failing. Others are occurring it
seems.

That's normal. As I said, if one reference is broken, all references fail to
work. When that happens, your app is basically useless until you fix the
broken reference.

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:f4********************************@4ax.com:

I did this on my development box. Here are the available
references I found there...

Visual Basic For Applications
Microsoft Access 8.0 Object Library
Microsoft DAO 3.51 Object Library
Microsoft Calendar Control 8.0
driveList ActiveX Control module
Microsoft Windows Common Controls-2...
MMFWCtrl ActiveX Control module

The first 4, I believe I need. Am unsure about the next 2. But the
last one - honestly, I have no idea how it got there. Apparently
its located in c:\program files\musicmatch\musicmatch
jukebox\mmfwctrl.ocx
Directory of c:\program files\musicmatch\musicmatch jukebox

02/10/2003 12:38 AM 81,920 MMFWCtrl.ocx
1 File(s) 81,920 bytes
0 Dir(s) 8,335,253,504 bytes free

Is it trash? I should uncheck it from my references, right?

Well, uncheck it and see if your application works.

If it doesn't, you need it.

The only three that every Access 97 MDB should have are the first
three. Everything else you should have *only* if you are using that
library.

I would definitely recommend getting rid of any dependencies on the
Windows Common Controls, because MS dicks around with that library
so much that it is not cross-compatible between many versions, and
you have little control over which version will be installed on a
target machine. It also provides nothing that can't be done through
plain old Windows API calls, which never fail (and require no
references).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MLH]

Good. Hopefully getting to the bottom of this. I have the
8 references listed below that are checked on my development
box. The target client machine has ONLY the first three. David
Fenton indicated that I need the first three. I do use the MS calendar
control in the app, so I think it too is needed. I'll uncheck the
others on my DEV box and see if the app still runs on the DEV
box. On the target client box (where the app is SUPPOSED to
run), is it necessary that I open the app itself, then the VBA editor
on one of the modules to look at the references? Or, can I simply
start A97 on the client PC, open ANY mdb and check them there?
The reason I ask is because I normally deliver only MDE to client
and I'm unable, of course, to open the VBA editor on the MDE file.

Visual Basic For Applications
Microsoft Access 8.0 Object Library
Microsoft DAO 3.51 Object Library
Microsoft Calendar Control 8.0
driveList ActiveX Control module
Microsoft Windows Common Controls-2...
MMFWCtrl ActiveX Control module

[MLH]

You were EXACTLY right. Problem went away.

Yup. It's a safe bet that's your problem reference.

[MLH]

>Well, uncheck it and see if your application works.
Did so. App worked. Left 'em unchecked.

If it doesn't, you need it.

The only three that every Access 97 MDB should have are the first
three. Everything else you should have *only* if you are using that
library. I trashed 'em all but the Calender OCX
I would definitely recommend getting rid of any dependencies on the
Windows Common Controls, because MS dicks around with that library
so much that it is not cross-compatible between many versions, and
you have little control over which version will be installed on a
target machine. It also provides nothing that can't be done through
plain old Windows API calls, which never fail (and require no
references).

Done. Couldn't agree more.

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:cd********************************@4ax.com:

The reason I ask is because I normally deliver only MDE to client
and I'm unable, of course, to open the VBA editor on the MDE file.

If I'm not mistaken, you can't change references in an MDE at all.

That might be the source of your problem, actually.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MLH]

All is well now. Did the trick.