[AccessD] "Test to Production" Procedures for Access2007 application 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
>