Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 18 of 18 total
Thread Create table at runtime
Tue, Jul 18 2017 3:17 PMPermanent Link

Matthew Jones

I will respond fully tomorrow at the office but read the link Tim posted on
thread use. And note that my m_ variables are object members. So only one
session is created per thread.
Tue, Jul 18 2017 7:53 PMPermanent Link

KimHJ

Comca Systems, Inc

Matthew Jones wrote:

>>I will respond fully tomorrow at the office but read the link Tim posted on
>>thread use. And note that my m_ variables are object members. So only one
>>session is created per thread.

I used your example and just removed the LocalConfigPath and it works.
Since you can only have one remote session it must automatic go to that session when you select stRemote.

  
function SendNotify.PrepareSession: TEDBSession;
begin
  Result := TEDBSession.Create(nil);
  Result.AutoSessionName := true;
  Result.SessionType := stRemote;
  Result.LoginUser := 'Administrator';
  Result.LoginPassword := 'EDBDefault';
  Result.Open;
end;


function SendNotify.PrepareDatabase(const ThreadSession: TEDBSession):TEDBDatabase;
begin
  Result := TEDBDatabase.Create(nil);
  Result.DataBase := SDatabase; (name of the database)
  Result.DatabaseName := 'ComcaNotify';
  Result.SessionName := ThreadSession.SessionName;
  Result.Connected := True;
end;


procedure SendNotify.PrepareConnection;
begin
  if not assigned(comcaThreadSession) then
  begin
     comcaThreadSession := PrepareSession;
  end;
  if not assigned(comcaThreadDatabase) then
  begin
     comcaThreadDatabase := PrepareDatabase(comcaThreadSession);
  end;
end;

Thanks again,
Kim
Wed, Jul 19 2017 3:45 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

KimHJ


You can have as many databases connected to a session and as many tables connected to a database in a thread as you want. You just have to make sure that the session, databases and tables are all isolated to the thread.

Just think of it as having a wall between all threads (including the main thread). Its a bit like having to synchronise between thread and UI. ElevateDB will take care of the necessary locking and synchronisation but only if it knows it needs to. The way to let it know it needs to is to create the session etc in the thread,

Roy Lambert
Wed, Jul 19 2017 3:55 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

KimHJ


>I used your example and just removed the LocalConfigPath and it works.
>Since you can only have one remote session it must automatic go to that session when you select stRemote.

No, totally wrong. You need to have a look at Tim's excellent documentation / examples.

The engine has a property - UseLocalSessionEngineSettings. If that is set to true then for each session the engine will use the "local" settings as defined in the session.

When you're using a c/s setup the local settings apply to the server not the client. By taking this line "Result.LocalConfigPath := g_xStartupConfig.DatabasePath;" out what you've essentially done is replace the path with the one Matthew was using to one that is relative to the server.

Roy
Wed, Jul 19 2017 5:23 AMPermanent Link

Matthew Jones

KimHJ wrote:

> I thought the SessionName always have to be the name of the Session you had created in ElevateDB Manager.

My understanding is that you are using threads. And the other thing you have fallen over is the same as I keep falling over - the ElevateDB Manager sessions have NOTHING to do with the ones in your application. Nothing!
So, the session in your application is all there is to connect to the database. If you create a Delphi app and pop an EDB database component on the form, and run it, there is a standard global EDB Session object that everything uses. It is sweet and easy. Come on in, the water is lovely! But hang on, you mentioned threads. Threads bring in the sharks, and so you have to be careful. Each thread needs to have its own session so that it doesn't interfere with any other access. And so you need to be able to link a thread's database accesses to the session for that thread, and that's done by name, and the easy way to make it all work is to have the AutoSessionName set to true. Then it makes sure that it is unique, and you can get on with your job. If you turn it on when it doesn't matter, it doesn't matter, so it is safe to assume it should be on.


> I see you then add a LocalConfigPath is this instead of the SessionName?

To be honest, I have no idea - my data is all local, and Roy's info is going to be better. The documentation will tell all.


> Since I connect Remote and not Local would I still be able to use AutoSessionName?

I think you would definitely need to - remembering that the session object is your applications link to the database, not to a session in EDB Manager.


> I have twenty different databases in my session and when a request is sent to the module it change to the database associated with the login.

Twenty databases, one session object per thread to connect to them.


> How will I be able to extract the localConfigPath for the session since I use a sessionname for connecting?
> I check my Session when the it connect and the LocalSessionPath is blank.

The documentation will tell you what is needed for local and remote connections. I keep finding Tim has thought of everything you might need, and reading the docs usually reveals the answers.

--

Matthew Jones
Wed, Jul 19 2017 11:17 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Kim,

<< Matthew I'm a little confused about the AutoSessionName.
I thought the SessionName always have to be the name of the Session you had created in ElevateDB Manager. >>

Session names in your application have nothing to do with the ElevateDB Manager.   They are using the same concept at run-time (the TEDBSession.SessionName property), but the persistence of the session names in the ElevateDB Manager is simply a feature of the manager application and not something that carries over to your application or the ElevateDB Server.  The persistence is a convenience feature so that you don't have to keep re-defining or re-entering the session information for various sessions that you wish to use.

The AutoSessionName property is a little confusing and is a hold-over from the BDE-compatibility days.  One of these days I'll probably axe the whole session name/database name stuff in favor of direct component references.  The performance of direct component references is way better with multi-threaded usage (no constant checks for duplicate session/database names that require critical sections, etc.).

Anyways.....the AutoSessionName property only works for hooking up other EDB components if the TEDBSession component is on a data module/form.  In other words, if you create a TEDBSession component with a nil owner, then you will need to manually assign the session name that is auto-assigned to the TEDBSession component to any other components that need to use the same session.  If, however, you were to put a TEDBSession component on a data module and set its AutoSessionName property to True, then any other EDB components on the same data module would automatically be assigned the same session name at run-time.

<< I see you then add a LocalConfigPath is this instead of the SessionName? >>

No, the Local* properties are used in cases where the TEDBEngine.UseLocalSessionEngineSettings property is set to True:

https://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelphiwin32&version=10T&comp=TEDBEngine&prop=UseLocalSessionEngineSettings

The UseLocalSessionEngineSettings is also a "rare" feature that is specifically used for situations like the ElevateDB Manager or the ElevateDB ODBC Driver/.NET Data Provider where multiple local sessions could be using completely different engine settings.

Unless you're using multiple sessions with different configuration path settings (or other engine settings) in your application, you should just use the TEDBEngine component for setting all of engine settings and all of your local sessions will use these same engine settings.

<< Since I connect Remote and not Local would I still be able to use AutoSessionName? >>

Yes.

<< I have twenty different databases in my session and when a request is sent to the module it change to the database associated with the login.

How will I be able to extract the localConfigPath for the session since I use a sessionname for connecting?
I check my Session when the it connect and the LocalSessionPath is blank. >>

If you're using remote sessions, then the Local* properties, as well as the engine properties in the TEDBEngine component, don't apply.  With remote sessions, the engine settings are all handled by the EDB Server and you have no control over them.

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Jul 19 2017 11:22 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Kim,

<< I used your example and just removed the LocalConfigPath and it works.
Since you can only have one remote session it must automatic go to that session when you select stRemote. >>

No, you can have as many sessions as you would like in an application, regardless of the session type. Remember, the ElevateDB Manager is a Delphi application, so anything you can do in it, you can do in your application.

BTW, your code looks fine and will work great.  Just remember to also manually assign the SessionName from the session/database component to any other EDB components that you're using, and you'll be all set for multi-threading (see my other post about when this occurs automatically and when you need to manually do it).

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Jul 26 2017 7:43 PMPermanent Link

KimHJ

Comca Systems, Inc

Tim Young [Elevate Software] wrote:

>>BTW, your code looks fine and will work great.  Just remember to also manually assign the SessionName from >>the session/database component to any other EDB components that you're using, and you'll be all set for multi->>threading (see my other post about when this occurs automatically and when you need to manually do it).

Thanks again to all.
This is a module so no EDB Components.
My head hurt after all those sessions Smile
Thanks, Kim
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image