[AccessD] "Test to Production" Procedures for Access2007application in a small environment

Dan Waters df.waters at comcast.net
Tue Aug 10 14:01:04 CDT 2010


I've discovered a fairly repeatable problem with decompile.

One of my files has about 23,000 lines of code.  If I decompile this (or
other sizable access files), and immediately open a code module, the file
will often close with the 'corrupt' message, and then try to send a message
to MS.

But if I wait about 10 seconds after the database window opens before I open
a code module, then everything works fine.

My theory is that with a file with this many lines of code, Access is still
removing the p-code at the same time I'm trying to open a module, and that
causes some kind of conflict, thus causing 'corruption'.

I went through a lot of these 'corruption' messages before I figured out
that just waiting a little while will prevent the issue.

HTH,
Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Tuesday, August 10, 2010 12:08 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] "Test to Production" Proceduresfor
Access2007application in a small environment

John,

<<It is not technically correct to say that Decompile is untested.  It is
undocumented.>>

  I would whole heartedly dis-agree.  MS does not include /decompile as any
part of their official test of Access for release. I don't consider use by
end users to be testing.

<<I have used decompile for many years and never had a failure specifically
caused by the act of 
decompiling.  YMMV.  I consider decompile 100% solid.>>

 As I said, it works 99.99% of the time, but I have personally seen two
instances where the use of /decompile trashed a database.  In fact you can
get it to trash a DB with a single line of code.  My preference has and
always will be to import everything into a fresh DB container (p-code does
not get imported).

<<Decompile was created long ago by Microsoft (of course) to allow beta
testers a means of flushing 
the pcode buffers and forcing a new compile of code. >>

  More specifically, it was created during the A2 to A95 conversion when
they were switching from Access Basic to VBA.  They were changing the
runtime binaries from sub-release to sub-release (which at the end was
weekly), so any existing p-code would be invalid.

  At that time, importing everything into a fresh DB container was a
difficult process as you needed to copy toolbars and import/export specs by
hand.  A lot of the beta testers complained, so Microsoft came up with
/decompile.  I know because I was there.

  But today, with the way import/export now works, it's really not needed.
But some still insist on using because they don't understand what it does or
why it was created.  You would not believe the number of people that I run
into that believe it does something magical to the db and give it credit for
doing a lot more then simply invalidating the p-code (if they even know
that).

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, August 10, 2010 12:11 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] "Test to Production" Procedures for
Access2007application in a small environment

Brad / Jim

It is not technically correct to say that Decompile is untested.  It is
undocumented.

Decompile was created long ago by Microsoft (of course) to allow beta
testers a means of flushing 
the pcode buffers and forcing a new compile of code.  It remains
"undocumented" because Microsoft 
does not want to be liable for any damage caused by its use, and perhaps
more realistic, because MS 
does not want to publicize the fact that VBA would have bugs forcing a
decompile.

Of course you should back up your database before use.  OTOH you should
backup your database anyway.

I have used decompile for many years and never had a failure specifically
caused by the act of 
decompiling.  YMMV.  I consider decompile 100% solid.

Your English language VBA code is "compiled" (interpreted really) and turned
into PCode, and placed 
into specific places in the MDB.  The PCode is what actually runs.  In fact
the PCODE is what is 
shipped in an MDE when you "strip out" the vba text files.

Decompile really is just a flush of the pcode streams.  Flushing those
buffers is a really low risk 
operation in the overall scheme of things.


John W. Colby
www.ColbyConsulting.com


Brad Marks wrote:
> Jim,
> 
> Thanks for the advice.  I was not aware that Decompile was undocumented
and perhaps not 100% solid.  I plan to incorporate your ideas into our
procedures.
> 
> Sincerely,
> Brad
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com on behalf of Jim Dettman
> Sent: Mon 8/9/2010 9:28 AM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] "Test to Production" Procedures for Access2007
application in a small environment
>  
> Brad,
> 
>   I think the only thing I would add is:
> 
> 1. A backup of the new changed ACCDB file before attempting a decompile.
> Folks need to remember that while decompile does work 99.9% of the time,
it
> still is an undocumented and untested switch by Microsoft.  If rare cases,
> it can mess up a DB.
> 
> 2. I generally make an archive copy of the existing production database
> before copying over it.  That why, if there is some form of corruption in
> new DB, I have a "Last known good copy" to fall back on.
> 
>   Also, not sure how your handling versioning, but I keep a local table in
> the db, tblAppVersionControl, which has the version number, developer
notes,
> end user message, and release date.
> 
> Jim. 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
> Sent: Monday, August 09, 2010 10:19 AM
> To: accessd at databaseadvisors.com
> Subject: [AccessD] "Test to Production" Procedures for Access 2007
> application in a small environment
> 
> All,
> 
> 
> I am in the process of establishing procedures for promoting changes from
> our Development (TEST) environment to our Production environment.
> 
> 
> The Access 2007 application uses data from a SQL Server database.  There
are
> no local tables.  The application is made available to the end-users as an
> .ACCDR file.
> 
> 
> I have one folder on the server for TEST and a second folder for PROD.
> 
> 
> Here the steps that I am currently using.
> 
> 
> Changes to the Access 2007 application are made and tested in the TEST
> folder (ACCDB file).
> 
> 
> Decompile ACCDB
> 
> 
> Compile ACCDB VBA code  / Save it
> 
> 
> Compact and Repair ACCDB / Save it
> 
> 
> Run a Utility to Copy the ACCDB file in the TEST folder to the ACCDR file
in
> the PROD folder.
> 
> 
> I am curious if these steps are similar to the steps that others use and I
> am curious if I am overlooking anything.
> 
> 
> 
> Thanks,
> 
> Brad
> 
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
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