Doug Murphy
dw-murphy at cox.net
Tue Aug 10 16:03:29 CDT 2010
It might be informative to re-read Michael Kaplan's 1999 article on Decompile http://www.trigeminal.com/usenet/usenet004.asp?1033 . He pretty much supports the "It may do more damage than good thought.". Backup is good! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Tuesday, August 10, 2010 10:08 AM 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