Create MDE CRASH

[fishbaugher]

I have encountered some interesting crashes lately (Access97). Here is
the symptom (after several days of different kinds of rebuilds
including import and LoadFromText, all resulting in databases with the
same symptoms).

1) Working database, Compile/Save All works, Create MDE works
2) Touch the references (mark a new reference, OK, then Unmark)
3) Create MDE works
4) Compile/Save All works
5) Now try creating MDE from the compiled state, CRASH (vba332.dll
access violation)

HMM...so the story continues

6) /decompile the database from step 5
5) You find yourself back at step 3 where you can build an MDE from an
uncompiled state. You can compile/save all without error, but if you
try to create an MDE from a compiled state then CRASH in vba332.dll

Obviously something wierd with references -- but what?? All the file
locations, regsvr32 registration, and versions check out. I am using
quite a few external DLL and OCX files (in addition to the standard 3
Access/VBA/DAO I have 10 references). This database and the set of
references has not given me any problems in the past. Recenty I added
one new OCX (IP*Works FileMailer). In fact a backup copy of the
database from a year ago with the same set of references (including the
new fileml60.ocx) does NOT exhibit this same behavior...

I've read some good stuff on how references work:

http://allenbrowne.com/ser-38.html

but no google/group search show anyone else experiencing this. Any
help is seriously appreciated

[bruce]

fishbaugher wrote:

I have encountered some interesting crashes lately (Access97). Here is the symptom (after several days of different kinds of rebuilds
including import and LoadFromText, all resulting in databases with the same symptoms).

1) Working database, Compile/Save All works, Create MDE works
2) Touch the references (mark a new reference, OK, then Unmark)
3) Create MDE works
4) Compile/Save All works
5) Now try creating MDE from the compiled state, CRASH (vba332.dll
access violation)

HMM...so the story continues

6) /decompile the database from step 5
5) You find yourself back at step 3 where you can build an MDE from an uncompiled state. You can compile/save all without error, but if you
try to create an MDE from a compiled state then CRASH in vba332.dll

Obviously something wierd with references -- but what?? All the file
locations, regsvr32 registration, and versions check out. I am using
quite a few external DLL and OCX files (in addition to the standard 3
Access/VBA/DAO I have 10 references). This database and the set of
references has not given me any problems in the past. Recenty I added one new OCX (IP*Works FileMailer). In fact a backup copy of the
database from a year ago with the same set of references (including the new fileml60.ocx) does NOT exhibit this same behavior...

I've read some good stuff on how references work:

http://allenbrowne.com/ser-38.html

but no google/group search show anyone else experiencing this. Any
help is seriously appreciated

I'm curious about a few things...

1) Are the references in your working backup copy of the database (the
one from which you can create a compiled MDE) in the same order as the
references in the current database (the one from which your MDE
crashes)?

2) Do the references in your working backup copy refer to exactly the
same files? While the reference names (e.g.'Microsoft DAO 3.6 Object
Library' may be the same in both databases, they might point to
different underlying files.

3) Are the working backup and the current database identical?

[fishbaugher]

I'm curious about a few things...

1) Are the references in your working backup copy of the database (the one from which you can create a compiled MDE) in the same order as the references in the current database (the one from which your MDE
crashes)?

I've isolated the problem even further since my last post. I start
with a working backup copy of my MDB file (compile/save OK, MDE build
from compiled state OK) with the following references:

ReferenceName FullPath Version
VBA C:\Program Files\Common Files\Microsoft
Shared\VBA\VBA3 32.DLL 3.0.0.7019
Access C:\Program Files\Microsoft
Office97\Office \MSACC8.OLB 8.0.0.3512
DAO C:\Program Files\Common Files\Microsoft
Shared\DAO\DAO3 50.DLL 3.51.1608.0
DUZACTXLib c:\windows\syst em32\duzactx.dl l 4.0.0.4
DZACTXLib c:\windows\syst em32\dzactx.dll 4.0.0.4
MSMAPI C:\WINDOWS\syst em32\MSMAPI32.O CX 6.0.81.69
csXImage C:\WINDOWS\syst em32\csXImage.o cx 1.3.0.6
MSComDlg C:\WINDOWS\syst em32\comdlg32.o cx 6.0.84.18
PWSTREETLib C:\WINDOWS\syst em32\Pwstrv2.oc x 2.0.0.40
IMAGETHUMB C:\WINDOWS\syst em32\ImageThumb nailCP.ocx 1.0.0.1
MSComCtl2 C:\WINDOWS\syst em32\MSCOMCT2.O CX 6.0.81.77
CRCCTRLLib C:\WINDOWS\syst em32\CrcCtrl.oc x 1.1.0.0

I then make a copy of the MDB file. Then if I even TOUCH the
references (either by adding anything or just marking then unmarking a
reference) the MDE build from an UNCOMPILED state still works. If I
then do a Compile/Save All, subsequent MDE builds crash vba332.dll as
indicated during the MDE build.

TIA

[DFS]

fishbaugher wrote:

I have encountered some interesting crashes lately (Access97). Here is
the symptom (after several days of different kinds of rebuilds
including import and LoadFromText, all resulting in databases with the
same symptoms).

1) Working database, Compile/Save All works, Create MDE works
2) Touch the references (mark a new reference, OK, then Unmark)
3) Create MDE works
4) Compile/Save All works
5) Now try creating MDE from the compiled state, CRASH (vba332.dll
access violation)

HMM...so the story continues

6) /decompile the database from step 5
5) You find yourself back at step 3 where you can build an MDE from an
uncompiled state. You can compile/save all without error, but if you
try to create an MDE from a compiled state then CRASH in vba332.dll

Obviously something wierd with references -- but what?? All the file
locations, regsvr32 registration, and versions check out. I am using
quite a few external DLL and OCX files (in addition to the standard 3
Access/VBA/DAO I have 10 references). This database and the set of
references has not given me any problems in the past. Recenty I added
one new OCX (IP*Works FileMailer). In fact a backup copy of the
database from a year ago with the same set of references (including
the new fileml60.ocx) does NOT exhibit this same behavior...

I've read some good stuff on how references work:

http://allenbrowne.com/ser-38.html

but no google/group search show anyone else experiencing this. Any
help is seriously appreciated

fish,

This may help http://support.microsoft.com/default...b;en-us;302986

[aatcbbtccctc]

Make sure that any references to DbEngine methods (in your code) are
explicitly qualified with the "dbengine" keyword. Eg.
dbengine.openda tabase, not just opendatabase.

Omitting that keyword can cause weird DAO licencing errors, including
the inability to create an MDE.

HTH,
TC

[Rick Brandt]

fishbaugher wrote:

I have encountered some interesting crashes lately (Access97). Here is
the symptom (after several days of different kinds of rebuilds
including import and LoadFromText, all resulting in databases with the
same symptoms).

1) Working database, Compile/Save All works, Create MDE works
2) Touch the references (mark a new reference, OK, then Unmark)
3) Create MDE works
4) Compile/Save All works
5) Now try creating MDE from the compiled state, CRASH (vba332.dll
access violation)

My main app that I work on has behaved similarly for a couple years now. I
can work on it and compile open modules, but if I do a "Compile and Save All
Modules" it will work, but I am unable to make an MDE from the result. I
tried _every_ method of fixing it to no avail so I just stopped doing full
compiles on it.

My deployment routine now is...

Compact onto a separate copy
Make MDE from that separate copy
Compact from separate copy back onto original
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[fishbaugher]

DFS wrote:

fish,

This may help

http://support.microsoft.com/default...b;en-us;302986

Yes, I had seen this article. Rather scary to think that VBA does not
protect its OWN reserved word name space. Rather implies that the MS
VBA compiler is --- do I dare say it -- BROKEN.

In anycase, I have reviewed my function/proc names to ensure there is
nothing that looks like a reserved word. Which leaves 'database
corruption' as the only other offered explanation.

[fishbaugher]

Rick,

This sounds like my EXACT symptom. Thanks for sharing with me. Maybe
we can hunt down the root cause together. I also have tried every
concievable rebuild method to no avail. That includes a complete
rebuild from text (having recently discovered the loadfromtext
methods). I strongly suspect something is going on with reference.
What does your list of references look like?

Have you noticed any strange interactions with references? Have you
tried making MDEs directly after a /decompile? When you make an MDE
from a compile state, does MSAccess crash in vba332.dll?

MJF

[Rick Brandt]

fishbaugher wrote:

Rick,

This sounds like my EXACT symptom. Thanks for sharing with me. Maybe
we can hunt down the root cause together. I also have tried every
concievable rebuild method to no avail. That includes a complete
rebuild from text (having recently discovered the loadfromtext
methods). I strongly suspect something is going on with reference.
What does your list of references look like?
I never have anything but the default three references in my apps.

VBA
C:\Program Files\Common Files\Microsoft Shared\VBA\VBA3 32.DLL
Access
C:\Program Files\access97\ Microsoft Office\Office\M SACC8.OLB
DAO
C:\Program Files\Common Files\Microsoft Shared\DAO\DAO3 50.DLL

Have you noticed any strange interactions with references? Have you
tried making MDEs directly after a /decompile? When you make an MDE
from a compile state, does MSAccess crash in vba332.dll?

I can make MDE after a decompile. I can make an MDE _any_ time with the one
exception being if I do a "Save and Compile All".

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[fishbaugher]

I never have anything but the default three references in my apps.

VBA
C:\Program Files\Common Files\Microsoft Shared\VBA\VBA3 32.DLL
Access
C:\Program Files\access97\ Microsoft Office\Office\M SACC8.OLB
DAO
C:\Program Files\Common Files\Microsoft Shared\DAO\DAO3 50.DLL

Have you noticed any strange interactions with references? Have you tried making MDEs directly after a /decompile? When you make an MDE from a compile state, does MSAccess crash in vba332.dll?
I can make MDE after a decompile. I can make an MDE _any_ time with

the one exception being if I do a "Save and Compile All".

Have you tried refreshing your references? Just add any reference,
press OK, then go back and unselect the reference. Then try an MDE
build from a compiled state. Does that make a difference?