jwcolby
jwcolby at colbyconsulting.com
Tue Aug 10 15:14:04 CDT 2010
Fascinating and good to know. John W. Colby www.ColbyConsulting.com Dan Waters wrote: > 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 >>