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

[cx-oracle-users] genesis of ORA-24816

[Michael B. <mi...@zz...>]

I have a user reporting this error message with SQLAlchemy / cx_oracle (cx_oracle/OCI versions unknown as of yet).    The official description of this message is:

ORA-24816:
Expanded non LONG bind data supplied after actual LONG or LOB column 
Cause: A Bind value of length potentially > 4000 bytes follows binding for LOB or LONG.
Action: Re-order the binds so that the LONG bind or LOB binds are all at the end of the bind list.

The statement in question is an UPDATE statement.  The CLOB field is the only parameter in the SET clause, and there is an additional bound parameter in the WHERE clause, but of course there is no option but for this parameter to appear later in the statement due to the syntax of UPDATE.

There is some confusion over whether "re-order the binds" refers to the SQL string, or just the order in which the bound parameters are passed to cursor.execute().    But Python dictionaries, as is passed for the parameter set to cursor.execute(), are not ordered, so it would seem to be that if this user is getting this issue, then by definition cx_oracle has to be doing the wrong thing, or does not have enough information to do the right thing.  

The user claims the issue occurs when using sqlalchemy .execute() but not when using cx_oracle cursor.execute(), however SQLalchemy of course uses cursor.execute() here in any case, which further points to the issue ultimately hinging on dictionary ordering, which is something that can change randomly depending on program structure.

Curious how cx_oracle handles this restriction of OCI, that CLOBs must occur last, and also if cursor.setinputsizes() has any impact.  We are currently not calling setinputsizes() for CLOB fields as we observed other problems there (I'd need to re-test to see what those issues were).

thanks for any pointers here.

Re: [cx-oracle-users] Optimizer Hints in Queries

[Andrew S. <saw...@gm...>]

I know my initial email had the degree - my script definitely
didn't....regardless,  I am running from scratch to see what happens.
sorry for the noise.
Andrew
On Apr 17, 2012 12:28 PM, "Mark Harrison" <mh...@pi...> wrote:

> On 4/17/12 11:46 AM, Andrew Sawyers wrote:
> > I have looked through many archived messages trying to find some details
> on using hints in queries.  I am using cc_Oracle 5.1.1 and oracle 11g -
> issuing a query, presuming I have a connection and a cursor, such as:
> > cursor.execute ("select /*+ first_rows °/ x, y, a from
> my_materialized_view")
> > Fails with "invalid character" - I am presuming that is from the / in
> the hint - I have tried various attempts too escape or other wise get this
> to work.....no luck.  Also no luck googling variations of my issue...
> > I am hoping someone here can provide  some help.
> > Cheers,
> > Andrew
>
> If this is an accurate cut and paste in your email, look at the "*/"
> part of your string.  It's showing up here as a degrees sign.
>
> The directive does work, here's a cut and paste from a bit
> of my code:
>
>         self.sql="""select /*+ FIRST_ROWS(1) */ seq,payload
>                       from opq_%s
>                      where status = 'queued'
>                      order by seq"""
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Optimizer Hints in Queries

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

On 4/17/12 11:46 AM, Andrew Sawyers wrote:
> I have looked through many archived messages trying to find some details on using hints in queries.  I am using cc_Oracle 5.1.1 and oracle 11g - issuing a query, presuming I have a connection and a cursor, such as:
> cursor.execute ("select /*+ first_rows °/ x, y, a from my_materialized_view")
> Fails with "invalid character" - I am presuming that is from the / in the hint - I have tried various attempts too escape or other wise get this to work.....no luck.  Also no luck googling variations of my issue...
> I am hoping someone here can provide  some help.
> Cheers,
> Andrew

If this is an accurate cut and paste in your email, look at the "*/"
part of your string.  It's showing up here as a degrees sign.

The directive does work, here's a cut and paste from a bit
of my code:

         self.sql="""select /*+ FIRST_ROWS(1) */ seq,payload
                       from opq_%s
                      where status = 'queued'
                      order by seq"""

Re: [cx-oracle-users] Optimizer Hints in Queries

[Andrew S. <saw...@gm...>]

Fwiw - I just figured this out, using alternative syntax:
cursor.execute("select --+ hint \n count(food) from my_mv")
That appears to work.....is there any doc I am missing to read that talks
about what characters are illegal?  I have found trying to run multiple
statements in a single execute separated by ";" doesn't work with the
"illegal character" error....
Cheers,
Andrew
On Apr 17, 2012 12:06 PM, "Andrew Sawyers" <saw...@gm...> wrote:

> Sorry, it is an asterisk.  I sent the original email from my phone, it
> likely messed that up.  ;p
> The SQL that errors works fine in sqldeveloper or sqlplus...
> Cheers,
> Andrew
> On Apr 17, 2012 12:04 PM, "Hancock, David (DHANCOCK)" <DHA...@ar...>
> wrote:
>
>>   In my email client, the character after first_rows looks like a degree
>> symbol. Try changing that to an asterisk and see if that works.
>>
>>  Cheers!
>> --
>> David Hancock
>>
>>   From: Andrew Sawyers <saw...@gm...>
>> Reply-To: "cx-...@li..." <
>> cx-...@li...>
>> Date: Tuesday, April 17, 2012 2:46 PM
>> To: "cx-...@li..." <
>> cx-...@li...>
>> Subject: [cx-oracle-users] Optimizer Hints in Queries
>>
>>   I have looked through many archived messages trying to find some
>> details on using hints in queries.  I am using cc_Oracle 5.1.1 and oracle
>> 11g - issuing a query, presuming I have a connection and a cursor, such as:
>> cursor.execute ("select /*+ first_rows °/ x, y, a from
>> my_materialized_view")
>> Fails with "invalid character" - I am presuming that is from the / in the
>> hint - I have tried various attempts too escape or other wise get this to
>> work.....no luck.  Also no luck googling variations of my issue...
>> I am hoping someone here can provide  some help.
>> Cheers,
>> Andrew
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> cx-oracle-users mailing list
>> cx-...@li...
>> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>>
>>

Re: [cx-oracle-users] Optimizer Hints in Queries

[Andrew S. <saw...@gm...>]

Sorry, it is an asterisk.  I sent the original email from my phone, it
likely messed that up.  ;p
The SQL that errors works fine in sqldeveloper or sqlplus...
Cheers,
Andrew
On Apr 17, 2012 12:04 PM, "Hancock, David (DHANCOCK)" <DHA...@ar...>
wrote:

>   In my email client, the character after first_rows looks like a degree
> symbol. Try changing that to an asterisk and see if that works.
>
>  Cheers!
> --
> David Hancock
>
>   From: Andrew Sawyers <saw...@gm...>
> Reply-To: "cx-...@li..." <
> cx-...@li...>
> Date: Tuesday, April 17, 2012 2:46 PM
> To: "cx-...@li..." <
> cx-...@li...>
> Subject: [cx-oracle-users] Optimizer Hints in Queries
>
>   I have looked through many archived messages trying to find some
> details on using hints in queries.  I am using cc_Oracle 5.1.1 and oracle
> 11g - issuing a query, presuming I have a connection and a cursor, such as:
> cursor.execute ("select /*+ first_rows °/ x, y, a from
> my_materialized_view")
> Fails with "invalid character" - I am presuming that is from the / in the
> hint - I have tried various attempts too escape or other wise get this to
> work.....no luck.  Also no luck googling variations of my issue...
> I am hoping someone here can provide  some help.
> Cheers,
> Andrew
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>

Re: [cx-oracle-users] Optimizer Hints in Queries

[Hancock, D. (DHANCOCK) <DHA...@ar...>]

In my email client, the character after first_rows looks like a degree symbol. Try changing that to an asterisk and see if that works.

Cheers!
--
David Hancock

From: Andrew Sawyers <saw...@gm...<mailto:saw...@gm...>>
Reply-To: "cx-...@li...<mailto:cx-...@li...>" <cx-...@li...<mailto:cx-...@li...>>
Date: Tuesday, April 17, 2012 2:46 PM
To: "cx-...@li...<mailto:cx-...@li...>" <cx-...@li...<mailto:cx-...@li...>>
Subject: [cx-oracle-users] Optimizer Hints in Queries


I have looked through many archived messages trying to find some details on using hints in queries.  I am using cc_Oracle 5.1.1 and oracle 11g - issuing a query, presuming I have a connection and a cursor, such as:
cursor.execute ("select /*+ first_rows °/ x, y, a from my_materialized_view")
Fails with "invalid character" - I am presuming that is from the / in the hint - I have tried various attempts too escape or other wise get this to work.....no luck.  Also no luck googling variations of my issue...
I am hoping someone here can provide  some help.
Cheers,
Andrew

[cx-oracle-users] Optimizer Hints in Queries

[Andrew S. <saw...@gm...>]

I have looked through many archived messages trying to find some details on
using hints in queries.  I am using cc_Oracle 5.1.1 and oracle 11g -
issuing a query, presuming I have a connection and a cursor, such as:
cursor.execute ("select /*+ first_rows °/ x, y, a from
my_materialized_view")
Fails with "invalid character" - I am presuming that is from the / in the
hint - I have tried various attempts too escape or other wise get this to
work.....no luck.  Also no luck googling variations of my issue...
I am hoping someone here can provide  some help.
Cheers,
Andrew

Re: [cx-oracle-users] Strange problem with query execution...

[Thierry F. <thi...@on...>]

Le Thu, 05 Apr 2012 05:39:40 -0600,
  Doug Henderson <djh...@te...> a écrit:

> Look for implicit type conversions in the where clause. If columns are
> converted to match the parameter type, then an index on the column
> will not be used. You may need to include explicit type conversion
> around the parameters to prevent implicit conversion of indexed
> columns. This is a subtle problem that can be very hard to detect,
> but cause horrible query performance.
> 
> For example, a clause like "numeric_column = :param1" may need to be
> coded as "numeric_column = to_number(:param1)".

Thanks for the hint !
But I checked all database columns and query parameters and I only use
strings; that's a point where SQLAlchemy prevents you from using bad
query parameters types...

Regards,
Thierry
-- 
  Chef de projets internet/intranet
  Office National des Forêts
  Direction des Systèmes d'Information
  2, Avenue de Saint Mandé
  75570 PARIS Cedex 12

  Tél. : 01 40 19 59 64
  Fax. : 01 40 19 59 85
  Mél. : thi...@on...
  WWW  : http://www.onf.fr

Re: [cx-oracle-users] Strange problem with query execution...

[Doug H. <djh...@te...>]

On 2012-04-05 01:08, Thierry Florac wrote:
> Hi,
>
> I'm using cx_Oracle (actually in release 5.1.1, but with the same
> symptoms in 5.1 and 5.0.4) through SQLAlchemy to access an Oracle 10g
> database (release 10.2.0.4).
>
> I'm building a web application querying a quite big table (nearly 3.5
> millions records), which is indexed correctly.
>
> After activating SQLAlchemy "echo SQL" feature, I noticed that :
>  - an SQLAlchemy request takes between 10 and 15 seconds
>  - the same request executed from an SQL worksheet (in Tora) is nearly
>    immediate.
>
> So I made a few tests using cx_Oracle without SQLAlchemy and the
> results are that :
>  - if I execute the same query with parameters (via
>    "cursor.execute("select...", param1=value1,...)", which is the way
>    SQLAlchemy works), it still takes between 10 and 15 seconds;
>  - but if I execute the same request with "hard-coded" parameters, the
>    result is immediate.
>
> Any idea (perhaps on the DB side) ?
>
> Thanks for any help,
> Thierry
Look for implicit type conversions in the where clause. If columns are
converted to match the parameter type, then an index on the column will
not be used. You may need to include explicit type conversion around the
parameters to prevent implicit conversion of indexed columns. This is a
subtle problem that can be very hard to detect, but cause horrible query
performance.

For example, a clause like "numeric_column = :param1" may need to be
coded as "numeric_column = to_number(:param1)".

-- 
Doug Henderson, Calgary, Alberta, Canada

Re: [cx-oracle-users] Strange problem with query execution...

[Thierry F. <thi...@on...>]

Le Thu, 05 Apr 2012 11:10:53 +0200,
  Lassi Tuura <la...@ce...> a écrit:

> > I'm using cx_Oracle (actually in release 5.1.1, but with the same
> > symptoms in 5.1 and 5.0.4) through SQLAlchemy to access an Oracle
> > 10g database (release 10.2.0.4).
> > 
> > I'm building a web application querying a quite big table (nearly
> > 3.5 millions records), which is indexed correctly.
> > 
> > After activating SQLAlchemy "echo SQL" feature, I noticed that :
> > - an SQLAlchemy request takes between 10 and 15 seconds
> > - the same request executed from an SQL worksheet (in Tora) is
> > nearly immediate.
> > 
> > So I made a few tests using cx_Oracle without SQLAlchemy and the
> > results are that :
> > - if I execute the same query with parameters (via
> >   "cursor.execute("select...", param1=value1,...)", which is the way
> >   SQLAlchemy works), it still takes between 10 and 15 seconds;
> > - but if I execute the same request with "hard-coded" parameters,
> > the result is immediate.
> > 
> > Any idea (perhaps on the DB side) ?
> 
> Yes, oracle peeks at bind variables as a part of query planning. My
> first guess would be that your query plans are bad, which could be
> for any number of reasons. Assuming you use standard cost-based
> plans, first check if you are running with up-to-date table
> statistics, which implies having your indices monitored. For example
> if your table stats say the table has one row but it has million rows
> now, bind value peek can totally mislead the query planner to make a
> bad choice.

Yes, tables and indexes statistics are up to date, rebuild once a day.
Query plan *shouldn't* be so bad, as hard-coded criterias give good
query plans and good response time...


> In sqlplus you can get the query plans with 'explain plan for
> <query>', then run '@?/rdbms/admin/utlxpls.sql'. This latter isn't in
> instant client but you can grab it from the full oracle client and it
> should still work in the instant client sqlplus.

Already done, activating tracing and many things to see SGA status and
query execution plans.
Result is as explayed : Oracle makes a full scan while using queries
with parameters :-(
What is strange is that it didn't do that just a few weeks ago and
that, according to my DBA, no configuration change occurred !


> There's a way to get that same info via APIs like cx-oracle, but I
> don't remember the incantations off the top of my head. If you can
> attach OEM to your database where you execute these queries, you can
> see the plans live, which may be a better way to evaluate your
> application.
> 
> Below you can find some useful SQL to dump and manage table stats.
> Feel free to search keywords on these, there's plenty of
> documentation.
> 
> Be *very* careful about running these in your production schema. If
> you have not had table monitoring on, and activate it, all your query
> plans can change dramatically. It *is* possible even if not likely
> the result is disastrously bad query plans. Though note that some
> DBAs enable all databases to run all of this automatically every day
> or some such scheme, so it may be that none of this is related to
> your problem.

Thanks for this, I'll try to have a look at them and forward them to my
DBA...

Best regards,
Thierry
-- 
  Chef de projets internet/intranet
  Office National des Forêts
  Direction des Systèmes d'Information
  2, Avenue de Saint Mandé
  75570 PARIS Cedex 12

  Tél. : 01 40 19 59 64
  Fax. : 01 40 19 59 85
  Mél. : thi...@on...
  WWW  : http://www.onf.fr

Re: [cx-oracle-users] Strange problem with query execution...

[Lassi T. <la...@ce...>]

Hi,

> I'm using cx_Oracle (actually in release 5.1.1, but with the same
> symptoms in 5.1 and 5.0.4) through SQLAlchemy to access an Oracle 10g
> database (release 10.2.0.4).
> 
> I'm building a web application querying a quite big table (nearly 3.5
> millions records), which is indexed correctly.
> 
> After activating SQLAlchemy "echo SQL" feature, I noticed that :
> - an SQLAlchemy request takes between 10 and 15 seconds
> - the same request executed from an SQL worksheet (in Tora) is nearly
>   immediate.
> 
> So I made a few tests using cx_Oracle without SQLAlchemy and the
> results are that :
> - if I execute the same query with parameters (via
>   "cursor.execute("select...", param1=value1,...)", which is the way
>   SQLAlchemy works), it still takes between 10 and 15 seconds;
> - but if I execute the same request with "hard-coded" parameters, the
>   result is immediate.
> 
> Any idea (perhaps on the DB side) ?

Yes, oracle peeks at bind variables as a part of query planning. My first
guess would be that your query plans are bad, which could be for any number
of reasons. Assuming you use standard cost-based plans, first check if you
are running with up-to-date table statistics, which implies having your
indices monitored. For example if your table stats say the table has one
row but it has million rows now, bind value peek can totally mislead the
query planner to make a bad choice.

In sqlplus you can get the query plans with 'explain plan for <query>',
then run '@?/rdbms/admin/utlxpls.sql'. This latter isn't in instant client
but you can grab it from the full oracle client and it should still work in
the instant client sqlplus.

There's a way to get that same info via APIs like cx-oracle, but I don't
remember the incantations off the top of my head. If you can attach OEM to
your database where you execute these queries, you can see the plans live,
which may be a better way to evaluate your application.

Below you can find some useful SQL to dump and manage table stats. Feel
free to search keywords on these, there's plenty of documentation.

Be *very* careful about running these in your production schema. If you
have not had table monitoring on, and activate it, all your query plans
can change dramatically. It *is* possible even if not likely the result
is disastrously bad query plans. Though note that some DBAs enable all
databases to run all of this automatically every day or some such scheme,
so it may be that none of this is related to your problem.

Hope this helps.

Lassi

1) Dump the current table / index stats with:

====
set lines 1000
set pages 1000

select
  table_name, inserts, updates, deletes,
  timestamp, truncated, drop_segments
from user_tab_modifications
order by table_name;

select
  index_name, num_rows, distinct_keys,
  leaf_blocks, clustering_factor, blevel,
  avg_leaf_blocks_per_key
from user_indexes
order by index_name;

select
  table_name, column_name, num_distinct,
  num_nulls, num_buckets, trunc(density,4)
from user_tab_col_statistics
where table_name in (select table_name from user_tables)
order by table_name, column_name;
====

2) Enable monitoring with something like this:

====
set serveroutput on size 100000

DECLARE
BEGIN
   FOR t IN (SELECT table_name FROM user_tables
             WHERE table_name NOT LIKE 'X%'
               AND monitoring != 'YES')
   LOOP
      dbms_output.put_line ('Enabling monitoring for table ' || t.table_name);
      execute immediate 'alter table ' || t.table_name || ' monitoring';
   END LOOP;

   FOR i IN (SELECT index_name FROM user_indexes
             WHERE index_name NOT LIKE 'SYS%'
               AND index_name NOT LIKE 'X%'
               AND index_type NOT LIKE 'IOT%'
               AND last_analyzed is null)
   LOOP
      dbms_output.put_line ('Enabling monitoring for index ' || i.index_name);
      execute immediate 'alter index ' || i.index_name || ' monitoring usage';
   END LOOP;
END;
/
====

3) Force table stats to update with something like this:

====
set serveroutput on size 100000
BEGIN
   dbms_stats.gather_schema_stats
      (ownname => user,
       options => 'GATHER AUTO',
       degree => 2,
       cascade => true,
       no_invalidate => false,
       force => true);
END;
/
====

Re: [cx-oracle-users] Strange problem with query execution...

[Andreas M. <and...@we...>]

Hi Thierry,

as far as I know Oracle DB's query planner can take 
into account how selective a value in a where clause
is. That can cause the described phaenomena:
Slow execution with bind parameters, fast with literal
values in sql statement.

Look at the query plan for both cases.
(Buzzword: Query Plan Stability)

Best regards
Andreas Mock


> -----Original Message-----
> From: Thierry Florac [mailto:thi...@on...]
> Sent: Thursday, April 05, 2012 9:08 AM
> To: cx-...@li...
> Subject: [cx-oracle-users] Strange problem with query execution...
> 
> 
> Hi,
> 
> I'm using cx_Oracle (actually in release 5.1.1, but with the same
> symptoms in 5.1 and 5.0.4) through SQLAlchemy to access an Oracle 10g
> database (release 10.2.0.4).
> 
> I'm building a web application querying a quite big table (nearly 3.5
> millions records), which is indexed correctly.
> 
> After activating SQLAlchemy "echo SQL" feature, I noticed that :
>  - an SQLAlchemy request takes between 10 and 15 seconds
>  - the same request executed from an SQL worksheet (in Tora) is nearly
>    immediate.
> 
> So I made a few tests using cx_Oracle without SQLAlchemy and the
> results are that :
>  - if I execute the same query with parameters (via
>    "cursor.execute("select...", param1=value1,...)", which is the way
>    SQLAlchemy works), it still takes between 10 and 15 seconds;
>  - but if I execute the same request with "hard-coded" parameters, the
>    result is immediate.
> 
> Any idea (perhaps on the DB side) ?
> 
> Thanks for any help,
> Thierry
> --
>   Chef de projets internet/intranet
>   Office National des Forêts
>   Direction des Systèmes d'Information
>   2, Avenue de Saint Mandé
>   75570 PARIS Cedex 12
> 
>   Tél. : 01 40 19 59 64
>   Fax. : 01 40 19 59 85
>   Mél. : thi...@on...
>   WWW  : http://www.onf.fr
> 
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users

[cx-oracle-users] Strange problem with query execution...

[Thierry F. <thi...@on...>]

Hi,

I'm using cx_Oracle (actually in release 5.1.1, but with the same
symptoms in 5.1 and 5.0.4) through SQLAlchemy to access an Oracle 10g
database (release 10.2.0.4).

I'm building a web application querying a quite big table (nearly 3.5
millions records), which is indexed correctly.

After activating SQLAlchemy "echo SQL" feature, I noticed that :
 - an SQLAlchemy request takes between 10 and 15 seconds
 - the same request executed from an SQL worksheet (in Tora) is nearly
   immediate.

So I made a few tests using cx_Oracle without SQLAlchemy and the
results are that :
 - if I execute the same query with parameters (via
   "cursor.execute("select...", param1=value1,...)", which is the way
   SQLAlchemy works), it still takes between 10 and 15 seconds;
 - but if I execute the same request with "hard-coded" parameters, the
   result is immediate.

Any idea (perhaps on the DB side) ?

Thanks for any help,
Thierry
-- 
  Chef de projets internet/intranet
  Office National des Forêts
  Direction des Systèmes d'Information
  2, Avenue de Saint Mandé
  75570 PARIS Cedex 12

  Tél. : 01 40 19 59 64
  Fax. : 01 40 19 59 85
  Mél. : thi...@on...
  WWW  : http://www.onf.fr

Re: [cx-oracle-users] How is cursor.callfunc() supposed to work?

[James C. M. <Jam...@or...>]

Hi Paul,

On 22/02/12 05:44 PM, James C. McPherson wrote:
> On 22/02/12 05:40 PM, Paul Moore wrote:
...
>>>    From this code, it appears the api call is a procedure, rather than a
>>> function (no return value). The cursor.callfunc method won't work for
>>> procedures, I suspect (no return type - you appear to have used
>>> cx_Oracle.NUMBER in your tests, for some reason...). So I'd suggest
>>> that you need to stick with the execute of a block solution.
>>
>> ... or use cursor.callproc, which I just noticed :-)
>
> Hmmm. I thought it was declared as a function but on
> re-reading the 1page snipped that is its documentation
> I see in bold type "Procedure".

Well ... waddayaknow .... after mucking around for a bit
(restarting my python shell to clean out some extraneous
bind variables and paying attention to the returned message
when I got the args wrong) it works!


Id= 13741059
comments= "new comment to enter"
commenttype= 'N'
error_code = 0
error_mesg = cursor.var(cx_Oracle.STRING)

keywordargs={ID : Id, 'comments' : comments,
     'commenttype' : 'N', 'error_code' : error_code,
     'error_mesg' : error_mesg }

rval = cursor.callproc('bug.bug_api.create_bug_line', [], keywordargs)

 >>> if rval.__contains__("Text line inserted successfully on %d" % Id):
...     print "hey, it worked!"
... else:
...     print "boooo"
...
hey, it worked!


:-D

Thankyou for your help with this problem.


James C. McPherson
--
Oracle
http://www.jmcp.homeunix.com/blog

Re: [cx-oracle-users] How is cursor.callfunc() supposed to work?

[James C. M. <Jam...@or...>]

On 22/02/12 05:40 PM, Paul Moore wrote:
> On 22 February 2012 07:38, Paul Moore<p.f...@gm...>  wrote:
>>> So ... should I try to use cursor.callfunc() in the future,
>>> or just stick with statements like the above?
>>
>>  From this code, it appears the api call is a procedure, rather than a
>> function (no return value). The cursor.callfunc method won't work for
>> procedures, I suspect (no return type - you appear to have used
>> cx_Oracle.NUMBER in your tests, for some reason...). So I'd suggest
>> that you need to stick with the execute of a block solution.
>
> ... or use cursor.callproc, which I just noticed :-)

Hmmm. I thought it was declared as a function but on
re-reading the 1page snipped that is its documentation
I see in bold type "Procedure".

I think what had me confused is that the last 2 params
are modified by the routine and on error contain an
error code and a message.

Thanks for the tip, I'll see how it goes.

Cheers!

James C. McPherson
--
Oracle
http://www.jmcp.homeunix.com/blog

Re: [cx-oracle-users] How is cursor.callfunc() supposed to work?

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

On 22 February 2012 07:38, Paul Moore <p.f...@gm...> wrote:
>> So ... should I try to use cursor.callfunc() in the future,
>> or just stick with statements like the above?
>
> From this code, it appears the api call is a procedure, rather than a
> function (no return value). The cursor.callfunc method won't work for
> procedures, I suspect (no return type - you appear to have used
> cx_Oracle.NUMBER in your tests, for some reason...). So I'd suggest
> that you need to stick with the execute of a block solution.

... or use cursor.callproc, which I just noticed :-)

Paul

Re: [cx-oracle-users] How is cursor.callfunc() supposed to work?

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

On 22 February 2012 06:07, James C. McPherson
<Jam...@or...> wrote:
> I eventually fell back to using a Statement ala
>
> cursor.execute("""
> DECLARE
> outnum NUMBER;
> outmsg VARCHAR2(5000);
> BEGIN
> package.api.functionname(
>     ID => 13741059,
>     comments => 'Fixed in changeset: 14209:585efc418ca7',
>     commenttype => 'N',
>     opaqueid => NULL,
>     error_code => bugoutnum,
>     error_mesg => bugoutmsg);
> END;
> """)
> connection.commit()
>
> ... which worked.
>
>
> So ... should I try to use cursor.callfunc() in the future,
> or just stick with statements like the above?

>From this code, it appears the api call is a procedure, rather than a
function (no return value). The cursor.callfunc method won't work for
procedures, I suspect (no return type - you appear to have used
cx_Oracle.NUMBER in your tests, for some reason...). So I'd suggest
that you need to stick with the execute of a block solution.

Paul

[cx-oracle-users] How is cursor.callfunc() supposed to work?

[James C. M. <Jam...@or...>]

Hi everybody,
I'm migrating a collection of python scripts from one db
(Oracle backend, but we get to use some Siebel middleware)
to another (raw Oracle 11g).

I've been trying to use the cursor.callfunc() method with
one of the API calls that we're allowed to use, but no matter
what variation of arguments I supply, I just cannot get the
method to work.


cursor.callfunc('package.api.functionname', cx_Oracle.NUMBER, [], { \
     'ID' : 13741059,
     'comments' : 'Fixed in rev:csetid',
     'commenttype' : 'N',
     'opaqueid' : 'NULL',
     'error_code' : 0,
     'error_mesg' : 'NULL'} )

This would fail with

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
cx_Oracle.DatabaseError: ORA-06550: line 1, column 13:
PLS-00306: wrong number or types of arguments in call to 'FUNCTIONNAME'
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored


The same issue occured when I used positional params instead
of keyword params.

Yes, I have checked and rechecked that I am supplying all the
args to the function which are mandatory, as well as those which
are merely optional. I also found Anthony's post from 2002
(http://mail.python.org/pipermail/python-list/2002-September/788482.html)
which mentions setinputsizes(), and tried using that route as well.
No joy there either



I eventually fell back to using a Statement ala



cursor.execute("""
DECLARE
outnum NUMBER;
outmsg VARCHAR2(5000);
BEGIN
package.api.functionname(
     ID => 13741059,
     comments => 'Fixed in changeset: 14209:585efc418ca7',
     commenttype => 'N',
     opaqueid => NULL,
     error_code => bugoutnum,
     error_mesg => bugoutmsg);
END;
""")
connection.commit()

... which worked.


So ... should I try to use cursor.callfunc() in the future,
or just stick with statements like the above?

I'm using cx_Oracle 5.1.1, Oracle Instant Client 11.2, running
with python2.6 on Solaris 11.


Pointers to where (and how) I misread the docs would be greatly
appreciated.

Thankyou in advance,
James C. McPherson
--
Oracle
http://www.jmcp.homeunix.com/blog

[cx-oracle-users] Integrating LIXA with cx_Oracle

[Christian F. <ca...@ya...>]

Dear All,
I'm the founder of LIXA project ( http://sourceforge.net/projects/lixa/ http://lixa.sourceforge.net/manuals/ ) and I'm interested in integrating LIXA with cx_Oracle.
LIXA is LIbre XA, a free and open source XA compliant transaction manager: it implements XA interface to deal with the Resouce Managers and implements TX interface to deal with the Application Programs.
LIXA supports Oracle as a Resource Manager and allows to create distributed transaction s (2 phase commit) with PostgreSQL, MySQL, Oracle and DB2.
XA and TX are interfaces designed for C (and C++) programs.
I am now interested in expanding the LIXA project scope to Python language and Python programmers.
It seems to me cx_Oracle is a good start point because it wraps the Oracle C API; LIXA too uses OCI.

It's time to describe my issue to ask some help to you.
First of all, I'm not a Python expert.
I've generated a LIXA wrapper using SWIG and it works fine, the usage is something like this (my development environment is based on Ubuntu 10.04):

tiian@mojan:~/src/swig$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lixa
>>> lixa.tx_open()
0
>>> lixa.tx_begin()
0
>>> lixa.tx_commit()
0
>>> lixa.tx_close()
0
>>>


tx_open(), tx_begin(), tx_commit(), tx_close() are the standard functions described in "TX (Transaction Demarcation) Specification" (CAE X/Open standard).
The operations related to the Resource Managers must be put between "tx_begin()" and "tx_commit()".

TX standard specifies the Resource Managers must be opened by the Transaction Manager using "tx_open()" by the Application Program. This is the key point: cx_Oracle supplies its own method to get a valid Oracle session: "cx_Oracle.connect(...)", while LIXA wants to create it using "lixa.tx_open()": the Transaction Manager must open all the Resource Managers, not only Oracle.
Using C as the development language, Oracle supplies some convenience methods to retrieve the environment and the context for a connection opened by an XA Transaction Manager: xaoEnv, xaoSvcCtx.

The following one is an excerpt from a C sample (http://lixa.svn.sourceforge.net/viewvc/lixa/doc/examples/example2_ora.c?revision=703&view=markup): 

[...]

    /* open the resource manager(s) */
    if (TX_OK != (txrc = tx_open())) {
        fprintf(stderr, "tx_open error: %d\n", txrc);
        exit(txrc);
    }

    /* retrieve environment and context */
    if (NULL == (oci_env = xaoEnv(NULL))) {
        fprintf(stderr, "xaoEnv returned a NULL pointer\n");
        exit(1);
    }
    if (NULL == (oci_svc_ctx = xaoSvcCtx(NULL))) {
        fprintf(stderr, "xaoSvcCtx returned a NULL pointer\n");
        exit(1);
    }

    /* allocate statement and error handles */
    if (0 != OCIHandleAlloc( (dvoid *)oci_env, (dvoid **)&stmt_hndl,
                             OCI_HTYPE_STMT, (size_t)0, (dvoid **)0)) {
        fprintf(stderr, "Unable to allocate statement handle\n");
        exit(1);
    }
    if (0 != OCIHandleAlloc( (dvoid *)oci_env, (dvoid **)&err_hndl,
                             OCI_HTYPE_ERROR, (size_t)0, (dvoid **)0)) {
        fprintf(stderr, "Unable to allocate error handle\n");
        exit(1);
    }

[...]

the Application Program does not use "OCIEnvNlsCreate(...)": the Transaction Manager calls "xa_open()" ("xaoopen") inside "tx_open()" and the Application Program retrieves the environment using a convenience method (xaoEnv).
The same happens when the connection must be closed using "tx_close()".

Thinking about integration between LIXA and cx_Oracle I'm proposing three different paths:
1. patching cx_Oracle substituting "OCIEnvNlsCreate" with "xaoEnv" and removing some functions using user/password, SID, etc... I don't like this solution because the patch must be managed and tested every time cx_Oracle releases something new; I don't think it would be well accepted by the users too

2. it could be easy to overload the "cx_Oracle.connect()" method: if it accepted something like a wrapped "OCIEnv *" too, the integration would be something like: 
cx_Oracle.connect(lixa.lixa_ora_get_ocienv() )
The proposed use case would be something like this:
import lixa
import cx_Oracle
import ...        (other Resource Manager modules)
lixa.tx_open()    ... create Transaction Manager context 
                  and open Resource Managers
liora = lixa.lixa_ora_get_ocienv()
conn = cx_Oracle.connect( some_function(liora) )
... some stuff ...
lixa.tx_begin()
... insert/update/delete using conn object ...
lixa.tx_commit()
conn.close()      ... it should destroy the Python object without calling the Oracle's close function
lixa.tx_close()   ... destroy Transaction Manager context 
                  and close Resource Manager connections 
                  using xa_close() (xaoclose)

3. it could be possible to call the logic of cx_Oracle.connect() and conn.close() inside lixa.tx_open() and lixa.tx_close()
The proposed use case would be something like this:
import lixa
import cx_Oracle
import ...        (other Resource Manager modules)
lixa.tx_open()    ... create Transaction Manager context, 
                  open Resource Managers, 
                  call cx_Oracle.connect logic (without OCIEnvNlsCreate)
conn = lixa.lixa_ora_get_conn()
... some stuff ...
lixa.tx_begin()
... insert/update/delete using conn object ...
lixa.tx_commit()
lixa.tx_close()   ... destroy Transaction Manager context, 
                  close Resource Manager connections, destroy 
                  conn connection object calling 
                  conn.close (cx_Oracle logic)

Option 3 requires more integration between LIXA and cx_Oracle object but could be more acceptable from the development community.

What's your opinions and suggestions?

If you were interested in, you could look at a previous discussion in Psycopg2 mailing list about the same topic (using PostgreSQL instead of Oracle):
http://archives.postgresql.org/psycopg/2012-02/msg00000.php
I'm trying to discuss the same topic in MySQLDB forum too:
https://sourceforge.net/projects/mysql-python/forums/forum/70461/topic/5035738

Thanks in advance for your help.
Regards,
Ch.F.
 
-------------------------------------------------------------------
Decent workarounds outperform poor solutions

Re: [cx-oracle-users] cx_Oracle-5.1.1 install help (Solaris 11 w/ Oracle DB Client 11.2.0.3 64-bit)

[Brad H. <bra...@gm...>]

Thanks again Chris. I did miss setting the LD_LIBRARY_PATH variable to the
client lib directory. It imports successfully now.

On Wed, Feb 15, 2012 at 12:24 PM, Christopher Jones <
chr...@or...> wrote:

>
> Perhaps you copied my typo, thus resulting in LD_LIBRARY_PATH not set to
> the Instant Client directory.
> I get your error if I don't have LD_LIBRARY_PATH set.
>
> With it correctly set, cx_Oracle 5.1.1 is working fine for me with Python
> 2.6.4 on Solaris 11 x86
>
> Chris

Re: [cx-oracle-users] cx_Oracle-5.1.1 install help (Solaris 11 w/ Oracle DB Client 11.2.0.3 64-bit)

[Christopher J. <chr...@or...>]

Perhaps you copied my typo, thus resulting in LD_LIBRARY_PATH not set to the Instant Client directory.
I get your error if I don't have LD_LIBRARY_PATH set.

With it correctly set, cx_Oracle 5.1.1 is working fine for me with Python 2.6.4 on Solaris 11 x86

Chris

On 02/15/2012 08:29 AM, Brad Hudson wrote:
> Thanks for that Chris. I was able to build/install cx_Oracle after deinstalling the 64-bit client and installing the 32-bit client. However, there still appears to be an issue. It looks like cx_Oracle-5.1.1 is not setup for python2.6?
>
> # python
> Python 2.6.4 (r264:75706, Oct 17 2011, 17:17:06) [C] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import cx_Oracle
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "build/bdist.solaris-2.11-sun4v/egg/cx_Oracle.py", line 7, in <module>
>    File "build/bdist.solaris-2.11-sun4v/egg/cx_Oracle.py", line 6, in __bootstrap__
> ImportError: ld.so.1: isapython2.6: fatal: libclntsh.so.11.1: open failed: No such file or directory
>  >>>
>
> # ls -l /u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so
> lrwxrwxrwx   1 oracle   oinstall      61 Feb 15 08:53 /u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so -> /u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so.11.1
> # pwd
> /usr/lib/python2.6/site-packages
> [root@ilhsf001v010]# ls -l cx_Oracle-5.1.1-py2.6-solaris-2.11-sun4v.egg
> -rw-r--r--   1 root     root       59402 Feb 15 09:09 cx_Oracle-5.1.1-py2.6-solaris-2.11-sun4v.egg
> # cat easy-install.pth
> import sys; sys.__plen = len(sys.path)
> ./SQLAlchemy-0.7.5-py2.6.egg
> ./cx_Oracle-5.1.1-py2.6-solaris-2.11-sun4v.egg
> import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
> #
>
> On Tue, Feb 14, 2012 at 6:35 PM, Christopher Jones <chr...@or... <mailto:chr...@or...>> wrote:
>
>
>     Try installing the 32bit Instant Client 'basic' & 'sdk' packages and
>     link cx_Oracle with it (by creating a symlink libclntsh.so ->
>     libclntsh.so.11.1 and setting ORACLE_HOME to the instant client
>     directory).
>
>     Subsequently, prior to python runtime, set LD_LIBARY_PATH to the
>     Instant Client directory.  ORACLE_HOME should not be set at runtime
>     since python is using Instant Client.  It's only the cx_Oracle
>     installer that overloads the meaning of ORACLE_HOME.  Connections will
>     need a connect string, such as "localhost/orcl".  If you use a
>     tnsnames.ora file, then simply set TNS_ADMIN to its containing
>     directory.
>
>     Chris
>

-- 
Email: chr...@or...
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/

Re: [cx-oracle-users] cx_Oracle-5.1.1 install help (Solaris 11 w/ Oracle DB Client 11.2.0.3 64-bit)

[Brad H. <bra...@gm...>]

Thanks for that Chris. I was able to build/install cx_Oracle after
deinstalling the 64-bit client and installing the 32-bit client. However,
there still appears to be an issue. It looks like cx_Oracle-5.1.1 is not
setup for python2.6?

# python
Python 2.6.4 (r264:75706, Oct 17 2011, 17:17:06) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.solaris-2.11-sun4v/egg/cx_Oracle.py", line 7, in
<module>
  File "build/bdist.solaris-2.11-sun4v/egg/cx_Oracle.py", line 6, in
__bootstrap__
ImportError: ld.so.1: isapython2.6: fatal: libclntsh.so.11.1: open failed:
No such file or directory
>>>

# ls -l
/u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so

lrwxrwxrwx   1 oracle   oinstall      61 Feb 15 08:53
/u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so ->
/u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so.11.1
# pwd
/usr/lib/python2.6/site-packages
[root@ilhsf001v010]# ls -l cx_Oracle-5.1.1-py2.6-solaris-2.11-sun4v.egg
-rw-r--r--   1 root     root       59402 Feb 15 09:09
cx_Oracle-5.1.1-py2.6-solaris-2.11-sun4v.egg
# cat easy-install.pth
import sys; sys.__plen = len(sys.path)
./SQLAlchemy-0.7.5-py2.6.egg
./cx_Oracle-5.1.1-py2.6-solaris-2.11-sun4v.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:];
p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert =
p+len(new)
#

On Tue, Feb 14, 2012 at 6:35 PM, Christopher Jones <
chr...@or...> wrote:

>
> Try installing the 32bit Instant Client 'basic' & 'sdk' packages and
> link cx_Oracle with it (by creating a symlink libclntsh.so ->
> libclntsh.so.11.1 and setting ORACLE_HOME to the instant client
> directory).
>
> Subsequently, prior to python runtime, set LD_LIBARY_PATH to the
> Instant Client directory.  ORACLE_HOME should not be set at runtime
> since python is using Instant Client.  It's only the cx_Oracle
> installer that overloads the meaning of ORACLE_HOME.  Connections will
> need a connect string, such as "localhost/orcl".  If you use a
> tnsnames.ora file, then simply set TNS_ADMIN to its containing
> directory.
>
> Chris
>
>

[cx-oracle-users] Package cx_Oracle for AIX 6.1

[Ivanelson N. <iva...@gm...>]

What most appropriate package to install cx_Oracle on AIX 6.1 Source RPM or
SourceCode Only?

Thanks!

Re: [cx-oracle-users] cx_Oracle-5.1.1 install help (Solaris 11 w/ Oracle DB Client 11.2.0.3 64-bit)

[Christopher J. <chr...@or...>]

Try installing the 32bit Instant Client 'basic' & 'sdk' packages and
link cx_Oracle with it (by creating a symlink libclntsh.so ->
libclntsh.so.11.1 and setting ORACLE_HOME to the instant client
directory).

Subsequently, prior to python runtime, set LD_LIBARY_PATH to the
Instant Client directory.  ORACLE_HOME should not be set at runtime
since python is using Instant Client.  It's only the cx_Oracle
installer that overloads the meaning of ORACLE_HOME.  Connections will
need a connect string, such as "localhost/orcl".  If you use a
tnsnames.ora file, then simply set TNS_ADMIN to its containing
directory.

Chris

On 02/14/2012 08:09 AM, Anthony Tuininga wrote:
> Hi,
>
> Looks to me like you are trying to use a 64-bit Oracle client with a
> 32-bit Python. That won't work. :-) You will need to have a 64-bit
> Python. If you already do, the other possibility is that you need a
> special switch to specify that you want to build 64-bit binaries. If
> that is the case, let me know what needs to be adjusted in setup.py to
> make things work for you. Thanks.
>
> Anthony
>
> On Tue, Feb 14, 2012 at 8:54 AM, Brad Hudson<bra...@gm...>  wrote:
>> Can anyone assist with an install of cx_Oracle-5.1.1 on Solaris 11? I have
>> installed the Oracle DB Client 11.2.0.3 (64-bit on SPARC) and receive the
>> following error when attempting to build cx_Oracle:
>>
>> # python setup.py build
>> running build
>> running build_ext
>> building 'cx_Oracle' extension
>> /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-sun4v-2.6-11g/cx_Oracle.o
>> -L/u01/app/oracle/product/11.2.0/client_1/lib -L. -lclntsh -lpython2.6 -o
>> build/lib.solaris-2.11-sun4v-2.6-11g/cx_Oracle.so
>> ld: fatal: file /u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so:
>> wrong ELF class: ELFCLASS64
>> ld: fatal: file processing errors. No output written to
>> build/lib.solaris-2.11-sun4v-2.6-11g/cx_Oracle.so
>> collect2: ld returned 1 exit status
>> error: command '/usr/lib/python2.6/pycc' failed with exit status 1
>> #
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> cx-oracle-users mailing list
>> cx-...@li...
>> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users

-- 
Email: chr...@or...
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/

Re: [cx-oracle-users] cx_Oracle-5.1.1 install help (Solaris 11 w/ Oracle DB Client 11.2.0.3 64-bit)

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

Hi,

Looks to me like you are trying to use a 64-bit Oracle client with a
32-bit Python. That won't work. :-) You will need to have a 64-bit
Python. If you already do, the other possibility is that you need a
special switch to specify that you want to build 64-bit binaries. If
that is the case, let me know what needs to be adjusted in setup.py to
make things work for you. Thanks.

Anthony

On Tue, Feb 14, 2012 at 8:54 AM, Brad Hudson <bra...@gm...> wrote:
> Can anyone assist with an install of cx_Oracle-5.1.1 on Solaris 11? I have
> installed the Oracle DB Client 11.2.0.3 (64-bit on SPARC) and receive the
> following error when attempting to build cx_Oracle:
>
> # python setup.py build
> running build
> running build_ext
> building 'cx_Oracle' extension
> /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-sun4v-2.6-11g/cx_Oracle.o
> -L/u01/app/oracle/product/11.2.0/client_1/lib -L. -lclntsh -lpython2.6 -o
> build/lib.solaris-2.11-sun4v-2.6-11g/cx_Oracle.so
> ld: fatal: file /u01/app/oracle/product/11.2.0/client_1/lib/libclntsh.so:
> wrong ELF class: ELFCLASS64
> ld: fatal: file processing errors. No output written to
> build/lib.solaris-2.11-sun4v-2.6-11g/cx_Oracle.so
> collect2: ld returned 1 exit status
> error: command '/usr/lib/python2.6/pycc' failed with exit status 1
> #
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>