Re: Way to get connection params on failure?

The problem of your implementation is that TDSECONN is passed by
libTDS and not all libraries add the required parameter so you can
have a not formatted string in other libraries.

Mixing normal string and string with format looks a bit security suspect to me.

Frediano

2014/1/4 Marc Abramowitz <[email protected]>:
> 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 <[email protected]> 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
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds