Is it still the case that there is no recovery from an error 9217 during a
restore? Unfortunately the restore had already done some tables, so the
database is inconsistent.

Robert

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:21AC4D49-5A33-41C0-AB70-6BCA30DCB24E@news.elevatesoft.com...
> Is it still the case that there is no recovery from an error 9217 during a
> restore? Unfortunately the restore had already done some tables, so the
> database is inconsistent.
>

The problem is caused by a corrupt table containing blobs. You can back it
up, but the restore will fail.

Any ideas on how to take care of this? I don't want to do a verify on all
tables before backing up (with DBISAM, table errors are very few and far
between, and I do a daily backup) but unless I do some operation against the
table that detects the error, I'm faced with a situation where the customer
can do a successful backup but the backup is useless.

Robert

Robert,

<< The problem is caused by a corrupt table containing blobs. You can back
it up, but the restore will fail. >>

Can you replicate this ?  If so, please send me the table.

The only issue that we've encountered with backups that have restore issues
is when someone points their session's private directory to the same as the
database directory, and the backup picks up temporary tables that aren't
covered by the locks obtained by the backup procedure.  Thus partial and
inconsistent table files are backed up and cause the backup to become
un-restorable.  Of course, the solution to this is to not have the private
directory pointing to a database directory.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:514828EC-BDAC-4FAF-A29F-F69A834DA97C@news.elevatesoft.com...
> Robert,
>
> << The problem is caused by a corrupt table containing blobs. You can back
> it up, but the restore will fail. >>
>
> Can you replicate this ?  If so, please send me the table.
>

Sent to timyoung@elev

Robert

Robert

<< Sent to timyoung@elev >>

Yes, the issue is caused by the fact that DBISAM is using the internal file
size in the header for determining the size of the file, and in the case of
a corrupted table, this file size is not correct.  I'll see about changing
this for the next build so it uses the file sytem file size instead.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:D8044A1C-1891-43BB-87A3-39BA7A676CE3@news.elevatesoft.com...
> Robert
>
> << Sent to timyoung@elev >>
>
> Yes, the issue is caused by the fact that DBISAM is using the internal
> file size in the header for determining the size of the file, and in the
> case of a corrupted table, this file size is not correct.  I'll see about
> changing this for the next build so it uses the file sytem file size
> instead.
>

If I read you correclty, the backup will continue to work, backing up a
corrupted table, and the restore will now restore the table?

It would be nice to know when doing the backup that there is a potential
problem, but that might not be possible without doing a verify.

Robert

Robert,

<< If I read you correclty, the backup will continue to work, backing up a
corrupted table, and the restore will now restore the table? >>

Correct, garbage-in, garbage-out, so to speak.  However, the table can still
be repaired just fine after it is restored, so it isn't like anything is
different from the situation that existed just prior to the backup.

<< It would be nice to know when doing the backup that there is a potential
problem, but that might not be possible without doing a verify. >>

Yes, the only way would be to do a (possibly lengthy) verify on every table
before the backup.

--
Tim Young
Elevate Software
www.elevatesoft.com