Strange corruption A2k

[Arno R]

Hi all
Yesterday I found a strange corruption-issue that I can't solve yet or actually point my finger at.
I converted an A97 app to A2k.
I have done this often enough so I didn't expect trouble here.

Conversion seems OK and I start the app. BUT . . .
Mainform doesn't work. Form comes up but none of the buttons react.
Why not? I go to design view and see that code is not compiled. (compile-option is active)
So I compile and go to normal view. It seems to work.
But the problem is not over yet. After I close the db the same story repeats.
I start the db again and open any module. I see that code is not compiled.
I don't really think the compilation-state is the problem here but nevertheless ...

Some more testing: When I start the app my mainform comes up.
When I switch to design-view and do NOTHING but switch to normal mode again the form works.
After this when I look at the 'compile-state' in any form or module the option to compile is
greyed-out.
So it's compiled again, or still ?

I can repeat this over and over.
Other apps on my PC do not have this problem, so I don't think it's a Access-install or SP-issue

I tried save as text - load from text for this form. (For other forms as well)
I also created a blank new db, imported everything but same result.

I will try to recreate the form from scratch, but for today I've had enough of this.
Going to play biljarts and have a beer or two now ;-)

Any idea's? Anyone had similar 'events' ?

TIA
Arno R

[DFS]

Before you go recreating the form, right click on the buttons that don't
work and choose Build Event. When the code comes up, add an extra space in
it somewhere, then choose recompile. Do this for each button.

"Arno R" <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

Hi all
Yesterday I found a strange corruption-issue that I can't solve yet or actually point my finger at. I converted an A97 app to A2k.
I have done this often enough so I didn't expect trouble here.

Conversion seems OK and I start the app. BUT . . .
Mainform doesn't work. Form comes up but none of the buttons react.
Why not? I go to design view and see that code is not compiled. (compile-option is active) So I compile and go to normal view. It seems to work.
But the problem is not over yet. After I close the db the same story repeats. I start the db again and open any module. I see that code is not compiled.
I don't really think the compilation-state is the problem here but nevertheless ...
Some more testing: When I start the app my mainform comes up.
When I switch to design-view and do NOTHING but switch to normal mode again the form works. After this when I look at the 'compile-state' in any form or module the option to compile is greyed-out.
So it's compiled again, or still ?

I can repeat this over and over.
Other apps on my PC do not have this problem, so I don't think it's a Access-install or SP-issue
I tried save as text - load from text for this form. (For other forms as well) I also created a blank new db, imported everything but same result.

I will try to recreate the form from scratch, but for today I've had enough of this. Going to play biljarts and have a beer or two now ;-)

Any idea's? Anyone had similar 'events' ?

TIA
Arno R

[Tony Toews]

"Arno R" <ar****************@tiscali.nl> wrote:

The only other thing I can think of is doing a decompile.

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

[Arno R]

Hi Tony,
Thanks for the tip but unfortunately also /decompile doesn't help.

I also get messages (when I try to comment out some startup-code)
that "changes can't be written to the project because the database can't be opened exclusively".
(Message translated from Dutch)
I am the one and only user at that moment ...
When I start the db with /excl I can make changes to the code.

I will keep on testing this afternoon and create the startupform again.

Arno R
"Tony Toews" <tt****@telusplanet.net> schreef in bericht
news:52********************************@4ax.com...

"Arno R" <ar****************@tiscali.nl> wrote:

The only other thing I can think of is doing a decompile.

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

[David W. Fenton]

ar****************@tiscali.nl (Arno R) wrote in
<3f**********************@dreader2.news.tiscali.nl >:

Yesterday I found a strange corruption-issue that I can't solve
yet or actually point my finger at. I converted an A97 app to A2k.
I have done this often enough so I didn't expect trouble here.

Conversion seems OK and I start the app. BUT . . .
Mainform doesn't work. Form comes up but none of the buttons
react. Why not? I go to design view and see that code is not
compiled. (compile-option is active) So I compile and go to normal
view. It seems to work. But the problem is not over yet. After I
close the db the same story repeats. I start the db again and open
any module. I see that code is not compiled. I don't really think
the compilation-state is the problem here but nevertheless ...

I would suggest to everyone who is converting between versions of
Access to decompile and recompile before conversion. My guess is
that the problem is in the original A97 database and simply didn't
show up in A97 (i.e., doesn't cause any visible problems, if it
causes any at all). Decompile in A97 does a lot more than in A2K,
as long as you do it right (compact, decompile, open in new
instance of Access, compact, recompile, compact).

I've seen apps spontaneously decompile before, but have never
traced down what cause such a thing. It is certainly not normal for
that to happen.

Also, have you tried creating an MDE from it? That might flush out
the problems it it's a code corruption issue.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Arno R]

Thanks David,
Your guess seems to be a right guess.

My guess is
that the problem is in the original A97 database and simply didn't
show up in A97
I haven't got a clue about the problem but it is gone after a decompile-recompile in A97 and
conversion afterwards.
So when someone is experiencing this kind of corruption a solution might be:
-Save in previous version (A97)
-Decompile-recompile as you described earlier
-Convert to A2k
This is a real PITA, especially when there are options used not supported by A97

Before this I even tried to save All objects as text and load from text but no avail.
A2k just stayed corrupted ... Corruption must be *somewhere* in the 'Project'.

Just tested something new with an interesting result:

Conversion of the same old (not decompiled-recompiled) A97 db results in the corruption described.
But: Created new database in A2k and just imported all the objects from this A97 db
results in a db that is OK ... (after a proper DAO 3.6 reference that is ...)
*********************
So: There is NO NEED for a *real* conversion, just import and be happy?
One has to set db.properties, startup properties and so on, but no other PITA then ?

Any thoughts on this?

Arno R

"David W. Fenton" <dX********@bway.net.invalid> schreef in bericht
news:94***************************@24.168.128.86.. . ar****************@tiscali.nl (Arno R) wrote in
<3f**********************@dreader2.news.tiscali.nl >:

Yesterday I found a strange corruption-issue that I can't solve
yet or actually point my finger at. I converted an A97 app to A2k.
I have done this often enough so I didn't expect trouble here.

Conversion seems OK and I start the app. BUT . . .
Mainform doesn't work. Form comes up but none of the buttons
react. Why not? I go to design view and see that code is not
compiled. (compile-option is active) So I compile and go to normal
view. It seems to work. But the problem is not over yet. After I
close the db the same story repeats. I start the db again and open
any module. I see that code is not compiled. I don't really think
the compilation-state is the problem here but nevertheless ...

I would suggest to everyone who is converting between versions of
Access to decompile and recompile before conversion. My guess is
that the problem is in the original A97 database and simply didn't
show up in A97 (i.e., doesn't cause any visible problems, if it
causes any at all). Decompile in A97 does a lot more than in A2K,
as long as you do it right (compact, decompile, open in new
instance of Access, compact, recompile, compact).

I've seen apps spontaneously decompile before, but have never
traced down what cause such a thing. It is certainly not normal for
that to happen.

Also, have you tried creating an MDE from it? That might flush out
the problems it it's a code corruption issue.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

ar****************@tiscali.nl (Arno R) wrote in
<3f**********************@dreader2.news.tiscali.nl >:

Your guess seems to be a right guess.

My guess is
that the problem is in the original A97 database and simply
didn't show up in A97
I haven't got a clue about the problem but it is gone after a
decompile-recompile in A97 and conversion afterwards.
So when someone is experiencing this kind of corruption a solution
might be: -Save in previous version (A97)
-Decompile-recompile as you described earlier
-Convert to A2k
This is a real PITA, especially when there are options used not
supported by A97

I was assuming from what you said that the database had been
converted from A97 to A2K, so if you'd started from that before
programming in A2K, the issue would be solved.

This is why I decompile regularly, because I don't want corruption
developing. I have several projects that I develop in A97 and
convert to A2K for distribution. The last step before conversion is
a compact/decompile/compact/compile/compact cycle in A97.
Before this I even tried to save All objects as text and load from
text but no avail. A2k just stayed corrupted ... Corruption must
be *somewhere* in the 'Project'.

Just tested something new with an interesting result:

Conversion of the same old (not decompiled-recompiled) A97 db
results in the corruption described. But: Created new database in
A2k and just imported all the objects from this A97 db results in
a db that is OK ... (after a proper DAO 3.6 reference that is
...) *********************
So: There is NO NEED for a *real* conversion, just import and be
happy? One has to set db.properties, startup properties and so on,
but no other PITA then ?

Any thoughts on this?

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.

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).

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.

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*. Others might even recommend
recreating the new A97 MDB with SaveAsText/LoadFromText, rather
than just importing. 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.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Peter Miller]

On Sat, 06 Dec 2003 21:36:30 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:

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.
Eminently reasonable.
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).
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.
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.
That would certainly seem to be the only reasonable starting point.
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*.
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.
Others might even recommend
recreating the new A97 MDB with SaveAsText/LoadFromText, rather
than just importing.
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.
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.

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

[David W. Fenton]

pm*****@pksolutions.com (Peter Miller) wrote in
<c8********************************@4ax.com>:

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.

It also seems to me that it conversely has more benefit in A97 and
less danger.

I don't use it as much in A2K. If I really need a clean A2K file, I
recreate it from scratch, importing from decompiled A2K source
file.

But in A97, decompile seems to fix a higher percentage of the
potential corruption problems and with a greater degree of success.

But that is a caveat that I started with, as we were talking about
A97 as a source.

All bets are off for A2K and beyond, so far as I'm concerned. I do
not really feel that I can fully guarantee a clean MDB in A2K at
all, short of recreating it from SaveAsText/LoadFromText. There's
also the bloat problem that comes up with decompile in later
versions of A2K+.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Arno R]

Hi David,

I do not really feel that I can fully guarantee a clean MDB in A2K at
all, short of recreating it from SaveAsText/LoadFromText
In fact I did recreate everything from SaveAsText/LoadFromText in A2k
I did *not* solve the corruption issue I was confronted with...
Importing as I described did, (and of course /decompile in the A97 db and convert after that)

As for a 'clean' A97-db. I *thought* my app was clean ... when I converted.
I didn't use /decompile as much as you do.
I will use it more often now !

Thanks,
Arno R
"David W. Fenton" <dX********@bway.net.invalid> schreef in bericht
news:94***************************@24.168.128.74.. . pm*****@pksolutions.com (Peter Miller) wrote in
<c8********************************@4ax.com>:

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.

It also seems to me that it conversely has more benefit in A97 and
less danger.

I don't use it as much in A2K. If I really need a clean A2K file, I
recreate it from scratch, importing from decompiled A2K source
file.

But in A97, decompile seems to fix a higher percentage of the
potential corruption problems and with a greater degree of success.

But that is a caveat that I started with, as we were talking about
A97 as a source.

All bets are off for A2K and beyond, so far as I'm concerned. I do
not really feel that I can fully guarantee a clean MDB in A2K at
all, short of recreating it from SaveAsText/LoadFromText. There's
also the bloat problem that comes up with decompile in later
versions of A2K+.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

ar****************@tiscali.nl (Arno R) wrote in
<3f**********************@dreader2.news.tiscali.nl >:

[I wrote:]

I do not really feel that I can fully guarantee a clean MDB in
A2K at all, short of recreating it from SaveAsText/LoadFromText
In fact I did recreate everything from SaveAsText/LoadFromText in
A2k I did *not* solve the corruption issue I was confronted
with... Importing as I described did, (and of course /decompile in
the A97 db and convert after that)

I don't see what possible corruption could survive
SaveAsText/LoadFromText, to be honest. You imported into a
freshly-created A2K MDB? And you imported all code-bearing objects
with LoadFromText? That would be forms, reports and modules. If you
don't do it for everything, and import directly some of the
objects, you could certainly get some of the corruption in those
code-bearing objects -- it all depends on what, excactly, is
corrupt.
As for a 'clean' A97-db. I *thought* my app was clean ... when I
converted. I didn't use /decompile as much as you do.
I will use it more often now !

Well, don't use it *too* often. Use it when it makes sense, after
you've been hammering the MDB with lots of development changes.

Also, be sure you turn off conditional compiling. That, more than
anything else, may be what keeps a project from corrupting. And
explicitly compile after every code change. That's my practice and
I hardly ever have issues with corruption. The only times I've
encountered it is when I've done heavy development for several
hours and not decompiled yet.

But I still say that advice applies only to A97, in regard to lots
of decompiling. In A2K, I would certainly make sure you have
conditional compiling turned off and compile explicitly after every
code change, but it's quite clear that code compiling and code
execution is a completely different animal in A2K than in A97. And
I've not yet figured it out (I have only been doing heavy-duty
development in A2K for the last year or so).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc