Project compilation crashes Microsoft Access

[Guest]

Hello! My name is Pavel.

I have a big project in Microsoft Access 2003 with hundreds of forms and
modules.
Every form or report have a module so. I use Implements of my own
interfaces, early binding if possible, own class modules, own events, may be
all of a VBA features. I don't use sign ! at all.
But it's not main thing. The crashes happen with any count of classes and
modules!

When I take changes to VBA code and try to compile project I can see that
the compilation progress bar is frozen, editor is not responding and finally
Access crashes. Some times I even afraid to click the buton Compile...
Exception every time is the same in vbe6.dll.
I think that a problem is in internal dependencies between objects.
Some module was not decompiled when other linked module was chenged.

My temporary solution is to Close/Open Access application. Every time when I
edit code, once compile, may be edit again, save changes, I quit Access and
run it again with /decompile option. My design-time and run-time are
different. I make a copy of mdb, prepare it for running and run it separately
from designed mdb.

So, my questions. What am I doing wrong? Why Access crashes while compile
entire project (thru Project\Compile menu)? What I have to do when I recieve
status loss message?

Thanks.

 

[Albert D. Kallal]

I don't use sign ! at all.

huh? You missed me somewhere? Use of the bang is preferred in those cases
where you are changing the reocordsouce of a form at runtime, then you MUST
use the bang to access the contents of a field (that is not bound on the
form).....since the "dot" is resolved at compile time. Sounds like someone
gave you bad advice, or your appraohc is just wong.

I would first make a copy. Then do a compact and repair....

if the above don't help, then try importing everything into a new blank
mdb..that should help.

another thing you can try is to de-compile. I had to do that quite often.

http://www.mvps.org/access/bugs/bugs0008.htm

And, some more reading on curruption can be found here:

http://www.granite.ab.ca/access/corruptmdbs.htm

 

[Guest]

Thank you Albert!

I have some comments to your posting.
Using of sign ! (bang).
It's very important to me to minimize run-time errors.
1. Compiler can check Me.MyControlName, and don't check
Me!MyMissedControlName.
2. ! simple replaces constructions like Me.Controls.Item("MyControlName") or
Rs.Fileds.Item("MyFieldName").
3. Case of identidier can be different for ControlSource and control name. I
can control it myself. In "" VBA editor don't change text case.

huh? You missed me somewhere? Use of the bang is preferred in those cases
where you are changing the reocordsouce of a form at runtime, then you MUST
use the bang to access the contents of a field (that is not bound on the
form).....since the "dot" is resolved at compile time. Sounds like someone
gave you bad advice, or your appraohc is just wong.

Me.Controls helps you.
For unbound controls this collection will return corresponding AccessField
object.

I would first make a copy. Then do a compact and repair....

if the above don't help, then try importing everything into a new blank
mdb..that should help.

another thing you can try is to de-compile. I had to do that quite often.

Right! But I'm tired every time to do this. I don't know before I click
compile if Access will hang up or not.
May be I prefer to syntax check without compile. Or full recompile without
living opened Access.

Best regards,
Pavel

 

[Albert D. Kallal]

Using of sign ! (bang).

It's very important to me to minimize run-time errors.
1. Compiler can check Me.MyControlName, and don't check
Me!MyMissedControlName.

Correct. However, if you in code replace the recordsouce of the form at
runtime, THEN YOU CAN NOT resolve to a field name in the underlying
reocrdset using the "dot" format. That all I saying. If you change a forms
reocrdset at runtime (and I do that a lot), then you either must


a) use bang to reference a field
or
b) ensure you have a control on the form that is bound to the field
(the result of this is that you OFTEN see a whole pile of invisible
controls piled up in the corner of the form because the developer
did not know you can use bang.

So, yes, for *most* of my code and anytime I reference a control on a form,
I use "dot".

However, when I have code that changes the reocrdsouce of the form, and I do
NOT want the control on the form, you MUST USE the bang notation, as this
can't be resolved at runtime. (or you *must* place a contorl on the form
with the same name)

So, I was just explain that you MUST use bang if the control is not on the
form, and you change the reocrdsouce (it not a choice...it *have* to do it
this way)

 

[Guest]

RTFM
Me!Any == Me.Controls.Item("Any") //form
Rst!Any == Rst.Fields.Item("Any") //recordset
Col!Any == Col.Item("Any") //Collection
And don't say *MUST" please.

Help me with CRASH on compile!!!

 

[David W. Fenton]

Help me with CRASH on compile!!!

Have you decompiled? Or are you ignoring that piece of Albert's good
advice, too?

 

[Guest]

Hello David!

I know how to decompile.
But project compilation at any time is unpredictable. It's a main problem.
Crash or not. 50/50.

When exception is in vbe6.dll who can say what's going on?

If you will run with /decompile, 1st time compile always will be ok. But 2nd
time compilation may be not ok. There is difference how to compilation work.
The best way before compilation is to decompile all internally (without
exiting Access) and compile from 0 start point when all modules was
decompiled.

Pavel.

 

[David W. Fenton]

I know how to decompile.
But project compilation at any time is unpredictable. It's a main
problem. Crash or not. 50/50.

When exception is in vbe6.dll who can say what's going on?

If you will run with /decompile, 1st time compile always will be
ok. But 2nd time compilation may be not ok. There is difference
how to compilation work. The best way before compilation is to
decompile all internally (without exiting Access) and compile from
0 start point when all modules was decompiled.

Huh? That's the *only* way that decompile works -- you decompile the
whole project, compact to remove the discarded data pages, then
compile the whole project again (and compact after that to remove
any unnecessary crud resulting from the compile operation). This is
the only way a decompile has any useful effect on your project.

Do you have COMPILE ON DEMAND turned off?

What version of VBE6.DLL do you have?

 

[Guest]

Hello!
It would be desirable to hear the opinion of the developers of VBA.

news:[email protected]:

Huh? That's the *only* way that decompile works -- you decompile the
whole project, compact to remove the discarded data pages, then
compile the whole project again (and compact after that to remove
any unnecessary crud resulting from the compile operation). This is
the only way a decompile has any useful effect on your project.

1. Editor context is lost.
2. I want to compile with the confidence that the project will not
unexpectedly closed.
3. I compile in order to correct the possible errors.

Do you have COMPILE ON DEMAND turned off?

I turn it off. This does not influence the stability.

What version of VBE6.DLL do you have?

Many versions has the same results. Tested on Access 2002 SP3, 2003 SP2, 2007.

Best regards,
Pavel

 

[David W. Fenton]

It would be desirable to hear the opinion of the developers of
VBA.

Have you read Michael Kaplan's article on this subject?

http://trigeminal.com/usenet/usenet004.asp?1033

He wasn't on the VBA team, but he knows whereof he speaks.

1. Editor context is lost.
2. I want to compile with the confidence that the project will not
unexpectedly closed.
3. I compile in order to correct the possible errors.

Eh? Dunno what you are talking about.

A decompile is something that you don't do often, only occasionally,
as a preventive measure to prevent code corruption.

I turn it off. This does not influence the stability.

Perhaps not for the error you are having, but for general coding, it
certainly *does* enhance stability.

Many versions has the same results. Tested on Access 2002 SP3,
2003 SP2, 2007.

If you're not going to answer the question, then I'll offer you no
more advice.