Persistable DLL?

[jsteph]

Hi all,
I would like to make a dll that makes an odbc connection. I want this same connection to be used by several stand-alone vb executables on the same machine, so each executable I want to have use not only the activeX dll, but the same process as whichever the first executable that ran was using.

IE, when the first exe runs, it opens a connection. Say an hour later ( the connection timeout allows this), another exe is started (while the first may or may not be still running)--now this second one I don't want another database connection, I want to share the same connection--I'm aware of the issues with transactions, etc, and I can deal with that. I just want to know if this is possible. Is it? Thanks...
steph

 

[alfredp77]

That's possible.

Ok, first of all, you cannot achieve such thing using an activeX DLL, because DLL will run in-process, that is, in the same process space as the EXE that invokes it. So it is impossible to access variables/objects in the same DLL that is invoked by another EXE.

You can do it using ActiveX EXE.

The general idea is to create a global connection object in a standard module in an ActiveX EXE, and create a class that will be instantiated by EXE clients. That class will return a reference to the connection object.

I have a sample code that does precisely what you want to achieve, if you like to see the program, I would be glad to mail it to you (it's only a simple code, but it would be too long to paste it here since I will also have to explain a few things about it)

You can also check the CoffeeMonitor sample project in MSDN. The principle is the same.

 

[strongm]

techniques for doing this sort of thing have been discussed in this forum a number of times in this forum. Code illustrating the idea has also been posted. Here's one of my earliest on the subject: thread222-117529

 

[jsteph]

Alfred,
Thank you very much. I looked at the coffeemonitor, and got a basic mockup ready to test. Yet when I try to open a recordset from one of the executables that reference my activeX.exe, I get the ado error 3001 - 'Argurments are of the wrong type...'

The ActiveX.exe is called BagConn, the Class it provides is called clsConn, and there is a Public Get called 'GlobalConn' that returns the Global ado connection object (which was opened via a modal form that that BagConn calls when my 'OpenBagConnection' method of clsConn is invoked. In the other executable, I have an adodb.connection variable which I set:

dim bc as BagConn.clsConn,rs as ADODB.Recordset
dim newConn as ADODB.Connection
set bc = New BagConn.clsConn
bc.OpenBagConnection 'modal form gets user/pwd, this works fine
Set newConn = bc.GlobalConn
if bc.IsConnected then ' "IsConnected" checks state
rs.Open "Select * from bags",newConn 'I get error here
else
msgbox "no connection" 'I do not see this (good thing)
end if

This code works fine if I replace the newConn with a connection object I set and open locally, but bc.GlobalConn seems to be a problem.

If you could email me a sample, that would be great. I can be reached (for the next week or so, anyway) at
cherihorton@wideopenwest.com

Thanks for all your help,
--steph

 

[alfredp77]

I've mail you the code. Hope it helps

 

[jsteph]

Alfred,
Thanks very much for that--I changed the connection string and ran it, and worked--thanks again.

I'm thinking that the reason for my error is that the connection object I'm returning is somehow just returning the connection string, but in a connection object(?), which must be the default property of a connection object, but the data type of the connection variable is still adodb.connection--so if I did:
rs.Open "select ..." ,Cstr(newConn)
This 'worked', in that it opened the recordset, but of course it was a separate connection because the .Open creates a new connection if just given a string instead of connection object. Wrapping the newConn in Cstr() got the string out of it, but not the actual connection. So I'll go with your method. Thanks again,
--steph