>Here's the experience my company has seen only a few times. You get the message about not having enough disk space and it stops adding info to the table. The part that seems 'corrupt' after that is when you do a pack it warns that the ftp is missing or invalid. We fix it by copying a portion of the data elsewhere (like an archive), delete those records from the 2gig table in question. FROM THERE, the too big table still refuses to pack, but you can then copy the undeleted records to another location, delete the original 'too big' one and rename the copy you just made. Then the complaints about missing/invalid FTP went away.
>
>The obvious good advice is to see the situation coming and prevent it in the first place. A lot less headache in the clean-up and no catastrophic system halt when you hit the limit. In our case, it was an automatic error logging system. A failed process that was writing to the log hit an infinite looping situation due to the error and continued writing to the log overnight until it maxed out! All existing records, however, we not corrupted and the only 'lost' data were the things it was never able to write due to the limit.

OK, thanks for the information.

I agree that trying to avoid the situation is the best strategy.

I can see that these kinds of logs can grow very fast. At Bata Shoe Organization, I had to clean up the audit trail every 1-2 months. However, it was still far from the 2 GB limit; I just transferred older data to reduce the size of the backups.