Why do I always get the Elevate DB Error #300 Cannot lock database X
for shared access, whenever I try to have a database open in EDB
Manager and run my program that uses that database? The help file says
to look at the section on Locking but there doesn't appear to be one.

Michael


I get the same (I now make sure I shut the one I'm not about to use). I think its to do with locking the configuration file. If you only have one configuration file (in case something - structure or lastautoinc - is changed) for the whole system you'll be OK but if you have different configuration files you'll have a problem.

I've moaned to Tim about it but I think he's got more pressing "opportunities" on his plate

Roy Lambert

On Fri, 22 Jun 2007 17:11:09 +0100, Roy Lambert
<roy.lambert@skynet.co.uk> wrote:

>Michael
>
>
>I get the same (I now make sure I shut the one I'm not about to use). I think its to do with locking the configuration file. If you only have one configuration file (in case something - structure or lastautoinc - is changed) for the whole system you'll be OK but if you have different configuration files you'll have a problem.

Right Roy, of course. I keep thinking EDB to work like DBISAM. The
solution for me is to put a copy of EDB Mgr in every data folder and
use that instead of just one copy as you could do with DBISAM.

>I've moaned to Tim about it but I think he's got more pressing "opportunities" on his plate

I think the problem is EDB was made to act like big DB server but it
isn't (or at least a lot of us don't want to use it that way). Big DB
servers have all the files in one location and manage them for you so
this sort of thing isn't a problem. The great thing about DBISAM was
the flexibility in this regard. I am willing to put up with this major
PITA for the performance improvement over DBISAM though.

Michael


In some respects the solution is simpler than that. Every time you open EDBMan click "Edit Options" before you open any tables and change the config path to the one where your data lives.

I'm pestering Tim to do a "backwards" move to sort of like DBISAM where you're asked for the path when you open EDBNam, or at least its more clearly visible.

Roy Lambert

Michael,

<< Why do I always get the Elevate DB Error #300 Cannot lock database X for
shared access, whenever I try to have a database open in EDB Manager and run
my program that uses that database? The help file says to look at the
section on Locking but there doesn't appear to be one. >>

You need to use one configuration file unless it is absolutely necessary to
do otherwise.  The recommendation is for one configuration file per
application or organization (if in-house application).  Then, make sure that
the EDB Manager and your application both use the same configuration file
via the configuration path.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< Right Roy, of course. I keep thinking EDB to work like DBISAM. The
solution for me is to put a copy of EDB Mgr in every data folder and use
that instead of just one copy as you could do with DBISAM. >>

That is a very bad idea and I would strongly suggest that you don't do such
a thing.  You seem to be equating the configuration file with each database,
and that is definitely not the way EDB is designed.

<< I think the problem is EDB was made to act like big DB server but it
isn't (or at least a lot of us don't want to use it that way). Big DB
servers have all the files in one location and manage them for you so this
sort of thing isn't a problem. The great thing about DBISAM was the
flexibility in this regard. I am willing to put up with this major PITA for
the performance improvement over DBISAM though. >>

C'mon now.  We're talking about making sure that *one* engine setting
(ConfigPath) is correct for all applications and utilities being used.  I
would hardly consider that a major departure from DBISAM considering what
that one configuration setting buys you that DBISAM doesn't have.  I suggest
that you look at the configuration requirements of "big DB servers" and see
if they are configured with one setting or not.  I think you'll have a hard
time finding a single one that even comes close.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,

> C'mon now.  We're talking about making sure that *one* engine setting
> (ConfigPath) is correct for all applications and utilities being used.  I
> would hardly consider that a major departure from DBISAM considering what
> that one configuration setting buys you that DBISAM doesn't have.  I suggest
> that you look at the configuration requirements of "big DB servers" and see
> if they are configured with one setting or not.  I think you'll have a hard
> time finding a single one that even comes close.

And don't forget! It's easier to backup one folder rather many


--
Charalabos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< And don't forget! It's easier to backup one folder rather many >>

Yes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>That is a very bad idea and I would strongly suggest that you don't do such
>a thing. You seem to be equating the configuration file with each database,
>and that is definitely not the way EDB is designed.

I know this isn't the way EDB is designed but it is the way a lot of us are used to working. The whole configuration/catalog thing is a major change to us erstwhile DBISAM users so keep expecting this sort of thing (unless you go off your rocker and make it impossible).

Roy Lambert

Roy,

<< I know this isn't the way EDB is designed but it is the way a lot of us
are used to working. The whole configuration/catalog thing is a major change
to us erstwhile DBISAM users so keep expecting this sort of thing (unless
you go off your rocker and make it impossible). >>

I understand, but copying the EDB Manager into every database directory ?
Plus, keep in mind that the configuration setup works exactly the same as
DBISAM C/S did, so for many customers there is absolutely zero changes at
all.

--
Tim Young
Elevate Software
www.elevatesoft.com