Change data and form crashes Access

[Bob Quintal]

I have a split database in which there is a form based on a table
(let's call it Frm2). It has about eight fields on it, four
comboboxes and four textboxes. The form opens from a button on
another form (call it Frm1), based on the same table. When I
close Frm2 I go back to Frm1. Seems straight forward enough. If
any data is changed on Frm2 it causes Access to crash upon closing
Frm2. If no data is changed, closing Frm2 causes no problem.

Frm1 has a Tab Control on it with a subform on most tabs, each
based on seperate tables, and linked to the record on Frm1. I've
recreated Frm2, imported it from previous versions of the DB on
which it does not create the crash, but in the current version of
the FE file, closing Frm2 after changing data always creates the
crash.

There is a fair amount of code on Frm1 making controls visible or
not based on being Null or not, changing the backcolor based on
the value, etc. Some requerying before displaying reports;
nothing extremely complicated and none of it has been changed
between the time Frm2 worked fine and now. There has been a new
subform added to the Tab Control and it appears to be working
fine. If data is changed in it, no crashing occurs, so I'm
"thinking" it isn't the issue at hand.

I don't know if this is a case of corruption and if so, corruption
of what; a form, table, etc. I've looked through all of the
tables that are used as record sources for any of the forms and
subforms involved with Frm1 and do not see Delete, which seems to
be an indication of a corrupted table. I'm not sure how to
proceed at this point in determining what is causing this crash
situation. Any ideas from you gurus out there?

What is meant by "causes Access to crash"?
What error messages do you get?
Does form Frm2 crash if frm1 isn't open?
Does the change in the form Frm2 get updated in the table before the
crash?
What version of Access are you using, on what version of Windows?
Is it possible that the issue is caused by the silent instalation of
Office Service Pack 3 (e.g. mid>late september 2007)?

Nobody on this list besides you can read your screen. We need more
info to even try to figure out what's happening.

 

[Geezer via AccessMonster.com]

I have a split database in which there is a form based on a table (let's call
it Frm2). It has about eight fields on it, four comboboxes and four
textboxes. The form opens from a button on another form (call it Frm1),
based on the same table. When I close Frm2 I go back to Frm1. Seems
straight forward enough. If any data is changed on Frm2 it causes Access to
crash upon closing Frm2. If no data is changed, closing Frm2 causes no
problem.

Frm1 has a Tab Control on it with a subform on most tabs, each based on
seperate tables, and linked to the record on Frm1. I've recreated Frm2,
imported it from previous versions of the DB on which it does not create the
crash, but in the current version of the FE file, closing Frm2 after changing
data always creates the crash.

There is a fair amount of code on Frm1 making controls visible or not based
on being Null or not, changing the backcolor based on the value, etc. Some
requerying before displaying reports; nothing extremely complicated and none
of it has been changed between the time Frm2 worked fine and now. There has
been a new subform added to the Tab Control and it appears to be working fine.
If data is changed in it, no crashing occurs, so I'm "thinking" it isn't the
issue at hand.

I don't know if this is a case of corruption and if so, corruption of what; a
form, table, etc. I've looked through all of the tables that are used as
record sources for any of the forms and subforms involved with Frm1 and do
not see Delete, which seems to be an indication of a corrupted table. I'm
not sure how to proceed at this point in determining what is causing this
crash situation. Any ideas from you gurus out there?

 

[Geezer via AccessMonster.com]

I figured I wouldn't give enough info, just wasn't sure what all was needed.
Here's more info per your questions.

Access crashes as in it closes, there is no Access error message, but rather
the standard "Access has encountered a problem and must close....... Do you
want us to repair your database and create a backup copy." Or something to
that affect.

Frm2 does NOT cause a crash if Frm1 is not open. >>> Good point, I hadn't
tested that. It appears there's something on Frm1 causing the problem.
Progress!

The data changes made on Frm2 do get written to the table correctly before
Access crashes.

Access 2003, Windows XP Home. Service Pack 3 might be involved as the issue
started sometime after mid-late September.

I'm sure there are more answers you need, but I don't know what else to
provide. I'll certain answer any questions that give you the details you
need to narrow things down. I definitely appreciate your help!!

 

[Geezer via AccessMonster.com]

Well Bob, your question about Frm2 crashing Access if Frm1 is not open was
the key. I deleted the subform that was recently added to Frm1, on a tab,
and simply dragged it back on from the DBWindow. I don't know how that could
solve the problem, but it seems to have. I've gone in to Frm2 and changed
all kinds of data, closed, and have not had a crash since. Something flukie
I suppose, but fixed is good no matter how or why. Thanks for your time; and
question!