Risks of decompile

[Sylvain Lafontaine]

Merely writing to a database won't corrupt it. The corruption can possibly

occur if the write is interrupted. Even then the chance of corruption is
slight unless there is a memo data type or other OLE field in the table.

Sorry to say that but I'm totally in disagreement with you. Even if the
only thing that you changing is a single character field in a non-indexed
field on a local machine (no network) with ECC (Error Checking and
Correcting) Memory, you have a chance of corrupting your database. The
chance might be small but it's not null. If you have a chance of one on a
million of corrupting your database by doing an operation and that you do
this one time a day, the possibility of having a corrupted database are
pretty low; at least, not before many thousands years. However, if you
repeat this operation one million times a day, it won't take years before
getting it. In the same way, if you are doing it one time a day but you are
one million people doing it; you will have an average of one person hit each
day.

I don't know what is the possibility of having an error if you change a
single non-indexed field on a local machine with ECC memory. However, if
you change an indexed field on a machine without ECC over a flaky network,
probably that your chances of corrupting your database must be in the
vicinity of Pluto.

Decompiling a database is a much bigger process than simply updating a
single field and as such, carry a much bigger chance of having something
going wrong. However, this doesn't mean that the processes who are smaller
cannot go wrong simply because they are smaller.

Finally, the fact that you have been able to past the last five years
without any case of corruption is interesting; however, I don't really
understand what this is bringing to the discussion. The fact that you have
been lucky these five years is a good think; however, I don't see how
someone else could make a decision based on your own personal luck.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)

 

[Arvin Meyer [MVP]]

Yes the world may come to an end. I suggest that with a high quality network
and well trained users, the chances of corruption are only slightly greater.
I have an Access 97 database completed in May of 1998 which has never
corrupted. It imports about 100,000 .csv records every day then writes the
data to a summary table and discards the import, leaving about 2000 to 2500
records of 32 bytes each. Once per year the database is archived and a new
one is started. It has been running 6 days per week for more than 10 years
now, and replaced a much larger and much slower Oracle database. As far as I
know, it has never been converted to a later version.

In that period of time, anything can happen including hard drive failures,
mistakes, power interruptions from disconnected UPS, etc. The building could
burn down. The database I mentioned, could corrupt tomorrow. That's why it's
a good idea to have a backup and a restore plan. There are no absolute
guarantees of anything in life, including corruption.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

No sure of totally understanding what you are doing but what I'm
using myself with Access 2003 is to use all the three command line
options (or parameters): /decompile /compact /repair

Since A97 SR2, the last is redundant, as a repair will be performed
as part of any compact if it's determined that it's needed.
Otherwise, it won't be done at all.

I'm leery of combining too many steps, and worry about the state of
the Access memory space during a decompile, given that much of
Access is, in fact, written in Access (not the EXE, but the wizards,
for example).

It does a pretty job of decompiling and compacting in a single
step. Sometimes, I repeat it a second time just to be sure.
Notice that the documentation say that using both /compact and
/repair at the same time is now useless since A2000; however, this
is not what I'm observing with Access 2003. I never tried it with
A2007.

What do you mean by that? What difference are you seeing in A2K3?

A repair is a dangerous operation and I think I'll leave it up to
Jet to decide when a repair is needed.

 

[Sylvain Lafontaine]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

Since A97 SR2, the last is redundant, as a repair will be performed
as part of any compact if it's determined that it's needed.
Otherwise, it won't be done at all.

I'm leery of combining too many steps, and worry about the state of
the Access memory space during a decompile, given that much of
Access is, in fact, written in Access (not the EXE, but the wizards,
for example).


What do you mean by that? What difference are you seeing in A2K3?

The compression is greater, similar (if not identical) to the one you get
when you take the precaution of pressing the Shift key when doing a
compact/repair from Access.