David McAfee
davidmcafee at gmail.com
Wed Aug 11 12:18:01 CDT 2010
I used to do something similar. In Win XP, I had a short cut to Access with the /Decompile and placed it in my SendTo folder, so I would just right click on an mdb and choose send to -> Acces-Decompile. :) On Wed, Aug 11, 2010 at 6:56 AM, Heenan, Lambert <Lambert.Heenan at chartisinsurance.com> wrote: > All who are following this thread: > > I use a couple registry entries that add "Compact' and 'Decompile' to the Explorer context menus. So all I need to do it right-click and MDB file and select whichever action I want done. > > You can set this up from within Explorer thus: > > 1/ Select Folder Options from the Tools menu. > 2/ Select the File Types tab in the dialog and locate the MDB extension. > 3/ Click the 'Advanced' button. > 4/ Click the New button to add a new action. > 5/ Enter the action name Decompile and in the "Application used to perform action" box type the command line, which will be of this form... > > "C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" /decompile "%1" > > All of those quote marks are required. > > 6/ Repeat for 'Compact' using this form of the command line... > > "C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" "%1" /compact > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin > Sent: Wednesday, August 11, 2010 8:59 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Decompile > > Dan: > > I use the Run box with a command like: > > "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" > C:\Clients\E-Z-MRP23\E-Z-MRP-Ver2363.mdb /decompile > > Since there's a history, I don't have to re-key the whole thing every time - just change the path and name of the mdb. > > Rocky > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Wednesday, August 11, 2010 4:57 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Decompile > > 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 >> > -- > 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 > > -- > 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 > > -- > 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 > > -- > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >