DLL with TADOConnection passed in

is the TADOConnection allready open ?
or are you passing the connectionstring ?

is it the same query that will be run on different databases ?
or will you pass the SQL too ?

will you be using the TADOConnection in the threads too besides the dll ?

few comments before I create some code.
note that each ADOConnection is treated as separate looged on user, so in your case each thread will represent different user logged on server - make sure everything is in tact with CALs and your licensing model on MSSQL.
I've used single ADOCOnnection with multiple threads and it works nice and smooth.

you want this DLL to use TADOConnection or maybe native ADO interface so it can be used with applications written in other languages?

ziolko.

The application threads each create a TADOConnection, open it, and use it before _and_ after the call to the DLL, for their own routines.

Their connection strings differ slightly, but only to distinguish their ID.
They are all talking to the same server and database in this case.
The application threadcount can be configured to match the licensing requirements
ATM it will be a maximum of 3 threads at 1 time.

My first thought was to use TADOConnection, but I can foresee a possibility (in 2 years) where it would be handy to have a C# .net service also call this DLL.

How much extra work is invoved in catering for a "native ADO interface"
sorry I am not familiar with that expression :-)

If it is tricky, then I will just stick with what I have (TADOConnection) and in 2 years time, will likely change it to allow a connection string to be passed in and a TADOConenction created in the DLL - Don't worry about this aspect atm at all, talking 2 years away :-)

The actual code that the DLL will run will be contained within the DL (in reality, it is a call to several stored procedures, but the delphi function will end up just returning 1 integer value (or an error string somehow)

ok, I'll try to make it using only ADO interface we'll see how much trouble yhat will be:)
calling this DLL from C#... mixing managed and non-mamaged code I'm not fan of that solution, but that's future:)

ziolko.

Fantastic!
integrates with my app sweet.

The 1 drawback I see using the interface and
   ADOInt._Connection(ConnectionEndPoint).Execute()
is that where I would normally use DB parameters   ( 'select * from mytable where field = :searchfield' )
I will now have to do it manually.
Not a big deal considering the actual queries/stored procs my app will be using

For anyone else interested in generating the DLL, type library and interface from scratch, you need to do the following
File -> New -> Other -> ActiveX -> ActiveX Library
File -> New -> Other -> ActiveX -> Automation Object
Finally, setup the names in the type library screen, and add a Method

you can do this on DLL side:

  ADOConn := TADOConnection.Create(nil);
  try
    ADOConn.ConnectionObject := ADOInt._Connection(ConnectionEndPoint);
    ...
  finally
    ADOConn.Free;
  end;


and further on use TADOConnection instead interface:)
then you can hook-up ADOQuery to this connection or stored procedure:)

ziolko.

you may bring it one step further with a connection pool in the DLL

Thanks ziolko, that makes migrating from my existing code a lot easier

glad I could help:)

ziolko.