On Wed, Dec 10, 2008 at 1:49 PM, desmaj <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 1:27 pm, "Rick Morrison" <[EMAIL PROTECTED]> wrote:
>> This has been bandied back and forth for months, and I think it's becoming
>> clear that having sqla map dburl's to ODBC connection strings is a losing
>> battle. Yet another connection argument is not sounding very attractive to
>> me.
>>
>> Perhaps a simple reductionist policy for ODBC connections would be best. The
>> user would either specify a DSN, which would be passed to the driver, or
>> give a full ODBC connection string (presumably via a keyword arg) which
>> would be used verbatim. Anything else seems to degrade to the kind of
>> error-prone heuristics we see here.
>
> You make a good point about heuristics. That describes the current
> implementation as well as my initial proposal involving argument
> values of 'windows' and 'freetds' and stuff. I'm glad you pointed that
> out. For the reasons I'll add below, I still favor a connection
> argument, but the argument values should indicate the outcome and not
> try to attribute behaviors to platforms when there's a lack of full
> understanding about what those behaviors are. I still can't think of
> good names.
>
> I dislike the idea of relying heavily on DSNs since I don't want SA to
> tell people how to manage their systems. Giving full support to DSN-
> less connections let's SA work with existing systems.
>
> Depending on a keyword argument seems troublesome, too, since there
> are so many existing configurations using SA that count on being able
> to specify connection information through a dburl. sqlalchemy-migrate
> is the one that I'm working with now. I may be overstating this, but
> the sense that I have is that using keyword arguments to specify
> connection information is something that most people don't do. I do it
> all the time so I'm glad it's there, but it's always felt like a
> workaround.
>
>> It is a big change from the current behavior of trying to "fit in" with the
>> way that the dburl works for other dialects, though. Jason's dialect
>> refactor is going to confront this problem head-on as well. Any thoughts
>> regarding this from that perspective?
>
> I don't know what this wll look like, so maybe the discussion is moot.
> I look forward to hearing about it.
I've been using the following connection string with unixodbc for a
year now since 0.4.6 version.
sqlalchemy.create_engine("mssql://user:[EMAIL
PROTECTED]:1433/databasename?driver=TDS&odbc_options='TDS_Version=8.0'")
which gets translated into :
pyodbc.connect("SERVER=xxxx;UID=xxx;PWD=xxx;DRIVER={TDS};TDS_Version=7.0")
It works great for me.
So what is not working exactly? Can you provide an example:
Have you setup the unixodbc/freetds already?
http://lucasmanual.com/mywiki/unixODBC
Thanks,
Lucas
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
