The logic in JDBC::Database.connect attempts to connect first using
the
DriverManager, and if that fails, uses the driver directly.
However, commit bdd1e3a4476a1033990efdafa2f2ceb938b207ac changed
the logic slighty. If the second (driver) attempt fails, it raises
the
original exception thrown by the driver manager instead of the one
thrown
by the driver itself.
In our case this is causing a loss of detail. Note the exception
messages in the following scenarios.
bad username/password using windows auth:
driverManager: java.sql.SQLException:
No suitable driver found for jdbc:sqlserver://
localhost;applicationName=XYZ
driver: com.microsoft.sqlserver.jdbc.SQLServerException:
Login failed for user 'JOESDOMAIN\joeblow'.
bad username/password using sql auth:
driverManager: java.sql.SQLException:
No suitable driver found for jdbc:sqlserver://
localhost;applicationName=XYZ
driver: com.microsoft.sqlserver.jdbc.SQLServerException:
Login failed for user 'x'.
bad host:
driverManager: java.sql.SQLException:
No suitable driver found for jdbc:sqlserver://
bad_host;applicationName=XYZ
driver: com.microsoft.sqlserver.jdbc.SQLServerException:
The TCP/IP connection to the host bad_host, port
1433 has
failed. Error: "null. Verify the connection
properties, check
that an instance of SQL Server is running on the
host and
accepting TCP/IP connections at the port, and that
no firewall
is blocking TCP connections to the port.".
I'm inclined to simply back out the second part of this commit, and
allow the
driver's exception through, but I wanted to hear what the rationale
was in the
first place. Are there situations in which the driverManager
exception is more
informative?
-Matt
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
