Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 8 of 8 total |
config path confusion |
Thu, Mar 12 2009 10:33 AM | Permanent Link |
"Fred H." | 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 |
Thu, Mar 12 2009 11:07 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Thu, Mar 12 2009 12:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Thu, Mar 12 2009 1:07 PM | Permanent Link |
"Fred H." | > 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. |
Thu, Mar 12 2009 1:14 PM | Permanent Link |
"Fred H." | 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. |
Thu, Mar 12 2009 2:00 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Thu, Mar 12 2009 6:46 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Mar 13 2009 12:11 AM | Permanent Link |
"Fred H." | 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. |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |