On Fri, 8 Jul 2016 08:15:27 -0700 (PDT)
Raj <rajenderreddykompa...@gmail.com> wrote:
> Initially the program giving err driver: bad connection for rows.Err
> (). So I added panic with that error to get the stack trace.
That's very unfortunate as it works right against the debugging by
leading whoever reads your problem statement down the wrong road.
Please don't do that next time: state what's your original problem,
not what you think of it.
> for rows.Next() {
> //stats calculation
> }
> if err := rows.Err(); err != nil {
> panic(err) *// this is line 498*
> }
> rows.Close()
>
> How can find out the reason for that error? Do I need to search in
> the library github.com/alexbrainman/odbc
[...]
Well, instead of asking this question you could just `git grep` the
local clone (what `go get` did for you) of that repository:
odbc% git grep 'bad connection'
mssql_test.go: // driver.ErrBadConn ...
So this gives you a hint on that the error message you're seeing is
just what database/sql/driver.ErrBadConn's Error() message produces.
Let's verify this:
odbc% go doc database/sql/driver.ErrBadConn
var ErrBadConn = errors.New("driver: bad connection")
ErrBadConn should be returned by a driver to signal to the sql
package that a driver.Conn is in a bad state (such as the server
having earlier closed the connection) and the sql package should retry
on a new connection.
To prevent duplicate operations, ErrBadConn should NOT be returned
if there's a possibility that the database server might have performed
the operation. Even if the server sends back an error, you shouldn't
return ErrBadConn.
So yes, this is a legitimate error which should be returned by a
particular driver implementation (github.com/alexbrainman/odbc in your
case) to the database/sql code when the driver thinks something gone
awry with a particular DB connection it manages.
So off you go -- git-gerpping for ErrBadConn this time:
odbc% git grep -F ErrBadConn
conn.go: if err == driver.ErrBadConn {
error.go: return driver.ErrBadConn
mssql_test.go: // driver.ErrBadConn ...
mssql_test.go: if should, is := river.ErrBadConn ...
stmt.go: return nil, driver.ErrBadConn
tx.go: return nil, driver.ErrBadConn
So you go and explore this code to see which cases return ErrBadConn,
and find in error.go/NewError():
if r.State == "08S01" {
return driver.ErrBadConn
}
So you google for ODBC+state+"08S01" [1] and discover that ODBC uses
this connection state to mean "general network failure" or
"communication link failure".
Not terribly interesting but at least two points could be made out:
* The github.com/alexbrainman/odbc is likely not the cause of the
problem.
* You have to dig deeper.
The first round of digging deeper is reading through links found by
Google. Another stab could be studying what [2] offers.
One more possible hint: while I think your connectivity is in fact OK --
otherwise _all_ requests would fail -- I would verify that you're not
hitting some sort of software limit of your server platform. This could
be either an SQL Server limit -- if it's some sort of castrated
"edition", or this could be your OS limit -- say, a non-server Windows
platform has tight limits on the number of concurrent TCP connections
it's able to serve. If these possible causes are ruled out, the next
step I would do is disabling SSL for your connections to your MSSQL
instance and dumping the traffic using Microsoft Network Monitor (which
has excellent dissectors for the MS-TDS protocol) and studying it for
possible hints.
1. https://www.google.com/search?q=ODBC+STATE+"08S01";
2. https://www.microsoft.com/en-us/search/result.aspx?q=ODBC+STATE+08S01
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
