On Nov 5, 2007 6:50 PM, Paul Johnston <[EMAIL PROTECTED]> wrote: [...]
> Are your strings VARCHAR or NVARCHAR? > > If they're NVARCHAR, all this will just work as-is with SA and MSSQL - > are you having any specific problems? > > If they're VARCHAR, then we need to think some more. I'm still not sure > what the semantics should be when trying to save a unicode object in a > non-unicode storage area. I have isolated the problem a little bit more: my column is defined in the MSSQL server as a user defined type which is based on VARCHAR. I tried to force the user defined type to be based on NVARCHAR and it works. BUT... I cannot do this in production since I don't own the dbs and they are used by other applications, I just have a read-only access on them to do some interrogations. My patch then "works" because in fact the object that come back from sql server is a binary string encoded using the aforementioned 'codepage'. I had contact with Christophe de Vienne (see above) who has access to the same databases from the same proprietary editor and confirmed the issue. Christophe also noted that in Linux since the supports_unicode resolves to False, we don't encounter problems. But since my code will run on Windows I am still searching for a way to sort that mess :) Thanks for the help and time Paul :-) Regards, Florent. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
