cx-oracle-users — Primary discussion list for users (and developers) of cx_Oracle

Re: [cx-oracle-users] is SessionPool thread safe?

[Forest W. <mo...@ti...>]

Thanks for the response, but I'm afraid it doesn't explain the matter.  It 
tells me how Connection objects behave when shared among threads, but it 
does not tell me how SessionPool objects behave when shared among threads.

One interpretation of what you wrote (and of the documentation) is that 
SessionPool.acquire() returns a thread-safe object when it was constructed 
with threaded=True, but the SessionPool.acquire() call itself is not 
thread safe.  If that is the case, a program's main thread could safely 
acquire() Connections and then pass them to worker threads, but multiple 
worker threads could not safely call acquire() on their own.

My program's worker threads have to acquire() Connections on an as-needed 
basis, rather than being handed a Connection when they start up.  The 
answer to my question will determine whether I have to write my own 
synchronization wrapper for SessionPool.acquire().

Anthony Tuininga <ant...@gm...> wrote:

> If you specify "threaded =3D True" in the constructor of the session
> pool, Oracle guarantees thread safety provided you use one thread for
> each connection you use. If you want more than one thread to access a
> connection, you will have to synchronize access. Does that explain the
> matter sufficiently?
> 
> On 9/12/05, Forest Wilkinson <mo...@ti...> wrote:
> 
>>I'm using cx_Oracle SessionPool objects in a threaded http server.  Since
>>I didn't see an explicit statement in the docs that SessionPool.acquire()
>>and SessionPool.release() are thread safe, I'm currently synchronizing
>>access to those methods with a threading.Condition object.  Is this
>>necessary?  If SessionPool does its own method synchronization, I'll get
>>rid of my wrapper class and perhaps get better performance.
>>=20
>>=20

Re: [cx-oracle-users] is SessionPool thread safe?

[Anthony T. <ant...@gm...>]

If you specify "threaded =3D True" in the constructor of the session
pool, Oracle guarantees thread safety provided you use one thread for
each connection you use. If you want more than one thread to access a
connection, you will have to synchronize access. Does that explain the
matter sufficiently?

On 9/12/05, Forest Wilkinson <mo...@ti...> wrote:
> I'm using cx_Oracle SessionPool objects in a threaded http server.  Since
> I didn't see an explicit statement in the docs that SessionPool.acquire()
> and SessionPool.release() are thread safe, I'm currently synchronizing
> access to those methods with a threading.Condition object.  Is this
> necessary?  If SessionPool does its own method synchronization, I'll get
> rid of my wrapper class and perhaps get better performance.
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Re: cx_oracle on Red Hat advance server 3

[Anthony T. <ant...@gm...>]

I'll take a look at the RPM spec -- I'm always open to improvements. :-)

On 9/12/05, Forest Wilkinson <mo...@ti...> wrote:
> I tried it with an rpm as well, and found that the rpm was placing
> cx_Oracle.so in the wrong directory.  If you want an rpm that will work,
> email me directly and I'll send you the one I made.
>=20
> Anthony T, you're welcome to contact me as well if you want my modified
> spec file and/or rpm for Red Hat ES3.
>=20
> Francois wrote:
> >  As anyone succeeded in installing cx_oracle on a Red Hat advance serve=
r 3?
> >
> >  Did try with Rpms designed for Red Hat 9, they install without errors,=
 but
> >  can"t import CX_oracle modules in Python, tried the source code versio=
n,
> >  no success...
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] is SessionPool thread safe?

[Forest W. <mo...@ti...>]

I'm using cx_Oracle SessionPool objects in a threaded http server.  Since 
I didn't see an explicit statement in the docs that SessionPool.acquire() 
and SessionPool.release() are thread safe, I'm currently synchronizing 
access to those methods with a threading.Condition object.  Is this 
necessary?  If SessionPool does its own method synchronization, I'll get 
rid of my wrapper class and perhaps get better performance.

[cx-oracle-users] Re: cx_oracle on Red Hat advance server 3

[Forest W. <mo...@ti...>]

I tried it with an rpm as well, and found that the rpm was placing 
cx_Oracle.so in the wrong directory.  If you want an rpm that will work, 
email me directly and I'll send you the one I made.

Anthony T, you're welcome to contact me as well if you want my modified 
spec file and/or rpm for Red Hat ES3.

Francois wrote:
>  As anyone succeeded in installing cx_oracle on a Red Hat advance server 3?
>  
>  Did try with Rpms designed for Red Hat 9, they install without errors, but
>  can"t import CX_oracle modules in Python, tried the source code version,
>  no success...

[cx-oracle-users] Re: Antwort: Re: cx_Oracle import problems

[Uwe H. <qu...@ti...>]

fel...@ba... schrieb:

> 
> Has anybody a suggestion, what is the best way to setup the rigth environment on
> windows?
> 

you can also try the oracle instant client, which doesn't use either the
registry or ORACLE_HOME. (only PATH and if needed NLS_LANG and
TNS_ADMIN)
http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html

regards
	uwe

Re: [cx-oracle-users] Connecting to a database in a way that doesn't stop a shutdown

[Paul M. <p.f...@gm...>]

On 9/12/05, Amaury Forgeot D Arc <Ama...@ub...> wrote:
> I've never used the Intelligent agent, but it seems on the contrary=20
> that a running agent is one of the causes which prevent=20
> SHUTDOWN NORMAL to work.=20
> A quick Google search reveals that some DBAs include a=20
> "agentctl stop" command in their shutdown procedures.=20

Hmm, I was sure I'd seen agent connections on a database which stopped
happily with SHUTDOWN NORMAL. Maybe I was mistaken... I don't have a
system I can do a realistic test of this on at the moment,
unfortunately :-(

> You should try to solve your case differently. Here are some ideas:=20
>=20
> - replace SHUTDOWN NORMAL by SHUTDOWN TRANSACTIONAL, which
> closes the connection after COMMIT or ROLLBACK.

To be honest, I would expect most shutdowns to be IMMEDIATE (or at
least to do IMMEDIATE if NORMAL doesn't respond within a reasonable
time). However, I'm not 100% certain that's the case - and I really
don't want to block a production system shutdown just because I wasn't
aware of it!
=20
> - Implement some kind of connection pooling, where the connection=20
> object is closed after 10 minutes of idle time.=20
> For this you will need another thread to close the connection.=20

That might work, although I expect the connections to spend most of
their time idle. The only reason I'm bothering about this is to
increase responsiveness of an application querying many databases,
with very small queries, where I want to avoid the issue of the
connect time dominating the response. Maybe it's simplest just to
accept the hit, and connect when needed - I can multithread the
connections, so that I'm only limited by the response of the slowest
connection.

> - Use the Oracle "Profiles" feature, and limit the "idle time"=20
> for the session.=20

Not really an option, as it needs changes to the target databases,
where I don't have that flexibility. A connection pool would probably
be better for my specific requirements here.

> Hope this helps,=20

It does, thanks.

Paul.

Re: [cx-oracle-users] Connecting to a database in a way that doesn't stop a shutdown

[Amaury F. D A. <Ama...@Ub...>]

Hello,

> Is there any way of creating a cx_Oracle connection which doesn't
> block a SHUTDOWN NORMAL? The Oracle Intelligent agent seems to work
> like this (agent connections are present in the database, but SHUTDOWN
> NORMAL still works), so I suspect it's possible, but I can't find
> anything in the documentation which tells me how.

I've never used the Intelligent agent, but it seems on the contrary
that a running agent is one of the causes which prevent
SHUTDOWN NORMAL to work.
A quick Google search reveals that some DBAs include a
"agentctl stop" command in their shutdown procedures.

You should try to solve your case differently. Here are some ideas:

- replace SHUTDOWN NORMAL by SHUTDOWN TRANSACTIONAL, which closes
the connection after COMMIT or ROLLBACK.

- Implement some kind of connection pooling, where the connection
object is closed after 10 minutes of idle time.
For this you will need another thread to close the connection.

- Use the Oracle "Profiles" feature, and limit the "idle time"
for the session.

Hope this helps,

--
Amaury Forgeot d'Arc
Ubix Development
www.ubitrade.com

[cx-oracle-users] Two-task protocol error when accessing NVARCHAR2 column

[Hamish L. <ham...@gm...>]

I get the following error when attempting to select an NVARCHAR2 column:

    cx_Oracle.DatabaseError: ORA-03106: fatal two-task communication
protocol error

I understand that ORA-03106 can arise dur to mismatches in character
sets. However the same query succeeds when tried from within SQL*Plus.
The database's character set is US7ASCII and its national character
set is AL16UTF16. The client machine runs Solaris 9.


Hamish Lawson

RE: RE: Antwort: Re: [cx-oracle-users] cx_Oracle import problems

[<fel...@ba...>]

Hi Nik,

> I've had similar problems when the ORACLEHOME was set incorrectly for=
 the
> version of cx_Oracle I had installed; might be worth checking

Thank's for the tip!

Mit freundlichen Gr=FC=DFen / Best Regards

Felix Uellendahl=

[cx-oracle-users] Connecting to a database in a way that doesn't stop a shutdown

[Paul M. <p.f...@gm...>]

I'm trying to write a long-running process which handles intermittent
data collection from a database. Basically my process will connect to
the database, and then sit there, occasionally querying the database
and passing data back to client applications.

If the database goes down, my application will be written to deal with
this - it will trap the error, and reconnect as necessary once the
database comes back.

Basically, I'm only keeping a connection open to ensure fast
turnaround of queries. The only problem I have is that I cannot afford
for my application to stop a SHUTDOWN NORMAL of the target database.
We have some admin tasks that do a shutdown normal, and they can't be
modified to take into account this extra process.

Is there any way of creating a cx_Oracle connection which doesn't
block a SHUTDOWN NORMAL? The Oracle Intelligent agent seems to work
like this (agent connections are present in the database, but SHUTDOWN
NORMAL still works), so I suspect it's possible, but I can't find
anything in the documentation which tells me how.

Thanks in advance,
Paul.

[cx-oracle-users] AW: cx_Oracle import

[Henning v. B. <H.v...@t-...>]

Hi Felix,

regarding your import problems on Windows:

If you have multiple Oracle homes,
it is not unusual that import problems occur.

The best way is then to write a setup script
(setenv.cmd) for each Oracle home that you
call before you start your application.
In this script, you can use
SET ORACLE_HOME=...
SET ORACLE_HOME_NAME=...
SET TNS_ADMIN=...
SET NLS_LANG=...

For every entry that you find in the windows registry
(HKLM\Software\Oracle\....) that differs between
the Oracle home instances, insert a corresponding
SET statement into your setup.cmd.

Special care must be taken for the PATH entry.

The best solution is to set it explicitly in your setup.cmd,
and just use directories from the one Oracle home you want
to use.

That way, the Operating system and Oracle can not mess around
with the several Oracle homes, and Bjorn Strong-in-the-Arm is
your uncle (everything should work alright).

Remember the Oracle standard way to look for settings is
a) Oracle Registry
b) override with environment variables.

BTW: However, other software (like, for example, the database 
libraries in Microsoft .Net), do not follow that standard 
- so you're quite lost with multiple Oracle homes in .Net.

And another remarkable thing to notice:
Remember Oracle version numbers have nothing to do with the version...

For example, IAS 9i uses Oracle 8i OCI libraries,
and IAS 10g uses Oracle 9.0.1 OCI libraries,
but AFAIK the version cx_Oracle for 9i is generated against
Oracle 9.2, and the OCINLGetNumericInfo function is not
part of the 9.0.1 OCI libraries etc.

Some Other examples:

IAS 10g contains Oracle Forms 9.0.4 = Oracle Forms 10g,
the same with Reports.

Version numbering for Oracle products is more or less
a marketing thing, as it seems.
Don't expect two Oracle products with the same major version
number to work together.

Henning

OT:
Will the next PIXAR animation film in our cinemas
be written in Python? Would be cool...

[cx-oracle-users] Pixar, looking for an experienced Oracle/Python person

[Mark H. <mh...@pi...>]

So, we're looking for an experience Oracle person, but
when we look in the usual places we run into a lot of
people with windows/java experience.

We're looking for more unix-based experience (specifically,
linux and osx), with C++ and Python backgrounds.

Here's a link with the full description:

http://jobsearch.pixar.careers.monster.com/getjob.asp?JobID=30736689&AVSDM=2005%2D08%2D05+17%3A46%3A22&Logo=0&col=dlt&sort=rv&vw=b&fn=8256&q=oracle

In case it gets mangled, go to

http://jobsearch.pixar.careers.monster.com/

and type in "oracle" for the search, it's the
"Senior Database Applications Developer" position.

If you submit a resume (it has to go through the web
site to get to HR), drop me a line so I can look
out for it...

Thanks!
Mark

-- 
Mark Harrison
Pixar Animation Studio

RE: Antwort: Re: [cx-oracle-users] cx_Oracle import problems

[Nik B. <Nik...@pe...>]

> Has anybody a suggestion, what is the best way to setup the 
> rigth environment on windows?

Do you have multiple copies of OCI.dll on the machine? In our environment,
for various reasons, there are often multiple ORACLEHOMEs and this means
multiple versions OCI.DLL.

I've had similar problems when the ORACLEHOME was set incorrectly for the
version of cx_Oracle I had installed; might be worth checking (SysInternal's
FileMon is useful to find out which OCI.DLL is being used;
http://www.sysinternals.com/Utilities/Filemon.html).

I hope this helps.

Nik

Antwort: Re: [cx-oracle-users] cx_Oracle import problems

[<fel...@ba...>]

Hello Markus,

thank you, that works fine!

Has anybody a suggestion, what is the best way to setup the rigth envir=
onment on
windows?


Mit freundlichen Gr=FC=DFen / Best Regards

Felix Uellendahl=

Re: [cx-oracle-users] cx_Oracle import problems

[Markus E. <mar...@me...>]

Hi Felix,

please define in /etc/profile the following lines:

# change these settings according to your installation
ORACLE_BASE=/home/oracle
#ORACLE_SID=

# these are Oracles default values, you should probably leave them as 
they are
ORACLE_HOME=$ORACLE_BASE/product/9.2.0
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data
PATH=$PATH:$ORACLE_HOME/bin
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$ORACLE_HOME/lib
TCL_LIBRARY=$ORACLE_HOME/network/agent/tcl

# For German Umlauts
NLS_LANG=AMERICAN_GERMANY.WE8ISO8859P15


export ORACLE_BASE
export ORACLE_HOME ORA_NLS33 ORACLE_SID PATH LD_LIBRARY_PATH
export NLS_LANG
export TCL_LIBRARY

With this settings, all users will get the necessary 
Oracle-client-environment for connecting against Oracle-DBs.

As root now install cx_Oracle again with python setup.py...

Greetings,

Ede


fel...@ba... wrote:

>
>
>Dear all,
>
>I use Python 2.4, Oracle 9.2.0 Client and installed
>cx_Oracle-4.1-9i-py24-1.i386.rpm on RedHat 9.
>
>[phulf@bycc19] (~): python
>Python 2.4.1 (#1, Jun 21 2005, 04:34:09)
>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
>  
>
>>>>import sys
>>>>sys.path
>>>>        
>>>>
>['', '/usr/local/eclipse_31/eclipse/plugins/org.python.pydev_0.9.8.1/PySrc',
>'/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2',
>'/usr/lib/python2.4/lib-dynload', '/usr/lib/python2.4/site-packages',
>'/usr/local/lib/python2.4/site-packages', '/u01/apps/oracle/9.2.0/lib',
>'/usr/lib/python24.zip', '/usr/lib/python2.4/lib-tk']
>  
>
>>>>import cx_Oracle
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>ImportError: libclntsh.so.9.0: cannot open shared object file: No such file or
>directory
>  
>
>
>[phulf@bycc19] (~): ll `echo $PYTHONPATH | sed 's/:/ /g'` | grep
>libclntsh.so.9.0
>-rwxr-xr-x    1 root     root     11529427 Sep  6 15:54 libclntsh.so.9.0
>---------------------------------------------------------------
>
>I also tried it on my windows XP Professional host:
>oracle 10.2.0 client, tested.
>Python 2.4
>cx_Oracle-4.1-win32-10g-py24.exe
>
>Error:
> Der Prozedureinsprungpunkt "OCINlsNumericInfoGet" wurde in der DLL "OCI.dll"
>nicht gefunden.
>(Pocedurecall "OCINlsNumericInfoGet" was not found in "OCI.dll")
>
>
>
>
>Mit freundlichen Grüßen / Best Regards
>
>Felix Uellendahl
>
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>cx-oracle-users mailing list
>cx-...@li...
>https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>  
>

Re: [cx-oracle-users] cx_Oracle import problems

[Marcos P. <ma...@bu...>]

You must include the location of this file ($ORACLE_HOME/lib) in your
LD_LIBRARY_PATH

I hope it helps.

The other case seems to be a version mismatch :-|

El jue, 08-09-2005 a las 13:42 +0200,
fel...@ba... escribi=C3=B3:
> ImportError: libclntsh.so.9.0: cannot open shared object file: No such
> file or
--=20
Marcos S=C3=A1nchez Provencio <ma...@bu...>

[cx-oracle-users] cx_Oracle import problems

[<fel...@ba...>]

Dear all,

I use Python 2.4, Oracle 9.2.0 Client and installed
cx_Oracle-4.1-9i-py24-1.i386.rpm on RedHat 9.

[phulf@bycc19] (~): python
Python 2.4.1 (#1, Jun 21 2005, 04:34:09)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/eclipse_31/eclipse/plugins/org.python.pydev_0.9.8.1/Py=
Src',
'/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2',
'/usr/lib/python2.4/lib-dynload', '/usr/lib/python2.4/site-packages',
'/usr/local/lib/python2.4/site-packages', '/u01/apps/oracle/9.2.0/lib',=

'/usr/lib/python24.zip', '/usr/lib/python2.4/lib-tk']
>>> import cx_Oracle
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: libclntsh.so.9.0: cannot open shared object file: No such =
file or
directory
>>>

[phulf@bycc19] (~): ll `echo $PYTHONPATH | sed 's/:/ /g'` | grep
libclntsh.so.9.0
-rwxr-xr-x    1 root     root     11529427 Sep  6 15:54 libclntsh.so.9.=
0
---------------------------------------------------------------

I also tried it on my windows XP Professional host:
oracle 10.2.0 client, tested.
Python 2.4
cx_Oracle-4.1-win32-10g-py24.exe

Error:
 Der Prozedureinsprungpunkt "OCINlsNumericInfoGet" wurde in der DLL "OC=
I.dll"
nicht gefunden.
(Pocedurecall "OCINlsNumericInfoGet" was not found in "OCI.dll")




Mit freundlichen Gr=FC=DFen / Best Regards

Felix Uellendahl
=

Re: [cx-oracle-users] unicode characters and cx_Oracle.

[Garrick W. <gar...@gm...>]

SSdtIGFmcmFpZCB0aGF0IGFsbCBvZiB0aGUgc3RyaW5ncyB0aGF0IEknbSB1c2luZyBhcmUgdXRm
LTggZW5jb2RlZC4gSSAKZmluYWxseSBjYW1lIHRvIHRoZSBwb2ludCB5ZXN0ZXJkYXksIHNpbmNl
IEkgZG9uJ3QgbmVlZCB0byBkbyBhbnkgU1FMIG9uIHRoZSAKZGF0YSBJJ20gaW5zZXJ0aW5nLCB0
aGF0IHRoZXkgY291bGQgc3Vydml2ZSBhcyBCTE9CcyBvciByYXcgb3Igb2JqZWN0cyAKaW5zdGVh
ZC4KCkFmdGVyIGhhdmluZyB0ZXN0ZWQgdGhpcywgdXRmLTggc3RyaW5ncyBhcmUgYWJsZSB0byBi
ZSByZWFkIGFuZCBkZWNvZGVkIApjb3JyZWN0bHkgZnJvbSB0aGUgZGF0YWJhc2UuIChCZXR3ZWVu
IHB5dGhvbiBhbmQgLk5FVCkKClRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLCBoYXZpbmcgeW91IGNv
bmZpcm0gdGhhdCBjeF9PcmFjbGUgd2FzIGluZGVlZCAKZW5jb2RpbmcgY2hhcmFjdGVycyB3YXMg
aW52YWx1YWJsZS4KCkNoZWVycywKR2FycmljawoKT24gOC8yNC8wNSwgTWFyY29zIFPDoW5jaGV6
IFByb3ZlbmNpbyA8bWFyY29zQGJ1cmtlLmF0aC5jeD4gd3JvdGU6Cj4gCj4gSSBhbSBzb3JyeSBp
ZiBJIHNheSBvYnZpb3VzIHRoaW5ncywgYnV0IHNvbWV0aW1lcyB0aGV5IGhlbHAKPiAob3RoZXJz
PykgOi0pCj4gCj4gWW91ciBzdHJpbmcgaXMgYmVpbmcgZW5jb2RlZCBhcyB1bmljb2RlIGFuZCB0
aGVuIGRlY29kZWQgYXMgaXNvLTg4NTktMQo+IChvciBzb21ldGhpbmcgc2ltaWxhcikuCj4gCj4g
QXJlIHlvdSBzdXJlIHlvdSBhcmUgbm90IG1peGluZyB1bmljb2RlIGFuZCBlbmNvZGVkIHN0cmlu
Z3MgaW4geW91cgo+IGNvZGU/IFdoZW4geW91IHJlYWNoIHRoaXMgc3RhdGVtZW50Ogo+IAo+ICMg
YSBfbXVzdF8gYmUgdW5pY29kZQo+IGEgPSBhLmVuY29kZSgidXRmLTgiKQo+ICMgbm93IGEgaXMg
YW4gZW5jb2RlZCBzdHJpbmcKPiAKPiBJIGd1ZXNzIHlvdSBtdXN0IHVzZSBzb21lIGNvbnZlbnRp
b24gaW4geW91ciBjb2RlIHRvIHNlcGFyYXRlIGJvdGggdHlwZXMKPiBvcyBzdHJpbmdzLgo+IAo+
IFRyeSB3aGF0IHlvdSByZWFkIGZyb20gdGhlIGRhdGFiYXNlLCB0byBzZWUgaWYgdGhlIHNhbWUg
c3RyaW5nIHlvdSByZWFkCj4gd29ya3Mgd2hlbiBmZWQgdG8gdGhlIHByb2NlZHVyZS4KPiAKPiBX
ZWxsLCBJIGhvcGUgSSBnYXZlIHlvdSBzb21lIHBvaW50ZXIuCj4gCj4gRWwgbWnDqSwgMjQtMDgt
MjAwNSBhIGxhcyAxMDowNyArMTAwMCwgR2FycmljayBXZWxzaCBlc2NyaWJpw7M6Cj4gPiBUaGFu
ayB5b3UuCj4gPgo+ID4gSSBhY3R1YWxseSBoYXZlIGJlZW4gZG9pbmcgdGhlIHNhbWUgc29ydCBv
ZiBlbmNvZGluZyBhcyB5b3UndmUKPiA+IHNwZWNpZmllZC4KPiA+Cj4gPiBUaGUgTkxTX0NIQVJB
Q1RFUlNFVCBvZiB0aGUgZGF0YWJhc2UgaXMgdXRmLTggYW5kIEkndmUgYmVlbiB1dGYtOAo+ID4g
ZW5jb2RpbmcgYW55IG9mIG15IHVuaWNvZGUgc3RyaW5ncyBiZWZvcmUgSSBhdHRlbXB0IHRvIGlu
c2VydCB0aGVtCj4gPiBpbnRvIHRoZSBkYXRhYmFzZS4gVW5mb3J0dW5hdGVseSB3aGVuIEkgYXR0
ZW1wdCB0byBhY2Nlc3MgdGhlIGluc2VydGVkCj4gPiBpbmZvcm1hdGlvbiBpdCdzIGRvbmUgdmlh
IC5ORVQuIFRoZSBjaGFyYWN0ZXJzIGluc2VydGVkIGFyZSBkZWZpbmF0ZWx5Cj4gPiBub3QgdGhv
c2UgdGhhdCB3ZXJlIGluc2VydGVkIGFuZCB0aGUgT3JhY2xlIFRhYmxlIEVkaXRvciBkaXNwbGF5
cyB0aGUKPiA+IGNoYXJhY3RlcnMgaWRlbnRpY2FsbHkgdG8gLk5FVC4KPiA+Cj4gPiBDaGVlcnMs
Cj4gPiBHYXJyaWNrCj4gPgo+ID4gKE1vcmUgaW1wbGVtZW50YXRpb24gZGV0YWlscykKPiA+IHJ1
c3NpYW4gLS3Rh9GC0L4g0YLQsNC60L7QtSDQvtGB0LXQvdGMLS0gcnVzc2lhbiAoaXMgdGhlIGlu
cHV0KQo+ID4gcnVzc2lhbiAtLcOR4oChw5HigJrDkMK+IMOR4oCaw5DCsMOQwrrDkMK+w5DCtSDD
kMK+w5HCgcOQwrXDkMK9w5HFki0tIHJ1c3NpYW4gKGlzIHdoYXQgaXMgc3RvcmVkCj4gPiBpbiB0
aGUgZGF0YWJhc2UpCj4gPgo+ID4gQmFzaWNhbGx5IHRoZSB0ZXN0IHRleHQgcnVzc2lhbiAtLdGH
0YLQviDRgtCw0LrQvtC1INC+0YHQtdC90YwtLSBydXNzaWFuIGlzIHN0b3JlZAo+ID4gaW4gYSB1
dGYtOCBlbmNvZGVkIGZpbGUuCj4gPgo+ID4gZiA9IGNvZGVjcy5vcGVuKCdtdWx0aS50eHQnLCdy
JywndXRmLTgnKQo+ID4gYSA9IGYucmVhZGxpbmUoKQo+ID4KPiA+IGEgPSBhLmVuY29kZSgidXRm
LTgiKQo+ID4KPiA+IFRoaXMgaXMgcGFzc2VkIGFzIGFuIGFyZ3VtZW50IHRvIGEgc3RvcmVkIHBy
b2NlZHVyZS4uLgo+ID4KPiA+IFRoZSB0ZXh0IGlzIHRoZW4gc2ltcGx5IGluc2VydGVkIGludG8g
YSBkYXRhYmFzZSB0YWJsZS4gVGhlIHRleHQKPiA+IGJldHdlZW4gdGhlIHNvdXJjZSBhbmQgdGhl
IGVuZCByZXN1bHQgaXMgZGlmZmVyZW50Lgo+ID4KPiA+Cj4gPiBPbiA4LzIyLzA1LCBNYXJjb3Mg
U8OhbmNoZXogUHJvdmVuY2lvIDxtYXJjb3NAYnVya2UuYXRoLmN4PiB3cm90ZToKPiA+IFRoaXMg
aXMgYW4gaW5jb21wbGV0ZSBjaHVuayBvZiBvbmUgb2YgbXkgcHJvZ3JhbXM6Cj4gPiBjb2RQeXRo
b25PcmFjbGU9ewo+ID4gJ1dFOElTTzg4NTlQMSc6J2lzby04ODU5LTEnLAo+ID4gJ1dFOElTTzg4
NTlQMTUnOidpc28tODg1OS0xNScsCj4gPiAnV0U4TVNXSU4xMjUyJzonY3AxMjUyJywKPiA+IH0K
PiA+Cj4gPiBjbGFzcyBMZWN0b3JFc3F1ZW1hKGZpcy5MZWN0b3JFc3F1ZW1hRmlzaWNvICk6Cj4g
PiBkZWYgbG9va3VwRGVzYyhzZWxmLHNxbCk6Cj4gPiBpZiBpc2luc3RhbmNlKHNxbCwgdW5pY29k
ZSk6Cj4gPiBzcWw9c3FsLmVuY29kZShzZWxmLmNvZGlmaWNhY2lvbikKPiA+IHJldHVybiBmaXMu
TGVjdG9yRXNxdWVtYUZpc2ljby5sb29rdXBEZXNjKHNlbGYsc3FsKQo+ID4gZGVmIGxvZ2luKHNl
bGYpOgo+ID4gc2VsZi5jb249ZGJhcGkuY29ubmVjdChzZWxmLnVzdWFyaW8sIHNlbGYuY2xhdmUs
Cj4gPiBzZWxmLmRzbiwgKQo+ID4gc3FsQ29kT3JhY2xlPScnJ3NlbGVjdCB2YWx1ZQo+ID4gZnJv
bSB2JG5sc19wYXJhbWV0ZXJzCj4gPiB3aGVyZSBwYXJhbWV0ZXIgPSAnTkxTX0NIQVJBQ1RFUlNF
VCcgJycnCj4gPiBjb2RPcmFjbGU9c2VsZi5sb29rdXAgKHNxbENvZE9yYWNsZSlbMF1bMF0KPiA+
IHNlbGYuY29kaWZpY2FjaW9uPWNvZFB5dGhvbk9yYWNsZVtjb2RPcmFjbGVdCj4gPgo+ID4gSSBk
b24ndCBoYXZlIHRoZSB0aW1lIHRvIHByZXBhcmUgYW4gZXhhbXBsZSwgYnV0IHlvdSBjYW4KPiA+
IGV4dHJhY3QgdGhlCj4gPiBpbmZvcm1hdGlvbiwgSSBob3BlLgo+ID4KPiA+ICogVGhlIGZpcnN0
IHRpbWUgeW91IGxvZ2luLCB5b3UgZ2V0IHRoZSBkZWZhdWx0IGRiIGVuY29kaW5nLgo+ID4gKiBU
aGVuIHlvdSB0cmFuc2xhdGUgd2hhdCB5b3UgZ2V0IGludG8gUHl0aG9uIChmaWxsIGluIHdoYXQK
PiA+IHlvdSBnZXQgaWYKPiA+IGl0IGlzIG5vdCBpbiB0aGUgZGljdCkuCj4gPiAqIFdoZW5ldmVy
IHlvdSByZWNlaXZlIGFuIHVuaWNvZGUgc3RyaW5nLCB0cmFuc2xhdGUgaW50byB0aGUKPiA+IG5l
ZWRlZAo+ID4gZW5jb2RpbmcgKGJvdGggdGhlIHNxbCBhbmQgdGhlIHBhcmFtZXRlcnMpIGJlZm9y
ZSBzZW5kaW5nIGl0Cj4gPiB0byBPcmFjbGUuCj4gPiAqIFdoZW5ldmVyIHlvdSByZWNlaXZlIGEg
c3RyaW5nLCBkZWNvZGUgaXQgdXNpbmcgdGhlIHNhbWUKPiA+IGVuY29kaW5nLCB0bwo+ID4gd29y
ayBpbnRlcm5hbGx5IGluIFVuaWNvZGUuCj4gPgo+ID4gSSBob3BlIGl0IGhlbHBzLiBUaGlzIHNo
b3VsZCBiZSBkb25lIGJ5IHRoZSBjeCBsaWJzLCBJIGd1ZXNzLgo+ID4KPiA+IEVsIGx1biwgMjIt
MDgtMjAwNSBhIGxhcyAxMzo0MCArMTAwMCwgR2FycmljayBXZWxzaCBlc2NyaWJpw7M6Cj4gPiA+
IEkgaGF2ZSB0aGUgZm9sbG93aW5nIHByb2JsZW0uIEkgaGF2ZSBhIHV0Zi04IGVuY29kZWQgc3Ry
aW5nLAo+ID4gdGhhdCBpcwo+ID4gPiB0byBiZSBpbnNlcnRlZCBpbnRvIGFuIE9yYWNsZSBEQiB1
c2luZyBjeF9PcmFjbGUuCj4gPiA+Cj4gPiA+IE5vdyBjeF9PcmFjbGUgYXBwZWFycyB0byBiZSBj
b25maWd1cmVkIHRvIGRvIGEgY2hhcmFjdGVyCj4gPiB0cmFuc2xhdGlvbgo+ID4gPiBvZiBzb21l
IGRlc2NyaXB0aW9uIG9uIHRoaXMgc3RyaW5nLiBJcyB0aGVyZSBhbnl3YXkgSSBjb3VsZAo+ID4g
aW5zZXJ0IHRoZQo+ID4gPiB1bmljb2RlIGVxdWl2YWxlbnQgc3RyaW5nPyAoaS5lLiB1ZGF0YSA9
IHVuaWNvZGUoZGF0YSwKPiA+ICJ1dGYtOCIpKQo+ID4gPiBpbnN0ZWFkIG9mIGEgcmVndWxhciBj
aGFyYWN0ZXIgc3RyaW5nIGludG8gdGhlIGRhdGFiYXNlPyBJZgo+ID4gbm90IGlzCj4gPiA+IHRo
ZXJlIGEgd2F5IHRvIGNvbmZpZ3VyZSB0aGUgZW5jb2RpbmcgdHlwZSB0aGF0IGN4X09yYWNsZQo+
ID4gZXhwZWN0cy4uLgo+ID4gPgo+ID4gPiBHYXJyaWNrCj4gPiA+Cj4gPiA+IC0tCj4gPiA+IEdh
cnJpY2sgV2Vsc2gKPiA+ID4KPiA+ID4gVGhlIGh1bWFuIHJhY2UgaXMgYSByYWNlIG9mIGNvd2Fy
ZHM7IGFuZCBJIGFtIG5vdCBvbmx5Cj4gPiBtYXJjaGluZyBpbgo+ID4gPiB0aGF0Cj4gPiA+IHBy
b2Nlc3Npb24gYnV0IGNhcnJ5aW5nIGEgYmFubmVyLgo+ID4gPiAtLSBNYXJrIFR3YWluCj4gPiAt
LQo+ID4gTWFyY29zIFPDoW5jaGV6IFByb3ZlbmNpbyA8bWFyY29zQGJ1cmtlLmF0aC5jeD4KPiA+
Cj4gPgo+ID4KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KPiA+IFNGLk5ldCBlbWFpbCBpcyBTcG9uc29yZWQgYnkgdGhlIEJldHRlciBT
b2Z0d2FyZSBDb25mZXJlbmNlICYKPiA+IEVYUE8KPiA+IFNlcHRlbWJlciAxOS0yMiwgMjAwNSAq
IFNhbiBGcmFuY2lzY28sIENBICogRGV2ZWxvcG1lbnQKPiA+IExpZmVjeWNsZSBQcmFjdGljZXMK
PiA+IEFnaWxlICYgUGxhbi1Ecml2ZW4gRGV2ZWxvcG1lbnQgKiBNYW5hZ2luZyBQcm9qZWN0cyAm
IFRlYW1zICoKPiA+IFRlc3RpbmcgJiBRQQo+ID4gU2VjdXJpdHkgKiBQcm9jZXNzIEltcHJvdmVt
ZW50ICYgTWVhc3VyZW1lbnQgKgo+ID4gaHR0cDovL3d3dy5zcWUuY29tL2JzY2U1c2YKPiA+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBjeC1vcmFj
bGUtdXNlcnMgbWFpbGluZyBsaXN0Cj4gPiBjeC1vcmFjbGUtdXNlcnNAbGlzdHMuc291cmNlZm9y
Z2UubmV0Cj4gPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9j
eC1vcmFjbGUtdXNlcnMKPiA+Cj4gPgo+ID4KPiA+IC0tCj4gPiBHYXJyaWNrIFdlbHNoCj4gPgo+
ID4gVGhlIGh1bWFuIHJhY2UgaXMgYSByYWNlIG9mIGNvd2FyZHM7IGFuZCBJIGFtIG5vdCBvbmx5
IG1hcmNoaW5nIGluCj4gPiB0aGF0Cj4gPiBwcm9jZXNzaW9uIGJ1dCBjYXJyeWluZyBhIGJhbm5l
ci4KPiA+IC0tIE1hcmsgVHdhaW4KPiAtLQo+IE1hcmNvcyBTw6FuY2hleiBQcm92ZW5jaW8gPG1h
cmNvc0BidXJrZS5hdGguY3g+Cj4gCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFNGLk5ldCBlbWFpbCBpcyBTcG9uc29yZWQg
YnkgdGhlIEJldHRlciBTb2Z0d2FyZSBDb25mZXJlbmNlICYgRVhQTwo+IFNlcHRlbWJlciAxOS0y
MiwgMjAwNSAqIFNhbiBGcmFuY2lzY28sIENBICogRGV2ZWxvcG1lbnQgTGlmZWN5Y2xlIAo+IFBy
YWN0aWNlcwo+IEFnaWxlICYgUGxhbi1Ecml2ZW4gRGV2ZWxvcG1lbnQgKiBNYW5hZ2luZyBQcm9q
ZWN0cyAmIFRlYW1zICogVGVzdGluZyAmIFFBCj4gU2VjdXJpdHkgKiBQcm9jZXNzIEltcHJvdmVt
ZW50ICYgTWVhc3VyZW1lbnQgKiBodHRwOi8vd3d3LnNxZS5jb20vYnNjZTVzZgo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gY3gtb3JhY2xlLXVzZXJz
IG1haWxpbmcgbGlzdAo+IGN4LW9yYWNsZS11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBo
dHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9jeC1vcmFjbGUtdXNl
cnMKPiAKCgoKLS0gCkdhcnJpY2sgV2Vsc2gKClRoZSBodW1hbiByYWNlIGlzIGEgcmFjZSBvZiBj
b3dhcmRzOyBhbmQgSSBhbSBub3Qgb25seSBtYXJjaGluZyBpbiB0aGF0CnByb2Nlc3Npb24gYnV0
IGNhcnJ5aW5nIGEgYmFubmVyLgotLSBNYXJrIFR3YWluCg==

Re: [cx-oracle-users] unicode characters and cx_Oracle.

[Marcos P. <ma...@bu...>]

I am sorry if I say obvious things, but sometimes they help
(others?) :-)

Your string is being encoded as unicode and then decoded as iso-8859-1
(or something similar).

Are you sure you are not mixing unicode and encoded strings in your
code? When you reach this statement:

# a _must_ be unicode
a =3D a.encode("utf-8")
# now a is an encoded string

I guess you must use some convention in your code to separate both types
os strings.

Try what you read from the database, to see if the same string you read
works when fed to the procedure.

Well, I hope I gave you some pointer.=20

El mi=C3=A9, 24-08-2005 a las 10:07 +1000, Garrick Welsh escribi=C3=B3:
> Thank you.
>=20
> I actually have been doing the same sort of encoding as you've
> specified.
>=20
> The NLS_CHARACTERSET of the database is utf-8 and I've been utf-8
> encoding any of my unicode strings before I attempt to insert them
> into the database. Unfortunately when I attempt to access the inserted
> information it's done via .NET. The characters inserted are definately
> not those that were inserted and the Oracle Table Editor displays the
> characters identically to .NET.
>=20
>     Cheers,
>                Garrick
>=20
> (More implementation details)
> russian  --=D1=87=D1=82=D0=BE =D1=82=D0=B0=D0=BA=D0=BE=D0=B5 =D0=BE=D1=81=
=D0=B5=D0=BD=D1=8C-- russian (is the input)
> russian  --=C3=91=E2=80=A1=C3=91=E2=80=9A=C3=90=C2=BE =C3=91=E2=80=9A=C3=
=90=C2=B0=C3=90=C2=BA=C3=90=C2=BE=C3=90=C2=B5 =C3=90=C2=BE=C3=91=C2=81=C3=
=90=C2=B5=C3=90=C2=BD=C3=91=C5=92-- russian (is what is stored
> in the database)
>=20
> Basically the test text russian  --=D1=87=D1=82=D0=BE =D1=82=D0=B0=D0=BA=
=D0=BE=D0=B5 =D0=BE=D1=81=D0=B5=D0=BD=D1=8C-- russian is stored
> in a utf-8 encoded file.
>=20
>         f =3D codecs.open('multi.txt','r','utf-8')
>         a =3D f.readline()     =20
>  =20
> a =3D a.encode("utf-8")
>=20
> This is passed as an argument to a stored procedure...
>=20
> The text is then simply inserted into a database table. The text
> between the source and the end result is different.
>=20
>=20
> On 8/22/05, Marcos S=C3=A1nchez Provencio <ma...@bu...> wrote:
>         This is an incomplete chunk of one of my programs:
>         codPythonOracle=3D{
>             'WE8ISO8859P1':'iso-8859-1',
>             'WE8ISO8859P15':'iso-8859-15',
>             'WE8MSWIN1252':'cp1252',
>         }
>        =20
>         class LectorEsquema(fis.LectorEsquemaFisico ):
>             def lookupDesc(self,sql):
>                 if isinstance(sql, unicode):
>                     sql=3Dsql.encode(self.codificacion)
>                 return fis.LectorEsquemaFisico.lookupDesc(self,sql)
>             def login(self):
>                  self.con=3Ddbapi.connect(self.usuario, self.clave,
>         self.dsn, )
>                 sqlCodOracle=3D'''select value
>                     from v$nls_parameters
>                     where parameter =3D 'NLS_CHARACTERSET' '''
>                 codOracle=3Dself.lookup (sqlCodOracle)[0][0]
>                 self.codificacion=3DcodPythonOracle[codOracle]
>        =20
>         I don't have the time to prepare an example, but you can
>         extract the
>         information, I hope.
>        =20
>         * The first time you login, you get the default db encoding.=20
>         * Then you translate what you get into Python (fill in what
>         you get if
>         it is not in the dict).
>         * Whenever you receive an unicode string, translate into the
>         needed
>         encoding (both the sql and the parameters) before sending it
>         to Oracle.=20
>         * Whenever you receive a string, decode it using the same
>         encoding, to
>         work internally in Unicode.
>        =20
>         I hope it helps. This should be done by the cx libs, I guess.
>        =20
>         El lun, 22-08-2005 a las 13:40 +1000, Garrick Welsh escribi=C3=B3=
:=20
>         > I have the following problem. I have a utf-8 encoded string,
>         that is
>         > to be inserted into an Oracle DB using cx_Oracle.
>         >
>         > Now cx_Oracle appears to be configured to do a character
>         translation=20
>         > of some description on this string. Is there anyway I could
>         insert the
>         > unicode equivalent string? (i.e. udata =3D unicode(data,
>         "utf-8"))
>         > instead of a regular character string into the database? If
>         not is=20
>         > there a way to configure the encoding type that cx_Oracle
>         expects...
>         >
>         >     Garrick
>         >
>         > --
>         > Garrick Welsh
>         >
>         > The human race is a race of cowards; and I am not only
>         marching in=20
>         > that
>         > procession but carrying a banner.
>         >                 -- Mark Twain
>         --
>         Marcos S=C3=A1nchez Provencio <ma...@bu...>
>        =20
>        =20
>        =20
>         -------------------------------------------------------=20
>         SF.Net email is Sponsored by the Better Software Conference &
>         EXPO
>         September 19-22, 2005 * San Francisco, CA * Development
>         Lifecycle Practices
>         Agile & Plan-Driven Development * Managing Projects & Teams *
>         Testing & QA=20
>         Security * Process Improvement & Measurement *
>         http://www.sqe.com/bsce5sf
>         _______________________________________________
>         cx-oracle-users mailing list
>         cx-...@li...
>         https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>=20
>=20
>=20
> --=20
> Garrick Welsh
>=20
> The human race is a race of cowards; and I am not only marching in
> that
> procession but carrying a banner.
>                 -- Mark Twain
--=20
Marcos S=C3=A1nchez Provencio <ma...@bu...>

Re: [cx-oracle-users] unicode characters and cx_Oracle.

[Garrick W. <gar...@gm...>]

VGhhbmsgeW91LgoKSSBhY3R1YWxseSBoYXZlIGJlZW4gZG9pbmcgdGhlIHNhbWUgc29ydCBvZiBl
bmNvZGluZyBhcyB5b3UndmUgc3BlY2lmaWVkLgoKVGhlIE5MU19DSEFSQUNURVJTRVQgb2YgdGhl
IGRhdGFiYXNlIGlzIHV0Zi04IGFuZCBJJ3ZlIGJlZW4gdXRmLTggZW5jb2RpbmcgCmFueSBvZiBt
eSB1bmljb2RlIHN0cmluZ3MgYmVmb3JlIEkgYXR0ZW1wdCB0byBpbnNlcnQgdGhlbSBpbnRvIHRo
ZSBkYXRhYmFzZS4gClVuZm9ydHVuYXRlbHkgd2hlbiBJIGF0dGVtcHQgdG8gYWNjZXNzIHRoZSBp
bnNlcnRlZCBpbmZvcm1hdGlvbiBpdCdzIGRvbmUgCnZpYSAuTkVULiBUaGUgY2hhcmFjdGVycyBp
bnNlcnRlZCBhcmUgZGVmaW5hdGVseSBub3QgdGhvc2UgdGhhdCB3ZXJlIAppbnNlcnRlZCBhbmQg
dGhlIE9yYWNsZSBUYWJsZSBFZGl0b3IgZGlzcGxheXMgdGhlIGNoYXJhY3RlcnMgaWRlbnRpY2Fs
bHkgdG8gCi5ORVQuCgpDaGVlcnMsCkdhcnJpY2sKCihNb3JlIGltcGxlbWVudGF0aW9uIGRldGFp
bHMpCnJ1c3NpYW4gLS3Rh9GC0L4g0YLQsNC60L7QtSDQvtGB0LXQvdGMLS0gcnVzc2lhbiAoaXMg
dGhlIGlucHV0KQpydXNzaWFuIC0tw5HigKHDkeKAmsOQwr4gw5HigJrDkMKww5DCusOQwr7DkMK1
IMOQwr7DkcKBw5DCtcOQwr3DkcWSLS0gcnVzc2lhbiAoaXMgd2hhdCBpcyBzdG9yZWQgaW4gdGhl
IApkYXRhYmFzZSkKCkJhc2ljYWxseSB0aGUgdGVzdCB0ZXh0IHJ1c3NpYW4gLS3Rh9GC0L4g0YLQ
sNC60L7QtSDQvtGB0LXQvdGMLS0gcnVzc2lhbiBpcyBzdG9yZWQgaW4gYSAKdXRmLTggZW5jb2Rl
ZCBmaWxlLgoKZiA9IGNvZGVjcy5vcGVuKCdtdWx0aS50eHQnLCdyJywndXRmLTgnKQphID0gZi5y
ZWFkbGluZSgpIAoKYSA9IGEuZW5jb2RlKCJ1dGYtOCIpCgpUaGlzIGlzIHBhc3NlZCBhcyBhbiBh
cmd1bWVudCB0byBhIHN0b3JlZCBwcm9jZWR1cmUuLi4KClRoZSB0ZXh0IGlzIHRoZW4gc2ltcGx5
IGluc2VydGVkIGludG8gYSBkYXRhYmFzZSB0YWJsZS4gVGhlIHRleHQgYmV0d2VlbiB0aGUgCnNv
dXJjZSBhbmQgdGhlIGVuZCByZXN1bHQgaXMgZGlmZmVyZW50LgoKCk9uIDgvMjIvMDUsIE1hcmNv
cyBTw6FuY2hleiBQcm92ZW5jaW8gPG1hcmNvc0BidXJrZS5hdGguY3g+IHdyb3RlOgo+IAo+IFRo
aXMgaXMgYW4gaW5jb21wbGV0ZSBjaHVuayBvZiBvbmUgb2YgbXkgcHJvZ3JhbXM6Cj4gY29kUHl0
aG9uT3JhY2xlPXsKPiAnV0U4SVNPODg1OVAxJzonaXNvLTg4NTktMScsCj4gJ1dFOElTTzg4NTlQ
MTUnOidpc28tODg1OS0xNScsCj4gJ1dFOE1TV0lOMTI1Mic6J2NwMTI1MicsCj4gfQo+IAo+IGNs
YXNzIExlY3RvckVzcXVlbWEoZmlzLkxlY3RvckVzcXVlbWFGaXNpY28gKToKPiBkZWYgbG9va3Vw
RGVzYyhzZWxmLHNxbCk6Cj4gaWYgaXNpbnN0YW5jZShzcWwsIHVuaWNvZGUpOgo+IHNxbD1zcWwu
ZW5jb2RlKHNlbGYuY29kaWZpY2FjaW9uKQo+IHJldHVybiBmaXMuTGVjdG9yRXNxdWVtYUZpc2lj
by5sb29rdXBEZXNjKHNlbGYsc3FsKQo+IGRlZiBsb2dpbihzZWxmKToKPiBzZWxmLmNvbj1kYmFw
aS5jb25uZWN0KHNlbGYudXN1YXJpbywgc2VsZi5jbGF2ZSwgc2VsZi5kc24sICkKPiBzcWxDb2RP
cmFjbGU9Jycnc2VsZWN0IHZhbHVlCj4gZnJvbSB2JG5sc19wYXJhbWV0ZXJzCj4gd2hlcmUgcGFy
YW1ldGVyID0gJ05MU19DSEFSQUNURVJTRVQnICcnJwo+IGNvZE9yYWNsZT1zZWxmLmxvb2t1cCAo
c3FsQ29kT3JhY2xlKVswXVswXQo+IHNlbGYuY29kaWZpY2FjaW9uPWNvZFB5dGhvbk9yYWNsZVtj
b2RPcmFjbGVdCj4gCj4gSSBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIHByZXBhcmUgYW4gZXhhbXBs
ZSwgYnV0IHlvdSBjYW4gZXh0cmFjdCB0aGUKPiBpbmZvcm1hdGlvbiwgSSBob3BlLgo+IAo+ICog
VGhlIGZpcnN0IHRpbWUgeW91IGxvZ2luLCB5b3UgZ2V0IHRoZSBkZWZhdWx0IGRiIGVuY29kaW5n
LiAKPiAqIFRoZW4geW91IHRyYW5zbGF0ZSB3aGF0IHlvdSBnZXQgaW50byBQeXRob24gKGZpbGwg
aW4gd2hhdCB5b3UgZ2V0IGlmCj4gaXQgaXMgbm90IGluIHRoZSBkaWN0KS4KPiAqIFdoZW5ldmVy
IHlvdSByZWNlaXZlIGFuIHVuaWNvZGUgc3RyaW5nLCB0cmFuc2xhdGUgaW50byB0aGUgbmVlZGVk
Cj4gZW5jb2RpbmcgKGJvdGggdGhlIHNxbCBhbmQgdGhlIHBhcmFtZXRlcnMpIGJlZm9yZSBzZW5k
aW5nIGl0IHRvIE9yYWNsZS4gCj4gKiBXaGVuZXZlciB5b3UgcmVjZWl2ZSBhIHN0cmluZywgZGVj
b2RlIGl0IHVzaW5nIHRoZSBzYW1lIGVuY29kaW5nLCB0bwo+IHdvcmsgaW50ZXJuYWxseSBpbiBV
bmljb2RlLgo+IAo+IEkgaG9wZSBpdCBoZWxwcy4gVGhpcyBzaG91bGQgYmUgZG9uZSBieSB0aGUg
Y3ggbGlicywgSSBndWVzcy4KPiAKPiBFbCBsdW4sIDIyLTA4LTIwMDUgYSBsYXMgMTM6NDAgKzEw
MDAsIEdhcnJpY2sgV2Vsc2ggZXNjcmliacOzOiAKPiA+IEkgaGF2ZSB0aGUgZm9sbG93aW5nIHBy
b2JsZW0uIEkgaGF2ZSBhIHV0Zi04IGVuY29kZWQgc3RyaW5nLCB0aGF0IGlzCj4gPiB0byBiZSBp
bnNlcnRlZCBpbnRvIGFuIE9yYWNsZSBEQiB1c2luZyBjeF9PcmFjbGUuCj4gPgo+ID4gTm93IGN4
X09yYWNsZSBhcHBlYXJzIHRvIGJlIGNvbmZpZ3VyZWQgdG8gZG8gYSBjaGFyYWN0ZXIgdHJhbnNs
YXRpb24KPiA+IG9mIHNvbWUgZGVzY3JpcHRpb24gb24gdGhpcyBzdHJpbmcuIElzIHRoZXJlIGFu
eXdheSBJIGNvdWxkIGluc2VydCB0aGUKPiA+IHVuaWNvZGUgZXF1aXZhbGVudCBzdHJpbmc/IChp
LmUuIHVkYXRhID0gdW5pY29kZShkYXRhLCAidXRmLTgiKSkKPiA+IGluc3RlYWQgb2YgYSByZWd1
bGFyIGNoYXJhY3RlciBzdHJpbmcgaW50byB0aGUgZGF0YWJhc2U/IElmIG5vdCBpcyAKPiA+IHRo
ZXJlIGEgd2F5IHRvIGNvbmZpZ3VyZSB0aGUgZW5jb2RpbmcgdHlwZSB0aGF0IGN4X09yYWNsZSBl
eHBlY3RzLi4uCj4gPgo+ID4gR2Fycmljawo+ID4KPiA+IC0tCj4gPiBHYXJyaWNrIFdlbHNoCj4g
Pgo+ID4gVGhlIGh1bWFuIHJhY2UgaXMgYSByYWNlIG9mIGNvd2FyZHM7IGFuZCBJIGFtIG5vdCBv
bmx5IG1hcmNoaW5nIGluIAo+ID4gdGhhdAo+ID4gcHJvY2Vzc2lvbiBidXQgY2FycnlpbmcgYSBi
YW5uZXIuCj4gPiAtLSBNYXJrIFR3YWluCj4gLS0KPiBNYXJjb3MgU8OhbmNoZXogUHJvdmVuY2lv
IDxtYXJjb3NAYnVya2UuYXRoLmN4Pgo+IAo+IAo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gCj4gU0YuTmV0IGVtYWlsIGlzIFNwb25z
b3JlZCBieSB0aGUgQmV0dGVyIFNvZnR3YXJlIENvbmZlcmVuY2UgJiBFWFBPCj4gU2VwdGVtYmVy
IDE5LTIyLCAyMDA1ICogU2FuIEZyYW5jaXNjbywgQ0EgKiBEZXZlbG9wbWVudCBMaWZlY3ljbGUg
Cj4gUHJhY3RpY2VzCj4gQWdpbGUgJiBQbGFuLURyaXZlbiBEZXZlbG9wbWVudCAqIE1hbmFnaW5n
IFByb2plY3RzICYgVGVhbXMgKiBUZXN0aW5nICYgUUEgCj4gCj4gU2VjdXJpdHkgKiBQcm9jZXNz
IEltcHJvdmVtZW50ICYgTWVhc3VyZW1lbnQgKiBodHRwOi8vd3d3LnNxZS5jb20vYnNjZTVzZgo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gY3gtb3Jh
Y2xlLXVzZXJzIG1haWxpbmcgbGlzdAo+IGN4LW9yYWNsZS11c2Vyc0BsaXN0cy5zb3VyY2Vmb3Jn
ZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9jeC1v
cmFjbGUtdXNlcnMKPiAKCgoKLS0gCkdhcnJpY2sgV2Vsc2gKClRoZSBodW1hbiByYWNlIGlzIGEg
cmFjZSBvZiBjb3dhcmRzOyBhbmQgSSBhbSBub3Qgb25seSBtYXJjaGluZyBpbiB0aGF0CnByb2Nl
c3Npb24gYnV0IGNhcnJ5aW5nIGEgYmFubmVyLgotLSBNYXJrIFR3YWluCg==

Re: [cx-oracle-users] unicode characters and cx_Oracle.

[Marcos P. <ma...@bu...>]

This is an incomplete chunk of one of my programs:
codPythonOracle=3D{
    'WE8ISO8859P1':'iso-8859-1',
    'WE8ISO8859P15':'iso-8859-15',
    'WE8MSWIN1252':'cp1252',
}

class LectorEsquema(fis.LectorEsquemaFisico):
    def lookupDesc(self,sql):
        if isinstance(sql, unicode):
            sql=3Dsql.encode(self.codificacion)
        return fis.LectorEsquemaFisico.lookupDesc(self,sql)
    def login(self):
        self.con=3Ddbapi.connect(self.usuario, self.clave, self.dsn, )
        sqlCodOracle=3D'''select value=20
            from v$nls_parameters=20
            where parameter =3D 'NLS_CHARACTERSET' '''
        codOracle=3Dself.lookup(sqlCodOracle)[0][0]
        self.codificacion=3DcodPythonOracle[codOracle]

I don't have the time to prepare an example, but you can extract the
information, I hope.

* The first time you login, you get the default db encoding.
* Then you translate what you get into Python (fill in what you get if
it is not in the dict).
* Whenever you receive an unicode string, translate into the needed
encoding (both the sql and the parameters) before sending it to Oracle.
* Whenever you receive a string, decode it using the same encoding, to
work internally in Unicode.

I hope it helps. This should be done by the cx libs, I guess.

El lun, 22-08-2005 a las 13:40 +1000, Garrick Welsh escribi=C3=B3:
> I have the following problem. I have a utf-8 encoded string, that is
> to be inserted into an Oracle DB using cx_Oracle.
>=20
> Now cx_Oracle appears to be configured to do a character translation
> of some description on this string. Is there anyway I could insert the
> unicode equivalent string? (i.e. udata =3D unicode(data, "utf-8"))
> instead of a regular character string into the database? If not is
> there a way to configure the encoding type that cx_Oracle expects...
>=20
>     Garrick
>=20
> --=20
> Garrick Welsh
>=20
> The human race is a race of cowards; and I am not only marching in
> that
> procession but carrying a banner.
>                 -- Mark Twain
--=20
Marcos S=C3=A1nchez Provencio <ma...@bu...>

[cx-oracle-users] unicode characters and cx_Oracle.

[Garrick W. <gar...@gm...>]

I have the following problem. I have a utf-8 encoded string, that is to be=
=20
inserted into an Oracle DB using cx_Oracle.

Now cx_Oracle appears to be configured to do a character translation of som=
e=20
description on this string. Is there anyway I could insert the unicode=20
equivalent string? (i.e. udata =3D unicode(data, "utf-8")) instead of a=20
regular character string into the database? If not is there a way to=20
configure the encoding type that cx_Oracle expects...

Garrick

--=20
Garrick Welsh

The human race is a race of cowards; and I am not only marching in that
procession but carrying a banner.
-- Mark Twain

RE: [cx-oracle-users] Session Pooling

[Orr, S. <so...@ri...>]

> Try "select user from dual" on your established connection...
Here's what I found. The cx_Oracle.connect() method accepts credential
args as well as a pool arg. If you supply the pool arg you don't have to
supply the credentials but if you do they are ignored as all connections
use the credentials given when SessionPool is instantiated. This means
you have to establish separate pools for each distinct Oracle username
if you want to pool their connections.=20

> In general I have used the pool to acquire connections...
I'm establishing connections through my dbfun class. This way, if I
decide later to pool the connections for a particular user I don't have
to change the code outside my class. Also, I don't need to know if they
are in the pool as Connection.close() works regardless of pool status.
The valuable connection pooling enhancement only required a little extra
code.=20
-----------------------------------------------------------------
class myConnection(cx_Oracle.Connection):
    def __init__(self, *args, **kwargs):
        cx_Oracle.Connection.__init__(self, *args, **kwargs)
        self.pool =3D kwargs.get('pool',None)
    def close(self):
        if self.pool: self.pool.release(self)
        else: super(myConnection, self).close()

class dbfun(object):
    def __init__(self):
        self.pool=3DmySessionPool(user=3D'name', password=3D'pw', =
dsn=3D'local',
                                min=3D2, max=3D16, increment=3D2)
    def connect(self, *args, **kwargs):
        if kwargs.get('user','NoUser') =3D=3D 'name':
            kwargs.setdefault('pool', self.pool)
        return myConnection(*args, **kwargs)
-----------------------------------------------------------------

Thanks,
Steve Orr
Bozeman, Montana... A little South of Canada :-)


-----Original Message-----
From: cx-...@li...
[mailto:cx-...@li...] On Behalf Of
Anthony Tuininga
Sent: Tuesday, August 02, 2005 7:40 AM
To: cx-...@li...
Subject: Re: [cx-oracle-users] Session Pooling

Exceeding the session limit should raise an exception (that is what
the code in cx_Oracle instructs Oracle to do) but there is a bug in
Oracle right now that causes that particular flag to be ignored. I'm
not sure if its fixed in Oracle 10g yet but I don't think so.

In general I have used the pool to acquire connections rather than
using the Connection class directly. In other words,

connection  =3D pool.acquire()

which is a little simpler than the code you indicated you are using.
:-) It also demonstrates why I've never run into the possibility of
using connections with different credentials than those established by
the pool. Are you certain that the credentials are actually different
on the established connection? The code in cx_Oracle automatically
calls pool.acquire() when a pool is passed in to the Connection
constructor. Try "select user from dual" on your established
connection.

Session pooling automatically implements statement caching and
cx_Oracle doesn't give you an option for turning it off at the moment.
As such no examples are needed. :-) If you are talking about caching
cursors in general then a simple dictionary suffices and in general
can save 15-20% if you are executing a lot of small singleton
query/insert/update/delete statements. You simply need to do the
following:

cursor =3D connection.cursor()
cursor.prepare(some_sql)

and then put that cursor in the cache. When you want to use it

cursor.execute(None, args)

Hope that helps.

On 8/1/05, Orr, Steve <so...@ri...> wrote:
> I'm looking to use session pooling for performance (Apache 2.0,
> mod_python, Quixote 2.0, cx_Oracle 4.x Oracle9). Here's some code for
> reference:
> import cx_Oracle
> class dbconnect(cx_Oracle.Connection):
>     def __init__(self, user=3DNone, password=3DNone, dsn=3DNone, =
pool=3DNone):
>         cx_Oracle.Connection.__init__(self, user=3Duser,
> password=3Dpassword,
>                                       dsn=3Ddsn, pool=3Dpool)
>         self.pool =3D pool
>     def close(self):
>         self.pool.release(self)
> class dbfun(object):
>     def __init__(self):
>         self.pool =3D cx_Oracle.SessionPool('user', 'pw', 'local', 1, =
8,
> 1)
>         self.pool.timeout =3D 30
>     def connect(self, user, password, dsn):
>         conn =3D dbconnect(user=3Duser, password=3Dpassword,
>                          dsn=3Ddsn, pool=3Dself.pool)
>         return conn
>=20
> Basically I subclassed the cx_Oracle connection object to over-ride
the
> close function to release a connection to the pool instead of closing
> it.
>=20
> Observations and Questions:
> Setting the timeout attribute doesn't seem to change anything, no
> connections are returned to the pool after 30 seconds. Is this a bug
or
> am I doing something wrong?
>=20
> If I exceed the session limit from Python it just hangs... Shouldn't
> cx_Oracle.Connection return an exception? Do I really HAVE to compare
> pool.busy and pool.opened in my code and raise my own exception?
>=20
> I found that if I kill a session from SQL*Plus it does not become
> available to the pool. Well okay.
>=20
> I found that when connecting through my dbfun class I could connect
with
> a different user/password than was established in the pool. What are
the
> ramifications of this? If I want to pool connections from different
> users do I need to create distinct pools for each user ID?
>=20
> Are there any other suggestions or sample code on how to implement
> connection pooling? Has anyone cached cursors and is it worth it?
>=20
> TIA,
> Steve Orr

Re: [cx-oracle-users] Session Pooling

[Anthony T. <ant...@gm...>]

On 8/1/05, Orr, Steve <so...@ri...> wrote:
> So long without answers? Are my questions too hard?  :-)

No. Just a long weekend here in Canada. :-)

> I was wrong about the SessionPool.timeout attribute. It works just fine.
> I can configure the number of processes which Apache spawns and even
> though each process establishes a reusable pool of database connections
> they level off with inactivity and scale up when needed. Pooling
> connections with cx_Oracle/Apache/mod_python serves up data driven web
> pages really FAST!

Sounds good.

> I'm still wondering about the ramifications of adding connections with
> different credentials than what the session pool was created with.

See earlier e-mail.

> I'd also like to get some feedback on caching cursors. It seems like I
> saw some code for that in the cx utilities or whatever. I'm just
> wondering how much coding effort is required and what's the benefit?

See earlier e-mail.

> Steve Orr
>=20
>=20
> -----Original Message-----
> From: cx-...@li...
> [mailto:cx-...@li...] On Behalf Of Orr,
> Steve
> Sent: Monday, August 01, 2005 11:28 AM
> To: cx-...@li...
> Subject: [cx-oracle-users] Session Pooling
>=20
> I'm looking to use session pooling for performance (Apache 2.0,
> mod_python, Quixote 2.0, cx_Oracle 4.x Oracle9). Here's some code for
> reference:
> import cx_Oracle
> class dbconnect(cx_Oracle.Connection):
>     def __init__(self, user=3DNone, password=3DNone, dsn=3DNone, pool=3DN=
one):
>         cx_Oracle.Connection.__init__(self, user=3Duser,
> password=3Dpassword,
>                                       dsn=3Ddsn, pool=3Dpool)
>         self.pool =3D pool
>     def close(self):
>         self.pool.release(self)
> class dbfun(object):
>     def __init__(self):
>         self.pool =3D cx_Oracle.SessionPool('user', 'pw', 'local', 1, 8,
> 1)
>         self.pool.timeout =3D 30
>     def connect(self, user, password, dsn):
>         conn =3D dbconnect(user=3Duser, password=3Dpassword,
>                          dsn=3Ddsn, pool=3Dself.pool)
>         return conn
>=20
> Basically I subclassed the cx_Oracle connection object to over-ride the
> close function to release a connection to the pool instead of closing
> it.
>=20
> Observations and Questions:
> Setting the timeout attribute doesn't seem to change anything, no
> connections are returned to the pool after 30 seconds. Is this a bug or
> am I doing something wrong?
>=20
> If I exceed the session limit from Python it just hangs... Shouldn't
> cx_Oracle.Connection return an exception? Do I really HAVE to compare
> pool.busy and pool.opened in my code and raise my own exception?
>=20
> I found that if I kill a session from SQL*Plus it does not become
> available to the pool. Well okay.
>=20
> I found that when connecting through my dbfun class I could connect with
> a different user/password than was established in the pool. What are the
> ramifications of this? If I want to pool connections from different
> users do I need to create distinct pools for each user ID?
>=20
> Are there any other suggestions or sample code on how to implement
> connection pooling? Has anyone cached cursors and is it worth it?
>=20
> TIA,
> Steve Orr
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>