When trying to update a field in a form the field suddenly said #deleted#
while the other fields were in tact. The user wasn't able to change the
specific field anymore. I did a compact/repair on the backend and now
everything is (or at least seems to be) fine.

I now do see a table in the backend called MSysCompactError which indicates
error -1017 (Can't find field Description).

Can I safely proceed and delete the Error table, or should I do something
else, maybe delete the whole record and enter it again?

Thanks,

Lars

"Lars Brownies" <(E-Mail Removed)> wrote in message
news:grn49m$1r7d$(E-Mail Removed)...
> When trying to update a field in a form the field suddenly said #deleted#
> while the other fields were in tact. The user wasn't able to change the
> specific field anymore. I did a compact/repair on the backend and now
> everything is (or at least seems to be) fine.
>
> I now do see a table in the backend called MSysCompactError which
> indicates error -1017 (Can't find field Description).
>
> Can I safely proceed and delete the Error table, or should I do something
> else, maybe delete the whole record and enter it again?

The presence of the system table, MSysCompactError, means at least one of
your table definitions is now unreliable. To be on the safe side, I'd
restore the most recent backup, then I'd create a new mdb file and import
all the objects from the corrupted database file into it. Then I'd add the
most recent records from the new mdb file to the restored database, remove
any deleted records, and update any updated records since the backup was
taken to make the restored database current.

On Fri, 10 Apr 2009 11:42:14 +0200, "Lars Brownies" <(E-Mail Removed)> wrote:

>When trying to update a field in a form the field suddenly said #deleted#
>while the other fields were in tact. The user wasn't able to change the
>specific field anymore. I did a compact/repair on the backend and now
>everything is (or at least seems to be) fine.
>
>I now do see a table in the backend called MSysCompactError which indicates
>error -1017 (Can't find field Description).
>
>Can I safely proceed and delete the Error table, or should I do something
>else, maybe delete the whole record and enter it again?
>
>Thanks,
>
>Lars
>

Sounds like corrupt systems tables! See
http://www.granite.ab.ca/access/corruptmdbs.htm
for suggestions. Gigamite's suggestion of creating a new database and
importing objects would be a very good start.
--

John W. Vinson [MVP]

"Lars Brownies" <(E-Mail Removed)> wrote:

>When trying to update a field in a form the field suddenly said #deleted#
>while the other fields were in tact. The user wasn't able to change the
>specific field anymore. I did a compact/repair on the backend and now
>everything is (or at least seems to be) fine.
>
>I now do see a table in the backend called MSysCompactError which indicates
>error -1017 (Can't find field Description).

Note that you should *ALWAYS* make a copy of the MDB before compacting
if you suspect corruption.

1017 - "Could not find field "Description" It's possible the problem
is with a table that has a self-join and Memo fields, and has
referential integrity enforced. ACC2000: Table Corruption After
Referential Integrity Checks - 296389
http://support.microsoft.com/?kbid=296389 But it's more likely to be a
sign of corruption

Now I'm not at all sure I agree with the advice of going to yesterdays
backup and making the required changes to it. The problem is that
your users may not recall what changes were made.

Instead I'd suggest importing this MDB into a new one which should
clean up the corruption. Then compare the number of records in the
new MDB with the current MDB in each table.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Thanks Gigamite. I imported the compacted mdb in a new mdb. Everything seems
to be fine. The further steps you mentioned was not possible since I'd be
spending days figuring out what values were edited.

Lars

"Gigamite" <(E-Mail Removed)> schreef in bericht
news:grninl$f9e$(E-Mail Removed)...
> "Lars Brownies" <(E-Mail Removed)> wrote in message
> news:grn49m$1r7d$(E-Mail Removed)...
>> When trying to update a field in a form the field suddenly said #deleted#
>> while the other fields were in tact. The user wasn't able to change the
>> specific field anymore. I did a compact/repair on the backend and now
>> everything is (or at least seems to be) fine.
>>
>> I now do see a table in the backend called MSysCompactError which
>> indicates error -1017 (Can't find field Description).
>>
>> Can I safely proceed and delete the Error table, or should I do something
>> else, maybe delete the whole record and enter it again?
>
> The presence of the system table, MSysCompactError, means at least one of
> your table definitions is now unreliable. To be on the safe side, I'd
> restore the most recent backup, then I'd create a new mdb file and import
> all the objects from the corrupted database file into it. Then I'd add
> the most recent records from the new mdb file to the restored database,
> remove any deleted records, and update any updated records since the
> backup was taken to make the restored database current.
>

Thank you.
Lars

"John W. Vinson" <jvinson@STOP_SPAM.WysardOfInfo.com> schreef in bericht
news:(E-Mail Removed)...
> On Fri, 10 Apr 2009 11:42:14 +0200, "Lars Brownies" <(E-Mail Removed)>
> wrote:
>
>>When trying to update a field in a form the field suddenly said #deleted#
>>while the other fields were in tact. The user wasn't able to change the
>>specific field anymore. I did a compact/repair on the backend and now
>>everything is (or at least seems to be) fine.
>>
>>I now do see a table in the backend called MSysCompactError which
>>indicates
>>error -1017 (Can't find field Description).
>>
>>Can I safely proceed and delete the Error table, or should I do something
>>else, maybe delete the whole record and enter it again?
>>
>>Thanks,
>>
>>Lars
>>
>
> Sounds like corrupt systems tables! See
> http://www.granite.ab.ca/access/corruptmdbs.htm
> for suggestions. Gigamite's suggestion of creating a new database and
> importing objects would be a very good start.
> --
>
> John W. Vinson [MVP]

Thanks Tony.
As far as I know there is no self-join (I assume by self join is meant that
you join a table to itself?) The field where the error occured was indeed a
memo field.

> Instead I'd suggest importing this MDB into a new one which should
> clean up the corruption. Then compare the number of records in the
> new MDB with the current MDB in each table.

This is what I've finally done and results seem OK.

Pretty scary stuff, these corruptions.

Lars

"Tony Toews [MVP]" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> "Lars Brownies" <(E-Mail Removed)> wrote:
>
>>When trying to update a field in a form the field suddenly said #deleted#
>>while the other fields were in tact. The user wasn't able to change the
>>specific field anymore. I did a compact/repair on the backend and now
>>everything is (or at least seems to be) fine.
>>
>>I now do see a table in the backend called MSysCompactError which
>>indicates
>>error -1017 (Can't find field Description).
>
> Note that you should *ALWAYS* make a copy of the MDB before compacting
> if you suspect corruption.
>
> 1017 - "Could not find field "Description" It's possible the problem
> is with a table that has a self-join and Memo fields, and has
> referential integrity enforced. ACC2000: Table Corruption After
> Referential Integrity Checks - 296389
> http://support.microsoft.com/?kbid=296389 But it's more likely to be a
> sign of corruption
>
> Now I'm not at all sure I agree with the advice of going to yesterdays
> backup and making the required changes to it. The problem is that
> your users may not recall what changes were made.
>
> Instead I'd suggest importing this MDB into a new one which should
> clean up the corruption. Then compare the number of records in the
> new MDB with the current MDB in each table.
>
> Tony
>
> --
> Tony Toews, Microsoft Access MVP
> Please respond only in the newsgroups so that others can
> read the entire thread of messages.
> Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.granite.ab.ca/accsmstr.htm
> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

"Lars Brownies" <(E-Mail Removed)> wrote:

>Pretty scary stuff, these corruptions.

Yes but they have two good uses.

1) They force you to think about your backup.

2) They are a good stress test for your heart. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

"Lars Brownies" <(E-Mail Removed)> wrote in
news:groiej$2bj9$(E-Mail Removed):

> Pretty scary stuff, these corruptions.

Gee, I haven't had one at any my clients in at least 5 years.

Corruption is usually an indication that you're doing something
wrong somewhere along the line.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

This was my first corruption in the 2 years this app exists. Lately the app
is being used by more users, 18 total of which about 8 are "heavy users".
Maybe that's the reason why this issue comes to light.

"something, somewhere, along the line..."

At least now I know where to start looking :-)

Though I've implemented anti corruption measures I will read up again on the
corruption pages. Maybe I have to separate the memo fields in a separate
table. Ouch, that will take a lot design changed.

Lars


"David W. Fenton" <(E-Mail Removed)> schreef in bericht
news:Xns9BE9D1985936Cf99a49ed1d0c49c5bbb2@74.209.136.89...
> "Lars Brownies" <(E-Mail Removed)> wrote in
> news:groiej$2bj9$(E-Mail Removed):
>
>> Pretty scary stuff, these corruptions.
>
> Gee, I haven't had one at any my clients in at least 5 years.
>
> Corruption is usually an indication that you're doing something
> wrong somewhere along the line.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/