Hello.
No, I was not able to connect via pymssql. Furthemore I would like to use pyodbc
if it is the preferred way. I just did not know that when I started with
pymssql.
It really is a misconfigured character encoding issue in pyodbc / freetds on my
part. I am just clueless as to what should I
Also, this works correctly:
isql -v zfp efractal efR@cZFP13
+---+
| Connected!|
| |
| sql-statement |
| help [tablename] |
| quit
Hi,
I've been using SQLAlchemy for the last couple of weeks. I'll definitely
call myself a beginner so I apologize if I'm missing something obvious with
this question :)
I'm working with a database where there is data split across tables with
the exact same structure, so there are cases
On Oct 9, 2012, at 6:03 AM, Ladislav Lenart wrote:
Hello.
No, I was not able to connect via pymssql. Furthemore I would like to use
pyodbc
if it is the preferred way. I just did not know that when I started with
pymssql.
It really is a misconfigured character encoding issue in pyodbc
On Oct 9, 2012, at 9:54 AM, Benjamin Gonzalez wrote:
Hi,
I've been using SQLAlchemy for the last couple of weeks. I'll definitely
call myself a beginner so I apologize if I'm missing something obvious with
this question :)
I'm working with a database where there is data split
Hello.
I made some progress. I have client charset in my freetds config file. I am also
certain that the config and the charset is used by pyodbc / freetds combo.
Without it I get 'Ne?...'. With it I get back a str encoded in utf-8. I also
enabled freetds logging where I clearly see two
On Oct 9, 2012, at 5:42 PM, Michael Bayer wrote:
On Oct 9, 2012, at 2:17 PM, Benjamin Gonzalez wrote:
Thanks for the valuable suggestions. You are actually correct: the scheme
that they are using is sharding across tables, that's why the structure is
the same.
And the way I was
