Hi Mark!

Yes, it does seem to work ok. The majority of the functionality I need from SDT is contained in an external EXE anyway, so I don't really need to worry too much about ADO (although I've found that you need to worry about it a lot more that you should!).

Thanks for the insight.

>
>I do not see why not as long as you are compiling into the DLL only those SDT components that are licensed for distribution. The DLL would not be using ADO to access the data. It would open the DBC and tables natively. Now here's the quagmire. Before doing anything that requires exclusive use, you have to have some means of closing all the tables opened by your ADO connection. You also have the issue of the SDT UI which may be undesirable when performing some of the functions.
>
>Since SDT has to have direct access to the DBC and tables, I would store the path and DBC name in an external text file or in the registry. Then have your DLL retrieve this information.
>
>All of this should be fairly easy to test.