Any consensus on stability/readiness of Access 2007 runtime?

[dbguy_atlanta]

I had forgotten about the /decompile switch years ago, thanks for reminding
me, it may have helped in several instances over the last few years.

But having said that, after looking into this again I remember that it would
be more acurate to say that I wrote it off rather than forgot about it. It
seems to me there is still some controversy about how helpful this option is
as compared to rebuilding a troublesome database.

My understanding of the feature is that it served a few specific purposes
for the development team and was never intended for general use.

What do you mean by "something that has been documented and supported for
several versions"? I could only find one reference to "decompile" in
Microsoft's entire Access knowledge base which was a reference to using the
option in one very specific scenario. The help system in AC2003 has nothing
on it. I'm not sure what you mean by "documented and supported", I'd like to
see the references.

Are the cautions about decompiling unless absolutely called for wrong? Some
are saying this feature can also do more harm than good depending upon what's
going on in a particular database.

I'm grateful for being reminded of a troubleshooting technique that could be
very useful in a dire situation but I'm still wondering if it's wise to use
this in the absence of specific problems.

I tried a decompile for the heck of it, AC2003 then proceeded to crash as
soon as I tried to compact. Hardly shocking, I'm running AC2003 on Vista,
crashes are to be expected, so I'm still left unsure what to make of this.

Here's some of the material I looked at:

http://www.trigeminal.com/usenet/usenet004.asp?1033

http://www.mvps.org/access/bugs/bugs0008.htm

http://support.microsoft.com/kb/814858

 

[Allen Browne]

You could be right: it's not really documented, but it is mentioned, e.g.:
http://support.microsoft.com/kb/819780
http://support.microsoft.com/kb/814858

 

[Brendan Reynolds]

Are the cautions about decompiling unless absolutely called for wrong?
Some
are saying this feature can also do more harm than good depending upon
what's
going on in a particular database.

I've known decompiling to cause a problem once. I've known it to solve
problems many times. So in my experience it is a valuable tool, just make
sure to make a copy of your database before decompiling it.

 

[Tony Toews [MVP]]

Allen, you're not seeing any significant slowdown using 2007? That's very
surprising to me. I've got systems developed in 2003 with some fairly complex
windows (8 or 9 tabs, several sub forms, various lookups and combo boxes,
etc.) that work great with 2003 (instant responses, very rapid display of
records when moving from record to record, etc) but which run much more
slowly under 2007.

A possible cause is

"And finally, what made the real change was surprisingly the "document
windows option", I changed it to "Tabbed Document" and the application
is running even faster than it was running in access 97."

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/

 

[David W. Fenton]

=?Utf-8?B?ZGJndXlfYXRsYW50YQ==?=

Thanks David, I did not think about recreating the links in A2K7
instead of relinking. Sometimes this kind of "voodoo
troubleshooting" (my term for any troubleshooting approach that
really should not make a difference) does the trick.

I've been making my living as a computer consultant since late 1994,
and the longer I do this, the more I find myself practicing "voodoo
troubleshooting" (the exact term, BTW, that I use to think about
it). Just this past week I was setting up a new laptop for a client
and couldn't get it to work with their WiFi (which had been working
just fine with two other PCs for years and years). I did various
things, none of which should have made any difference, and for some
unidentified reason, it eventually started working.

Question on decompiling: I thought this was a thorny issue, that
sometimes decompiling causes problems and Microsoft has suggested
rebuilding MDB's rather than trying to decompile?

I don't know that MS has ever made any kind of definitive statement
on this undocumented feature. Michael Kaplan always advised caution
in its use. I've always used it extensively, and never lost a line
of code. That may, after all, be precisely because I use it
regularly enough to prevent corruption from accumulating to the
point that it causes any loss of objects within the database.

Let me admit ignorance on this topic, of
course I've been compiling MDB's and creating MDE's for a long,
long time but for one reason or another I've never looked into
decompiling, the benefits, risks, etc.

I do it before every major release of any app. And I do it after any
significant programming session.

Oh, another major issue is making sure you have CONDITIONAL
COMPILATION turned off (this was recommended by Michael Kaplan, and
if you understand what it does and how VBA compiles, you'll
recognize that it's a good idea).

Of course, you should never decompile without a backup, just as you
should never compact without a backup.

My experience with decompiling goes back over a decade, so I'm
pretty sure it's not dangerous at all if you're practicing good
programming practices to begin with (i.e., conditonal compilation
turned off, regular backups with compacts and regular decompiles to
keep things cleaned up).

 

[David W. Fenton]

decompiling moved from and
undocumented (voodoo?) tip in early versions to something that has
been documented and supported for several versions.

It has? Sources for that, please?

 

[Tony Toews [MVP]]

Are the cautions about decompiling unless absolutely called for wrong? Some
are saying this feature can also do more harm than good depending upon what's
going on in a particular database.

Once I had a problem as well. But because I always make a copy
immediately before hand everything was fine.

Also see Decompile or how to reduce Microsoft Access MDB/MDE size and
decrease start-up times
http://www.granite.ab.ca/access/decompile.htm

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/

 

[David W. Fenton]

The sequence that works for me is:
1. Make a copy of the MDB (in case something goes wrong.)

2. Compact (dumps any deleted stuff)

3. Decompile (dumps the binary), holding down Shift so any
start-up code does not execute.

4. Compact again (actually removes the dumped binary), still
holding down Shift.

5. Compact again (because a compact after a decompile doesn't work
in some versions, unless you restart in between.)

6. Compile (verifies the text version is fine.)

7. Possibly another compact, and then back up.

On Michael Kaplan's recommendation, never continue working in the
instance of Access in which you decompiled. This may be the source
of problems that cause you to do step 5 (a repeat of step 4).

 

[David W. Fenton]

=?Utf-8?B?ZGJndXlfYXRsYW50YQ==?=

But having said that, after looking into this again I remember
that it would be more acurate to say that I wrote it off rather
than forgot about it. It seems to me there is still some
controversy about how helpful this option is as compared to
rebuilding a troublesome database.

If you wait to use it when a database is having problems, then,
sure, the better option maybe importing everything into a new
database (though you would want to decompile and compact the source
database before importing its objects, or you'll run the risk of
importing corrupted objects).

But if you use decompile as a regular part of the development
process (as, I think, most of the professional developers around
here do it), then you won't ever encounter corruption, except in the
rarest cases. I can count on one hand the number of times I've
encountered corruption. I can also remember the 3 times I had to
import objects to get rid of corruption (and in one of those cases,
it didn't fix the problem).

In my opinion, decompile is a tool that you use as a regular part of
the development process. If you don't use it that way, you're in for
grief in the long run, and when you *do* end up using it, it will be
after things are already pretty much hosed.

I use decompile as a preventative action, to avoid corrupted code in
the first place. And I am very happy with the results, since I
almost never have any corruption (I haven't encountered any in at
least the last two years, even with a half dozen or so active
development projects in A97, A2K and A2K3).

 

[David W. Fenton]

=?Utf-8?B?ZGJndXlfYXRsYW50YQ==?=

I tried a decompile for the heck of it, AC2003 then proceeded to
crash as soon as I tried to compact.

Never do anything in the instance launched with the decompile switch
-- immediately exit it after the decompile has completed (you get no
notification of that in versions after A97), and reload your
decompiled MDB in a new instance of Access (with the SHIFT key held
down to prevent startup code from running). Only then should you
compact, recompile and compact again. At that point, you'll either
be notified that there are problems or your code will run.

 

[Pete D.]

Yes, cautions are correct but if you make back up copies what do you have to
worry about. I do this if I'm even going to change a field, it is just good
common sense. If you have working back-up then party, without, your a fool
to even open the file. Issues that can go bad, disk write error, network
error, system patch error, Microsoft admits it isn't supported error...and
they have the source code, power outage, wife mad and kicks the CPU, or
dumps your beer on computer. If you have the backup who cares if it goes
bad.

 

[dbguy_atlanta]

Thanks, sounds like a good possibility.

A possible cause is

"And finally, what made the real change was surprisingly the "document
windows option", I changed it to "Tabbed Document" and the application
is running even faster than it was running in access 97."

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/

 

[dbguy_atlanta]

Thanks, great info.

Do you create your own class modules, use property get/set, etc??? Use any
of VBA's (semi) object oriented features? I thought I read somewhere the
decompiler has potential problems with that?

Also "conditional compilation setting"?? What have I missed, I thought
conditional compilation was purely a coding construct, not an IDE setting as
for example "Compile on Demand" is??? Just in case, I went looking for a
setting related to conditional compiles and could not find anything. I don't
normally use conditional code constructs at all except for once in a blue
moon.

 

[dbguy_atlanta]

I wonder if anybody has connections on the Access development team and could
get a position comment on the issue of regular use of the decompile option.
What you are saying sounds reasonable and I always like to hear about actual
experience, but I'd also be curious to see what they have to say about
regular use.

 

[Allen Browne]

Yes, that's exactly right, David.

Closing and re-opening would actually be the ideal approach, and I should
probably promote that. In practice, compacting a 2nd time actually achieves
the same outcome in a slightly faster way (i.e. Access closes it and reopens
it.)

 

[Allen Browne]

Your best shot might be to ask the Access Team Blog if they would care to
comment:
http://blogs.msdn.com/access/contact.aspx
Mention this thread to show that others are interested too.

Regardless of any response you get, I will continue to use decompile as an
essential tool for solving a particular kind of problem when developing in
Access.

 

[Tony Toews [MVP]]

I wonder if anybody has connections on the Access development team and could
get a position comment on the issue of regular use of the decompile option.
What you are saying sounds reasonable and I always like to hear about actual
experience, but I'd also be curious to see what they have to say about
regular use.

I very much doubt you'd get an official response from them.

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/

 

[Tony Toews [MVP]]

Thanks, sounds like a good possibility.

Turns out that was mentioned on my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm See the first
section. <sigh>

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/

 

[David W. Fenton]

=?Utf-8?B?ZGJndXlfYXRsYW50YQ==?=

Do you create your own class modules, use property get/set, etc???

I use class modules quite extensively. The last time I recall having
corruption was in a class-module-heavy application, but that was
more than 5 years ago.

Use any
of VBA's (semi) object oriented features? I thought I read
somewhere the decompiler has potential problems with that?

I don't know what you mean with the reference to object oriented
features.

Also "conditional compilation setting"??

I have have one or two such somewhere in my code library, but it's
not something I use, as I don't find myself programming one codebase
to run on incompatible versions of Access. Mostly, this means I
don't use "new" features in VBA.

What have I missed, I thought
conditional compilation was purely a coding construct, not an IDE
setting as for example "Compile on Demand" is???

You're right in pointing out that this was me confusing the
terminology.

Just in case, I went looking for a
setting related to conditional compiles and could not find
anything. I don't normally use conditional code constructs at all
except for once in a blue moon.

I don't know if conditional compilation makes code more
corruption-prone (as heavy use of class modules is known to). I
don't use it enough for it to be an issue.

But COMPILE ON DEMAND is without question a major cause of
corruption and should be turned off in all cases.

 

[David W. Fenton]

=?Utf-8?B?ZGJndXlfYXRsYW50YQ==?=

I wonder if anybody has connections on the Access development team
and could get a position comment on the issue of regular use of
the decompile option. What you are saying sounds reasonable and I
always like to hear about actual experience, but I'd also be
curious to see what they have to say about regular use.

It's undocumented. Thus, they will say "use at your own risk,"
precisely because they don't want to be held responsible for even
very unlikely things that can go wrong.

Experience tells me that it's very safe.

That doesn't mean I think MS will say it's very safe.