pyodbc isn't quite DB API 2.0 compliant

[GoogleCodeExporter]

The one issue I've run into is with connection strings. According to PEP 249:

    [1] As a guideline the connection constructor parameters should be
        implemented as keyword parameters for more intuitive use and
        follow this order of parameters:

          dsn         Data source name as string
          user        User name as string (optional)
          password    Password as string (optional)
          host        Hostname (optional)
          database    Database name (optional)

        E.g. a connect could look like this:

          connect(dsn='myhost:MYDB',user='guido',password='234$')

Of course, I realize that implementing this specific interface for ODBC may
be troublesome... plus the fact that this is only a "should", rather than a
"must". Still, it's just one of those things that would be nice. This did
actually cause me some trouble with django-pyodbc, with the way it
constructs its connection strings. You can see a ticket related to that
here: http://code.google.com/p/django-pyodbc/issues/detail?id=18

Preferably I would have refactored it to work as proposed to Django's
psycopg2 adaptor here: http://code.djangoproject.com/ticket/6710  however
that isn't really possible with the current connect interface in pyodbc.

I'm thinking it may also be possible to implement something like this
without breaking API compatibility with the 2.x series. Since currently,
kwargs are not the recommended usage for passing connection strings, then
perhaps if they are used, it could be taken as referring to the interface
mentioned above and otherwise it uses the current pyodbc connect interface.

Original issue reported on code.google.com by tarkatronic on 30 Dec 2008 at 3:32

[GoogleCodeExporter]

The reason I originally chose not to do this is because the ODBC connection 
strings I
work with are usually much more complicated.  I couldn't possibly add all of 
the ODBC
keywords.

If I can, I'll add keyword parameters and make the first string parameter 
optional. 
Then you can use either.

In addition to the keywords above, I'll accept any and put them together into 
the
final connection string.

Original comment by mkleehammer on 31 Dec 2008 at 3:25

• Changed state: Investigating
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Added in 2.1.3

See the updated documentation on the [Module] page.

Original comment by mkleehammer on 31 Dec 2008 at 5:43

• Changed state: Verified

[GoogleCodeExporter]

Original comment by mkleehammer on 21 Nov 2010 at 4:45

• Changed state: Complete