Circumventing Inconvenience Error by Opening DB in Prior Access Version

[robert demo via AccessMonster.com]

I'm developing my database in Access 2002, but the default file format is
Access 2000. It always seems like after I do one or two days of serious
development, I inevitably recieve the following message upon trying to reopen
the database.

"Microsoft Access has encountered a problem and needs to close. We are sorry
for the inconvenience."

I am unable to get into the database at all. Since this has happened to me a
lot, I do regularly backup the database. But just today, the most recent
backup also experienced the same error.

Someone recommended to me that I might try opening the DB in Access 2000
instead, which resides on my laptop. Amazingly, the DB opens fine in Access
2000. I can open it there and then it will reopen in Access 2002.

I thought 2002 was supposed to be much more stable than 2000? I'm glad that
I've found this "back door" around the problem, but does anyone know why this
works?

Some additional information about my database:

1) Front end with three backends. Startup routine checks links to backends
and if backends are missing from location from last session, it will attempt
to look for the backends in the front end folder location. If not found,
error messages are generated for the user to fix the problem.

2) Backends have all permissions removed. Am using RWOP for access to data
tables in the front end.

3) Workgroup security has been implemented.

4) DB has probably about 100 forms, 60 tables and around 15,000 lines of code.


I have not yet imported my DB into a clean database.

 

[Allen Browne]

Robert, check out this article:
Preventing Corruption
at:
http://allenbrowne.com/ser-25.html

Particularly:
- service packs for A2002.
- Name AutoCorrupt
- The LinkChildFields issue (problem with A2002 and not 2000).
- Editing with multiple copies at once.

Additionally, I have found it necessary to decompile every time before
switching development version. For example, if I have been developing in
A2002, and am about to open the db in A2000, I will first decompile with
A2002. This dumps the compiled version of the code, leaving only the text
version. It prevents lots of intermittent errors, though not specifically
the crash'n'shut-down-by-Windows type.

A2000 SP3 on JET 4 SP8 is now at least as stable as A2002 in my experience.
In fact there are at least 2 bugs I am aware of in A2002 SP3 that are not in
A2000 SP3: the LinkChildFields problem with subforms crashing Access, and
the spurious "No Current Record" error message.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

message

 

[robert demo via AccessMonster.com]

Allen:

Excellent article; best I've seen on this topic. I'm guilty of a number of
mistakes, particularly working on the code while the code is running and then
goes into break mode.

I do have a couple of subforms and don't understand what you mean by the
following:

"In your subforms, include a text box for each field in its LinkChildFields
property."

Can you please elaborate?

Thanks.

Robert, check out this article:
Preventing Corruption
at:
http://allenbrowne.com/ser-25.html

Particularly:
- service packs for A2002.
- Name AutoCorrupt
- The LinkChildFields issue (problem with A2002 and not 2000).
- Editing with multiple copies at once.

Additionally, I have found it necessary to decompile every time before
switching development version. For example, if I have been developing in
A2002, and am about to open the db in A2000, I will first decompile with
A2002. This dumps the compiled version of the code, leaving only the text
version. It prevents lots of intermittent errors, though not specifically
the crash'n'shut-down-by-Windows type.

A2000 SP3 on JET 4 SP8 is now at least as stable as A2002 in my experience.
In fact there are at least 2 bugs I am aware of in A2002 SP3 that are not in
A2000 SP3: the LinkChildFields problem with subforms crashing Access, and
the spurious "No Current Record" error message.

I'm developing my database in Access 2002, but the default file format is
Access 2000. It always seems like after I do one or two days of serious

[quoted text clipped - 41 lines]

I have not yet imported my DB into a clean database.

 

[Allen Browne]

Access 2002 and 2003 (but not earlier versions) frequently crash (shut down
by Windows) when handling subforms. My understanding of this bug is purely
circumstantial, but the behavior is consistent.

A subform control has properties for LinkMasterFields and LinkChildFields.
Typically, the LinkMasterFields has the name of the main form's primary key,
and the LinkChildFields has the name of the subform's foreign key field. And
typically the subform does not display the foreign key value, i.e. there is
no text box in the subform bound to this field. The LinkChildFields string
then refers to an object of type AccessField, and the bug that causes the
crash seems to be in the way Access handles this type.

You can work around this bug by adding a text box to the subform for the
foreign key field. After making changes to the main form also, Access now
treats the name in LinkChildFields as referring to an object of type
TextBox. This object does not have the bug, and so the crash does not occur.

So, providing a text box in each subform for the field(s) named in
LinkChildFields avoids this crash. The text box can be small, placed in the
Form Header section if you wish, and can have its Visible property set to
No. The important thing is that it is present, so the LinkChildFields
reference is not interpreted as an AccessField.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

message

Excellent article; best I've seen on this topic. I'm guilty of a number
of
mistakes, particularly working on the code while the code is running and
then
goes into break mode.

I do have a couple of subforms and don't understand what you mean by the
following:

"In your subforms, include a text box for each field in its
LinkChildFields
property."

Can you please elaborate?

Thanks.

Robert, check out this article:
Preventing Corruption
at:
http://allenbrowne.com/ser-25.html

Particularly:
- service packs for A2002.
- Name AutoCorrupt
- The LinkChildFields issue (problem with A2002 and not 2000).
- Editing with multiple copies at once.

Additionally, I have found it necessary to decompile every time before
switching development version. For example, if I have been developing in
A2002, and am about to open the db in A2000, I will first decompile with
A2002. This dumps the compiled version of the code, leaving only the text
version. It prevents lots of intermittent errors, though not specifically
the crash'n'shut-down-by-Windows type.

A2000 SP3 on JET 4 SP8 is now at least as stable as A2002 in my
experience.
In fact there are at least 2 bugs I am aware of in A2002 SP3 that are not
in
A2000 SP3: the LinkChildFields problem with subforms crashing Access, and
the spurious "No Current Record" error message.

I'm developing my database in Access 2002, but the default file format
is
Access 2000. It always seems like after I do one or two days of serious

[quoted text clipped - 41 lines]

I have not yet imported my DB into a clean database.

 

[robert demo via AccessMonster.com]

I typically use DAO to read/update all tables/queries. I wasn't aware of
these subform properties and on my subforms the properties are all "blanks".
So am I correct in assuming that this is not a potential problem for my
application?

Access 2002 and 2003 (but not earlier versions) frequently crash (shut down
by Windows) when handling subforms. My understanding of this bug is purely
circumstantial, but the behavior is consistent.

A subform control has properties for LinkMasterFields and LinkChildFields.
Typically, the LinkMasterFields has the name of the main form's primary key,
and the LinkChildFields has the name of the subform's foreign key field. And
typically the subform does not display the foreign key value, i.e. there is
no text box in the subform bound to this field. The LinkChildFields string
then refers to an object of type AccessField, and the bug that causes the
crash seems to be in the way Access handles this type.

You can work around this bug by adding a text box to the subform for the
foreign key field. After making changes to the main form also, Access now
treats the name in LinkChildFields as referring to an object of type
TextBox. This object does not have the bug, and so the crash does not occur.

So, providing a text box in each subform for the field(s) named in
LinkChildFields avoids this crash. The text box can be small, placed in the
Form Header section if you wish, and can have its Visible property set to
No. The important thing is that it is present, so the LinkChildFields
reference is not interpreted as an AccessField.

Excellent article; best I've seen on this topic. I'm guilty of a number
of

[quoted text clipped - 44 lines]

 

[Allen Browne]

If you do not use bound subforms, you will not encounter the problem with
the AccessField type.

While I am aware that some people use unbound forms and read/write the data
themselves, that always seemed to me to be the worst of both worlds: you are
using a fairly heavy data-centric program like Access (less efficient than C
or VB), and yet getting none of the benefit of bound forms that make it such
as dream to manage the data.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

message

I typically use DAO to read/update all tables/queries. I wasn't aware of
these subform properties and on my subforms the properties are all
"blanks".
So am I correct in assuming that this is not a potential problem for my
application?

Access 2002 and 2003 (but not earlier versions) frequently crash (shut
down
by Windows) when handling subforms. My understanding of this bug is purely
circumstantial, but the behavior is consistent.

A subform control has properties for LinkMasterFields and LinkChildFields.
Typically, the LinkMasterFields has the name of the main form's primary
key,
and the LinkChildFields has the name of the subform's foreign key field.
And
typically the subform does not display the foreign key value, i.e. there
is
no text box in the subform bound to this field. The LinkChildFields string
then refers to an object of type AccessField, and the bug that causes the
crash seems to be in the way Access handles this type.

You can work around this bug by adding a text box to the subform for the
foreign key field. After making changes to the main form also, Access now
treats the name in LinkChildFields as referring to an object of type
TextBox. This object does not have the bug, and so the crash does not
occur.

So, providing a text box in each subform for the field(s) named in
LinkChildFields avoids this crash. The text box can be small, placed in
the
Form Header section if you wish, and can have its Visible property set to
No. The important thing is that it is present, so the LinkChildFields
reference is not interpreted as an AccessField.

Excellent article; best I've seen on this topic. I'm guilty of a number
of

[quoted text clipped - 44 lines]

I have not yet imported my DB into a clean database.