Re: Using Pro*C in a Windows DLL

>>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?

>No. I was assuming you expected not to have to include a connect
>function. The ora-1012 is a clear sign you are not connected. This
>may happen of course when you have no connect at all, or when your
>connect fails. So your connect must fail, and your program doesn't
>deal with ith properly.

However, the connect does succeed. I can see it in the database. What's more, the connection lasts while the program continues to run. I can verify this by letting the program sleep for, say, 20 seconds after calling the login function. The dba_audit_sessions view shows a session lasting exactly 20 seconds.

So the connection exists, but the Pro*C function returns a "not connected" error. That indicates that whatever Pro*C uses to keep track of the connection (a handle to a structure in memory, maybe?) is getting lost or overwritten between calls to the dll.

>I'm not sure why you don't test on the SQLCA directly instead of
>sqlstate.

I think the idea was to make it more ANSI compliant. But the library was first written more than 5 years ago, so I'm not certain.

>Obviously if no database name is specified, the registry variable
>LOCAL must have been set to the default database, or you should
>error out.

The original assumption was that the database connection *would* be local. The second form of the connect statement was added more recently when the assumption was changed. The library has been running on Solaris, so registry variables weren't an issue. The ORACLE_SID environment variable determined the database when the library made a local connection.

Keith Received on Fri Feb 25 2005 - 03:06:40 CST