I'm thinking of http://www.trigeminal.com/usenet/usenet004.asp?1033
where the assertion is

"...you are relying on the ability to globally invalidate a compiled
state. If there is ever a problem in either area, /decompile will take
a project that was working fine and turn it into cottage cheese. And
while such bugs should not happen.... it is impossible to make a /
decompile bug happen without using /decompile. They simply did not
extensively test a command line switch that was never meant to be
used.... nor should they have to, really."


This was news to me - having religiously /Decompile'd before every
compact/repair - sometimes several times per day over the past way-too-
many years.

My SOP is to:
--------------------------------------------------------------------------------------------
1) Zip the application up and move the .zip file to an archive area.

2) Rename the existing version/subversion to "x..." as in SfimApp.
275g.mdb ==> xSfimApp.275g.mdb.

3) Compact the renamed version/subversion into a new subversion
qualifier as in
xSfimApp.275g.mdb ==> SfimApp.275h.mdb
--------------------------------------------------------------------------------------------

Seems like I'm covered in the event /Decompile makes "cottage cheese"
out of the app: retrieve the .zip file from the archive area and
revert to that version.

Am I missing anything?

PeteCresswell wrote:
> Seems like I'm covered in the event /Decompile makes "cottage cheese"
> out of the app: retrieve the .zip file from the archive area and
> revert to that version.

AFAICT, you're covered.

However, what benefits do you gain from all that religious decompiling?

On Apr 24, 11:37*am, Hans Up <hans.upd...@nospam.invalid> wrote:

> However, what benefits do you gain from all that religious decompiling?

I don't know enough to say definitively.

But it seems to me like Access DBs sometimes get "just a little"
corrupted - where they still appear tb functioning normally, but
stuff builds up over time until one day "Ooops!".

Unencumbered by any in-depth knowledge, I figure that Decompile might
smoke out any problems sooner rather than later.

From what I've read so far, it sounds like that would be the case in
the event of Canonical text being compromised. Better to find out
today than next week with a serious deadline looming....

??

PeteCresswell <(E-Mail Removed)> wrote:

>Unencumbered by any in-depth knowledge, I figure that Decompile might
>smoke out any problems sooner rather than later.
>
>From what I've read so far, it sounds like that would be the case in
>the event of Canonical text being compromised. Better to find out
>today than next week with a serious deadline looming....

That's also the way I think.

I only decompile when bizarre things start happening or when the app
is slow to startup.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

PeteCresswell wrote:
> On Apr 24, 11:37 am, Hans Up <hans.upd...@nospam.invalid> wrote:
>
>> However, what benefits do you gain from all that religious decompiling?
>
> I don't know enough to say definitively.
>
> But it seems to me like Access DBs sometimes get "just a little"
> corrupted - where they still appear tb functioning normally, but
> stuff builds up over time until one day "Ooops!".
>
> Unencumbered by any in-depth knowledge, I figure that Decompile might
> smoke out any problems sooner rather than later.
>
> From what I've read so far, it sounds like that would be the case in
> the event of Canonical text being compromised. Better to find out
> today than next week with a serious deadline looming....

Thanks for your reply, Pete. I intend to steal your "unencumbered ..."
expression; that one will be real useful for me. :-)

I seldom use decompile ... maybe 3 times in the last 4 years. Until
recently, I was unaware of the risk of irretrievably hosing the
database. Fortunately, I didn't get bit even though I was not as
fastidious about making backups as you. I think I will use that as my
take-away message --- not to ever decompile without making a backup first.

Hans

"Tony Toews [MVP]" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> I only decompile when bizarre things start happening or when the
> app is slow to startup.

I decompile "regularly", i.e., at the end of any major development
cycle.

I think that decompile is dangerous for people who are careless with
their code. This means people who:

1. don't use OPTION EXPLICIT 100% of the time.

2. don't have COMPILE ON DEMAND turned off.

3. don't regularly compile their app (and I mean full compilation in
that after hitting the compile command the app really is compiled).

Since I am constantly compiling I know when my code has problems. I
decompile after major development cycles because it's possible for
problems to develop (though I must say it's been literally years
since I've seen any such issues).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Hans Up <(E-Mail Removed)> wrote in
news:#(E-Mail Removed):

> I seldom use decompile ... maybe 3 times in the last 4 years.
> Until recently, I was unaware of the risk of irretrievably hosing
> the database.

I think there is no such risk is you have a backup and take care of
your code.

If you decompile without a backup and don't take good care of your
code, then, yes, indeed, it's risky to decompile.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/