OK, so the DLL has it's own private little agenda. My needs are to build a DLL that (well, I thought anyway) could have utilized connection and SQL objects to properly return a cursor regardless of the backend. Now that I can't get a cursor from there, it appears that the only real use for the DLL would be as a SQL parser to simply create and then pass back a proper SQL string for the host to run. This doesn't exactly seem advantageous. So for the folks here at the UT who are using DLLs to get to various backend data, just what are you doing that makes the DLLs the thing to use. If I can't get the cursor for population of grids, that leaves me with just various object properties that I might map to a VB/C++ form. By not being able to return a cursor from a SELECT statement to VB/C++, it seems that I'm limited in what I can do.

Thanks,
Steve