Board index » delphi » About ADO Connections and DLLs

About ADO Connections and DLLs


2006-01-19 12:06:26 AM
delphi248
This is an interesant question :)
I have Delphi 2006. I am programming "extensions" to a main application that
is made by another corporation in VB.
And I made it fine. Works beautiful.
The extensions are all DLL. The main server: Microsoft SQL 2000 Server.
It's fine. All works fine.
Every extension is a DLL. Every DLL has a lot of units. And ONE Data
Module -i love this-.
But I am very worried about the following.
All DLL's have lot of procedures inside, and sometimes one calls each other.
Every procedure create one instance of the Data Module and the DataModule
creates a SQL connection.
So, every connection consumes one license on the SQL server.
My question:
I would like to create one DLL for the connection with the server and I want
that all my DLLs uses that "dll connector" to work. is this possible? how?
If the ADO Connection component is inside this "DLL connector" , How can
the-others-DLL access to this ADO Connection?
Regards,
Pablo Romero
www.pabloromero.com.ar
 
 

Re:About ADO Connections and DLLs

I dont know is it possible or not.
Im writing an application like that but Im coding it 3 tier.
My application server connects to SQL Server and stay connected.
Im using kbmMW components to do this.
Its very easy to convert normal application to kbmMW.
By the way there is no need to install SQL Server clients to client machine.
take a look at : www.components4developers.com/
gurcan
"Pablo Romero" <XXXX@XXXXX.COM>writes
Quote
This is an interesant question :)

I have Delphi 2006. I am programming "extensions" to a main application
that
is made by another corporation in VB.
And I made it fine. Works beautiful.

The extensions are all DLL. The main server: Microsoft SQL 2000 Server.
It's fine. All works fine.

Every extension is a DLL. Every DLL has a lot of units. And ONE Data
Module -i love this-.

But I am very worried about the following.

All DLL's have lot of procedures inside, and sometimes one calls each
other.

Every procedure create one instance of the Data Module and the DataModule
creates a SQL connection.

So, every connection consumes one license on the SQL server.

My question:

I would like to create one DLL for the connection with the server and I
want
that all my DLLs uses that "dll connector" to work. is this possible? how?
If the ADO Connection component is inside this "DLL connector" , How can
the-others-DLL access to this ADO Connection?

Regards,

Pablo Romero
www.pabloromero.com.ar


 

Re:About ADO Connections and DLLs

Pablo Romero writes:
Quote
If the ADO Connection component is inside this "DLL connector" , How can
the-others-DLL access to this ADO Connection?
Easy. ADO uses COM interfaces, and these can be shared between COM
libraries of the same application.
tAdoconnection has a property "connectionobject" that you can read and
write,
you can pass this along between your DLL's as long as they're all COM Dll's.
myadoconnection.Connectionobject := Anotherdll.ConnectionObject;
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
 

Re:About ADO Connections and DLLs

Oh, very interesting...
1) So, If I have one ADO Connection inside a "master" DLL, The "dependents"
DLL can use it?
2) Inside my main DLL, I have an ADOConnection object. How this DLL exports
this ADOConnection object?
3) You say "anotherDLL.ConnectionObject". The "another" part how is declared
referenced in a dependent DLL?
You are giving me lights....
Regard
Pablo
"Arthur Hoornweg" <XXXX@XXXXX.COM>writes
Quote
Pablo Romero writes:

>If the ADO Connection component is inside this "DLL connector" , How
can
>the-others-DLL access to this ADO Connection?

Easy. ADO uses COM interfaces, and these can be shared between COM
libraries of the same application.

tAdoconnection has a property "connectionobject" that you can read and
write,
you can pass this along between your DLL's as long as they're all COM
Dll's.

myadoconnection.Connectionobject := Anotherdll.ConnectionObject;





--
Arthur Hoornweg

(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)