Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Wim

<<I'm still baffled about which pc's access which tables.<<



There is one set of tables on the server, all pc's acces those tables

Wim


>There is one set of tables on the server, all pc's acces those tables

In that case the answer is simple ONE configuration file in a shared directory. If you have a common directory where all PC's load the .exe from I'd stuff it there otherwise I'd dump it in with the data.

Roy Lambert

>>Roy Lambert <roy.lambert@skynet.co.uk> wrote:

In that case the answer is simple ONE configuration file in a shared directory. If you have a common directory where all PC's load the .exe from I'd stuff
it there otherwise I'd dump it in with the data.

Roy Lambert >>

Thanks Roy and Tim, that is what I expected.
It sure takes getting used to coming from dbisam 3.30
I hope it is all worth it, as it seems to me EDB is ment for client server in the first place.
Well,  for new applications, I might just as wel change to that.

Wim

>>Roy Lambert <roy.lambert@skynet.co.uk> wrote:

In that case the answer is simple ONE configuration file in a shared directory. If you have a common directory where all PC's load the .exe from I'd stuff
it there otherwise I'd dump it in with the data.

Roy Lambert >>


Ok, one more question though.
What if I am a bad boy and I use multiple configuration files for shared databases.
What am I risking then? Corruption? Malfunction?
I am asking this because for a few applications I am not interested in the features that the configuration database provides.

Wim

Wim



>Ok, one more question though.
>What if I am a bad boy and I use multiple configuration files for shared databases.
>What am I risking then? Corruption? Malfunction?
>I am asking this because for a few applications I am not interested in the features that the configuration database provides.

You'll only be able to open the tables from one app at a time (at least with 1.02). One of my complaints is that if I have an app with a separate configuration file and want to look at the tables in EDBMan I can't without altering the configuration path.

Roy Lambert .

Tim Young [Elevate Software] wrote:
>
> On the server drive, preferrably in a shared folder that *isn't* the
> database folder.

Out of curiosity, why do you recommend that the configuration file not
be in the database folder?  What are the disadvantages of having the
configuration file in the data folder?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Wim,

<< What if I am a bad boy and I use multiple configuration files for shared
databases.
What am I risking then? Corruption? Malfunction? >>

You'll get locking errors and it won't work because the sessions won't see
each other.

<< I am asking this because for a few applications I am not interested in
the features that the configuration database provides. >>

ElevateDB uses it regardless of whether you think you're actually using it.
IOW, there's other stuff going on behind the scenes with respect to locking
and user security that you may not be immediately aware of.

--
Tim Young
Elevate Software
www.elevatesoft.com

Gordon,

<< Out of curiosity, why do you recommend that the configuration file not be
in the database folder?  What are the disadvantages of having the
configuration file in the data folder? >>

Because it's too easy in such a situation to just blow away the database
directory, thinking that you're just deleting the database stuff only, when
in reality you just blew away everything.  

--
Tim Young
Elevate Software
www.elevatesoft.com

"Gordon Turner" <gordon@mycroftcomputing.com> wrote in message
news:E9CB44A2-19DD-4FFC-AAB7-E830F86D4C36@news.elevatesoft.com...
> Tim Young [Elevate Software] wrote:
>>
>> On the server drive, preferrably in a shared folder that *isn't* the
>> database folder.
>
> Out of curiosity, why do you recommend that the configuration file not be
> in the database folder?  What are the disadvantages of having the
> configuration file in the data folder?
>
> --
> Gordon Turner
> Mycroft Computing
> http://www.mycroftcomputing.com

In our development environment we have several versions of the same database
(all from different clients) for testing purposes. With the CFG separate, it
is much easier to switch database (DROP, followed by CREATE DATABASE).

RoyJ

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:EED70B8C-30FC-46C7-BBC4-D0BF171B6717@news.elevatesoft.com...
> Gordon
>
>
> You have to use UNC paths. If they don't exist you're in serious trouble
>
>
> Roy Lambert

Or put the CFG inside the database folder on the network, and use '.' as
database path. Just kidding.