We've got a customer who has received this error a number of times - any idea what it means please and how to resolve it? (Have tried REPAIR TABLE etc.)

Thanks,

Hedley

Hedley,

maybe this will provide some interesting informations (though it's
related to DBISAM):

http://www.elevatesoft.com/incident?action=viewaddr&category=dbisam&release=4.33&incident=3566

Uli

Hedley,

<< We've got a customer who has received this error a number of times - any
idea what it means please and how to resolve it? (Have tried REPAIR TABLE
etc.) >>

This could be cause by a lot of things - the internal structure that raises
this error is used in many different places.  Let's start with the basics -
what version/build are you using ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

That customer is on 2.12 build 2 - as are dozens of other customers who aren't experiencing any issues.

This is the Client/Server version of EDB and my app is a C# .NET program which uses the EDB ADO.NET drivers.

The routine which through this error in the last reported instance was nothing special - just a SELECT statement which returned a handful of rows.

Many thanks!

Any thoughts please chaps?

Hedley


Why not open a support session to get some priority? Remember these are in the main user supported groups with Tim popping in whenever he surfaces from whatever he's doing.

Roy Lambert

Thanks Roy. It's not a critical issue as we're only seeing it for 1 (out of 100s) of customers.

Hopefully when Tim "pops in" to this thread he can offer some insights on what might be causing it and how we might resolve it - thanks!

On 9/19/2013 3:53 AM, Hedley Muscroft wrote:
> Any thoughts please chaps?

Waiting for Tim is the way to go on this.

Wild guess - i looked at most obvious place 4096 limits are listed
(http://www.elevatesoft.com/manual?action=topics&id=edb2&product=rsdelphiwin32uni&version=XE4&section=appendix_system_cap)
:
- # of concurrent sessions : check your server sessions and see how many
you have
- # of total jobs
- # of routines in DB
- # of tables (i assume temp included)
- # of users defined

Raul

Thanks Raul - good suggestions.

- # of total jobs -> I never use "jobs"
- # of routines in DB -> zero
- # of tables (i assume temp included) -> approx 120 tables unless loads of temp ones are being spawned
- # of users defined -> always 2

This leaves :-
- # of concurrent sessions : check your server sessions and see how many you have

As I'm using ADO.NET with connection pooling enabled... I wonder if there's something in the EDB ADO.NET implementation which might not be closing connections correctly? I know this customer leaves their database application running 24/7 (as it has automated processes) so maybe over time the session limit is being hit?

Looking forward to Tim's thoughts.

On 9/19/2013 3:29 PM, Hedley Muscroft wrote:
> As I'm using ADO.NET with connection pooling enabled... I wonder if there's something in the EDB ADO.NET implementation which might not be closing connections correctly? I know this customer leaves their database application running 24/7 (as it has automated processes) so maybe over time the session limit is being hit?
>

AFAIK EDB is fairly aggressive in removing dead Sessions so i doubt it's
the sessions.

However, if you have access to the EDB Server then it would tell you #
of connections on user interface or you can query the ServerSessions
table
(http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ServerSessions_Table).

Raul