Delphi 7 Pro DBISAM 4.25 Build 2

Hi Tim: I have a client with a large table of financial data. For whatever reason, it has become corrupt about two thrids of the way through. It had corrupt headers but
the repair utility fixed those. When the client scrolls through the records and hits the corrupt area, he gets a 9217 engine error. If he tries to copy the file, it won't let
him. If he zips the file, it ony zips as far as the corruption and truncates the rest of the data. I had a range of record ids that encompasses the area of corruption and
wrote a SQL statement to delete those but he gets the same error. All this to say that he can't send me the file to look at. I though a hex editor may be able to see what
is going on. Anyhow, I am really stuck, any ideas? Thanks, Sean

Sean


What about start at the bottom and copy out what records you can until it hits the corruption. Then start at the top and copy out what you can. Hope the stuff in the middle wasn't important


Roy Lambert

Sean,

<< Hi Tim: I have a client with a large table of financial data. For
whatever reason, it has become corrupt about two thrids of the way through.
It had corrupt headers but the repair utility fixed those. When the client
scrolls through the records and hits the corrupt area, he gets a 9217 engine
error. If he tries to copy the file, it won't let him. If he zips the file,
it ony zips as far as the corruption and truncates the rest of the data. I
had a range of record ids that encompasses the area of corruption and wrote
a SQL statement to delete those but he gets the same error. All this to say
that he can't send me the file to look at. I though a hex editor may be able
to see what is going on. Anyhow, I am really stuck, any ideas? Thanks, >>

The repair should fix any 9217 errors caused by improper internal file
pointers or file lengths.  Also, how does the client know that the .zip file
only gets to the corruption ?  It is possible that the rest of the data is
not there anymore because the file system messed up the file blocks.
Finally, it would help immensely if you could get him to send me the table.
That way I can see if anything can be done to recover the rest of the data.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim, thanks and Roy too. I have been away this past week. The ZIP file was sent to me and I had a look at it. I can only 'see' to the area where he feels the
corruption commences as he can see the record numbers and then he then gets the error while scrolling further. Same for scrolling up. When I look at the zip file , my
file ends on about the same record as where he gets the corruption so I believe wrongly or rightly that the zip process truncates any records once the corruption is
seen. I will check with him to see if he has had any luck. I suggested a Ghost copy of the file as I believe it does a bit by bit copy and may get past the corruption. Is
this wishful thinking? All for now, many thanks, Sean

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Sean,

<< Hi Tim: I have a client with a large table of financial data. For
whatever reason, it has become corrupt about two thrids of the way through.
It had corrupt headers but the repair utility fixed those. When the client
scrolls through the records and hits the corrupt area, he gets a 9217 engine
error. If he tries to copy the file, it won't let him. If he zips the file,
it ony zips as far as the corruption and truncates the rest of the data. I
had a range of record ids that encompasses the area of corruption and wrote
a SQL statement to delete those but he gets the same error. All this to say
that he can't send me the file to look at. I though a hex editor may be able
to see what is going on. Anyhow, I am really stuck, any ideas? Thanks, >>

The repair should fix any 9217 errors caused by improper internal file
pointers or file lengths.  Also, how does the client know that the .zip file
only gets to the corruption ?  It is possible that the rest of the data is
not there anymore because the file system messed up the file blocks.
Finally, it would help immensely if you could get him to send me the table.
That way I can see if anything can be done to recover the rest of the data.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sean,

<< Hi Tim, thanks and Roy too. I have been away this past week. The ZIP file
was sent to me and I had a look at it. I can only 'see' to the area where he
feels the corruption commences as he can see the record numbers and then he
then gets the error while scrolling further. Same for scrolling up. When I
look at the zip file , my file ends on about the same record as where he
gets the corruption so I believe wrongly or rightly that the zip process
truncates any records once the corruption is seen. I will check with him to
see if he has had any luck. I suggested a Ghost copy of the file as I
believe it does a bit by bit copy and may get past the corruption. Is this
wishful thinking? >>

I doubt if it is the .zip process that is truncating the file.  It's more
likely just the file system that thinks the file actually ends there due to
the prior corruption of the file blocks for the file.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sean in Novi wrote:
> Delphi 7 Pro DBISAM 4.25 Build 2
>
> Hi Tim: I have a client with a large table of financial data. For whatever reason, it has become corrupt about two thrids of the way through. It had corrupt headers but
> the repair utility fixed those. When the client scrolls through the records and hits the corrupt area, he gets a 9217 engine error. If he tries to copy the file, it won't let
> him. If he zips the file, it ony zips as far as the corruption and truncates the rest of the data. I had a range of record ids that encompasses the area of corruption and
> wrote a SQL statement to delete those but he gets the same error. All this to say that he can't send me the file to look at. I though a hex editor may be able to see what
> is going on. Anyhow, I am really stuck, any ideas? Thanks, Sean
>
Sean,
    Has the client done a surface test on the drive? Maybe the drive
has bad blocks?

Sam