FreeTDS Development Group

[Alberto Pulvirenti <alberto.pulvirenti AT crowdengineering.com>]

Dear James,

I still want to test a little bit more, but it seems you found the problem,
indeed.
About the DBA, I agree with you but that's the life.

How could it become a runtime option?

A useful option could be to set it as a boolean data member in the
DBLIBCONTEXT object, and add it as an option in the dbinit() function,
setting as default its current behaviour.

Thanks

Best and thankful regards

Alberto

2012/9/29 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>