Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Error #601 The table X is corrupt (Error flushing header to disk).
Sun, Nov 11 2012 5:33 PMPermanent Link

IQA

Hi All,

I'm using ElevateDB UNICODE version 2.10 Build 1 and just received this
error on my client / server program on the client side.

It was only updating one record and there's plenty of room on the hard
drive.

Should I be checking the table itself for corruption in this situation?

Thanks,

Phil.



Attachments: error601.jpg
Sun, Nov 11 2012 5:41 PMPermanent Link

IQA

> I'm using ElevateDB UNICODE version 2.10 Build 1 and just received this
> error on my client / server program on the client side.
>
> It was only updating one record and there's plenty of room on the hard
> drive.
>
> Should I be checking the table itself for corruption in this situation?
>
> Thanks,
>
> Phil.

Just in addition, I tried verifying the table in question, it said no
problems, so I just tried repairing and it cause a buffer flush error
right at the end... Then I tried optimizing the table and all was
well... Then the error came up for another table, so I repeated the same
process and then it jumps to another table giving the error?

Any ideas, strange one.
Mon, Nov 12 2012 3:33 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Phil


As the manual says I'd contact Tim direct.

Roy Lambert
Wed, Jan 2 2013 5:54 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Phil,

<< I'm using ElevateDB UNICODE version 2.10 Build 1 and just received this
error on my client / server program on the client side. >>

This indicates that there was a disk issue when writing data, either a lack
of disk space or something more serious.

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Jan 2 2013 1:04 PMPermanent Link

Terry Swiers

Hi Phil,

> Then the error came up for another table, so I repeated the same process
> and then it jumps to another table giving the error?

Saw this same exact situation with a customer of ours recently using a
real-time backup software like Carbonite.  The backup software was locking
the tables with exclusive access during the backups and causing write
failures if our software attempted update a file that was currently being
backed up.

We had the customer configure a scheduled backup from the EDB server to run
periodically and then configured their backup software to make backups of
the backups, NOT the live data.   Once we did this, the problems went away.


---------------------------------------
Terry Swiers
Millennium Software, Inc.
http://www.1000years.com
http://www.atrex.com
---------------------------------------


Image