[AccessD] VBA project corruption

Dan Waters dwaters at usinternet.com
Wed Jul 5 19:52:51 CDT 2006


Hello Steve!

I believe that the decompile/compile issue is something that only a
developer needs to worry about, because you only need to do this with code
that is undergoing development.  Once deployed, the code doesn't change, and
won't bloat.

I got caught once installing a system that had a compile error, and it
opened in the code window on the VP's PC with a bright yellow line.  :-(  So
I put in a routine that automatically compiles the FE of my app each time it
shuts down normally.  So, if I've screwed up the code it'll get caught on my
PC instead of my client's PC.

Compact/Repair is something that will be a problem for users.  I have a
routine that forces a compact/repair of the BE when the LAST user logs out.
The BE has the Compact on Close option checked, and the code in the FE
simply opens and immediately closes the BE file.  A status bar progress bar
runs when this occurs.

The FE on each client will compact/repair every time it's closed (I use a
lot of FE Temp tables).  This happens in a few seconds so no one complains.
I just check the Compact on Close option.

All the best!
Dan 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Capistrant
Sent: Wednesday, July 05, 2006 5:38 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] VBA project corruption

Dan,
I think we'll get in that habit, but with a slight twist, because this
app is used by end-users in MDE format.  So they'd never tolerate the
load delay.  But the app has a "Tune Up" feature in the administrative
area, which runs a bunch of troubleshooting routines.  

Or maybe we force decompile/recompile(and other hygiene functions like
Compact/Repair) to run on a schedule (e.g. once every 10 times it
opens).  We've tried standardizing compact on exit, but it seems to
cause user confusion (why so slow to close?) and file chaos (relaunch
right away, causing the db1.mdb temp file to abort and get stranded).

Thanks again to all of you who gave advice to solve the problem!

Steve Capistrant
Symphony Information Services
scapistrant at symphonyinfo.com
www.symphonyinfo.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Wednesday, July 05, 2006 5:16 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] VBA project corruption

Excellent!

A couple of things you might to do:

1) Always use a shortcut to open the app.  In that shortcut, include the
/decompile after the path to your app.  So the app gets decompiled every
time it's opened.

2) In the VB window, modify the Standard toolbar.  Add a Compile button
next
to the Properties Window button.  Now you can Compile quickly whenever
you
want.

Doing both of these helps a lot to keep the database small and the code
healthy.

Dan Waters


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Liz Doering
Sent: Wednesday, July 05, 2006 4:28 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] VBA project corruption

Andy, Bill, William and Dan,

Steve handed this issue off to me--being the boss has some
advantages--for him!  :)
 
Turns out, this is a .dll problem, not an actual object corruption
problem.  Microsoft explains it all here:
http://support.microsoft.com/?scid=kb;EN-US;304548. 
 
I didn't like the solutions they offered, which included exporting
objects to text files and reimporting them.  There are nearly 900 forms,
reports and modules in this .mdb!  Using the advice from
http://www.granite.ab.ca/access/decompile.htm, I made a .bat file to
decompile with 2003, ("C:\Program Files\Microsoft
Office\OFFICE11\MSAccess.exe" /decompile).  Once the decompile had run
(a long time), I saved the file to 2003 format and all was well.   

I imagine that this is because 2003 is playing nicely with version
6.3.91.8 of the Vbe6.dll file, unlike 2000.  But I don't understand why
just opening the thing in 2003 didn't have the same effect.  

Thanks for all your help!



Liz Doering
Symphony Information Services
ldoering at symphonyinfo.com
www.symphonyinfo.com
763-391-7400 x802

 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list