Hello
One of my clients want to move an application to a new computer. The program include files with Blob field that cause errors
During the copy It's raise the error that can't read from source file.
I try to zip the file but it's show the error "Data error (cyclic redundancy check)
I try to Verify, Repair, Optimize and it's raise the Error #601 The table MyBlobTable is corrupt
(Cannot find BLOB block during retrieval from cache) or (Error reading BLOB blocks into cache)

Can you give more suggestions how to fix the problem?
Thanks Sorin

On 12/14/2016 12:50 PM, Hershcu Sorin wrote:
> One of my clients want to move an application to a new computer. The program include files with Blob field that cause errors
> During the copy It's raise the error that can't read from source file.
> I try to zip the file but it's show the error "Data error (cyclic redundancy check)
> I try to Verify, Repair, Optimize and it's raise the Error #601 The table MyBlobTable is corrupt
> (Cannot find BLOB block during retrieval from cache) or (Error reading BLOB blocks into cache)
> Can you give more suggestions how to fix the problem?

Sorin,

Usually this is due to a failing hard drive or at least file system problem.

Do they backups ?

The only fix i know of involves using a data recovery software to try to
recover the file and/or trying to repair file system (for example chkdsk
/f).

However there is a good chance you will be losing some or all of that data.

I would attempt a disk level backup prior (this might or might not work
with bad sectors but number of backup solutions can try to skip those)
and then do disk repair. Assuming you do get the db files out then run
edb verify/repair to see what data is still intact.

Raul

Sorin


Raul is probably right but here are a few other things to try:

1. Isolate PC from internet
2. Run anti-virus, anti-malware, anti-adware to make sure system is clean
3. Turn off anti-virus, anti-malware, anti-adware

4. If the files are small enough try writing to DVD (weird though it may be sometimes its worked)
5. Try EXPORTing the tables in EDBManager

6. If you have any idea where in the file the problem is you can use a hex editor to try and smooth over the cracks - you'll end up losing a blob or two. One way to try and find out is to open the table and walk down it and see where EDBManager bombs

7. Ship the disk to a data recovery specialist (expensive)

8. Ship the disk to Tim (I don't know what he'll charge)

9. Revert to backup

Roy Lambert

Usually this is due to a failing hard drive or at least file system problem.

Do they backups ?

The only fix i know of involves using a data recovery software to try to
recover the file and/or trying to repair file system (for example chkdsk
/f).

However there is a good chance you will be losing some or all of that data.

I would attempt a disk level backup prior (this might or might not work
with bad sectors but number of backup solutions can try to skip those)
and then do disk repair. Assuming you do get the db files out then run
edb verify/repair to see what data is still intact.

Thanks Raul
I try defragment but it doesn't help.
Their backups also have the same error.
I'll try chkdsk but I'm very worried. They have more then 20GB of data on .EDBBlb files.
Thanks Sorin

On 12/15/2016 2:57 AM, Hershcu Sorin wrote:
> I try defragment but it doesn't help.

It's not a defrag issues - in fact defrag might cause even more problems
if the actual disk is having bad sectors.

> Their backups also have the same error.

Again looks like issue with disk or file system.

i would try a backup that is sector based and (for example disk snapshot
http://www.drivesnapshot.de/en/ - trial version should work fine) or
similar to see if it can backup the disk.

If it's really important data then you could look at data recovery
specialists (Roy's suggestion) but that's expensive and even they are
limited if actual disk going bad.


> I'll try chkdsk but I'm very worried. They have more then 20GB of data on .EDBBlb files.

Been in this situation before and it's always trouble. However you also
want to figure out what is going and try to recover as much as you can
quickly because there is always a chance that disk gets worse.

Raul

Sorin


One of the things I've done in a similar situation is write a small program to move the data from one table to another.

Create a new database with a table duplicating the structure of the existing one

Program using both old and new databases to simply copy the fields from the old to the new table using navigation methods. Do not select any index - just open tables. Wrap things in try..except blocks and just move on to the next record when an exception is raised.

It depends on what and where the corruption is but I have recovered over 90% of records doing this. Sometimes I recovered 0% but its worth a try

Roy Lambert