some of our customers are getting this error with latest server but we can't reproduce this on our side.

What is happening on serverside that these messages are shown on client-side?
Also one customer today had again a "#601 the table XX is corrupt (The index XXXX contains duplicate keys)" after some of #1006 are shown.

Repair of table has solved the problem in the first step but again, why can a client destroy a index on server side. Also it was not possible to repair the table ... all clients were shutdown but the repair showed that the table is in use. Only stopping of server - engine and restarting + reparing the table was possible in this case.

Anyone else having such problems?

Yusuf Zorlu
MicrotronX

Yusuf


There are ways of corrupting an EDBTable - the best is hacking it with a hex editor. The second best is insufficiently isolated threads.

I'm hoping your customer isn't using a hex editor on the table so my guess would be threads. Does your application use threads? If not other alternatives are:

anti virus in some way interfering with the data flow
buffering - network vs windows vs ElevateSoft (you should be able to test this by turning ElevateSoft's buffering off)
hardware - real fun

The fact that a table remained locked until terminating the server with no apparent connections would, to me, indicate threads.

Its worth getting hold of a tool to allow you to see what's locking a file - my toy is available at https://www.majorgeeks.com/files/details/unlocker.html

Roy Lambert

Roy Lambert wrote:

<< There are ways of corrupting an EDBTable - the best is hacking it with a hex editor. The second best is insufficiently isolated threads.

Thanks for you tips Roy,

we have disabled threads to check this out and in this case it has nothing to do with threads. Everything works in mainthread with enabled buffering. We'll see if we can get more information to reproduce this on our side.

Yusuf Zorlu
MicrotronX

Yusuf


That makes it much more difficult

I'll see if I can come up wit something else.

Roy Lambert

On 4/26/2019 9:06 AM, Yusuf Zorlu wrote:
> we have disabled threads to check this out and in this case it has nothing to do with threads. Everything works in mainthread with enabled buffering. We'll see if we can get more information to reproduce this on our side.

Are you using global buffered file I/O ?

How are you running repair ?

Global buffered file I/O will have an exclusive lock on the table (even
with no clients connected) so repair needs to be run using remote
connection to EDBSRVR.

If you want to run local repair then EDBSRVR must be shut down (like you
had to do).

If you're not using global buffered file I/O then there must be a
disconnected session(s) on the EDBSRVR that is locking the table. If
this is the case you can check for server sessions before shutting down
EDBSRVR to see if you can identify what it is.

Raul

Raul wrote:

> Are you using global buffered file I/O ?
> How are you running repair ?

Hi Raul,

we're using buffered file i/o and doing everything only over remote-connections. It seems that the edbmanager is blocking something. We had same "table in use" on friday at another customers system, closing the edbmanager and restarting it was successful in that case. User had not opened any table but it seems that there was an cursor open.

Yusuf Zorlu
MicrotronX

Yusuf,

<< Repair of table has solved the problem in the first step but again, why can a client destroy a index on server side.  >>

We have exchanged about 50 emails on this subject (and over 200, in general, over the last few months - I counted), so I can only assume that you're trying to just simply make us look bad by posting this comment.  You also know that I've personally spent hours upon hours, including weekends, trying to help reproduce what you're seeing, yet I have had zero success in doing so.  And, we never charged you a *penny* for any of this support.  Is this how you say "thank you" ???

Either send me a project that reproduces what you're describing, or don't.  But, stop posting the same thing over and over again.  You know darn well that I can't fix something that I can't reproduce (or even come up with a valid reason for occurring in the first place).

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Either send me a project that reproduces what you're describing

I just want to say how good Tim has been at this too. Years ago I had some very obscure bug in DBISAM that my particular code fell over. I gave him my code as-was, and he refined it down to something he could build and reproduce. It didn't show the bug, but he sent it back, and I was able to adjust that to make it happen, and a day later it was sorted. Fantastic support that I've never seen anywhere else. But of course you have to be able to reproduce it to fix it, and if you can't provide something that reproduces it, then it probably isn't the database code.

--

Matthew Jones

Tim Young [Elevate Software] wrote:

<< We have exchanged about 50 emails on this subject (and over 200, in general, over the last few months - I counted), so I can only assume that you're trying to just simply make us look bad by posting this comment.  You also know that I've personally spent hours upon hours, including weekends, trying to help reproduce what you're seeing, yet I have had zero success in doing so.  And, we never charged you a *penny* for any of this support.  Is this how you say "thank you" ???


Hi Tim, sorry but you misunderstood me.

I don't want to make that you / elevatedb looks bad. It is a very good product which works perfect.

I wanted to know if other users / developers have same things. We know that something on our side must be doing something wrong and i hoped that we hit someone who had same issues ... This is for what a forum is for?? If you don't want us to post to this forum than tell it to us. If i have direct questions to you i would send you a mail but in this case it is for asking the developement community but again, if you don't want us to post we will not post any more.

Yusuf Zorlu
MicrotronX

Can anyone test a very basic query, of course a wrong written query:

select * from mytable1, mytable2

Be sure that mytable1 and mytable2 has >1000 rows in it.
If i do this, than the server does the query but all other sessions from all other computers are hanging.
Also doing a select from configuration.serversessions results in  "ElevateDB Error #506 Cannot lock the session manager (ID: 7)"

Again, we're not saying that ElevateDB is bad! We have the source and we have added some code to ServerEngineAfterStart to initialize some basic tables... where the problem can be.

It is possible that the other problems are a result of this hang and something unknown happens there if a lot of clients trying to edit / post / insert in the time where the server hangs / or does a lot of reading to combine that where-join...

So to find the bug on our side i need another developer which can test the above query + doing other queries / select at the same time to the server. Thanks for some help.

Yusuf Zorlu
MicrotronX