> We've had some cases where an OPTIMIZE TABLE failed because we ran out > of disk-space (error message "28 when fixing table"). All subsequent > operations gave us an error 144 ("Table is crashed and last repair > failed"), resulting in partial backups and partially updated databases.
> What I'd like to do is check on the table's condition *before* doing > something that might give us that error message. I'm assuming there's a > status bit somewhere that says that the table is crashed, and basically > I'd like to be able to read that bit. > CHECK TABLE or myisamchk is not really an option, because with the size > of tables we're using that can take over an hour, even with the -q flag. Using myisamchk -r -n -t <tmpdir> table_name significantly speeds up the repair process. Copy one of your large tables and give it a shot. Specify a tmpdir that is on a disk/volume that gets little use and has plenty of space, if possible. Best of luck! -Bruce Bristol -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]