Thanks: the extra detail helps understand when this occurs.
If you have not split the database, and it is being opened by multiple users
(or even multiple instances on your own computer), David's suggestion of
splitting will help. I assume you know what we are talking about here:
tables in one file in a shared location (the back end), and all other
objects (queries, forms, reports, code, ...) and attached tables in a
seprate file (the front end) such that each user opens an indepdent copy of
the front end.
Editing code in break mode can cause corruption IME. Merely pausing in break
mode (followed by a continue or reset) should not corrupt the file (unless
it affects some other dependences between classes or objects that disappear
when you reset.)
When you start modifying the design of a form, Access creates a backup
(which it will restore if you discard your current design changes.) When you
edit a form's module, it also creates a back up of the module. Consider what
happens if you open a form in Form view (not design view), start using it,
and then go to break mode. At this point, there is at least 1 copy of the
form, plus 2 copies of the code (the text version you view in the IDE, and
the compiled code that's running, which may or may not be saved.) Now if you
start editing the code in break mode, Access has to create a backup copy of
the code, and keep track of the backup to restore (with or without the saved
compiled code), plus the one being edited (which may or may not get saved in
the end), while actually still handling the compiled version that's running
(in break mode), and keep track of all this stuff correctly. It actually
does a pretty reasonable job of this most of the time, but IME there are
cases where it gets confused. You end up with a corrupt form, breakpoints
that don't break, code that executes which no longer exists in the module
(when you read the text version), or some other kind of corruption. And that
gets confused further by interacting with other bugs (such as with the
AccessField type where a form's module refuses to compile when it used to),
or inconsistencies between the forms in MSysObjects and those in AllForms.
I have no reason to think that A2007 is better/worse than other versions
with all of that.
But there is another factor with the Delete event. When Form_Delete fires,
Access has begun an implicit transaction that will be committed or rolled
back between BeforeDelConfirm and AfterDelConfirm. If you are experiencing
corruption when you interrupt it while the implicit transaction is active
(particularly if there are multiple users in the same file), I wonder if
something may be going wrong there?
Sorry: I can't be more specific. Hope that just talking about it may suggest
something that's worth considering, so you can find a path around whatever
is triggering this corruption.
IME, it's quite rare to get corruption of a completed project (where you are
not modifying forms/reports/code, e.g. of an MDE), but pretty common during
development.
--
Allen Browne - Microsoft MVP. Perth, Western Australia
Reply to group, rather than allenbrowne at mvps dot org.
"CrazyAccessProgrammer" <
[email protected]>
wrote in message
