[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Michael Bayer
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

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Lukasz Szybalski
On Wed, Dec 10, 2008 at 4:21 PM, Rick Morrison <[EMAIL PROTECTED]> 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 inc

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Rick Morrison
> > so you mean create_engine('mssql://? > odbc_connect > = > DRIVER > = > {SQLServer > };SERVER=server;DATABASE=database;UID=user;PWD=password') ?I can't > go with that, there has to be some way to plug in a URL handler.if > you really need to send that raw string straight through you can

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Michael Bayer
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 fo

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Rick Morrison
> > mssql://user:[EMAIL PROTECTED]/database? > connect_type=TDS7&other=args&that=are&needed=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 f

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Rick Morrison
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 componen

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Michael Bayer
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 > Server};SERVE

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Lukasz Szybalski
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 b

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Michael Bayer
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 kin

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Rick Morrison
> > > 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 wi

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread desmaj
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

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Lukasz Szybalski
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'

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Lukasz Szybalski
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

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Michael Bayer
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.

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread desmaj
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.

[sqlalchemy] Re: MSSQL pyodbc connection string - broken for me!

2008-12-10 Thread Rick Morrison
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 bes