Hi, after several days of investigations we found out that using the non-standard character set US7ASCII also affected the C++ programs.
Setting the NLS_ORA33 variable solved the problem. Stephan -----Original Message----- From: Winkler, Stephan Sent: Thursday, May 27, 2004 16:39 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Oracle: Embedded Perl & 7/8 bit character sets Hi all, I use an Embedded Perl Interpreter in a C++ program that already has Oracle database access with (7 bit) US7ASCII character set via ProC or whatever. So there are multiple database accesses. One from the original program and a second one via something like a callback routine in which a Perl interpreter has been embedded. When establishing a connecting via Perl (in multi-threading mode) with Oracle-1.15 driver to a different database with ( 8 bit) WE8ISO8859P1 characters, I noticed that I get stack problems with the dbh->execute command. The SqlNet traces show me that the correct results were returned, but the execute function either report Two Task protocol errors or even other problems (sometimes it simply crashes). So there are heavy stack problems with the application in this context (only if the character set differs, retrieving numeric datatypes is ok.). However, I did not use any specific DBI connect routine such as telling DBD to share the connection. It seems to be that the Oracle client libraries (Oracle 9.2.0.3) provides the result in a way that the Perl driver cannot decode. Moreover, setting such as NLS_LANG before establishing the connection in Perl do not help. Regards Stephan
