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

Heenan, Lambert Lambert.Heenan at chartisinsurance.com
Tue Aug 10 11:28:47 CDT 2010


I'm pretty sure that M$ got around to documenting /decompile in version 2007 and higher, though I have not yet inflicted myself with that version. Anyone care to search Help and confirm?

Lambert 

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