On Sat, 06 Dec 2003 21:36:30 GMT,
dXXXfenton@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
[color=blue]
>If you have a clean, uncorrupted A97 MDB, the conversion will
>produce a clean, uncorrputed A2K MDB. So, to me, it seems that the
>solution is to make sure the A97 MDB is OK *before* converting.[/color]
Eminently reasonable.
[color=blue]
>Keep in mind that certain kinds of problems will survive the import
>(as well as surviving the conversion), even though you've
>determined that your particular one does not (though it does
>survive the conversion).[/color]
True enough. Remember that certain things, especially visual controls
and their binding to code, are not really thoroughly tested in an
import, and problems can ride within such controls into a new file.
Its unlikely, but I've seen it often enough to be concerned about it.
[color=blue]
>So, it seems to me that the only course of action is to never
>convert versions until you know you've got a clean source file.[/color]
That would certainly seem to be the only reasonable starting point.
[color=blue]
>Some of the folks around here would advocated creating a new A97
>MDB, importing everything into it, restoring properties that don't
>import and then converting *that*.[/color]
Most of the time that's fine. But it depends on (a) how many custom
properties have been established (if its just the startup stuff, then
its no big deal to recreate, but if you've loaded up a bunch of your
own properties, and you've established intricate security settings,
then this is NOT the way to proceed) and (b) whether you have any
reason to suspect corruption. If (b) is so, never assume anything
about an import fixing the problem unless you can verify too.
[color=blue]
>Others might even recommend
>recreating the new A97 MDB with SaveAsText/LoadFromText, rather
>than just importing.[/color]
I see this recommended a lot too (by others), but I have to say that
its overkill for most situations. Its like the advice to export to a
different db format, or to Excel, and then import back data that is
suspect. There's simply no reason to do this (for data). Importing
the data into a new file will result (with one very unusual and rare
exception that I know of) in a clean new file (and possibly a refusal
to import badly corrupted data from the old one). ITs on the
application objects (not data ones) that import is unreliable. Still,
like I said, SaveAsText/LoadFromText is in general overkill.
[color=blue]
>But those are generally people who are not big
>fans of regular use of decompile, as I am (I use it daily, after
>any major development cycle), so they are more likely to find
>utility in doing those things because problems are much more likely
>to accumulate in A97 if you have decompiled only very seldom.[/color]
I agree and disagree. I agree decompile should be a prime candidate
for consideration as a corruption prevention tool. I don't use it
daily, but I do support using it periodically, and especially when
involved in heavy development or when dealing with (even unrelated)
buggy apps or system crashes. Frequency of use does reduce
complexity, to a certain extent, so I'm in agreement there. I
disagree slightly on the need to focus on it as the center of
anti-corruption efforts (but perhaps this difference is only one of
perception on my part).
One thing to note is that there aren't as many layers of storage
involved for code, or for that matter, for application objects
non-code (ie visual) design elements, in Access 97 as there are in
Access 2000 and later versions, with their handling of garbage and
fragments within system tables. In other words, doing heavy
development in A2K, AXP and A2K3 all result in much more garbage
buildup than in A97. Decompile is therefore less effective (though
still worthwhile) in A97.
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
