If memory serves, there is already an 'encoding' attribute on each Dialect instance that is normally used in conjunction with another Dialect flag 'convert_unicode'. Not sure if it dovetails with your plans, tho....
On 11/25/07, Paul Johnston <[EMAIL PROTECTED]> wrote: > > > Hi Florent, > > Just realised we'd gone quiet on this thread... > > >humm What bothers me is that I already get this comportement when > >running my query program from a Linux host (using pyodbc same version) > >but need the above mentioned patch on a windows host so there is > >definitely a different behavior. > > > > > Is this a difference in PyODBC or SQLAlchemy? I suspect the former, but > good if you can confirm. > > >>From my point of view I am responsible to give the engine the right > >encoding when I instantiate it. At the moment I have a master database > >that provides me this info and so I feed it to the constructor at > >engine creation time. > > > > > That sounds ok. I'd be happy to add a "string_charset" option or > something that defaults to None which means no decoding. In fact, this > wouldn't have to be MSSQL specific, it could apply to any DB. > > Paul > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
