self._guess_input_sizes([params])
506 try:
--> 507 return self.cursor.execute(query,
self._param_generator(params))
508 except Database.IntegrityError, e:
509 raise utils.IntegrityError,
utils.IntegrityError(*tuple(e)), sys.exc_info()[2]
: ORA-
...
1
>>> print rows
((1,),)
>>> result = cursor.execute(r"SELECT 1 FROM DUAL WHERE DUMMY
LIKE TRANSLATE('X' USING NCHAR_CS) ESCAPE TRANSLATE('\' USING
NCHAR_CS)")
Traceback (most recent call last):
File "", line 1, in
File
"
On Dec 2, 3:17 pm, Tim Sawyer wrote:
> I unpatched mine (changed LIKEC to LIKE) and then ran:
>
> >>> from django.db import connection
> >>> cursor = connection.cursor()
> >>> result = cursor.execute(r"SELECT 1 FROM DUAL WHERE TRANSLATE('A'
> USING NCHAR_CS) LIKE TRANSLATE('A' USING NCHAR_CS) E
On 03/12/10 12:52, Jani Tiainen wrote:
On Thursday 02 December 2010 17:13:48 Tim Sawyer wrote:
Hello,
I'm using Django against an Oracle 10 database. It used to work. Then
they upgraded it to 10.2.0.5 (not sure what from, I can probably find out).
This query now gives: ORA-01425: e
On 02/12/10 19:14, Jirka Vejrazka wrote:
It looks as though something like that may be necessary. For those of
you running into this problem, do you get the error with the following
query?
cursor.execute(r"SELECT 1 FROM DUAL WHERE TRANSLATE('A' USING NCHAR_CS) LIKE
TRANSLATE('A' USING NCHAR_C
> No error for me, but that's on a monkeypatched system. I can try
> without the patch, but only after weekend :(
Actually, screw production servers :) Tried on unpatched Django
1.2.1, got exactly the same result, no error.
Jirka
--
You received this message because you are subscribed to the
> It looks as though something like that may be necessary. For those of
> you running into this problem, do you get the error with the following
> query?
>
cursor.execute(r"SELECT 1 FROM DUAL WHERE TRANSLATE('A' USING NCHAR_CS)
LIKE TRANSLATE('A' USING NCHAR_CS) ESCAPE TRANSLATE('\' USI
On Dec 2, 8:40 am, Jirka Vejrazka wrote:
> P.S. This got me thinking - maybe the Oracle backend could do some
> "autodetection" of which version works fine in the current
> environment? Yes, it'd be extra query at startup I guess, but don't
> really see any other way...
It looks as though someth
> Interesting that I'm seeing this in an upgrade from 10.2.0.4 to 10.2.0.5.
>
> Instead of changing from LIKE to LIKEC - if I add more backslashes will that
> work?
Honestly, I can't tell. It's been too long and I can't test it now :-(((
Jirka
--
You received this message because you are
On 02/12/10 15:40, Jirka Vejrazka wrote:
I'm using Django against an Oracle 10 database. It used to work. Then they
upgraded it to 10.2.0.5 (not sure what from, I can probably find out).
Hi Tim,
sorry, I don't have a solution for you, but you might want to check
out http://code.djangoproj
rom, I can probably find out).
This query now gives: ORA-01425: escape character must be character
string of length 1.
'SELECT "BROKER_LENDER_LOG"."BLL_SECURITY_TOKEN",
"BROKER_LENDER_LOG"."BLL_TRANSACTION",
"BROKER_LENDER_LOG"."BLL
> I'm using Django against an Oracle 10 database. It used to work. Then they
> upgraded it to 10.2.0.5 (not sure what from, I can probably find out).
Hi Tim,
sorry, I don't have a solution for you, but you might want to check
out http://code.djangoproject.com/ticket/14149 and add description
Hello,
I'm using Django against an Oracle 10 database. It used to work. Then
they upgraded it to 10.2.0.5 (not sure what from, I can probably find out).
This query now gives: ORA-01425: escape character must be character
string of length 1.
'SELECT "BROKER_LENDER_LOG"
13 matches
Mail list logo