jwcolby
jwcolby at colbyconsulting.com
Tue Aug 10 16:53:03 CDT 2010
LOL, I have read that. I am just giving my experience. I learned about /decompile back in '97 or so and have been using it since. I ROUTINELY decompile / compile / compact / repair. In fact I have dedicated icons for opening Access with the decompile switch. Any time I have those "can't solve it any other way" moments I decompile. I have never had a database corrupt due to the decompile. OTOH, it might happen tomorrow, who knows. And if it truly were 99.99% reliable (a number picked from thin air of course) then you are talking 1 in 10K times used. Let's just say that since 1997 I have probably decompiled a thousand times and never had a corruption. Backup is certainly good! As for Jim's export / import, it certainly is "better" however it can be a royal PITA and is almost certainly more work than just opening a file with /decompile, closing, reopening without and then compiling the database. My clients can do a decompile / compile just using the shortcuts I give them. John W. Colby www.ColbyConsulting.com Doug Murphy wrote: > 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 >>