FreeTDS Development Group

[Marc Abramowitz <msabramo AT gmail.com>]

Ah, thanks. That *is* a lot easier!


On Sun, Jan 5, 2014 at 11:21 AM, Frediano Ziglio <freddy77 AT gmail.com> wrote:

> Hi Marc,
>   should be much easier than this. TDSSOCKET has a login parameter
> that during login is not NULL and contains the login informations. If
> is not valid... I think it should!
>
> Frediano
>
> 2014/1/4 Marc Abramowitz <msabramo AT gmail.com>:
> > I think code may better explain what I'm looking for. Something like
> this:
> >
> > https://gitorious.org/freetds/freetds/merge_requests/24
> >
> > The particular implementation here is probably not ideal, as I stored the
> > server name/port in a global variable, which seems pretty icky. I
> > considered adding a field to the dbproc struct -- this seems like a
> better
> > place for it but then I shied away from doing that because I wondered if
> > you guys try to limit adding stuff to structs in case it affects binary
> > compatibility? (though perhaps it's OK if the client always deals with
> > pointers to the structs and treats them opaquely?). Or maybe it could
> even
> > be passed on the stack, though that looked tricky because there are so
> many
> > levels.of calls.
> >
> > In any case, this shows the augmented error message that I think would be
> > ideal. If the idea is good and the implementation can be improved, I'm
> > willing to fix it up, if you give me some guidelines.
> >
> > Marc
> >
> >
> > On Thu, Jan 2, 2014 at 6:31 PM, Marc Abramowitz <msabramo AT gmail.com>
> wrote:
> >
> >> Recently a well-known Python database module developer was using pymssql
> >> and it wasn't working for him because he was connecting to a SQL Server
> on
> >> a non-standard port and he had put this port in an entry in his
> >> freetds.conf and was able to connect with tsql, but he was getting
> errors
> >> when trying to connect with pymssql, which turned out to be because
> pymssql
> >> calls DB-LIB functions that don't end up consulting freetds.conf to get
> the
> >> port and so the connect was failing for him, whereas it passed with
> tsql,
> >> so he thought that he had discovered a bug in pymssql.
> >>
> >> The solution was simple. By adding an explicit `port` argument to his
> >> Python code, stuff worked. But we only discovered this after I advised
> him
> >> about TDSDUMPCONFIG and such and ultimately figured it out.
> >>
> >> The takeaway for me and he said this as well, is that it would be nice
> if
> >> there were better error messages on connection failure. Either from
> pymssql
> >> or FreeTDS. This would help people diagnose their connection issues much
> >> quicker.
> >>
> >> Currently a failed connection results in an error like this:
> >>
> >> Error 20009 (severity 9):
> >>         Unable to connect: Adaptive Server is unavailable or does not
> exist
> >>         OS error 61, "Connection refused"
> >>
> >> Note that it doesn't say what IP address, port, etc. it was trying to
> >> connect to.
> >>
> >> Is there a way to either augment the default FreeTDS error messages --
> >> e.g.: "Connection refused to 127.0.0.1:1433" or DB-API calls that,
> given
> >> the dbproc or such, will give the IP address, port, etc. so that I can
> >> print them out in my error handler?
> >>
> >> Marc
> >>
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>