Hello,

I have sometimes exception with message "ElevateDB Error #100 There is an error in the metadata for the table MyTable (A write operation did
not complete and a repair is required)". Code is very simple:

with MyTable do
begin
SetRangeProc(aparams);//MyTable.SetRange() for select one specified record
if RecordCount = 0 then
begin
Append;
try
//set fields value
finally
 Post; <-- exception
end;
end;
end;

What may cause this exception when Append was executed without problems?
My app has many threads. Every thread has own set of dbcomponents (session with uniqe name, database, table, queries).

--
best regards,
PF

Piotr,

<< I have sometimes exception with message "ElevateDB Error #100 There is an
error in the metadata for the table MyTable (A write operation did not
complete and a repair is required)". Code is very simple:

What may cause this exception when Append was executed without problems? >>

First of all, Append doesn't actually do anything with the database.  It
just sets up a new buffer for use during an insert.  The Post actually
performs the insert.

<< My app has many threads. Every thread has own set of dbcomponents
(session with uniqe name, database, table, queries). >>

If you're getting this error message, and the table isn't actually
corrupted, then you've got an issue with your multi-threading setup.  You
can verify if the table is actually corrupted by trying the operation on the
same table in the EDB Manager.  If it works there, then you've got
re-entrancy into the database engine from multiple threads, which is a
definite no-no.

--
Tim Young
Elevate Software
www.elevatesoft.com

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

<< If you're getting this error message, and the table isn't actually
corrupted, then you've got an issue with your multi-threading setup.  >>

Could you tell me what must be done when we want to write VERY SAFE multi-threaded
application which every thread (for example, dozens threads) work on one ElevateDB table?
Every thread has its own components: unique (remote) session, db, table, query. What else?

I resigned from KeepTablesOpen=true in thread's sessions and now
I have occasionally new exceptions like #601 and #1007 (threads don't delete
any records!). I don't understand how it's possible that we can corrupt tables
on remote server so easily... :-/

Maybe 2.02b1 will be better, I will try it tomorrow.

<<You  
can verify if the table is actually corrupted by trying the operation on the
same table in the EDB Manager.  >>

If this exception occur I can only repair table :-/

--
best regards,
Piotr F

Piotr,

<< Could you tell me what must be done when we want to write VERY SAFE
multi-threaded application which every thread (for example, dozens threads)
work on one ElevateDB table? Every thread has its own components: unique
(remote) session, db, table, query. What else? >>

You need to make sure that each component is properly connected to the
proper session component via the SessionName property.  Failure to do so
will cause one or more threads to access the same Default session, and will
cause multi-threading issues.  If you want me to take a look at your code
and tell you what is wrong, just send me an email with the project source.

<< I resigned from KeepTablesOpen=true in thread's sessions and now I have
occasionally new exceptions like #601 and #1007 (threads don't delete any
records!). I don't understand how it's possible that we can corrupt tables
on remote server so easily... :-/ >>

Two things:

1) The tables are most likely not corrupted.  What you're seeing is a
message from the engine saying that it *looks* like they're corrupted
because of an inaccurate state in the engine.  This is most likely due to
the threading issues that I have already mentioned.

2) We cannot prevent re-entrancy into the engine because, in some cases,
ElevateDB requires this itself.

<< Maybe 2.02b1 will be better, I will try it tomorrow. >>

It most likely will have absolutely no affect on this issue for you.

<< If this exception occur I can only repair table :-/ >>

I'm not sure what you mean ?  Are you saying that you cannot open the table
until you repair it ?

--
Tim Young
Elevate Software
www.elevatesoft.com