Rocky Smolin
rockysmolin at bchacc.com
Wed Aug 11 10:05:58 CDT 2010
Doesn't switching from one version of Access to another give you that long
'Installing...' delay?
R
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Wednesday, August 11, 2010 7:58 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Decompile
I used to do that for opening secured .mdb's and .mdbs with different
versions of Access. (So right clicking on an .mdb would give me 'Secured
97, Access 97, Secured 2003, Access 2003'...)
Problem is, that Windows 7 doesn't give you a direct interface to do that.
There are free tools that let you do it, and you can actually just copy the
registry values from one machine to another. Stopped doing it though,
because Access 97 doesn't play very nice with Windows 7, when you switch
between versions. (It works fine on it's own, but when you've used 2003,
then go to open 97, it tries to change registry entries that Windows 7 won't
allow (if UAC is turned on). So either you have to run it in 'Administrator
mode' or it won't start, and kicks out a registry error. Going back the
other way, however, doesn't give any errors, and works just fine. So now I
just use Virtual PC for different versions.
Drew
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin
Sent: Wednesday, August 11, 2010 9:05 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Decompile
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 The information contained in this
transmission is intended only for the person or entity to which it is
addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive
material. If you are not the intended recipient, please contact the sender
immediately and destroy the material in its entirety, whether electronic or
hard copy.
You are notified that any review, retransmission, copying, disclosure,
dissemination, or other use of, or taking of any action in reliance upon
this information by persons or entities other than the intended recipient is
prohibited.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com