Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Any tips on getting around EDB Error #300?
Tue, May 20 2014 12:53 AMPermanent Link

Mario Enríquez

Open Consult

Hello Everybody,

We have EDB 2.12 b2 application running for about a year now, but until a week ago a user started getting the following error on daily bases.

"ElevateDB Error #300 Cannot lock the catalog Merkantus in the database Merkantus for read access"

This is during login, a no other database operation is done during this stage.

We've around 6~14 concurrent users at any given time. The EDB Server is on unicode and most workstation are on Windows 7.

The user thats getting the error it usually the same and when it attempts a logon other users are working normally.

I've no idea where to begin searching for this bug, any recommendations are welcome. Frown

Regards,
Mario
Sat, May 24 2014 4:41 PMPermanent Link

Barry

Mario Enríquez,

I haven't seen this myself, so I will throw some general questions at you and maybe someone with more experience can chime in.


Something like this occurred back in 2008. See the thread http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&page=1&msg=7410#7410

1) I'm assuming you have the full EDB C/S version and not using the limited user C/S version that comes with EDB Standard.

2) Can the user who is locked out, log in ok a few minutes later or after someone else has logged out?

3) Can the user who is locked out, log in using EDBMgr using the same user name and password?

4) Are you sure all users are connected using C/S and no one is using local access to the database?

5) If someone has the catalog locked, then (I think) the following commands should also fail:

select * from configuration.serversessions;
select * from configuration.serversessionlocks;

6) You have only one catalog for the database, right?

7) http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Starting_Configuring_Server

"It is very important that you do not have more than one instance of the ElevateDB Server using different configuration files and accessing the same database(s). Doing so will cause locking errors. All instances of the ElevateDB Server must use the same configuration file if they will be accessing the same database(s)."

Barry
Sat, May 24 2014 10:43 PMPermanent Link

Mario Enríquez

Open Consult

Barry,

Thank you very much for your help...

My comments below...


>>1) I'm assuming you have the full EDB C/S version and not using the limited user C/S version that comes with >>EDB Standard.

Yep, Ful EDB C/S version.


>>2) Can the user who is locked out, log in ok a few minutes later or after someone else has logged out?
Yes, after a while the locked out user is able to logon, but the amount of time elapsed is uncertain.

The "fix" we've found is to log out every user from the server, and everything is back to normal, until next day...

>>3) Can the user who is locked out, log in using EDBMgr using the same user name and password?

Haven't tried that yet.

>>4) Are you sure all users are connected using C/S and no one is using local access to the database?
No, not completely sure about but I going the check it out. Thanks for the heads up!

>>5) If someone has the catalog locked, then (I think) the following commands should also fail:
>>select * from configuration.serversessions;
>>select * from configuration.serversessionlocks;
Haven't tried to issue those commands, would have it present next time I'm diagnosing

>>6) You have only one catalog for the database, right?
Not sure I get you there, it is my understanding that the server will have one, and only one, catalog for each database. It is possible to have more than one catalog for a database, and how is the useful?

>>7) http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Starting_Configuring_Server
>>"It is very important that you do not have more than one instance of the ElevateDB Server using different >>configuration files and accessing the same database(s). Doing so will cause locking errors. All instances of the >>ElevateDB Server must use the same configuration file if they will be accessing the same database(s)."

I believe this is related to No.5, and there is a possibility this might be the problem. I'll check it out asap... Wink


Barry, thank you very much again.

Regards,
Mario
Sun, May 25 2014 2:57 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Mario


You say its usually the same user, if that means the same workstation I'd be suspicious of the physical network.

Roy Lambert
Sun, May 25 2014 1:48 PMPermanent Link

Barry

Mario

>>4) Are you sure all users are connected using C/S and no one is using local access to the database?
>No, not completely sure about but I going the check it out. Thanks for the heads up!

Have each user log in and they should show up in the list generated by executing (in EDBMgr from any machine):
select * from configuration.serversessions;

If the user logs in and does NOT show up in the server sessions, then he is connected locally. There may be a better way to determine if the user is locally connected, but I can't think of any off hand (unless you built it into your application by displaying a message or adding a record to a table when they connect).


>>6) You have only one catalog for the database, right?
>Not sure I get you there, it is my understanding that the server will have one, and only one, catalog for each >database. It is possible to have more than one catalog for a database, and how is the useful?

Actually it is not useful. It could be an old catalog you had lying around before you moved the database to a different location. If a client is somehow accessing this old catalog (locally? or with a different server) that is pointing to the same set of data files, you are in for a world of hurt. Smile

Just to be on the safe side I would do an index search for "EDBDatabase.EDBCat" just to be sure.

>>Barry, thank you very much again.

No problem. Let us know if you find a solution. It will no doubt help someone else down the road.

Barry
Image