On 7/29/15 4:27 AM, Ladislav Lenart wrote:
Hello.
I don't know why but the problematic version uses bytes as keys in the params
dictionary (e.g. b'batch_id') whereas the working version uses strings (e.g.
'batch_id'). I am not a Python 3 expert but I think that the two types are
distinct and
On 7/28/15 11:17 AM, Bob Ternosky wrote:
I'm new to SQLAlchemy and have been playing with it for a week. I've
got many SELECT based pieces working and exercising properly, but have
hit a huge wall when trying to test inserts. Worse, what's happening
makes no sense at all.
This will hopefully
Hello.
I don't know why but the problematic version uses bytes as keys in the params
dictionary (e.g. b'batch_id') whereas the working version uses strings (e.g.
'batch_id'). I am not a Python 3 expert but I think that the two types are
distinct and thus the search for a string fails. This would
I'm new to SQLAlchemy and have been playing with it for a week. I've got
many SELECT based pieces working and exercising properly, but have hit a
huge wall when trying to test inserts. Worse, what's happening makes no
sense at all.
This will hopefully contain the full set of information needed.
Just curious, can you try out cx_Oracle 5.1.3? I've seen some problems
reported with Py3K and cx_Oracle 5.2.
On 7/28/15 11:17 AM, Bob Ternosky wrote:
I'm new to SQLAlchemy and have been playing with it for a week. I've
got many SELECT based pieces working and exercising properly, but have
That did it.
2015-07-28 12:06:16,283 INFO sqlalchemy.engine.base.Engine INSERT INTO
corp.test_table (batch_id, batch_type, scheduled_date, status, emp_id,
bill_per, label, log_file, debug_file, completed_date) VALUES (:batch_id,
:batch_type, :scheduled_date, :status, :emp_id, :bill_per,
Glad it worked out! Sorry my suggestions didn't pan out -- 90% of oracle
issues i've had have come down to some default case setting in a file I
didn't know about.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group