On 5/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On 5/4/07, benk <[EMAIL PROTECTED]> wrote: > ... > > > > text length = 3998, saved length = 3998 > > text length = 3999, saved length = 3999 > > text length = 4000, saved length = 4000 > > text length = 4001, saved length = 2001 > > text length = 4002, saved length = 2002 > > > ... > > Django on Linux + Oracle on Linux : Fail > > Django on WinXP + Oracle on Linux : Fail > > Django on Linux + Oracle on WinXP : Pass > > Django on WinXP + Oracle on WinXP : Pass > ... > > however I have no idea what this could be because from what I can see > > both > > instances of the database are "identical". > > Speaking in total ignorance of NCLOB and the DB-API implementation, > could this be a unicode byte order problem? I'm not sure why the 4k > boundary would matter, but that's what it smells like to me.
Actually, the 4k boundary is the part that makes sense to me. We're binding strings naively, without calling setinputsizes, so I believe they get bound as a VARCHAR2 if they're 4k or less, and they get bound as an CLOB if they're longer than 4k. As for what the actual problem is, my guess is as good as yours. It's probably an encoding problem as you said. All I can recommend is to fiddle with it and see if anything clears it up. Some things to try would be changing the database's character encoding, changing the Django process's NLS_LANG setting, or changing the table to use CLOB instead of NCLOB. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
