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
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.
On Dec 10, 2008, at 2:49 PM, desmaj wrote:
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.
DSNs would eliminate these issues for SQLAlchemy.
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
On Wed, Dec 10, 2008 at 2:05 PM, Michael Bayer [EMAIL PROTECTED] wrote:
On Dec 10, 2008, at 2:49 PM, desmaj wrote:
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
On Dec 10, 3:05 pm, Michael Bayer [EMAIL PROTECTED] wrote:
this is just my 2c, im not here to say how it should be done or not.
I would think that the standard SQLA host/port connect pattern should
work as well if we just are aware of what kind of client library we're
talking to. If we
Whats the status of 0.5, is DSN the default in trunk now ?
DSN is the first choice in MSSQLDialect_pyodbc.make_connect_string
right now.
That's not what I see. I just pulled the 0.5 trunk, which I haven't been
tracking lately. Still uses the 'dsn' keyword build a connection string with
DSN is the one keyword for host that is universally recognized as
part of odbc proper, so it makes sense that host/port would be the
exception case - especially considering it seems like we now have to
pick among many formats for propagating host/port and are going to
require some kind
On Wed, Dec 10, 2008 at 3:42 PM, Rick Morrison [EMAIL PROTECTED] wrote:
Whats the status of 0.5, is DSN the default in trunk now ?
DSN is the first choice in MSSQLDialect_pyodbc.make_connect_string
right now.
That's not what I see. I just pulled the 0.5 trunk, which I haven't been
Here is my take, keeping in mind i havent used a windows machine in
about a year:
On Dec 10, 2008, at 5:13 PM, Lukasz Szybalski wrote:
cnxn = pyodbc.connect(DSN=dsnname;UID=user;PWD=password)
mssql://user:[EMAIL PROTECTED]/
or
cnxn = pyodbc.connect('DRIVER={SQL
Something like this:
As of 0.5 for pyodbc connections:
a) If the keyword argument 'odbc_connect' is given, it is assumed to be a
full ODBC connection string, which is used for the connection (perhaps we
can include a facility for Python sting interpolation into this string from
the dburi
mssql://user:[EMAIL PROTECTED]/database?
connect_type=TDS7other=argsthat=areneeded=foo
using connect_type, or some better name, we can map the URL scheme
to an unlimited number of vendor specific connect strings on the back.
Yeah, it's exactly that kind of mapping that has so far been a
On Dec 10, 2008, at 5:21 PM, Rick Morrison wrote:
Something like this:
As of 0.5 for pyodbc connections:
a) If the keyword argument 'odbc_connect' is given, it is assumed to
be a full ODBC connection string, which is used for the connection
(perhaps we can include a facility for
On Dec 10, 2008, at 5:39 PM, Rick Morrison wrote:
Its really not a big deal to maintain if
we just make a modular URLHandler class that given a sqlalchemy.URL
and a DBAPI, returns a connection. Anytime someone has some new
goofy string they need, they can provide one of these, we add
14 matches
Mail list logo
