"This action will reset the current code in break mode" message when CLOSING a TABLE

I am running Access 2K on a WinXP machine.

When I open a TABLE and look at the data I get the message:

This action will reset the current code in break mode.  

When I try to X out of the table.  The only way to kill the error message is to use the task manager to close access.
Keep in mind, no user created code should be running.

I am able to copy the table STRUCTURE, but not the STRUCTURE and DATA.  When I attempt to copy STRUCTURE and DATA, no records are copied.
If I create a new mdb file, then attempt to import the table, the table is imported, but NO records.  When I open the empty table, then try to close it, the same problem shows up.

If I try to append all records created before RecordCreateDate <#11/23/04# everything appends correctly.
If I try to append all records created before RecordCreateDate <#11/24/04# the operation fails.

It seems to me as though there is a corrupt record somewhere that is causing some internal code to fail.

Please help!!!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

It definitely sounds like you have a corrupted record. I'm assuming you've tried the basic compact and repair, and as indicated, you've tried importing into a new DB, without success. My suggestion would be to attemt to find the corrupt record, delete it, and then reimport everything.

There will usually be some indication in the data the it's a bad record. First thing to do would be to sort the table and see if anything seems out of sorts. Sort on the Primary Key, and some of the other commonly used fields.

Another method to locate, use some make table queries to split the table into halves, and try importing the result table of those queries. Use the Primary Key to split things up. Assuming that one of the tables will not import, repeat until you can locate the bad record. Binary searches aren't fun, but they usually work.

I've had to do that a few times, and it's not fun.

Hope that helps.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Alan WarrenApplications DeveloperCommented:
Try creating a new blank database and import the table into the new database, if succesfull, rename your old table in the original database and import the table from the new database you created. Sounds like corrupt tabledef entry.


pcalabriaAuthor Commented:
MGPSoft1, I used your make table query idea to find the bad record.  Once found, I deleted the record, which fixed the problem.

All fields of the bad record looked normal ...except one.
In one field, instead of finding data, I found: #Deleted

Half of my problem is solved.... I have now found the bad record and deleted it to correct the situation...

Now for the other half... How the heck did this happen in the first place????  What caused the: #Deleted  entry to show up in the first place?

Is it possible that a special key combination was entered with the record open?  I remember in dBase III a similar problem could show up if you marked a record for deletion but did not PACK the database.  Is this a similar problem?  

Alan, thanks for your suggestion.  Actually, I had tried importing and no records were imported.
the field that showed #Deleted was probably a LINKED field to a record in another table, and the corresponding record in that second table had been deleted.  This is known as a ORPHAN record, and probably indicates that you should set up a RELATIONSHIP between the main table and this second table, and in that relationship you should enforce REFERENTIAL INTEGRITY.

I'm not quite 100% sure what causes these errors, but my best guess is that Memo fields are part of the problem. I have a really big table in one database, and it has a few memo fields in it. Why I do it that way is another reason. But I've seen hints in newsgroups and such that if 2 people edit a memo field at the same time, it causes corruption. Again, that's my best guess at it, not quite sure.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.