On 06-Jan-2003 Jeff Urlwin wrote:
> [snip]
>>
>> BTW, SQLConnect (the ODBC 1.0 function DBD::ODBC can use) has
>> a limit on the size of the string you can pass in the first
>> argument (I think it is 32). DBD::ODBC used to get around
>> this by looking for "DSN=" at the start of the string and
>> using SQLDriverConnect instead. I'm not sure without
>> examining the source again that a connection string starting
>> with "DRIVER=" will go to SQLDriverConnect (which it needs to).
>
> FYI -- DBD::ODBC checks for DSN= or a strlen(DSN) > SQL_MAX_DSN_LENGTH
> and thus should avoid the call to SQLConnect. And, the current version
> only falls back to SQLConnect if SQLDriverConnect fails. I believe this
> is is "safe" behavior, but any suggestions you have, Martin, are most
> welcome.
Sorry for slowness of reply but I've been tinkering with a firewall for a few
days and could not access my email (this is ongoing to may happen again over
the next few days). Current solution sounds OK to me, I forgot the
strlen(DSN_string) > SQL_MAX_DSN_LENGTH bit was there.
The only situation I've seen that can be a little confusing is this:
DBI->connect('dbi:ODBC:dsnname', 'dbuser', 'dbpass')
works
and
DBI->connect('dbi:ODBC:DSN=dsnname', 'dbuser', 'dbpass')
fails with whatever message the database engine returns for invalid
user/password (in MS SQL Server it is something to do with NULL user).
First time I hit this it took a little head scratching to work out what was
going on. In the first case SQLConnect('dsnname', 'dbuser', 'dbpass') is called
and as the database engine required a username/password all was OK. In the
second case SQLDriverConnect(..., "DSN=dsnname", ...) was called and I got the
NULL user error. Adding ";UID=dbuser;PWD=dbpass;" to the "DSN=dsnname" fixes
the problem but it can be a little confusing if you don't recognise the problem.
Perhaps a note about this in the docs might help.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
