jwcolby
jwcolby at colbyconsulting.com
Wed Aug 11 07:05:38 CDT 2010
Dan, No, that is how it is done, as a parameter of a command line. John W. Colby www.ColbyConsulting.com Dan Waters wrote: > Hi Jim, > > I use decompile as an argument in the target field of a shortcut > (/decompile). It's the only way I know to initiate decompile. This > wouldn't allow me to target a specific code procedure. > > Is there another way to initiate decompile? > > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > Sent: Wednesday, August 11, 2010 12:00 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] "Testto Production"Procedures > forAccess2007application in asmall environment > > Hi Dan: > > I would imagine you would put the sleep function right after initiating the > decompile option. The decompile option is most likely designed as a stand > alone feature and therefore was not built to work within an application. > > There are no methods or properties you can use to check its progress, in the > conventional way where a 'do event' loop would work so 'Sleep' call is a way > to slow/stop your application from fighting with the decompile option for > resources. > > In a few applications I have running, the client used PDFCreator and there > was sample coding for handling that external feature and the 'Sleep' > function did the task of waiting until PDFCreator had performed its task and > was removed from memory. I think it could work with the external decompile > option as well... > > HTH > Jim > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, August 10, 2010 7:38 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] "Test to Production"Procedures > forAccess2007application in a small environment > > Hi Jim, > > I use the Sleep function for a few things - would you put this into the > startup code? Or would Sleep cause decompile to sleep also? > > Thanks! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > Sent: Tuesday, August 10, 2010 6:21 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] "Test to Production"Procedures > forAccess2007application in a small environment > > Hi Dan: > > You could use something like this in code: > > Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long) > > Public Sub... > ... > > Sleep 8000 ' Wait until Decompile is removed from memory > > End Sub > > Too bad there is not more (any) documentation on the function as a simple do > loop could then monitor a parameter and the apps progress. > > HTH > Jim > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, August 10, 2010 12:01 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] "Test to Production" Procedures > forAccess2007application in a small environment > > 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 >>