FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Fri, 28 Sep 2012 18:11:57 +0200
Alberto Pulvirenti <alberto.pulvirenti AT crowdengineering.com> wrote:

> The problem, in this logon trigger is that it has set to OFF the
> following three variables:
> 
> set ansi_warnings off
> set ansi_padding off
> set concat_null_yields_null off
> 
> 
> and the admin of this instance told me that he will NEVER switch them
> to ON. Then I must find a way to access this instance having these
> setting as they are currently.

http://msdn.microsoft.com/en-us/library/bb326598.aspx

I see now.  I never used logon triggers, and was only dimly aware of
their existence.  Now I am slightly lessly dimly aware of them.  

It's too bad your DBA has chosen not to use his power for good.
Instead of ensuring that every logon has particular session properties
he deeems necessary (by issuing the very statements you found), he's
instead prevented logons by clients that don't.  

Sigh.  But you have the power, because you have the compiler.  Look in
src/dblib/dblib.c for the phrase "we're not an ODBC driver".  Delete
that line, recompile, and try to connect.  If that works, we know
what the problem is.  Other than your DBA, of course.  

In option_flag2 in the TDS 7 login packet is a bit that signals to the
server that the client is an ODBC driver.  It's turned off in db-lib
because that's how db-lib always worked.  Nothing prevents the FreeTDS
db-lib from turning that bit on, or from making it an option.  I think
you will find the bit presents no problem at all.   (Curious, though,
isn't it, that it's not the vendor but your own organization that
imposes this effort on you?)  

If you would like to make this a run-time option for FreeTDS db-lib,
I'm sure others would find it beneficial, too.  

HTH.  

--jkl