>Terry,
>If ADODC has it why not use it. In the thread I mentioned it was reported to fail on other site but I have many working samples using it (I never tried it with COM though).

>I think the key is your signature :)
>Cetin
Cetin,
Here is what I learned last night.
First, the ADODC seems to only allow implementation (as COM) inside a FORM object. My goal was to build a DLL. When I built a DLL with ADODC, the build would complete without error. However, CREATEOBJECT forwarded an x80004005 error. Building an EXE with ADODC allowed instanciation and the processes worked okay (but it was an EXE).

So I researched ADODB (looking at stuff on this board (and your submissins too - thanks) - and looked at MSDN). So I struggled with ADODB. It works great, plus the backend errors can be trapped using COMRETURNERROR. The CRE is nice, because it does not turn off the COM connection. Instead, it does a CALL BACK to a client side ON ERROR. CRE will intercept connection string errors, bad sql errors as well as mis-named stored procedure error, and still remain online. From what I've read - the big issue with server side coms is error management, and the affect these errors might have with client to COM connections, or COM to backend connections. I am also sure that this implementation will serve a vatiety of clients and backends. I have a little more to do on finishing the demo.

On ADODB Errors: I added an ERROR procedure the the custom class that contains the ADODB. In that method I have a COMRETURNERROR. I was chasing error traps from within the ADODB objects (Connection,Record,Command, Errror) to no avail. The Custom container error method trapped and wrapped COMRETURNERROR().

More to come ...