Delphi 2005/v4.25

We just converted backup feature in our software from using FileCopy to DBISAM.Backup
function and during testing we got one of these

Engine Error # 9217 Error reading from the table or backup file

There were no errors during backup. No power off, no reboots. Database and backup file are
local (no network issues). Original DB Size ~500MB.

I do not need to restore this specific file (we are just testing) but I have a BIG
questions. How reliable this Backup/Restore functionality in v4.25 ? If during my few
dozens tests on relatively clean environment I got a corrupt backup once - what is going
to happen in the real world with 100s of customers? Are we just better off with FileCopy?

bump...

Any ideas, suggestions?

alex,

> bump...
>
> Any ideas, suggestions?

Can DBSYS read the backup file successfully? (I am assuming from your
description that the restore problems are with your own application). Is
there a significant difference in size between the faulty bkp file and
the others that work OK?

Eryk

Alex,

<< We just converted backup feature in our software from using FileCopy to
DBISAM.Backup function and during testing we got one of these

Engine Error # 9217 Error reading from the table or backup file

There were no errors during backup. No power off, no reboots. Database and
backup file are local (no network issues). Original DB Size ~500MB.

I do not need to restore this specific file (we are just testing) but I
have a BIG questions. How reliable this Backup/Restore functionality in
v4.25 ? >>

We use it for all of our data have done so for the entire time that 4.x has
been around.  We've had one other report of an instance like this where an
application's backup/restore has run into this problem, but were unable to
determine the cause.  However, it appears to be related to an issue with
compiler settings and the compression
code.   Are you recompiling any DBISAM source code in your application ?

--
Tim Young
Elevate Software
www.elevatesoft.com

>Are you recompiling any DBISAM source code in your application ?

No, using DCU's that came with the installer. Any way to quick validate backup without
restore?

Alex,

<< No, using DCU's that came with the installer. >>

Could you send me the backup file that was corrupted ?

<< Any way to quick validate backup without restore? >>

Not at this time, no.  It shouldn't be necessary if the backup completed
properly and the backup file is stored on a secure media.

--
Tim Young
Elevate Software
www.elevatesoft.com

<< No, using DCU's that came with the installer. >>
> Could you send me the backup file that was corrupted ?

Hmmm... I could not find it. VMWare image that I used for testing was reverted to snapshot
and I did not save a copy

We will keep testing, if we get another broken backup - we will send you a file.

Alex,

<< We will keep testing, if we get another broken backup - we will send you
a file. >>

Thanks.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:FA76FF97-EAE6-4DC6-B2AC-896086BD3960@news.elevatesoft.com...
> Alex,
>
> << We will keep testing, if we get another broken backup - we will send
> you a file. >>
>

Only case I've experienced was a backup that did not end, I forget now the
reason whiy it did not end. It is not a bad practice to have a log table and
log beginning and end of things like a backup. In my case, it was easy to
see in the log that the backup started, but we never logged an end. With
time we have added more and more stuff to the log, it comes in really handy
to research those head-scratchers, and the cost is mimimal.

Robert