Tim,

>>Also, are you using any ALTER statements ?

Yep, sorry, forgot that. But all 4 ALTER statements I used where in memory database context.

Heiko

Tim,

just a thought : I designed the application so that nothing SHOULD (again, not absolutely
sure at the moment) alter the database but me manually via EDB-Manager.

Can I set a Windows Write-Protect on the catalog for testing purposes, or is it possible
to cause damage of any kind by doing so ?

Heiko

Heiko,

<< Yep, sorry, forgot that. But all 4 ALTER statements I used where in
memory database context. >>

Which ALTER statements are you using ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

<< just a thought : I designed the application so that nothing SHOULD
(again, not absolutely sure at the moment) alter the database but me
manually via EDB-Manager.

Can I set a Windows Write-Protect on the catalog for testing purposes, or
is it possible to cause damage of any kind by doing so ? >>

Unfortunately, setting the rights so that the catalog is read-only to all
users will cause ElevateDB to treat the database as read-only for the table
updates also.

--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

<< 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. >>

Are you seeing any errors in the log at all now ?  The main thing is that a
catalog lock issue would have to have an unexpected exception occur during a
DDL operation in order to possibly cause the lock to not be released.
Looking at the EDB code, what I've found so far is that there are only a
couple of instances where there could be an issue, and they are related to
trying to ALTER a non-existent function or procedure, as well as a couple of
other objects.  But, again, this type of error (function not found, etc.)
should show up in the log so that it can be confirmed that such an error is
occurring.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>Which ALTER statements are you using ?

ALTER TABLE.

>>Are you seeing any errors in the log at all now ?

Besides the "Cannot lock the catalog db1 for read access", no. Only connects/disconnects,
and one failed prepare statement a few hours ago (error in my code, but I don't think its
related, was a simple select) for today.

Heiko

Tim,

an update: I checked my code, and no, I'm definitely using no DDL statements against the
disk database.

And the database lock seems to disappear after a while, so it's not present "forever" or
until server restart. I still don't know if it disappears at the moment a certain user
logs off (the one that caused it), or if it's some kind of time-out.

The "disconnection problem" didn't occurred again since I set the server/session values
back to defaults, it seems that one was homebrewed. Sorry for that.

Heiko

Heiko,

<< an update: I checked my code, and no, I'm definitely using no DDL
statements against the disk database. >>

So, you're seeing the catalog lock error on the disk-based catalog, but
you're not executing any DDL statements against that database ?  The only
other way for a session to encounter such an error would be for EDB to
acquire a read lock and then not release it.  I'll do some further scanning
and see what I can find, but I already looked for this in the code once and
couldn't find anything.

<< The "disconnection problem" didn't occurred again since I set the
server/session values back to defaults, it seems that one was homebrewed.
Sorry for that. >>

No problem.  It's just that once you start lowering the timeouts to very low
values, you run into issues where session are killed and removed faster than
reconnects or pings can occur, and that will cause all sorts of errors on
the remote side as the remote session tries to reconnect to a non-existent
session on the server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

any news ?

Heiko,

<<  any news ? >>

I have nothing to go on at this point, so I haven't even been able to
investigate anything with actual tests.  Until I have more information,
there's nothing else I can do.  I've checked the code several times, and
everything looks fine apart from the possible issues with an ALTER operation
that I indicated before (and doesn't apply in your case).  Any attempts that
I would make to try to construct a test would be basically a waste of time
without even knowing the general circumstances behind the issue.

Have you checked the logged events again to see if there's any indication of
the current function that is experiencing the issue ?  EDB logs the function
that was being executed with every single exception in the log manager.

--
Tim Young
Elevate Software
www.elevatesoft.com