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

[cx-oracle-users] RE: strange character encoding problems

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

Ahmm, might be a dumb question,
but have you checked your environment variables
and (on Windows) Oracle Regstry keys?

In particular, how is NLS_LANG set?
If the character set in NLS_LANG differs from that
used in the database, then Oracle will convert characters.
If the character set are equal, Oracle will pass all
characters AS IS, and your program can even use characters
that are not defined at all in the character set.

Henning

> -----Urspr=FCngliche Nachricht-----
> Von: cx-...@li...
> [mailto:cx-...@li...]Im Auftrag von
> cx-...@li...
> Gesendet: Dienstag, 31. Januar 2006 05:01
> An: cx-...@li...
> Betreff: cx-oracle-users digest, Vol 1 #193 - 2 msgs
>=20
>=20
> Send cx-oracle-users mailing list submissions to
> 	cx-...@li...
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> or, via email, send a message with subject or body 'help' to
> 	cx-...@li...
>=20
> You can reach the person managing the list at
> 	cx-...@li...
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cx-oracle-users digest..."
>=20
>=20
> Today's Topics:
>=20
>    1. RE: strange character encoding problems (Amaury Forgeotdarc)
>    2. Re: strange character encoding problems (Marcus Eggenberger)
>=20
> --__--__--
>=20
> Message: 1
> Subject: RE: [cx-oracle-users] strange character encoding problems
> Date: Mon, 30 Jan 2006 09:31:40 +0100
> From: "Amaury Forgeotdarc" <Ama...@gl...>
> To: <cx-...@li...>
> Reply-To: cx-...@li...
>=20
> Hello,
>=20
> Marcus Eggenberger wrote:
> > I am not able to store characters of the latin-1 charset in my=3D20
> > oracle-database. I've encoded them according to=20
> NLS_CHARACTERSET but=3D20
> > that doesn't help.
> > I'm running Oracle 10g XE, Python 2.4.1 and cx_Oracle 4.1
> >=3D20
> > Here is some sample code which shows the very strange results:
> >=3D20
> >=3D20
> > #!/usr/bin/python=3D20
> >=3D20
> > # -*- coding: iso-8859-1 -*-=3D20
> >=3D20
> > import cx_Oracle
> >=3D20
> > db =3D3D cx_Oracle.connect('TESTUSER/TESTPASSWORD@localhost')
> > c =3D3D db.cursor()
> >=3D20
> > query =3D3D unicode("SELECT '=3DE4=3DF6=3DFC' FROM dual", =
'iso-8859-1')
> > charsets =3D3D ['iso-8859-1', 'cp1252', 'utf-8', 'utf-16']
> >=3D20
> > c.execute('SELECT * FROM V$NLS_PARAMETERS')
> > for row in c:
> >      print row
> >=3D20
> > for charset in charsets:
> >      try:
> >          c.execute(query.encode(charset))
> >      except cx_Oracle.Error, err:
> >          print err
> >      else:
> >          print charset, c.fetchone()[0]
> >=3D20
> > c.close()
> > db.close()
>=20
> I tried the same script, and I get correct results on my database
> for the first two charsets, as expected.
>=20
> Did you check that your database can handle latin-1 characters?
> Take a look at NLS_CHARACTERSET in the NLS_DATABASE_PARAMETERS view.
>=20
> Another thing: the -*- coding -*- line is not correctly placed.
> It must be the first or second line of the script.
> I don't know if this makes the difference.
>=20
> --=3D20
> Amaury Forgeot d'Arc
> Ubix Development
> www.ubitrade.com
>=20
>=20
> --__--__--
>=20
> Message: 2
> Date: Mon, 30 Jan 2006 12:50:29 +0100
> From: Marcus Eggenberger <i...@eg...>
> To:  cx-...@li...
> Subject: Re: [cx-oracle-users] strange character encoding problems
> Reply-To: cx-...@li...
>=20
> Hi,
>=20
> thanks for the reply.
>=20
> Amaury Forgeotdarc wrote:
> > Hello,
> >=20
> > Marcus Eggenberger wrote:
> >=20
> >>I am not able to store characters of the latin-1 charset in my=20
> >>oracle-database. I've encoded them according to=20
> NLS_CHARACTERSET but=20
> >>that doesn't help.
> >>I'm running Oracle 10g XE, Python 2.4.1 and cx_Oracle 4.1
> >>
> >>Here is some sample code which shows the very strange results:
> >>
> >>
> >>#!/usr/bin/python=20
> >>
> >># -*- coding: iso-8859-1 -*-=20
> >>
> >>import cx_Oracle
> >>>=20
> >=20
> > I tried the same script, and I get correct results on my database
> > for the first two charsets, as expected.
> >=20
> Darn, I really hoped my code would be wrong...
>=20
> > Did you check that your database can handle latin-1 characters?
> > Take a look at NLS_CHARACTERSET in the NLS_DATABASE_PARAMETERS view.
> >=20
> The Output of NLS_DATABASE_PARAMETERS is the very same as=20
> V$NLS_PARAMETERS.
> NLS_CHARACTERSET: WE8MSWIN1252
> NLS_NCHAR_CHARACTERSET: AL16UTF16
>=20
> > Another thing: the -*- coding -*- line is not correctly placed.
> > It must be the first or second line of the script.
> > I don't know if this makes the difference.
> >=20
> In my sources the line was right beneath the shebang line. Otherwise=20
> python would have raised an Warning.
>=20
> What's strange too:
> When I insert a latin-1 character via the oracle htmldb, it is stored=20
> correctly. Since it shows up correctly in the htmldb object browser.
> But when I'm reading this value via my python script the=20
> umlauts are gone.
> This means: =E4 -> a, =F6 -> o, =FC -> u
>=20
> I'm totally lost with this one.
> Any other Ideas?
>=20
> Kind regards,
> Marcus
>=20
>=20
>=20
> --__--__--
>=20
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>=20
>=20
> End of cx-oracle-users Digest
>=20

Re: [cx-oracle-users] strange character encoding problems

[Marcus E. <i...@eg...>]

Hi,

thanks for the reply.

Amaury Forgeotdarc wrote:
> Hello,
> 
> Marcus Eggenberger wrote:
> 
>>I am not able to store characters of the latin-1 charset in my 
>>oracle-database. I've encoded them according to NLS_CHARACTERSET but 
>>that doesn't help.
>>I'm running Oracle 10g XE, Python 2.4.1 and cx_Oracle 4.1
>>
>>Here is some sample code which shows the very strange results:
>>
>>
>>#!/usr/bin/python 
>>
>># -*- coding: iso-8859-1 -*- 
>>
>>import cx_Oracle
>>> 
> 
> I tried the same script, and I get correct results on my database
> for the first two charsets, as expected.
> 
Darn, I really hoped my code would be wrong...

> Did you check that your database can handle latin-1 characters?
> Take a look at NLS_CHARACTERSET in the NLS_DATABASE_PARAMETERS view.
> 
The Output of NLS_DATABASE_PARAMETERS is the very same as V$NLS_PARAMETERS.
NLS_CHARACTERSET: WE8MSWIN1252
NLS_NCHAR_CHARACTERSET: AL16UTF16

> Another thing: the -*- coding -*- line is not correctly placed.
> It must be the first or second line of the script.
> I don't know if this makes the difference.
> 
In my sources the line was right beneath the shebang line. Otherwise 
python would have raised an Warning.

What's strange too:
When I insert a latin-1 character via the oracle htmldb, it is stored 
correctly. Since it shows up correctly in the htmldb object browser.
But when I'm reading this value via my python script the umlauts are gone.
This means: ä -> a, ö -> o, ü -> u

I'm totally lost with this one.
Any other Ideas?

Kind regards,
Marcus

RE: [cx-oracle-users] strange character encoding problems

[Amaury F. <Ama...@gl...>]

Hello,

Marcus Eggenberger wrote:
> I am not able to store characters of the latin-1 charset in my=20
> oracle-database. I've encoded them according to NLS_CHARACTERSET but=20
> that doesn't help.
> I'm running Oracle 10g XE, Python 2.4.1 and cx_Oracle 4.1
>=20
> Here is some sample code which shows the very strange results:
>=20
>=20
> #!/usr/bin/python=20
>=20
> # -*- coding: iso-8859-1 -*-=20
>=20
> import cx_Oracle
>=20
> db =3D cx_Oracle.connect('TESTUSER/TESTPASSWORD@localhost')
> c =3D db.cursor()
>=20
> query =3D unicode("SELECT '=E4=F6=FC' FROM dual", 'iso-8859-1')
> charsets =3D ['iso-8859-1', 'cp1252', 'utf-8', 'utf-16']
>=20
> c.execute('SELECT * FROM V$NLS_PARAMETERS')
> for row in c:
>      print row
>=20
> for charset in charsets:
>      try:
>          c.execute(query.encode(charset))
>      except cx_Oracle.Error, err:
>          print err
>      else:
>          print charset, c.fetchone()[0]
>=20
> c.close()
> db.close()

I tried the same script, and I get correct results on my database
for the first two charsets, as expected.

Did you check that your database can handle latin-1 characters?
Take a look at NLS_CHARACTERSET in the NLS_DATABASE_PARAMETERS view.

Another thing: the -*- coding -*- line is not correctly placed.
It must be the first or second line of the script.
I don't know if this makes the difference.

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

[cx-oracle-users] strange character encoding problems

[Marcus E. <eg...@di...>]

I am not able to store characters of the latin-1 charset in my 
oracle-database. I've encoded them according to NLS_CHARACTERSET but 
that doesn't help.
I'm running Oracle 10g XE, Python 2.4.1 and cx_Oracle 4.1

Here is some sample code which shows the very strange results:


#!/usr/bin/python 

# -*- coding: iso-8859-1 -*- 

import cx_Oracle

db = cx_Oracle.connect('TESTUSER/TESTPASSWORD@localhost')
c = db.cursor()

query = unicode("SELECT 'äöü' FROM dual", 'iso-8859-1')
charsets = ['iso-8859-1', 'cp1252', 'utf-8', 'utf-16']

c.execute('SELECT * FROM V$NLS_PARAMETERS')
for row in c:
     print row

for charset in charsets:
     try:
         c.execute(query.encode(charset))
     except cx_Oracle.Error, err:
         print err
     else:
         print charset, c.fetchone()[0]

c.close()
db.close()

=======================================================
OUTPUT:

python charsettest.py
('NLS_LANGUAGE', 'AMERICAN')
('NLS_TERRITORY', 'AMERICA')
('NLS_CURRENCY', '$')
('NLS_ISO_CURRENCY', 'AMERICA')
('NLS_NUMERIC_CHARACTERS', '.,')
('NLS_CALENDAR', 'GREGORIAN')
('NLS_DATE_FORMAT', 'DD-MON-RR')
('NLS_DATE_LANGUAGE', 'AMERICAN')
('NLS_CHARACTERSET', 'WE8MSWIN1252')
('NLS_SORT', 'BINARY')
('NLS_TIME_FORMAT', 'HH.MI.SSXFF AM')
('NLS_TIMESTAMP_FORMAT', 'DD-MON-RR HH.MI.SSXFF AM')
('NLS_TIME_TZ_FORMAT', 'HH.MI.SSXFF AM TZR')
('NLS_TIMESTAMP_TZ_FORMAT', 'DD-MON-RR HH.MI.SSXFF AM TZR')
('NLS_DUAL_CURRENCY', '$')
('NLS_NCHAR_CHARACTERSET', 'AL16UTF16')
('NLS_COMP', 'BINARY')
('NLS_LENGTH_SEMANTICS', 'BYTE')
('NLS_NCHAR_CONV_EXCP', 'FALSE')
iso-8859-1 ???
cp1252 ???
utf-8 ??????
ORA-00911: invalid character


As you can see either encoding returns only questionmarks.
Any thoughts about this?

[cx-oracle-users] BoffinSQL for Oracle Press Release

[<mor...@bo...>]

PGh0bWw+Cgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0
ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIj4KPHRpdGxlPlJlPC90aXRsZT4KPHN0eWxl
Pgo8IS0tCiBwLk1zb05vcm1hbAoJe21zby1zdHlsZS1wYXJlbnQ6IiI7CgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7Cglmb250LXNpemU6MTIuMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h
biI7CgltYXJnaW4tbGVmdDowY207IG1hcmdpbi1yaWdodDowY207IG1hcmdpbi10b3A6MGNtfQpo
MQoJe21hcmdpbi1ib3R0b206LjAwMDFwdDsKCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7Cglmb250
LXNpemU6MTguMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Cglmb250LXdlaWdo
dDpub3JtYWw7IG1hcmdpbi1sZWZ0OjBjbTsgbWFyZ2luLXJpZ2h0OjBjbTsgbWFyZ2luLXRvcDow
Y219CmgyCgl7bWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsK
CWZvbnQtc2l6ZTozNi4wcHQ7Cglmb250LWZhbWlseToiUGFnb2RhIFNGIjsKCWNvbG9yOm5hdnk7
Cglmb250LXdlaWdodDpub3JtYWw7IG1hcmdpbi1sZWZ0OjBjbTsgbWFyZ2luLXJpZ2h0OjBjbTsg
bWFyZ2luLXRvcDowY219Ci0tPgo8L3N0eWxlPgo8L2hlYWQ+Cgo8Ym9keT4KCjxoMSBhbGlnbj0i
Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjogY2VudGVyIj48Yj4KPHNwYW4gbGFuZz0iRU4tR0Ii
IHN0eWxlPSJmb250LXNpemU6IDIwLjBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSI+UFJFU1MgUkVM
RUFTRTwvc3Bhbj48L2I+PC9oMT4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg
c3R5bGU9InRleHQtYWxpZ246IGNlbnRlciI+CjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u
dC1zaXplOiAxNi4wcHQiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8aDIgYWxpZ249ImNlbnRlciIgc3R5
bGU9InRleHQtYWxpZ246IGNlbnRlciI+PHNwYW4gbGFuZz0iRU4tR0IiPkJvZmZpblNRTCBmb3Ig
Ck9yYWNsZTwvc3Bhbj48L2gyPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H
QiIgc3R5bGU9ImZvbnQtc2l6ZTogMTYuMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTogMTZw
dCI+Qm9mZmluIApBc3NvY2lhdGVzIGFyZSBwbGVhc2VkIHRvIGFubm91bmNlIHRoZSBsYXVuY2gg
b2YgQm9mZmluU1FMIGZvciBPcmFjbGWuIHdoaWNoIApzaW1wbGlmaWVzIHRoZSBwcm9jZXNzIG9m
IGdldHRpbmcgZGF0YSBmcm9tIE9yYWNsZSBkYXRhYmFzZXMgaW50byBtYW5hZ2VtZW50IApyZXBv
cnRzLiZuYnNwOyA8L2ZvbnQ+IDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOiAxNi4wcHQiPiZuYnNwOzwvc3Bhbj48L3A+
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBqdXN0aWZ5Ij4KPHNwYW4g
bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6IDE2LjBwdCI+QnkgZW5hYmxpbmcgc2ltcGxl
IGRvd25sb2FkIG9mIGRhdGEgCmludG8gYSByYW5nZSBvZiBmb3JtYXRzIGluY2x1ZGluZyBFeGNl
bCCuLCBBY2Nlc3MgriwgbmV3IG1hbmFnZW1lbnQgcmVwb3J0cyBjYW4gCmJlIHF1aWNrbHkgZGV2
ZWxvcGVkIGFuZCBhdXRvbWF0ZWQgYnkgbm9uLW9yYWNsZSB1c2VycyB3aG8gd2lsbCBvbmx5IG5l
ZWQgCmFzc2lzdGFuY2Ugd2l0aCB0aGUgU1FMLiA8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0idGV4dC1hbGlnbjoganVzdGlmeSI+CjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls
ZT0iZm9udC1zaXplOiAxNi4wcHQiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBqdXN0aWZ5Ij4KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl
PSJmb250LXNpemU6IDE2LjBwdCI+Rm9yIElUIGRlcGFydG1lbnRzIEJvZmZpblNRTCAKY3JlYXRl
cyBjb3N0ICZhbXA7IHRpbWUgc2F2aW5ncyBieSBub3QgaGF2aW5nIHRvIHdhc3RlIHRpbWUgZGV2
ZWxvcGluZyBncmFwaGljYWwgCnJlcG9ydHMuIEFsbCB0aGV5IG5lZWQgdG8gcHJvdmlkZSBzaW1w
bHkgaXMgdGhlIFNRTCB3aGljaCB3aWxsIGVuYWJsZSB0aGUgdXNlciAKdG8gZ2V0IGEgcG9ydGFi
bGUgZGF0YSBleHRyYWN0LCBnaXZpbmcgdGhlbSBlYXN5IGFjY2VzcyB0byB0aGUgZGF0YSB0aGV5
IG5lZWQgaW4gCmEgZmFtaWxpYXIgZm9ybWF0IHdoaWNoIHRoZXkgY2FuIHVzZSBhbmQgbWFuaXB1
bGF0ZS4gVGhpcyBtZWFucyB0aGF0IEJvZmZpblNRTCAKcHJvdmlkZXMgdGhlIGFiaWxpdHkgdG8g
c3VwcGx5IHRhY3RpY2FsIGluZm9ybWF0aW9uIHF1aWNrbHkgYW5kIGVhc2lseSwgd2hpY2ggCmNh
biB0aGVuIGJlIHVzZWQgdG8gcHJvdG90eXBlIHN0cmF0ZWdpYyBzb2x1dGlvbnMuPC9zcGFuPjwv
cD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBqdXN0aWZ5Ij4KPHNw
YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6IDE2LjBwdCI+Jm5ic3A7PC9zcGFuPjwv
cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246IGp1c3RpZnkiPgo8c3Bh
biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTogMTYuMHB0Ij5Gb3IgdGhlIGRlcGFydG1l
bnRhbCBtYW5hZ2VyIApCb2ZmaW5TUUwgcHJvdmlkZXMgYSBzaW1wbGUsIGVmZmVjdGl2ZSBhbmQg
bG9zdCBjb3N0IHNvbHV0aW9uIGZvciBkZWxpdmVyaW5nIAppbmZvcm1hdGlvbiBmcm9tIE9yYWNs
ZSBkYXRhYmFzZXMgdG8gaW5kaXZpZHVhbHMgaW4gdGhlIGZvcm1hdCBvZiB0aGVpciBjaG9pY2Uu
Jm5ic3A7IApUaGUgZGVsaXZlcnkgb2YgdGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgYXV0b21hdGVk
IG9uIGEgcmVndWxhciBiYXNpcyB0byBhbnl3aGVyZSAKaW4gdGhlIHdvcmxkLiBCeSB1c2luZyB0
aGVpciBvd24gcHJlZmVycmVkIHByZXNlbnRhdGlvbiB0b29scywgcmVwb3J0cyBjYW4gYmUgCmNo
YW5nZWQgcXVpY2tseSBhbmQgZWFzaWx5IGJ5IHRoZSBkZXBhcnRtZW50YWwgcmVwb3J0IG93bmVy
cyBhcyB3ZWxsIGFzIAphZGRpdGlvbmFsIGRhdGEgYW5hbHlzaXMsIHJhdGhlciB0aGFuIHdhaXRp
bmcgZm9yIGZvcm1hbCBkZXZlbG9wbWVudCBvZiBjaGFuZ2VzIApieSB0aGUgSVQgZGVwYXJ0bWVu
dC48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5
bGU9ImZvbnQtc2l6ZTogMTYuMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjogY2VudGVyIj4KPHNwYW4gbGFu
Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6IDE2LjBwdCI+Rm9yIGEgZnJlZSB0cmlhbCBjb3B5
IHRoYXQgd29ya3MgCmZvciAyNSBkYXlzIHBsZWFzZSB2aXNpdAo8YSBzdHlsZT0iY29sb3I6IGJs
dWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyB0ZXh0LXVuZGVybGluZTogc2luZ2xlIiBo
cmVmPSJodHRwOi8vd3d3LmJvZmZpbi5vcmcudWsvIj4Kd3d3LmJvZmZpbi5vcmcudWs8L2E+PC9z
cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt
YWxpZ246IGNlbnRlciI+CiZuYnNwOzwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl
bnRlciIgc3R5bGU9InRleHQtYWxpZ246IGNlbnRlciI+CjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDE2cHQiPkZvciBhIGJyb2NodXJlIDwvc3Bhbj48c3BhbiBsYW5nPSJlbi1nYiI+PHU+Cgo8Zm9u
dCBjb2xvcj0iIzAwMDBGRiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTZwdCI+CjxhIGhyZWY9
Imh0dHA6Ly93d3cuYm9mZmluLm9yZy51ay9Cb2ZmaW4vRU5HTElTSC9Cb2ZmaW5Ccm9jaHVyZS5w
ZGYiPgpodHRwOi8vd3d3LmJvZmZpbi5vcmcudWsvQm9mZmluL0VOR0xJU0gvQm9mZmluQnJvY2h1
cmUucGRmPC9hPjwvc3Bhbj48L2ZvbnQ+PC91Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOiAxNi4wcHQiPiZuYnNwOzwv
c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiPgo8c3BhbiBsYW5n
PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTogMTYuMHB0Ij5Gb3IgZnVydGhlciBpbmZvcm1hdGlv
biBwbGVhc2UgCmNvbnRhY3QgdXMgYXQKPGEgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29y
YXRpb246IHVuZGVybGluZTsgdGV4dC11bmRlcmxpbmU6IHNpbmdsZSIgaHJlZj0ibWFpbHRvOm1v
cmVpbmZvQGJvZmZpbi5vcmcudWsiPgptb3JlaW5mb0Bib2ZmaW4ub3JnLnVrPC9hPjwvc3Bhbj48
L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu
OiBjZW50ZXIiPgo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0Ij4m
bmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0idGV4dC1hbGlnbjogY2VudGVyIj4KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp
emU6IDEwLjBwdCI+T3JhY2xlIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgCnRoZSBPcmFj
bGUgQ29ycG9yYXRpb248L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0idGV4dC1hbGlnbjogY2VudGVyIj4KCjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls
ZT0iZm9udC1zaXplOiAxMC4wcHQiPkV4Y2VsIGFuZCBBY2Nlc3MgYXJlIHJlZ2lzdGVyZWQgCnRy
YWRlbWFya3Mgb2YgdGhlIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbjwvc3Bhbj48L3A+CjxwIGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXIiPgom
bmJzcDs8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiPjxmb250IHNpemU9
IjIiPlRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyAKbWFpbGluZyBsaXN0IHBsZWFzZSBzZW5kIGEg
bWFpbCB0byA8L2ZvbnQ+CjxhIGhyZWY9Im1haWx0bzp1bnN1YnNjcmliZUBib2ZmaW4ub3JnLnVr
Ij48Zm9udCBzaXplPSIyIj4KdW5zdWJzY3JpYmVAYm9mZmluLm9yZy51azwvZm9udD48L2E+PC9w
PgoKPC9ib2R5PgoKPC9odG1sPgo=

Re: [cx-oracle-users] Choosing client libraries

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

On 1/27/06, Paul Watson <pw...@re...> wrote:
> >  Ok, I can accept that the risks are reasonable. The only other
> >  difference in behavior that I can think of is that some of the current
> >  differences between OCI releases are based on #define constants --
> >  which are definitely not available in the dll. We will need to find
> >  some function that exists in one release and not in the other and use
> >  the presence of that function instead as a means of determining what
> >  client level is being used. Are you volunteering to find those??? :-)
> >  Are you volunteering to provide the template I should be using to try
> >  this? How eager are you to move down this path?
>
> How about using the VERSIONINFO from oci.dll?

That's only available on Windows. cx_Oracle does run on other
platforms -- what would you suggest for those platforms?

> I still do not understand your statement, Anthony, that cx_Oracle is link=
ed to a specific version of Oracle client.  I can use the same cx_Oracle wi=
th 10g and 8.1.7 by changing the PATH.  There are three components with "ve=
rsion" states.  If cx_Oracle executable does a static link to one version o=
f the Oracle client library, then how can I use the same cx_Oracle to conne=
ct with both 8.1.7 and 10g?

The binaries I am providing are indeed dynamically linked. As I have
stated elsewhere in this thread, on Windows Oracle has named the DLL
oci.dll so you can quite easily run modules compiled against __older__
Oracle clients in __newer__ Oracle clients without trouble. Running a
module compiled against __newer__ Oracle clients with an __older__
Oracle client does __NOT__ work because new methods are referenced in
the module and cannot be found in the dll. That's what I am referring
to. On Unix platforms Oracle chose to include the basic version in the
name of the shared library so you cannot mix and match there as
easily.

I believe this thread was supposed to be about removing even this
restriction by dynamically looking up the methods to see if they exist
-- currently that code is added automatically by the linker which is
what I was trying to say. Obviously I haven't been very clear. :-)
Hopefully this makes it clearer??

> cx_Oracle
> Oracle client
> Oracle database
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Choosing client libraries

[<pw...@re...>]

>  Ok, I can accept that the risks are reasonable. The only other
>  difference in behavior that I can think of is that some of the current
>  differences between OCI releases are based on #define constants --
>  which are definitely not available in the dll. We will need to find
>  some function that exists in one release and not in the other and use
>  the presence of that function instead as a means of determining what
>  client level is being used. Are you volunteering to find those??? :-)
>  Are you volunteering to provide the template I should be using to try
>  this? How eager are you to move down this path?

How about using the VERSIONINFO from oci.dll?

I still do not understand your statement, Anthony, that cx_Oracle is linked to a specific version of Oracle client.  I can use the same cx_Oracle with 10g and 8.1.7 by changing the PATH.  There are three components with "version" states.  If cx_Oracle executable does a static link to one version of the Oracle client library, then how can I use the same cx_Oracle to connect with both 8.1.7 and 10g?

cx_Oracle
Oracle client
Oracle database

Re: [cx-oracle-users] RE: Re: Choosing client libraries

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

On 1/26/06, Amaury Forgeotdarc <Ama...@gl...> wrote:
> Anthony Tuininga wrote:
> > What I meant is that shadow functions will have to be defined
> > which call the real functions. These will look very similar
> > to the ones defined in the Oracle include files. If/when such
> > things change those changes will have to be reflected. Note
> > that this technique assumes that Oracle __never__ changes or
> > removes their API for a particular function. They only add
> > functions. I'm not convinced this will always be the case
> > which makes this technique somewhat of a risk -- fairly low
> > but still a risk.
>
> The same risk already exists with every Oracle application,
> even when explicitely linked with a specific Oracle oci.lib,
> even the current cx_Oracle:
>
> When loading a DLL, Windows checks every function by its name,
> but has no way to check for the number or type of the arguments
> (unless they use the C++ call convention, which encodes the
> types in the function name).
>
> Actually, the "shadow functions" we are about to write are
> very close to the code embedded when linking with oci.lib.
>
> As long as there is a file named oci.dll, Oracle will have to
> ensure compatibility between releases.

Ok, I can accept that the risks are reasonable. The only other
difference in behavior that I can think of is that some of the current
differences between OCI releases are based on #define constants --
which are definitely not available in the dll. We will need to find
some function that exists in one release and not in the other and use
the presence of that function instead as a means of determining what
client level is being used. Are you volunteering to find those??? :-)
Are you volunteering to provide the template I should be using to try
this? How eager are you to move down this path?

> --
> Amaury Forgeot d'Arc
> Ubix Development
> www.ubitrade.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

RE: [cx-oracle-users] RE: Re: Choosing client libraries

[Amaury F. <Ama...@gl...>]

Anthony Tuininga wrote:
> What I meant is that shadow functions will have to be defined=20
> which call the real functions. These will look very similar=20
> to the ones defined in the Oracle include files. If/when such=20
> things change those changes will have to be reflected. Note=20
> that this technique assumes that Oracle __never__ changes or=20
> removes their API for a particular function. They only add=20
> functions. I'm not convinced this will always be the case=20
> which makes this technique somewhat of a risk -- fairly low=20
> but still a risk.

The same risk already exists with every Oracle application,
even when explicitely linked with a specific Oracle oci.lib,
even the current cx_Oracle:

When loading a DLL, Windows checks every function by its name,
but has no way to check for the number or type of the arguments
(unless they use the C++ call convention, which encodes the=20
types in the function name).

Actually, the "shadow functions" we are about to write are
very close to the code embedded when linking with oci.lib.

As long as there is a file named oci.dll, Oracle will have to=20
ensure compatibility between releases.

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

Re: [cx-oracle-users] RE: Re: Choosing client libraries

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

On 1/25/06, Amaury Forgeot d'Arc <ama...@gm...> wrote:
> Anthony wrote:
> > Ok. It sounds like a bunch of grunt work but nothing particularly
> > difficult. There is the necessity of "copying" the Oracle header files
>
> Not necessarily. You may require that compiling a cx_Oracle distribution
> needs the latest Oracle header files for the module to contain all featur=
es.
>
> Then, when installed on another machine, the module will silently
> disable some features if they do not match the Oracle version.

What I meant is that shadow functions will have to be defined which
call the real functions. These will look very similar to the ones
defined in the Oracle include files. If/when such things change those
changes will have to be reflected. Note that this technique assumes
that Oracle __never__ changes or removes their API for a particular
function. They only add functions. I'm not convinced this will always
be the case which makes this technique somewhat of a risk -- fairly
low but still a risk.

> > and there is the question of performance as well. Any thoughts on
> > those?
>
> Well, if the code is carefully written and uses inline functions,
> the overhead could be reduced to a simple check on a static
> variable.

True. The only overhead would be during import or first reference of a
particular function and that would be relatively small.

> --
> Amaury
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Choosing client libraries

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

On 1/25/06, Paul Watson <pw...@re...> wrote:
> How can I know, at runtime, with which version of Oracle libs my cx_Oracl=
e is linked?
>
> >>> print cx_Oracle.version
> HEAD
> >>> print cx_oracle.apilevel
> 2.0
> >>> print cx_oracle.buildtime
> January 26, 2005 14:37:48

You can't. I can guess by looking at the constants that are defined in
the header files but Oracle does not indicate what client version is
in use -- so it would only be a guess. BTW, the HEAD designation was
accidentally left in for cx_Oracle 4.1.1. If you get cx_Oracle 4.1.2
it will give you the correct version.

> I am confused by your statement that cx_Oracle is linked to a specific Or=
acle client.  If I have Oracle 8.1 client in the PATH when I run my Python =
script using cx_Oracle I can access an Oracle 8.1.7 running on an AIX box. =
 If I have the Oracle XE directory in the PATH, I can access the Oracle 10g=
 XE running on the local machine.

The version of the Oracle database to which you are connecting is not
the issue. Its the client version that matters. On Windows, the DLL
name is called oci.dll for all versions of Oracle so the link will
fail if and only if you use a cx_Oracle build for (for example) Oracle
10g and then try to actually run it with an Oracle 8i client. If you
have a cx_Oracle build for Oracle 8i you should be able to run it
successfully against Oracle 9i and Oracle 10g clients since Oracle is
usually fairly careful about their API. On Unix platforms the client
library is named libclntsh.so.<VERSION> and can be determined by using
ldd. Since the version is included in the name of the shared library
you cannot run cx_Oracle compiled against 8i with an Oracle 9i client.
Does that clear things up? Or make things even more confusing? :-)

> With respect to the suggestion that cx_Oracle have a set of redirection c=
alls to connect with the Oracle libs, I do not think that the overhead of a=
 function call will be significant.

Probably not -- especially if all of the function pointers are stored
in global memory so the effort of looking them up is only performed
once. I'm still uncertain as to whether the effort is worth it or
not....I'm still thinking about it. Any further input would be
appreciated.

> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Safely replacing a SessionPool after database restart?

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

The technique that we have been using is to simply replace the pool
after a database restart. Any existing connections acquired from the
pool will fail on the next attempt to do something, including the
attempt to release back to the pool. Note that when a connection is
garbage collected it is automatically returned to the correct pool.
You don't need to explicitly call pool.release() unless you want it to
happen before the connection is garbage collected. The safeguard of
ensuring that you are not trying to release the connection back to the
wrong pool should work -- but even if it does not, Oracle will give
you an error so I think you can rest easy on that one. Hope that
helps.

On 1/24/06, Forest Wilkinson [sf] <mo...@ti...> wrote:
> I'm trying to get my code to handle a database restart automatically,
> which turns out to be tricky when using a SessionPool.
>
> My first approach was to use SessionPool.drop() instead of release() when
> a dead connection was detected, but it turns out that drop() fails after =
a
> database restart.
>
> My second approach was to replace the SessionPool entirely when a dead
> connection was detected.  In order to keep any remaining old connections
> from being released to the new pool, I tried waiting for SessionPool.busy
> to reach 0 before doing the replacement.  Unfortunately, in practice, it
> never reached 0.  This was probably because release() fails with my dead
> connection, so it can never be returned to the pool.  In other words, a
> kind of deadlock.
>
> Out of curiosity, I tried deliberately releasing a connection to a
> SessionPool it didn't come from, to see how cx_Oracle would respond.  It
> raised a cx.ProgrammingError.  Is this safeguard guaranteed to work?  If
> so, I suppose I can replace my SessionPool as soon as a dead connection i=
s
> found, and rely on this safeguard to keep anything bad from happening whe=
n
> remaining old connections get returned to the new pool.
>
> Is there a better approach?
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Choosing client libraries

[<pw...@re...>]

How can I know, at runtime, with which version of Oracle libs my cx_Oracle is linked?  

>>> print cx_Oracle.version
HEAD
>>> print cx_oracle.apilevel
2.0
>>> print cx_oracle.buildtime
January 26, 2005 14:37:48

I am confused by your statement that cx_Oracle is linked to a specific Oracle client.  If I have Oracle 8.1 client in the PATH when I run my Python script using cx_Oracle I can access an Oracle 8.1.7 running on an AIX box.  If I have the Oracle XE directory in the PATH, I can access the Oracle 10g XE running on the local machine.

With respect to the suggestion that cx_Oracle have a set of redirection calls to connect with the Oracle libs, I do not think that the overhead of a function call will be significant.

[cx-oracle-users] RE: Re: Choosing client libraries

[Amaury F. d'A. <ama...@gm...>]

Anthony wrote:
> Ok. It sounds like a bunch of grunt work but nothing particularly
> difficult. There is the necessity of "copying" the Oracle header files

Not necessarily. You may require that compiling a cx_Oracle distribution
needs the latest Oracle header files for the module to contain all features=
.

Then, when installed on another machine, the module will silently
disable some features if they do not match the Oracle version.

> and there is the question of performance as well. Any thoughts on
> those?

Well, if the code is carefully written and uses inline functions,
the overhead could be reduced to a simple check on a static
variable.

--
Amaury

[cx-oracle-users] Safely replacing a SessionPool after database restart?

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

I'm trying to get my code to handle a database restart automatically, 
which turns out to be tricky when using a SessionPool.

My first approach was to use SessionPool.drop() instead of release() when 
a dead connection was detected, but it turns out that drop() fails after a 
database restart.

My second approach was to replace the SessionPool entirely when a dead 
connection was detected.  In order to keep any remaining old connections 
from being released to the new pool, I tried waiting for SessionPool.busy 
to reach 0 before doing the replacement.  Unfortunately, in practice, it 
never reached 0.  This was probably because release() fails with my dead 
connection, so it can never be returned to the pool.  In other words, a 
kind of deadlock.

Out of curiosity, I tried deliberately releasing a connection to a 
SessionPool it didn't come from, to see how cx_Oracle would respond.  It 
raised a cx.ProgrammingError.  Is this safeguard guaranteed to work?  If 
so, I suppose I can replace my SessionPool as soon as a dead connection is 
found, and rely on this safeguard to keep anything bad from happening when 
remaining old connections get returned to the new pool.

Is there a better approach?

Re: [cx-oracle-users] Re: Choosing client libraries

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

On 1/24/06, Amaury Forgeotdarc <Ama...@gl...> wrote:
> Anthony wrote:
> > To understand what I mean, try loading a cx_Oracle module compiled
> > against Oracle 9i with an Oracle 8i client. You will get a
> > messagebox indicating that the symbol OCISessionGet could
> > not be located in oci.dll. If you have a suggestion about how
> > to get around that problem __without__ involving a huge
> > rewrite of cx_Oracle to call everything dynamically I'm all ears.
>
> This is what I did some years ago with the old OCI7 function.
> At the time, it was the only way to have a program run with
> both Oracle7 and Oracle 8i, even if you use only functions
> that belong to both libraries.
>
> My solution is:
> - cx_Oracle does not link with any Oracle library.
> - instead, we provide an implementation for each OCI* function,
> which simply loads dynamically the Oracle client, bind the
> function, and call it.
> (I just counted 54 different OCI functions in cx_Oracle!)
>
> Below is a sample, for the old 'olog' function.
>
> This change would not touch any existing cx_Oracle file,
> Only one more file is compiled and linked with cx_Oracle.
>
> I think the same trick would also work on some other platforms.
> At the end, we could have a "dynamic" version of cx_Oracle!

Ok. It sounds like a bunch of grunt work but nothing particularly
difficult. There is the necessity of "copying" the Oracle header files
and there is the question of performance as well. Any thoughts on
those?

Anthony

RE: [cx-oracle-users] Re: Choosing client libraries

[Amaury F. <Ama...@gl...>]

Anthony wrote:
> To understand what I mean, try loading a cx_Oracle module compiled=20
> against Oracle 9i with an Oracle 8i client. You will get a=20
> messagebox indicating that the symbol OCISessionGet could=20
> not be located in oci.dll. If you have a suggestion about how=20
> to get around that problem __without__ involving a huge=20
> rewrite of cx_Oracle to call everything dynamically I'm all ears.

This is what I did some years ago with the old OCI7 function.
At the time, it was the only way to have a program run with=20
both Oracle7 and Oracle 8i, even if you use only functions=20
that belong to both libraries.

My solution is:
- cx_Oracle does not link with any Oracle library.
- instead, we provide an implementation for each OCI* function,
which simply loads dynamically the Oracle client, bind the
function, and call it.
(I just counted 54 different OCI functions in cx_Oracle!)

Below is a sample, for the old 'olog' function.

This change would not touch any existing cx_Oracle file,
Only one more file is compiled and linked with cx_Oracle.

I think the same trick would also work on some other platforms.
At the end, we could have a "dynamic" version of cx_Oracle!

-----------------------------

typedef sword (*OCIPROC)();
HINSTANCE hOCI =3D NULL;

// Find the OCI library
HINSTANCE check_dll()
{
  // This could be enhanced to choose the desired library
  if (!hOCI) hOCI =3D LoadLibrary("oci.dll");
  return hOCI;
}

// Load the OCI library and find the function
OCIPROC check_function(char *name, OCIPROC *fn)
{
  if( *fn ) return *fn;
  if( !check_dll() ) return NULL;
  *fn =3D (OCIPROC)GetProcAddress( hOCI, name );
  return *fn;
}

// All OCI functions must be written like this
sword olog(LDA *lda, ub1 *hda, text *uid, sword uidl,
text *pswd, sword pswdl, text *conn, sword connl, ub4 mode)
{
  static OCIPROC p_olog=3DNULL;
  if( check_function("olog", &p_olog))
    return p_olog(lda,hda,uid,uidl,pswd,pswdl,conn,connl,mode);
  else
    return 1; // error
}

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

Re: [cx-oracle-users] Re: Choosing client libraries

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

On 1/24/06, Paul Watson <pw...@re...> wrote:
> Anthony:
>
> Yes, I realize that this is very Windows specific.  I usually have Oracle=
 on Solaris or AIX, but you know which OS is on the client.  Developer tool=
s sometimes do Windows specific things because 1) there are so many of them=
 and 2) the Winodws user (and frequently Windows developers) are least like=
ly to be able to handle technical problems.

I understand this and have no fundamental objection to something very
OS specific if it solves a problem cleanly (this is a relative term
since cross platform issues are rarely clean). In this case, however,
I'm not sure there would be any benefit. See below.

> Is the source code of the external program part of the cx_Oracle kit?  If=
 so, would it be acceptable if I suggested a patch?  Any hints as to the mo=
st relevant filename(s) involved?

It is part of the cx_OracleDBATools project which is available at
http://starship.python.net/crew/atuining. Having such logic as part of
cx_Oracle would not very helpful, I believe. The reason is that
currently cx_Oracle is linked directly. In other words, the symbol
OCISessionGet in the library oci.dll is referenced directly in the
cx_Oracle source, not dynamically. To do what you suggest would
involve searching the directories as I suggested above looking for
which client version is currently installed and then dynamically link
at runtime (as opposed to compile time) to the relevant symbols. To
understand what I mean, try loading a cx_Oracle module compiled
against Oracle 9i with an Oracle 8i client. You will get a messagebox
indicating that the symbol OCISessionGet could not be located in
oci.dll. If you have a suggestion about how to get around that problem
__without__ involving a huge rewrite of cx_Oracle to call everything
dynamically I'm all ears. :-) That's why I suggested doing something
like the following in pure Python:

driver =3D None
drivers =3D [
        ("8i", "oraclient8.dll"),
        ("9i", "oraclient9.dll"),
        ("10g", "oraclient10.dll")
]
for dir in os.environ["PATH"].split(os.pathsep):
    for driverSuffix, clientFileName in drivers:
        if os.path.exists(os.path.join(dir, clientFileName)):
            moduleName =3D "cx_Oracle_%s" % driverSuffix
            driver =3D sys.modules["cx_Oracle"] =3D __import__(moduleName)
            break
if not found:
    raise "COULD NOT FIND ORACLE CLIENT INSTALLATION!"

Proceed as normal from this point forward. I think this solves your
problem and is simple to implement. And integrating this into
cx_Oracle would be very difficult to say the least -- unless I'm
missing something, of course. Does that answer your question
satisfactorily?

> >  Date: Mon, 23 Jan 2006 07:46:40 -0700
> >  From: Anthony Tuininga <ant...@gm...>
> >  To: cx-...@li...
> >  Subject: Re: [cx-oracle-users] Choosing client libraries
> >  Reply-To: cx-...@li...
> >
> >  I thought I was trying to help you?? :-)
> >
> >  I currently look for oraclient.dll in $ORACLE_HOME/bin on Windows and
> >  for libclient.a in $ORACLE_HOME/lib on all other platforms. What you
> >  suggest would be very Windows specific and cx_Oracle runs on a lot
> >  more platforms than Windows. In addition, this is done by an external
> >  program, not as part of the cx_Oracle module itself.
> >
> >  So did I answer your original question satisfactorily? Or have you
> >  moved on since then??
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Re: Choosing client libraries

[<pw...@re...>]

Anthony:

Yes, I realize that this is very Windows specific.  I usually have Oracle on Solaris or AIX, but you know which OS is on the client.  Developer tools sometimes do Windows specific things because 1) there are so many of them and 2) the Winodws user (and frequently Windows developers) are least likely to be able to handle technical problems.

Is the source code of the external program part of the cx_Oracle kit?  If so, would it be acceptable if I suggested a patch?  Any hints as to the most relevant filename(s) involved?


>  Date: Mon, 23 Jan 2006 07:46:40 -0700
>  From: Anthony Tuininga <ant...@gm...>
>  To: cx-...@li...
>  Subject: Re: [cx-oracle-users] Choosing client libraries
>  Reply-To: cx-...@li...
>  
>  I thought I was trying to help you?? :-)
>  
>  I currently look for oraclient.dll in $ORACLE_HOME/bin on Windows and
>  for libclient.a in $ORACLE_HOME/lib on all other platforms. What you
>  suggest would be very Windows specific and cx_Oracle runs on a lot
>  more platforms than Windows. In addition, this is done by an external
>  program, not as part of the cx_Oracle module itself.
>  
>  So did I answer your original question satisfactorily? Or have you
>  moved on since then??

Re: [cx-oracle-users] Choosing client libraries

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

I thought I was trying to help you?? :-)

I currently look for oraclient.dll in $ORACLE_HOME/bin on Windows and
for libclient.a in $ORACLE_HOME/lib on all other platforms. What you
suggest would be very Windows specific and cx_Oracle runs on a lot
more platforms than Windows. In addition, this is done by an external
program, not as part of the cx_Oracle module itself.

So did I answer your original question satisfactorily? Or have you
moved on since then??

On 1/21/06, Paul Watson <pw...@re...> wrote:
> >  Date: Fri, 20 Jan 2006 15:57:51 -0700
> >  From: Anthony Tuininga <ant...@gm...>
> >  To: cx-...@li...
> >  Subject: Re: [cx-oracle-users] Choosing client libraries
> >  Reply-To: cx-...@li...
> >
> >  Unfortunately Oracle does not provide the client version in its files
> >  anywhere so that information cannot be provided directly. You can
> >  check for the existence of certain attributes (like
> >  cx_Oracle.SessionPool is only available in 9i and up and
> >  cx_Oracle.Connection.module is only available in 10g and up) or
> >  something similar but I'm not aware of any other method of doing this.
> >  Recognize as well that since cx_Oracle is linked directly against the
> >  Oracle client libraries these must be present in order to even import
> >  the module. Windows seems to like to also put information in a message
> >  box (very unhelpful for server applications) when an import fails
> >  because of a linking problem.
> >
> >  The only effective means I have found of dealing with this is found in
> >  my cx_OracleDBATools package. I search $ORACLE_HOME/lib for files that
> >  are only found in 8i, 9i or 10g and then specifically import
> >  cx_Oracle_8i or cx_Oracle_9i or cx_Oracle_10g as cx_Oracle. In other
> >  words, you need to have each module available as a separate name and
> >  then decide which version you want to import yourself.
>
> The oci.dll library has the version information in the Windows VERSIONINF=
O structure.  At least, in the 8.1.7 client and the beta XE server packages=
 it does.  This can be accessed through the win32 module or directly using =
ctypes.
>
> Does this help?
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Choosing client libraries

[<pw...@re...>]

>  Date: Fri, 20 Jan 2006 15:57:51 -0700
>  From: Anthony Tuininga <ant...@gm...>
>  To: cx-...@li...
>  Subject: Re: [cx-oracle-users] Choosing client libraries
>  Reply-To: cx-...@li...
>  
>  Unfortunately Oracle does not provide the client version in its files
>  anywhere so that information cannot be provided directly. You can
>  check for the existence of certain attributes (like
>  cx_Oracle.SessionPool is only available in 9i and up and
>  cx_Oracle.Connection.module is only available in 10g and up) or
>  something similar but I'm not aware of any other method of doing this.
>  Recognize as well that since cx_Oracle is linked directly against the
>  Oracle client libraries these must be present in order to even import
>  the module. Windows seems to like to also put information in a message
>  box (very unhelpful for server applications) when an import fails
>  because of a linking problem.
>  
>  The only effective means I have found of dealing with this is found in
>  my cx_OracleDBATools package. I search $ORACLE_HOME/lib for files that
>  are only found in 8i, 9i or 10g and then specifically import
>  cx_Oracle_8i or cx_Oracle_9i or cx_Oracle_10g as cx_Oracle. In other
>  words, you need to have each module available as a separate name and
>  then decide which version you want to import yourself.

The oci.dll library has the version information in the Windows VERSIONINFO structure.  At least, in the 8.1.7 client and the beta XE server packages it does.  This can be accessed through the win32 module or directly using ctypes.

Does this help?

Re: [cx-oracle-users] Choosing client libraries

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

Unfortunately Oracle does not provide the client version in its files
anywhere so that information cannot be provided directly. You can
check for the existence of certain attributes (like
cx_Oracle.SessionPool is only available in 9i and up and
cx_Oracle.Connection.module is only available in 10g and up) or
something similar but I'm not aware of any other method of doing this.
Recognize as well that since cx_Oracle is linked directly against the
Oracle client libraries these must be present in order to even import
the module. Windows seems to like to also put information in a message
box (very unhelpful for server applications) when an import fails
because of a linking problem.

The only effective means I have found of dealing with this is found in
my cx_OracleDBATools package. I search $ORACLE_HOME/lib for files that
are only found in 8i, 9i or 10g and then specifically import
cx_Oracle_8i or cx_Oracle_9i or cx_Oracle_10g as cx_Oracle. In other
words, you need to have each module available as a separate name and
then decide which version you want to import yourself.

Hope this helps.

On 1/20/06, Paul Watson <pw...@re...> wrote:
> Is there any way to control which client libraries will be used by cx_Ora=
cle?
>
> If the 8.1 client is used, then it cannot connect to XE or 10g.
> If the XE client is used, then it cannot connect to 8.1.7.
>
> When it fails, how can I give the user helpful information from which the=
 problem might be resolved?  Yes, I can handle an exception.  What informat=
ion should I give the user?
>
> C:\src\python\db\cx_Oracle>test1.py
> apilevel =3D 2.0
> buildtime =3D January 26, 2005 14:37:48
> version =3D HEAD
> type =3D  <type 'str'>
> dsn =3D  (DESCRIPTION=3D(ADDRESS_LIST=3D(ADDRESS=3D(PROTOCOL=3DTCP)(HOST=
=3D172.168.80.80)(PORT=3D1521)))(CONNECT_DATA=3D(SID=3DTRAIN)))
> Traceback (most recent call last):
>   File "C:\src\python\db\cx_Oracle\test1.py", line 15, in ?
>     connection =3D cx_Oracle.connect("pwatson", "***********", "TRAIN")
> cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect ide=
ntifier specified
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Choosing client libraries

[<pw...@re...>]

Is there any way to control which client libraries will be used by cx_Oracle?

If the 8.1 client is used, then it cannot connect to XE or 10g.
If the XE client is used, then it cannot connect to 8.1.7.

When it fails, how can I give the user helpful information from which the problem might be resolved?  Yes, I can handle an exception.  What information should I give the user?

C:\src\python\db\cx_Oracle>test1.py
apilevel = 2.0
buildtime = January 26, 2005 14:37:48
version = HEAD
type =  <type 'str'>
dsn =  (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.168.80.80)(PORT=1521)))(CONNECT_DATA=(SID=TRAIN)))
Traceback (most recent call last):
  File "C:\src\python\db\cx_Oracle\test1.py", line 15, in ?
    connection = cx_Oracle.connect("pwatson", "***********", "TRAIN")
cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect identifier specified

Re: [cx-oracle-users] Access Oracle 8i's XML Query Functions

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

cx_Oracle currently does not support the XMLType (as you have
noticed). You can work around this fairly easily though by simply
transforming it into a type that cx_Oracle does support as in the
example below.

import cx_Oracle

connection =3D cx_Oracle.Connection("anthony/dev@dev")
cursor =3D connection.cursor()
cursor.execute("""
       select
         Id,
         XMLType.GetClobVal(Value)
       from XMLTable""")
for id, value in cursor:
   print "Id:", id
   print "Value (length):", value.size()
   file("test_%d.xml" % id, "w").write(value.read())

Hope that helps.

On 1/19/06, Gooch, John <Joh...@ec...> wrote:
> Has someone come up with a way to run the Oracle Java/C++ XML Query
> functions? These take a normal query as input, but return the results in
> XML format.
>
> What I plan on doing to have an ASP Web page and feeds data in XML
> format my Flash UI, which has XML data retrieval, storage, and parsing
> facilities built in.
>
> Thank You,
>
>
> John A. Gooch
> "May the Python-force be with you...always."
> Systems Administrator
> EchoStar Satellite L.L.C.
> Desk: 720-514-5708
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Access Oracle 8i's XML Query Functions

[Gooch, J. <Joh...@ec...>]

Has someone come up with a way to run the Oracle Java/C++ XML Query
functions? These take a normal query as input, but return the results in
XML format.=20

What I plan on doing to have an ASP Web page and feeds data in XML
format my Flash UI, which has XML data retrieval, storage, and parsing
facilities built in.

Thank You,


John A. Gooch
"May the Python-force be with you...always."
Systems Administrator
EchoStar Satellite L.L.C.
Desk: 720-514-5708=20