Hi Team,
I have never seen this before.  See attached screenshot.
Can someone enlighten me on its possible cause(s)??
I have no idea how I could debug this.
64bit edbsrvr is running on the Customer's Win 2012 R2 server PC.

Regards & TIA,
Ian

Ian

Are you running the last version of edbsrvr ?

If not this could be the reason. There were some critical bugs in prior versions while dealing with cleanup dead sessions and it could cause weird errors.

Regards
Eduardo

Ian


If Jose's suggestion doesn't help  it reminds me of occasions where things were closed down out of order or whilst events could still be fired by a visual component. I had to do quite a bit of work (dbgrids if I remember) to check if the form/application was closing and if so abort running the event.

Roy Lambert

Hi Jose,
Yup, current version.

Ian

Hi Roy,

Oh dear.  That doesn't sound good.

As I said, this is the first time I have seen it, in 7 years of EDB.
If it happens again I will get more concerned.

Regards,

Ian

Ian


As I remember it it was more a case of it not looking to good rather than any actual harm. Event fired which required a component that had already been freed which generated the AV. Never any damage to the data and the PC didn't go up in smoke.Took quite a while to work out what the problem was and come up with a signalling scheme to prevent it.

Roy Lambert

Hi,

since our last release with server version 2.38.0.2 we encountered lot of customer callbacks with malfunctions.
Error: Cannot lock the table [...] in the schema Default for shared access

I digged into it and it seems to be a faulty edbsrv.

We also get this AV.
Access violation at address 006634E8 in module 'edbsrvr.exe'. Read of address 00000004
And afterwards locking problems.

It turns out to be the time when a client lost the connection and the server begin to clear up the dead session.
Default 300 seconds (ServerDeadSessionExp)? I set the client into standby at 13:16:20

Error 9999 at 13:21:20
Further #300 locking errors.

The only solution to eliminate this is to restart the server.

I'm now back to 2.37.0.3
Works like a charm.

gripsware wrote:

> Hi,
>
> since our last release with server version 2.38.0.2 we encountered
> lot of customer callbacks with malfunctions.  Error: Cannot lock the
> table [...] in the schema Default for shared access
>
> I digged into it and it seems to be a faulty edbsrv.
>
> We also get this AV.
> Access violation at address 006634E8 in module 'edbsrvr.exe'. Read of
> address 00000004 And afterwards locking problems.
>
> It turns out to be the time when a client lost the connection and the
> server begin to clear up the dead session.  Default 300 seconds
> (ServerDeadSessionExp)? I set the client into standby at 13:16:20
>
> Error 9999 at 13:21:20
> Further #300 locking errors.
>
> The only solution to eliminate this is to restart the server.
>
> I'm now back to 2.37.0.3
> Works like a charm.

Hi, have you informed TIM / ElevateDB support about this?