>>Error #100...Are you executing any DDL statements at all when this happens ?

>I have to check.

Addition : Against the disk database, no for sure. Against the memory database, maybe...I
have the habit of wrapping transactions around big chunks of operations (often dml
statements and dataset.edit-...-post mixed) to ensure that either everything, or nothing
is executed. May be, that in some cases I create memory tables for temporary stuff and
doing cross database things during a transaction.

Heiko,

<< Addition : Against the disk database, no for sure. Against the memory
database, maybe...I have the habit of wrapping transactions around big
chunks of operations (often dml statements and dataset.edit-...-post mixed)
to ensure that either everything, or nothing is executed. May be, that in
some cases I create memory tables for temporary stuff and doing cross
database things during a transaction. >>

Okay, I checked out the DDL statements, and they all have transaction
checks, so that's not it.  Are you creating any temporary tables using
CREATE TEMPORARY TABLE ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>Are you creating any temporary tables using CREATE TEMPORARY TABLE ?

No, I always use memory tables for temporary stuff.

Heiko

Heiko,

<< No, I always use memory tables for temporary stuff. >>

Okay, that makes things easier.  I'm about to start running the stress tests
here, but if you could keep exploring on your end I would definitely
appreciate it.  There's no such thing as too much information with these
types of issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

thank you very much for your effort.

>>I'm about to start running the stress tests here

If they include only login/logoff, I think you won't succeed. I think that at some time,
some client executes a command that creates some kind of "lock" on the database...and at
the moment I'm absolutely in the dark what operation initiates this.

If you start the server and just do X logins with EDB-Manager, it works. The "9" Users was
only a current example...sometimes it happens when only 2 users are logged on.

The schema is always : A random count of users log in, working a while without problems,
logging on and off, doing everything...and then, absolutely unpredictable, one client
can't login.

Heiko

Heiko,

<< If they include only login/logoff, I think you won't succeed. I think
that at some time, some client executes a command that creates some kind of
"lock" on the database...and at the moment I'm absolutely in the dark what
operation initiates this. >>

They include a database open that triggers the connection.

<< If you start the server and just do X logins with EDB-Manager, it works.
The "9" Users was only a current example...sometimes it happens when only 2
users are logged on.

The schema is always : A random count of users log in, working a while
without problems, logging on and off, doing everything...and then,
absolutely unpredictable, one client can't login. >>

Yes, but a login wouldn't be prevented by a database lock, and I was under
the impression that you cannot simply even login to the server when the
problem occurs.  Is that not correct ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>I was under the impression that you cannot simply even login to the server when the
problem occurs.  Is that not correct ?

The first occurrence is at a "database.Open". I'm doing a successful "session.Connect"
before that. Only when I'm trying to remove sessions manually from the server, during the
5-minute-freeze that occurs then, "session.Connect" fails.

It happened again at the moment, and this time while in "error state" I tried to open
EDB-Manager (haven't tried that before). It hangs a while, after that I get "The
connection to the ElevateDB Server has timed out while waiting for a response.  Would you
like to stay connected and keep waiting ?" If I answer "Yes", I get "ElevateDB Error #300
Cannot lock the catalog db1 for read access."


Heiko

Heiko,

<< The first occurrence is at a "database.Open". I'm doing a successful
"session.Connect" before that. Only when I'm trying to remove sessions
manually from the server, during the 5-minute-freeze that occurs then,
"session.Connect" fails.

It happened again at the moment, and this time while in "error state" I
tried to open EDB-Manager (haven't tried that before). It hangs a while,
after that I get "The connection to the ElevateDB Server has timed out while
waiting for a response.  Would you like to stay connected and keep waiting
?" If I answer "Yes", I get "ElevateDB Error #300 Cannot lock the catalog
db1 for read access." >>

If there's an issue with the catalog locking, then that means that something
is locking the catalog for update and not releasing the lock, which would be
very unusual.  Is the client application multi-threaded at all ?  Also,
exactly what DDL operations are occurring during the execution of the
application ?  You can see a list of them all here:

http://www.elevatesoft.com/manual?action=mancat&id=edb2sql&category=10

--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

Also, are you using any ALTER statements ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>Is the client application multi-threaded at all ?  

No. Even forbidden to start more than a single instance.

>>exactly what DDL operations are occurring during the execution of the application ?  

I'm pretty sure that I don't use DDL operations for the disk database at all. I'll check
that, it will take a while. For the memory database I constantly use CREATE TABLE (AS
select * from diskdb.table), DROP TABLE and CREATE/DROP INDEX but that's all.

Heiko