Code not saving in Access 97 on Windows XP.

[Steve Jorgensen]

I have recently had reason to worke on 3 different Access/VBA applications of
different sizes on Windows XP machines. In all cases, I've had frequent
instances of code changes being discarded, and having to re-write the changes.
has anyone else seen this problem?

It was pretty embarassing for a while delivering code that worked before I
closed Access, then failed upon deployment. I finally developed the habit of
copying my code into Notepad before closing Access, then re-opening the app to
test it to see if all my changes were retained.

[Allen Browne]

Hi Steve

Yes, this kind of corruption is not uncommon. It occurs when the 2 copies of
the code (the compiled and text versions) are out of sync. A decompile fixes
it.

Triggers of the problem include:

1. Switching versions.
If you develop something in A2003 and then run it in an earlier version,
2000 or 2002 cannot read the A2003 binary, so they have to recompile for
their own. This implicit recompiling seems to contribute to the problem. We
now explicitly decompile, compact and recompile in the target version
whenever we switch versions.

2. Name AutoCorrect
You probably know all about this, but for anyone who's following the thread:
http://members.iinet.net.au/~allenbrowne/bug-03.html:

3. Crashes
Naturally. Example: the bug that crashes A2002 and A2003 if the field named
in the LinkChildFields of a subform control is not represented by a control
in the subform (and is therefore an AccessField object instead of a Textbox
object).

Another symptom of the same problem is breakpoints that don't break or don't
clear.

HTH

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:ou******** *************** *********@4ax.c om...

I have recently had reason to worke on 3 different Access/VBA applications
of
different sizes on Windows XP machines. In all cases, I've had frequent
instances of code changes being discarded, and having to re-write the
changes.
has anyone else seen this problem?

It was pretty embarassing for a while delivering code that worked before I
closed Access, then failed upon deployment. I finally developed the habit
of
copying my code into Notepad before closing Access, then re-opening the
app to
test it to see if all my changes were retained.

[Steve Jorgensen]

Well, I've seen it happen occasionally in A2K & A2K2 as you describe as well,
but only once in a while. When doing Access 97 development on Windows XP,
however, I'm seeing it happen several times a day, on multiple projects at
multiple sites.

I never used to have this much trouble with Access 97 on Windows 2K and W98.
I had occasional corruption, sure, but not this often, and not usually with
this symptom, and I don't have such difficulty with A2K on WXP.

On Thu, 20 Jan 2005 12:36:00 +0800, "Allen Browne"
<Al*********@Se eSig.Invalid> wrote:

Hi Steve

Yes, this kind of corruption is not uncommon. It occurs when the 2 copies of
the code (the compiled and text versions) are out of sync. A decompile fixes
it.

Triggers of the problem include:

1. Switching versions.
If you develop something in A2003 and then run it in an earlier version,
2000 or 2002 cannot read the A2003 binary, so they have to recompile for
their own. This implicit recompiling seems to contribute to the problem. We
now explicitly decompile, compact and recompile in the target version
whenever we switch versions.

2. Name AutoCorrect
You probably know all about this, but for anyone who's following the thread:
http://members.iinet.net.au/~allenbrowne/bug-03.html:

3. Crashes
Naturally. Example: the bug that crashes A2002 and A2003 if the field named
in the LinkChildFields of a subform control is not represented by a control
in the subform (and is therefore an AccessField object instead of a Textbox
object).

Another symptom of the same problem is breakpoints that don't break or don't
clear.

HTH