Hi Tim (and others),

We've experience on a regular base the following error message:
"ElevateDB Error #100 There is an error in the metadata for the table Artikelen (A write operation did not complete and a repair is required)"

My colleague Kick Martens has written about this in the past see:
http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&msg=11777&start=1&keywords=kick&searchbody=True&forum=EDB_Announce&forum=EDB_General&forum=EDB_SQL&forum=EDB_Connect&forum=EDB_Extensions&forum=EDB_Beta&forum=EDB_Binaries&forum=EDB_Suggestions&forum=EDB_ThirdParty&forum=EDB_Discussion#11777

Yesterday I've had the same problem again with an customer of us, I've downloaded the customers its data (files which are being imported) so i can test/try it here locally, and guess what... the problem was reproduce-able, after receiving the error i repeat the steps again to see if i really can reproduce it and... yes i can!.

But, after reading some well spoken topic's on the Elevate forum about the #100 error i thought "let's give it another try, but now with some other setup", I've totally disabled the Symantec End-Point Protection on my local machine and re-import it again... this time the file is successfully imported (after a 2 hour run). I was totally excited about it.. wow... is this the problem for the  #100 error's with our customers?

As i wanna know for sure, I've again repeat the above steps. But this time with the Symantec End-Point Protection fully enabled (i thought... now the import *must* fail again!) you almost can guess it... it didn't FAIL

So after the fourth run i got a little bit disappointed, i thought we have found/tackled the problem, but my feeling about it is not sure... was this an random/coincidence solution?, or do you think it can absolutely be the problem for the annoying #100 error.
(why is it annoying for our customers... the average import time with our customers is varying from 1 hour to 6 hours. When the import fails after 5 hours of crunching they are less happy... no imported file, 5 lost hours on a server task, and not for the first time).

So can you help me out with some pointers to look at? We are using ElevateDB 2.06B1. The Elevate server is installed as an Service on a W2K3 / W2K8 machine, the import tool runs also on that same server, it's connecting via Remote (see: my other topic, as we speak I'm busy with re-program the import tool and use an local connection, hybrid mode... local/remote support). The files that needs to being imported are also located locally on that same server.

Are there any other points to look at or taking care of?
@Tim: is the early'er apply'ed fix (you've fixed the problem of my colleague iirc in a 2.03bx version) also/still available in the 2.06B1 version?

Thanks in advance,



With kind regards,

Richard Lichtendahl
ENK Software BV - The Netherlands, Europe (+1 GMT)

Richard,

<< My colleague Kick Martens has written about this in the past see:
> http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&msg=11777&start=1&keywords=kick&searchbody=True&forum=EDB_Announce&forum=EDB_General&forum=EDB_SQL&forum=EDB_Connect&forum=EDB_Extensions&forum=EDB_Beta&forum=EDB_Binaries&forum=EDB_Suggestions&forum=EDB_ThirdParty&forum=EDB_Discussion#11777
>  >>

That's a different problem than what you're describing.  The problem that
Kick reported had to do with memory exhaustion during an import due to an
issue with the buffer manager.

<< Yesterday I've had the same problem again with an customer of us, I've
downloaded the customers its data (files which are being imported) so i can
test/try it here locally, and guess what... the problem was reproduce-able,
after receiving the error i repeat the steps again to see if i really can
reproduce it and... yes i can!. >>

What are you reproducing - the #100 error ?  And, if so, are you saying that
it simply occurs by itself, with no other exception/error message prior to
it ?

<< (why is it annoying for our customers... the average import time with our
customers is varying from 1 hour to 6 hours. When the import fails after 5
hours of crunching they are less happy... no imported file, 5 lost hours on
a server task, and not for the first time). >>

Kick indicated that the import was executing in around 8 minutes.  Where is
the 5 hours coming from ?

<< Are there any other points to look at or taking care of? >>

I'm not even sure that the problem is yet, based upon your description, so I
can't really answer that question.

<< @Tim: is the early'er apply'ed fix (you've fixed the problem of my
colleague iirc in a 2.03bx version) also/still available in the 2.06B1
version? >>

Yes, of course.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,


<<That's a different problem than what you're describing.  The problem that
Kick reported had to do with memory exhaustion during an import due to an
issue with the buffer manager.>>

Sorry you are absolutely right, i didn't look good enough at Kick's error message,
he tipped me about his post on the newsgroup and probably thought that this problem
was the same as then. But i also overlooked the message from the original post.



<<What are you reproducing - the #100 error ?  And, if so, are you saying that
it simply occurs by itself, with no other exception/error message prior to
it ?>>

I thought i was (read: can) reproducing the #100 error, but after a couple of
reproductions i changed the configuration (by turning of the Symantec End-Point Protection) and
after that i can't reproduce it anymore. Even after turning back on the Symantec EPP.
Was it just luck? i don't know. This is exactly the same issue some of our customers experience,
this week the import runs fine, the next week it fails (or not) and sometimes after re-starting the
same import (just a couple of hours later) it will succeed (or not).
So what you see with our customers is totally randomness. (although, it look like randomness)
AFAIK the #100 error is the only one i receive, no exception(s) prior to it.



<<Kick indicated that the import was executing in around 8 minutes.  Where is
the 5 hours coming from ?>>

Thats correct, we (Kick and I) both have some heavy developer machines with 2 SDD disk running in
stripe-mode (RAID). Thats the reason why we reached some ridiculous fast imports. Our
customers have a big variety of servers, some of them have 'old' servers running W2K3 and
some of them have nice 'new' ones with W2K8, but until now i did not have seen any customer server which is
performing so fast as our local machines. And to making it more varying, the customers can have different
sizes of import files, some of them have < 1GB files and some of them have > 1GB and lots of them just
somewhere in between, so the size of the import file can vary a lot.
That's why i was talking about 1 to 6 hours, and the 5 i mentioned is nothing hard, it was just
a random number in this random situation.



<<I'm not even sure that the problem is yet, based upon your description, so I
can't really answer that question.>>

OK, is there some extensive logging mechanism available in the EDBServer, which can give us more detailed information about the exception (rownumber? columnnumber? etc?)?
So i can try to turn it on with a customer if they have the same problem again? Other options? ideas?



<<Yes, of course.>>

That makes sense, i would expected it, but you never be sure. So i thought... just ask it on Tim to make sure.
Better one time too many asked, then one time too short.



Thank you for taking the time to answer Tim.



With kind regards,

Richard Lichtendahl
ENK Software BV - The Netherlands, Europe (+1 GMT)

Richard,

<< I thought i was (read: can) reproducing the #100 error, but after a
couple of reproductions i changed the configuration (by turning of the
Symantec End-Point Protection) and after that i can't reproduce it anymore.
Even after turning back on the Symantec EPP.  Was it just luck? i don't
know. >>

Running *any* kind of anti-virus software that does real-time scanning
alongside of EDB is a recipe for such problems.  You simply cannot have such
software interfering with the database operations.  Everything EDB is about
involves reading/writing to disk, and such AV software specifically
interjects itself into such reads/writes.

<< That's why i was talking about 1 to 6 hours, and the 5 i mentioned is
nothing hard, it was just a random number in this random situation.  >>

Okay, it just stuck out as a really high number compared to what you were
mentioning before.  However, you should also keep in mind that the above
comments also apply to performance.  Having 3rd party software interject
itself into the I/O chain will cause slowdowns and performance issues, also.

<< OK, is there some extensive logging mechanism available in the EDBServer,
which can give us more detailed information about the exception (rownumber?
columnnumber? etc?)?
So i can try to turn it on with a customer if they have the same problem
again? Other options? ideas? >>

We have a debug version of the EDB Server in the \servers subdirectory of
the main installation directory.  However, it will only perform a debug dump
on unhandled exceptions like AVs.  What you want is this table:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=LogEvents_Table

You can view it easily in the EDB Manager under the active session node
(View Logged Events).  You can then filter the table for errors and see if
there are any import errors in there.

--
Tim Young
Elevate Software
www.elevatesoft.com