Frank Millman wrote:
> Filipe wrote:
> Try out the suggestions and let us know what happened. I for one will
> be very interested.
The last version of ODBTPAPI is 0.1-alpha, last updated 2004-09-25.
Which is a bit scary...
I might try it just the same though.
--
http://mail.python.org/mailman/l
Filipe wrote:
>
> The only reason I still think Pymssql (and therefore, DB-Library) might
> be the best option is that, it is the only one I know that is both
> cross-platform and free - as in beer and as in freedom. (check, in this
> thread, a previous message by Tim Golden)
>
I have bookmarked
Dennis Lee Bieber wrote:
> If I interpret a short Google search, DB-Library might date back to
> the original Sybase core from which M$ SQL Server was spawned. M$'s site
> recommends /not/ using DB-Library but to use ODBC/OLEDB methods instead
> -- something about ODBC being extensible. Could be c
Dennis Lee Bieber wrote:
> The setting most likely has to be made on the machine running the
> server -- and M$ SQL Server doesn't exist on Linux either
>
> If the conversion was being done by some client library on Windows,
> then again, since that library probably doesn't exist on L
Hi Martin,
> One would have to ask the authors of pymssql, or Microsoft,
> why that happens; alternatively, you have to run pymssql
> in a debugger to find out yourself.
Tried running pymssql in a debugger, but I felt a bit lost. There are
too many things I would need to understand about pymssql
Filipe wrote:
> They do, in fact, output different values. The value outputed by
> pyscripter was "135" (x87) while the value outputed in the command line
> was "216" (xd8). I can't understand why though, because the script
> being run is precisely the same on both environments.
That's indeed surp
Martin v. Löwis wrote:
> Filipe wrote:
> > term = row[1]
> > print repr(term)
> >
> > output I got in Pyscripter's interpreter window:
> > 'Fran\x87a'
> >
> > output I got in the command line:
> > 'Fran\xd8a'
> >
> > I'd expect "print" to behave differently according with the console's
> > encoding
Filipe wrote:
> term = row[1]
> print repr(term)
>
> output I got in Pyscripter's interpreter window:
> 'Fran\x87a'
>
> output I got in the command line:
> 'Fran\xd8a'
>
> I'd expect "print" to behave differently according with the console's
> encoding, but does this mean this happens with repr(
Martin v. Löwis wrote:
> Filipe wrote:
> > output ---
> > u'Fran\xd8a'
> > FranØa
> >
> >
> > What do you think? Might it be Pymssql doing something wrong?
>
> I think the data in your database is
Filipe wrote:
> output ---
> u'Fran\xd8a'
> FranØa
>
>
>
> What do you think? Might it be Pymssql doing something wrong?
I think the data in your database is already wrong. Are you
sure the valu
> In summary
>
> + Depends on what your requirements are, but...
>
> + Go for ADODBAPI for the widest spread of versions and licenses, but
> the least cross-platformability
> + Go for Object Craft MSSQL for <= 2.3 and best overall behaviour
> + Go for pymssql for >= 2.4 with some small limitations
Martin v. Löwis wrote:
> > What do you mean by "ANSI-to-OEM conversion is enabled"?
>
> See AutoAnsiToOem in
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;199819
>
I checked the registry key
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\DB-Lib", and
verified AutoAnsiToOem w
Marc 'BlackJack' Rintsch wrote:
> The `unicode()` call doesn't fail here but the ``print`` because printing
> unicode strings means they have to be encoded into a byte string again.
> And whatever encoding the target of the print (your console) uses, it
> does not contain the unicode character u'\x
Frank Millman wrote:
> You did not mention the odbc module from Mark Hammond's win32
> extensions. This is what I use, and it works for me. I believe it is
> not 100% DB-API 2.0 compliant, but I have not had any problems.
>
> I have not tried connecting to the database from a Linux box (or from
> a
Filipe wrote:
>> Also, it appears that DB-Library (the API used by pymssql) always
>> returns CP_ACP characters (unless ANSI-to-OEM conversion is enabled);
>> so the "right" encoding to use is "mbcs".
>
> do you mean using something like the following line?
> term = unicode(row[1], "mbcs")
Correc
Filipe wrote:
> Hi,
>
> I've done some searching and settled for pymssql, but it's not too late
> to change yet.
> I've found these options to connect to a MSSqlServer database:
>
> Pymssql
> http://pymssql.sourceforge.net/
>
> ADODB for Python (windows only)
> http://phplens.com/lens/adodb/adodb-
[Filipe]
| I've done some searching and settled for pymssql, but it's
| not too late to change yet.
Indeed, the good thing about the DBAPI-compatibility of
such libraries is that you can often switch and switch
about with no cost to you at all. (Believe me, I've done
it). Sometimes there is a co
In <[EMAIL PROTECTED]>, Filipe wrote:
> The error I'm getting is beeing thrown when I print the value to the
> console. If I just convert it to unicode all seems ok (except for not
> beeing able to show it in the console, that is... :).
>
> For example, when I try this:
> print unicode("Fran\xd8a
Fredrik Lundh wrote:
> works for me, given your example:
> >>> s = "Fran\xd8a"
> >>> unicode(s, "iso-8859-1")
> u'Fran\xd8a'
>
> what does
> print repr(row[1])
>
> print in this case ?
It prints:
'Fran\xd8a'
The error I'm getting is beeing thrown when I print the value to the
console. If I
Hi,
Martin v. Löwis wrote:
> Also, it appears that DB-Library (the API used by pymssql) always
> returns CP_ACP characters (unless ANSI-to-OEM conversion is enabled);
> so the "right" encoding to use is "mbcs".
do you mean using something like the following line?
term = unicode(row[1], "mbcs")
W
Filipe wrote:
> Thanks for the reply.
> Instead of:
> term = row[1]
> I tried:
> term = unicode(row[1], "iso-8859-1")
>
> but the following error was returned when printing "term":
> Traceback (most recent call last):
> File "test.py", line 11, in ?
> print term
> File "c:\Program
Hi Fredrik,
Thanks for the reply.
Instead of:
term = row[1]
I tried:
term = unicode(row[1], "iso-8859-1")
but the following error was returned when printing "term":
Traceback (most recent call last):
File "test.py", line 11, in ?
print term
File "c:\Program Files\Python24\lib\enco
Fredrik Lundh wrote:
> looks like the DB-API driver returns 8-bit ISO-8859-1 strings instead of
> Unicode
> strings. there might be some configuration option for this; see
>
Where did you want to point the OP here?
> in worst case, you could do something like
>
> def unicodify(value):
>
Filipe wrote:
> In the console output, for a record where I expected to see "França"
> I'm getting the following:
>
> "" -When I print the type (print type(row[1]))
> "Fran+a" -When I print the "term" variable (print term)
> "Fran\xd8a" -When I print all the query results
Hi all,
I'm starting to learn python but am having some difficulties with how
it handles the encoding of data I'm reading from a database. I'm using
pymssql to access data stored in a SqlServer database, and the
following is the script I'm using for testing purposes.
-
25 matches
Mail list logo
