<
[email protected]>:
Is this a critisism of my suggestions? If so, allow me to "defend" or
explain myself ;-)
Importing into a new empty database has the same effect as
decompiling.
I didn't know this. I've always thought there where differences.
I can't document it, but with a bit of saerch, I found some quotes from
another NG indicating there might be different opinions on the matter,
see for instance Allen Browne here (watch for linebreaks in the links)
http://groups.google.com/group/comp.databases.ms-access/msg/d7a973b7aee5327e
"If the decompile fails, it is time to create a new (blank) database,
turn Name AutoCorrect off, and import all the *other* objects.
Then decompile the new database, since importing the modules can import
the corruption. Create the form from scratch. Then paste in the code
from notepad if you wish."
and David W. Fenton here
http://groups.google.com/group/comp.databases.ms-access/msg/afb467350ccd9e6a
"I would try the decompile, then compact, then import everything
into a new database then compile and save all. If that has no
effect, then try Application.SaveAsText and
Application.LoadFromText. Corruption might survive the import, but
it can never survive .SaveAsText."
These quotes represents what I've always thought, based on previous
experience, I don't know the inner workings of these functions or
methods, so I wouldn't know.
My reason for suggesting a /decompile is
1 - you didn't, and I had the impression that they are different, and
that it could make a difference
2 - it's solved my code corruption issues over the last couple of years
3 - there's no need to enter the VBE and reset the references - which
might be relevant for users of 2000 and 2002, as the reference to
DAO isn't default, when importing to a new databae
4 - if/when using check constraints, there's no need to reimplement,
them which would be the case when doing an import
In the context of this thread, I thought a demonstration of both saving
and retrieving the information of a specific object was called for.