For those of you using ADO
From: Robert Brewer (fumanchu_at_amor.org)
Date: 11/25/03
- Next message: Paul McGuire: "Re: need object crafts csv module pre-compiled for 2.3"
- Previous message: Greg Ewing (using news.cis.dfn.de): "Re: Origin of the term "first-class object""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 24 Nov 2003 16:57:47 -0800 To: <python-list@python.org>
This has to be the oddest thing I've yet come across. My current Big
Project uses a win32com wrapper to ADO. For weeks now, I've wrestled
with connection strings: adding parameters, then removing them, then
changing the order, then trying silly things like extra semicolons, etc.
I finally nailed down a thesis for Why It Was So Hard--the ADO 2.7 dll
ignores the first parameter in the connection string. I have to admit
I'm guessing it's ADO's fault, that win32com.client just passes the
string along. Correct me if I'm wrong, but the fix is simple enough I
don't feel I need to track it down further.
The fix is the same as the proof:
"DSN=RE7_1;UID=mcuser;PWD=*******;"
doesn't work, giving an error like "Neither DSN nor SERVER found in
connection string," (this is for MS SQL Server; different messages with
the same intent result on e.g. MS Access), while:
"DSN=RE7_1;UID=mcuser;PWD=*******;DSN=RE7_1;"
does work. Further combinations with and without duplicating the first
param produce similar results. Go figure.
Not really a Python problem, I don't think, but I figured someone might
be aided by the theory/fix.
Adding another page to the Googlable universe,
Robert Brewer
MIS
Amor Ministries
fumanchu@amor.org
- Next message: Paul McGuire: "Re: need object crafts csv module pre-compiled for 2.3"
- Previous message: Greg Ewing (using news.cis.dfn.de): "Re: Origin of the term "first-class object""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
