Re: Difference between tsql and libsybdb
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 28 Sep 2012 18:11:57 +0200 Alberto Pulvirenti <[email protected]> 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