Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 17 total
Thread AutoSessionName, ver 3.3
Fri, Sep 4 2009 5:02 AMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 AMPermanent 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 Wink
HTH also
Rita

Page 1 of 2Next Page »
Jump to Page:  1 2
Image