Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 17 total |
AutoSessionName, ver 3.3 |
Fri, Sep 4 2009 5:02 AM | Permanent Link |
Peter | Hello
I am confused about whether the AutoSessionName should remain at the default False, or be set to True. The application using 3.3 is used in a LAN, with typically no more than 3 or 4 concurrent users. What are the ramifications of leaving it at False, when the Help file seems to suggest that the opposite is appropriate? Regards & TIA Peter |
Fri, Sep 4 2009 7:16 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Peter
Autosessionname is basically a helper guaranteeing that your session has a unique name per process. As long as you provide a unique name yourself it can be set to false. Whichever way you do it the important thing to remember is to make sure your tables and queries reference the correct session. Roy Lambert [Team Elevate] |
Fri, Sep 4 2009 10:30 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Autosessionname is basically a helper guaranteeing that your session has a unique name per process. >> Actually, it's per session, and more accurately, per thread. AutoSessionName is normally used with multiple threads to ensure that each session has a unique name per thread. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Sep 4 2009 4:31 PM | Permanent Link |
Peter | Thank you - are there examples of using threads for tables and\or queries? I have seen a few references to the fact that threads should be used, but can't
find an example of their use. Back to the AutoSessionName, when the setting is true in my Data Module all the datasets on the Data Module pick up the newly assigned SessionName in the IDE. The datasets on other forms do not automatically pick up the new SessionName, and refuse to open the dataset when the app is running. Do I have to manually set (in the IDE) the dataset's SessionName to the new value that is being used in the Data Module? Regards & TIA Peter |
Fri, Sep 4 2009 7:29 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Peter,
<< Thank you - are there examples of using threads for tables and\or queries? I have seen a few references to the fact that threads should be used, but can't find an example of their use. >> See here: http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=d&version=7&category=2&topic=8 There's no difference between using a query or table in a thread vs. using it elsewhere. In fact, in an application without any explicit threads, you're still using a single main thread for all of the work being done in the process. << Back to the AutoSessionName, when the setting is true in my Data Module all the datasets on the Data Module pick up the newly assigned SessionName in the IDE. The datasets on other forms do not automatically pick up the new SessionName, and refuse to open the dataset when the app is running. Do I have to manually set (in the IDE) the dataset's SessionName to the new value that is being used in the Data Module? >> Yes. AutoSessionName only updates datasets that are present on the same owner container as the TDBISAMSession component. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Sep 5 2009 7:36 AM | Permanent Link |
Peter | Tim
The code I use for most queries is quite similar to example you provided, except in some of the older parts of the app, which was a port from Paradox. In those areas it isn't unusual for me to have used a TDBISAMTable with such simplistic methods as Edit and Post, with no trace of a thread or variation in the SessionName. I am not sure how I could open a TDBISAMTable and edit it in a thread, but I gather that you are saying that I should replace all those archaic methods with the type set out in the example. Is that the case? Regards & TIA Peter |
Sat, Sep 5 2009 10:11 AM | Permanent Link |
"Rita" | "Peter" <peter@petercrain.com> wrote in message news:ECB331A3-5F9D-4A8F-988E-ECC51E7C5948@news.elevatesoft.com... > Tim > > The code I use for most queries is quite similar to example you provided, > except in some of the older parts of the app, which was a port from > Paradox. In > those areas it isn't unusual for me to have used a TDBISAMTable with such > simplistic methods as Edit and Post, with no trace of a thread or > variation in the > SessionName. > > I am not sure how I could open a TDBISAMTable and edit it in a thread, but > I gather that you are saying that I should replace all those archaic > methods > with the type set out in the example. > > Is that the case? > > Regards & TIA > > Peter > Well yes it is best in a multi-thread app. 1st tho. When you create a database component, it is automatically associated with the default session. You need only associate a database component with an explicitly named session if the component performs a simultaneous query against a database already opened by the default session. When creating a multi-threaded database application, you must create one additional session to handle each additional thread. So in Tims example UPDATEACCOUNTS thats very much how you do it now. So every procedure in your app that makes a move on a table or query no difference there. Tim could have called that session UpdateTheAccountsSession thats how I go about it only in my Data Module I list the meaningful names like above in a list and give them names like 'UtAs' . I treat Sessions in a similair way as the Flock() in xBase type apps before Delphi came along. Its probaly wrong but every move on a table keeps me focused on keeping it bullet proof as if its ommited the app will still compile and run, then oneday Peter + Roy + Tim + Rita will all update the accounts at the same time. Love them or hate them whatever database you use in Delphi these days you need them unless its just a desktop app thats not multiuser, then it still uses the default session without any problems. Good luck in all that rewriting u have ahead. Rita |
Sat, Sep 5 2009 11:10 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Peter,
<< I am not sure how I could open a TDBISAMTable and edit it in a thread, but I gather that you are saying that I should replace all those archaic methods with the type set out in the example. >> No, I'm not saying anything specifically about your application. My response simply indicated how a threaded method for updating the database would look. Let's take a step back a second. Why are you interested in using threads ? We usually recommend that you only delve into using threads when there is a compelling reason to do so. Otherwise you can end up introducing some nasty bugs in your application, especially if you're not entirely sure of how to deal with mutual exclusion and resource protection among multiple threads. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Sep 5 2009 7:54 PM | Permanent Link |
Peter | Tim
<<Let's take a step back a second. Why are you interested in using threads ? >> There are very few situations in my app that could benefit from separate threads as it uses modal dialogs almost everywhere. However I can see one or two spots that might benefit from being able to pass the process off to a thread while allowing the user to get on with another, hence the interest. Rita - thanks for your help too, I've taken it all on board. Regards Peter |
Mon, Sep 7 2009 9:44 AM | Permanent Link |
"Rita" | "Peter" <peter@petercrain.com> wrote in message news:7825C04C-3FBC-4009-889B-E3378C43B4E8@news.elevatesoft.com... > > Rita - thanks for your help too, I've taken it all on board. > > No problem just one thing ommited from Tims example. If someone else has or is updating the table then you will need to refresh the table such as dmPeter.tblPeter.refresh; Sessions u need eyes in your bum with them HTH also Rita |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, March 28, 2024 at 06:18 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |