>
>
> On 12-Feb-2002 Jeff Urlwin wrote:
> > <snip>
> >
> >>
> >> >> > > DBI->connect(database=onetoone;host=64.78.148.124;port=1071)
> >> >> > > failed: [iODBC][Driver Manager]Invalid string or buffer
> >> >> length (SQL-S1090)
> >>
> >> This happens because DBD::ODBC tries to use SQLDriverConnect
> >> first and if that
> >> fails it uses SQLConnect. SQLConnect in the ODBC spec is defined
> >> as taking a
> >> Server string (the first arg to SQLConnect) no longer than
> >> SQL_MAX_DSN_LENGTH
> >> which is usually 32.
> >
> > Hmmm...I wonder if I should skip the SQLConnect, if the string is longer
> > than SQL_MAX_DSN_LENGTH?
> >
> >
> >>
> >> >> > > [iODBC][Driver Manager]Data source name not found and no default
> >> >> > > driver specified. Driver could not be loaded (SQL-IM002)(DBD:
> >> >> > > db_login/SQLConnect err=-1) at t/02simple.t line 13
> >>
> >> You did not appear to specify a driver in the connect string.
> You need to
> >> specify one of DSN=, DRIVER= or FILEDSN=.
>
> Ages ago when I discovered DBD::ODBC was calling SQLConnect and
> if that failed,
> SQLDriverConnect I relaxed the SQL_MAX_DSN_LENGTH checking in
> OOB. OOB maps
Actually, it's the other way around (now?). I'm not sure if it's changed (I
can't remember), but it's SQLDriverConnect and if that fails, call
SQLConnect. My thinking would be along the lines of:
/* the ifdef is currently there */
#ifndef DBD_ODBC_NO_SQLDRIVERCONNECT
try SQLDriverConnect()
if success, return success.
otherwise, if the length of "DSN" is > SQL_MAX_DSN_LENGTH, then return
the
error
otherwise (failure) AllODBCErrors() and continue on.
#else
now try SQLConnect() and return results
#endif
> the Server, Username and Password parameters to SQLConnect to
> SQLDriverConnect("DSN=ServerName,UID=Username;PWD=password") so if someone
> calls DBI->connect with a connection string containing attributes
> separated
> by semicolons it continued to work so long as the DSN name was first in
> the string. This was way before there was a reasonable ODBC
> driver manager for
> UNIX and just after DBD::ODBC introduced the requirement for
> SQLDrivers and
> SQLDataSources support (apparently relaxed in later versions).
>
> Now that most people use an ODBC driver manager under DBD::ODBC this has
> returned to not working as I planned as the driver manager tends
> to throw out
> the call to SQLConnect due to SQL_MAX_DSN_LENGTH before I see it and then
> DBD::ODBC falls back on SQLDriverConnect and it works.
>
> As a result, your suggestion of only using SQLDriverConnect (skipping
> SQLConnect) if the connection string is > SQL_MAX_DSN_LENGTH
> would probably work
> except for the recent code which allows DBD::ODBC to link directly with a
> driver that does not support SQLDriverConnect (what would happen
> in this case).
> The OOB FAQ specifically suggests users of DBD::ODBC, unixODBC and OOB use
> DBI->connect('dbi:ODBC:DSN=xxx',...) because it allows longer connection
> strings and automatically fails SQLConnect code but until recent patches I
> supplied to you this had the down side of leaving an ODBC
> diagnostic on the
> stack for SQLConnect failures which was seen if something went
> wrong later.
>
> I guess if first arg to DBI->connect is longer than
> SQL_MAX_DSN_LENGTH then
> calling SQLDriverConnect or signalling an error (if linked
> directly to driver
> which does not have SQLDriverConnect) would be perfectly reasonable as the
> driver manager or driver being called with this long string is
> only likely to
> throw it out as too long anyway when called for SQLConnect.
>
> However, my personal preference would be to call SQLDriverConnect
> FIRST unless
> the driver has #ifdef code in DBD::ODBC saying it does not have
> SQLDriverConnect. Reasoning - unless the connection string is wrong, it
> connects every time, first time, instead of possible failing in
> SQLConnect, only
> to result in calling SQLDriverConnect anyway. As far as my reading
> (and experience) of the ODBC spec is concerned I do not see any reason
> why a reversal of the ordering would have any adverse affects - there
> is no ODBC versioning issue inferred by using SQLDriverConnect
> instead of SQLConnect. Obviously, I have a bias here but I do not
> think it would
> break anything in other drivers if changed this way - partly
> based on the fact
> that OOB never transfers an SQLConnect call as SQLConnect but instead uses
> SQLDriverConnect (as in paragraph above).
Thinking further,
Try SQLDriverConnect (if available)
if that fails and one of the following:
strcmpni(DSN, "DSN=",4) or
strlen(DSN) > SQL_MAX_DSN_LENGTH or
strstr(DSN, ";")
don't try SQLConnect
> else
try SQLConnect
Jeff
