Stuart McLachlan
stuart at lexacorp.com.pg
Wed Aug 11 16:00:17 CDT 2010
I often do that sort of thing with a batch file and a link in the SendTo folder. (which MS in their wisdom decided to hide in Vista/7 - it's now hidden in "C:\Users\XXXXXXXXXX\AppData\Roaming\Microsoft\Windows\SendTo" -- Stuart On 11 Aug 2010 at 7:05, Rocky Smolin wrote: > Lambert: > > That is extremely cool. Going to save me some real headaches . Tks. > > Rocky > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, > Lambert Sent: Wednesday, August 11, 2010 6:56 AM To: Access Developers > discussion and problem solving Subject: Re: [AccessD] Decompile > > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >