|
|
|
|
|
|
| Author |
Message |
Keith Bloom
*nix forums beginner
Joined: 24 Feb 2005
Posts: 4
|
 Posted: Mon Feb 28, 2005 3:46 pm Post subject:
Re: Using Pro*C in a Windows DLL
|
|
|
Ah! That's it! Of course on Solaris it was always a local connection;
that's why it worked. Now I see that it's not enough to add the "at
polrepo" after the connect; I also need it for each cursor declaration.
It's in the documentation, naturally, but since I only used Pro*C
several years ago to do a few simple selects, I missed it.
Thank you. |
|
| Back to top |
|
 |
Dave
*nix forums Guru
Joined: 19 Feb 2005
Posts: 1725
|
| Posted: Mon Feb 28, 2005 11:27 am Post subject:
Re: Using Pro*C in a Windows DLL
|
|
|
Keith Bloom wrote:
| Quote: | 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;
|
Interesting, with those connect statements you would need to test dbname
for every SQL you performed to know whether or not to use AT POLREPO.
If you connect AT POLREPO and then EXEC SQL AT somewhere_else (no AT
statement implies a default), which isn't connected, then you would get
ORA-1012 errors.
Dave. |
|
| Back to top |
|
|
Keith Bloom
*nix forums beginner
Joined: 24 Feb 2005
Posts: 4
|
| Posted: Fri Feb 25, 2005 8:06 am Post subject:
Re: Using Pro*C in a Windows DLL
|
|
|
| Quote: | 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.
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
Sybrand Bakker
*nix forums Guru
Joined: 03 Apr 2005
Posts: 1766
|
| Posted: Thu Feb 24, 2005 8:44 pm Post subject:
Re: Using Pro*C in a Windows DLL
|
|
|
On 24 Feb 2005 11:32:23 -0800, "Keith Bloom" <akbloom@toad.net> wrote:
| Quote: | 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.
I'm not sure why you don't test on the SQLCA directly instead of
sqlstate.
Obviously if no database name is specified, the registry variable
LOCAL must have been set to the default database, or you should error
out.
--
Sybrand Bakker, Senior Oracle DBA |
|
| Back to top |
|
|
Keith Bloom
*nix forums beginner
Joined: 24 Feb 2005
Posts: 4
|
| Posted: Thu Feb 24, 2005 6:32 pm Post subject:
Re: Using Pro*C in a Windows DLL
|
|
|
| Quote: | 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 |
|
| Back to top |
|
|
Keith Bloom
*nix forums beginner
Joined: 24 Feb 2005
Posts: 4
|
| Posted: Thu Feb 24, 2005 5:13 pm Post subject:
Using Pro*C in a Windows DLL
|
|
|
I have a shared library written in Pro*C (no OCI) for Solaris. The
client program first calls a function in the library to connect to the
database, then calls additional functions to get the information it
needs.
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?
I'm using the Microsoft Visual C++ .NET compiler on Windows XP, with
the Oracle9i client software. The connection is to Oracle9i
(9.2.0.1.0) 64-bit on HPUX 11.
Keith |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:02 am | All times are GMT
|
|
Loans | Learn real Kung Fu | Dominios | Loans | Knitting Instructions
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Databases
»
Oracle
