I'm getting a little confused about the 2 different ConfigPath
properties in both the Engine and Session components and therefore
would like to understand better the purpose and significance of both
when living together...and separately.

   Engine Component = ConfigPath
   Session Component = LocalConfigPath

   Optional ConfigPath-related propery:
      Engine Component = UseLocalSessionEngineSettings


1a) Of the dialog I've read on here, I'm gathering that if I have both
Engine and Session components in a DataModule that I should disregard
the "ConfigPath" Property in the Engine (leave it blank) and set
"UseLocalSessionEngineSettings" to TRUE...and proceed to set the
"LocalConfigPath" Property in the Session Component.

1b) If YES....then why is it better to set the Session properties and
not just the Engine properties?


2) Contrary to 1)...then at what point would I want to ONLY use the
"ConfigPath" property in the Engine Component and not in the Session
Component? (assuming both are in a DataModule)


3a) If both components are in a DataModule...and I only set the Engine
"ConfigPath", does this override what the Session component is set
to....or do I still need to set the Session "LocalConfigPath" property?

3b) Should I avoid this and use the Session component for the path to
the configuration files everytime instead?


There's obviously a few ways to set things up here and I'm sure it's
because of the flexibility to either have JUST an Engine Component in a
DataModule...or just a Session Component - that in either case it's
necessary to set the ConfigPath for each hence why both have the same
property.  BUT! I would just like to understand better the signifance
of setting one or the other in the different situations since this is
basically the most important part of getting a database connected.

Thanks!
Fred

Fred


To me the basic idea (which I haven't tried) is that if UseLocalSessionEngineSettings is true then you can have multiple sessions pointing at their own config files. If its false you're restricted to one and one only config file. So with UseLocalSessionEngineSettings True you could have a remote and a local connection running simultaneously. Without it its all local or all remote.

If, say, you don't have a session component on the form (you could use the default) then with UseLocalSessionEngineSettings set to false you only need to set the info in the engine, and you don't need an engine component on the form. If you don't one will be created for you at run time, but it will make things VERY difficult to hook everything up in the IDE and (eg) have a grid populated in the IDE

>1a) Of the dialog I've read on here, I'm gathering that if I have both
>Engine and Session components in a DataModule that I should disregard
>the "ConfigPath" Property in the Engine (leave it blank) and set
>"UseLocalSessionEngineSettings" to TRUE...and proceed to set the
>"LocalConfigPath" Property in the Session Component.

Its certainly my preferred option, but if you think of the CDCollector Tim's doing it the other way. If there's only one config file and one session type then who cares - either will work.

>1b) If YES....then why is it better to set the Session properties and
>not just the Engine properties?

Dunno.

>2) Contrary to 1)...then at what point would I want to ONLY use the
>"ConfigPath" property in the Engine Component and not in the Session
>Component? (assuming both are in a DataModule)

Still no idea

>3a) If both components are in a DataModule...and I only set the Engine
>"ConfigPath", does this override what the Session component is set
>to....or do I still need to set the Session "LocalConfigPath" property?

Depends on the value of UseLocalSessionEngineSettings if False then your statement is correct

>3b) Should I avoid this and use the Session component for the path to
>the configuration files everytime instead?

I prefer that but who knows.

Roy Lambert [Team Elevate]

Fred,

<< I'm getting a little confused about the 2 different ConfigPath properties
in both the Engine and Session components and therefore would like to
understand better the purpose and significance of both when living
together...and separately. >>

It's very simple.   You should only use UseLocalSessionEngineSettings=True
in cases where you need to have multiple sessions in the same application
accessing different configuration files, ala the EDB Manager.  If you don't
have that requirement, then just use the TEDBEngine to configure the
ConfigPath, etc. and leave it at that.

--
Tim Young
Elevate Software
www.elevatesoft.com

> To me the basic idea (which I haven't tried) is that if
> UseLocalSessionEngineSettings is true then you can have multiple
> sessions pointing at their own config files. If its false you're
> restricted to one and one only config file. So with
> UseLocalSessionEngineSettings True you could have a remote and a
> local connection running simultaneously. Without it its all local or
> all remote.

ok cool. Tim said basically the same thing.  Got it.

> If, say, you don't have a session component on the form (you could
> use the default) then with UseLocalSessionEngineSettings set to false
> you only need to set the info in the engine, and you don't need an
> engine component on the form. If you don't one will be created for
> you at run time, but it will make things VERY difficult to hook
> everything up in the IDE and (eg) have a grid populated in the IDE

If I'm understanding you correctly then, Roy...if I just set the Engine
Component and don't even include a Session Component (and accept all of
the defaults of the "Default Session")...then theoretically I can just
use the "Default" Session to hook up other components.

I'm basically thinking of a local app where there's nothing complicated
going on (like a multi-Session) and just accept the defaults of the
"Default Session" with no other settings customized (ie changing type
to remote).

I'm assuming in this situation as well that the default username and
password will automatically work.

Anyway....I'll give it a quick try in a short bit, but like you
said...I'll probably always thrown in a Session component for good
measure, but it's nice to know the options and how it works with or
without.

Other stuff you mentioned - Tim clarified as well.

Anyway, Roy....thanks to yours, Tim's and others help....I'm finally
coming around and understanding EDB's way of doing things and
understand alot more than I did a couple of days ago!  I did manage to
convert one of my simple DBISAM apps and run it on my other laptop (and
using the ALTER DATABASE statement)...so I'm getting there...slowly,
but surely.

Tim - wonderful...thanks for the explanation...that is indeed simple to
understand.

I mentioned one other thing in my reply to Roy...about the Default
Session and whether or not it's really necessary to drop on a form if
accepting all the defaults and no need for multi-session.

Thanks again!

--



Tim Young [Elevate Software] wrote:

> Fred,
>
> << I'm getting a little confused about the 2 different ConfigPath
> properties in both the Engine and Session components and therefore
> would like to understand better the purpose and significance of both
> when living together...and separately. >>
>
> It's very simple.   You should only use
> UseLocalSessionEngineSettings=True in cases where you need to have
> multiple sessions in the same application accessing different
> configuration files, ala the EDB Manager.  If you don't have that
> requirement, then just use the TEDBEngine to configure the
> ConfigPath, etc. and leave it at that.

Fred


>If I'm understanding you correctly then, Roy...if I just set the Engine
>Component and don't even include a Session Component (and accept all of
>the defaults of the "Default Session")...then theoretically I can just
>use the "Default" Session to hook up other components.

I think so but I've never tried it

>Anyway, Roy....thanks to yours, Tim's and others help....I'm finally
>coming around and understanding EDB's way of doing things and
>understand alot more than I did a couple of days ago! I did manage to
>convert one of my simple DBISAM apps and run it on my other laptop (and
>using the ALTER DATABASE statement)...so I'm getting there...slowly,
>but surely.

Brilliant

Roy Lambert [Team Elevate]

Fred,

<< I mentioned one other thing in my reply to Roy...about the Default
Session and whether or not it's really necessary to drop on a form if
accepting all the defaults and no need for multi-session. >>

Well, the only issue is the LoginUser and LoginPassword properties, which
are blank by default.   As long as you set them in the BeforeConnect event
handler for the default session, then you'll be all set.  However, if you
leave them blank, then you'll get a password dialog prompt when you try to
connect the session.

--
Tim Young
Elevate Software
www.elevatesoft.com

Yeah...shortly after I posted that message, Tim, I went ahead and tried
the default Session to see what would happen and quickly figured out I
needed to put the LoginUser and Password in code since that dialog box
started popping up.  So yep...works just as you said.

Cheers!

--



Tim Young [Elevate Software] wrote:

> Fred,
>
> << I mentioned one other thing in my reply to Roy...about the Default
> Session and whether or not it's really necessary to drop on a form if
> accepting all the defaults and no need for multi-session. >>
>
> Well, the only issue is the LoginUser and LoginPassword properties,
> which are blank by default.   As long as you set them in the
> BeforeConnect event handler for the default session, then you'll be
> all set.  However, if you leave them blank, then you'll get a
> password dialog prompt when you try to connect the session.