Re: Using Pro*C in a Windows DLL

From: Keith Bloom <akbloom_at_toad.net>
Date: 24 Feb 2005 11:32:23 -0800
Message-ID: <1109273543.490747.74950@f14g2000cwb.googlegroups.com>

>>I've been able to get the library to compile with minor changes as a
>>Windows DLL, and when the client program calls the connect function
the
>>DLL makes the connection. However, any function called after that
>>returns an ORA-01012 "not connected" error. Auditing sessions in the
>>database shows that the connection persists while the program
>>continues to run. So the connection is there, but the DLL is unable
>>to find it again.

>>Is there some way to get this to work on Windows?

>Include a connect statement in your Pro*C code and reconsider what you
>are doing. Sessions aren't shared between Winblows threads

I don't quite understand. The connection function looks like this (eliminating irrelevancies):

   if (strlen(dbname) == 0) {

      EXEC SQL WHENEVER SQLERROR DO sql_error("login");
      EXEC SQL CONNECT :username IDENTIFIED BY :password;
   } else {
      EXEC SQL WHENEVER SQLERROR DO sql_error("login");
      EXEC SQL DECLARE POLREPO DATABASE;
      EXEC SQL CONNECT :username IDENTIFIED BY :password AT POLREPO
	       USING :dbname;

   }
   if (strcmp(SQLSTATE, SQL_SUCCESS) != 0) {

      strcpy (*p_errcode, SQLSTATE);
      return -1;

   }
   return 0;

Is there some other kind of connect statement I need to include?

I just now checked out the threads idea by putting some tracing code in the DllMain function. There aren't separate threads. The dll's client does not create a new thread when it calls a different function in the same dll.

The library's client is a commercial program that includes an API for calling out to a shared library. I have no choice but to use a dll. I could rewrite the Pro*C to reconnect to the database at the beginning of each function call and disconnect at the end, but that could cause a serious performance problem.

There is an option of not doing it at all; but it would be a convenience for users to be able to run their programs from Windows instead of on a Unix server.

Keith Received on Thu Feb 24 2005 - 13:32:23 CST