Skip to Content.
Sympa Menu

freetds - RE: [freetds] Config or environment setting for toggling quoted identifiers setting

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Mark Gruetzner" <mgruetzner AT rw3.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Config or environment setting for toggling quoted identifiers setting
  • Date: Tue, 24 Jun 2003 14:39:43 -0500

That makes sense. I've got some time before I need to resolve this on
my end (a few weeks), so I may wait to see if you guys incorporate a fix
by then...else, I will opt for the quick fix you suggest below...

Thanks a ton!
-Mark

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Lowden, James K
Sent: Tuesday, June 24, 2003 2:21 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Config or environment setting for toggling quoted
identifiers setting


> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: June 24, 2003 5:57 AM
>
> > It would very
> > strange, though, for the same database to exhibit different defaults
> > depending on the protocol version. Is that what you're seeing?
>
> option_flag2 |= 0x02; /* client is an ODBC driver */
...
> When we log in using the TDS 7 protocol, by setting that bit in the
> option_flag2, we claim to be an ODBC driver.

Understood.

> If you look at SQL server books online, under "ANSI
> compliance options" you
> will see many statements like:
>
> "By default, ODBC and OLE DB clients issue a connection-level
> SET statement
> setting QUOTED_IDENTIFIER to ON when connecting to SQL Server."

Which is exactly what we don't do. We don't issue a "connection-level
SET
statement". We just claim to be an ODBC driver, even when we're not.

The behavior is also not as described in the documentation; it is what
you
said it is. Setting the bit on turns QUOTED_IDENTIFIER ON all by
itself; no
set command need be sent. I just proved that here. Commenting that
line
out reverts the behavior.

With "option_flag2 |= 0x02":

$ tsql -U$U -P$P -S$S
...
1> select "hi"
2> go
Msg 207, Level 16, State 3, Server NTS0214, Line 1
Invalid column name 'hi'.
1> select 'hi'
2> go

hi
1>


Without "option_flag2 |= 0x02":

$ tsql -U$U -P$P -S$S
...
1> select "hi"
2> go

hi
1> select 'hi'
2> go

hi
1>

<pedantic> We're in uncharted waters. There no other db-lib on the
planet
that speaks TDS 7.0; Microsoft's uses TDS 4.2. </pendantic>

We should conform to the db-lib documentation (and behavior), turning
off
QUOTED_IDENTIFIER regardless of TDS version.

Mark, the quick fix if you have GNU iconv installed is for you to use a
recent snapshot and comment out the line in login.c. That will make all
your connections, regardless of which library you use, default to
QUOTED_IDENTIFIER OFF. Note this is highly experimental. I expect it's
completely safe, but you're the #1 client, if you see what I mean.

A harder fix would be to find the same offset in 0.60. I'm not going to
pursue that myself, because I'm more concerned with doing the Right
Thing.

To DTRT, we have to make login.c aware of whence we come. It has to
know if
it's logging in on behalf of an ODBC client or not, and set the flag
accordingly. That will take a little work, because that information (by
design) isn't in the TDSSOCKET.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged
and confidential information and is intended only for the use of the
person(s) named above. If you are not the intended recipient, or an
employee or agent responsible for delivering this message to the
intended recipient, any review, dissemination, distribution or
duplication of this communication is strictly prohibited. If you are not
the intended recipient, please contact the sender immediately by reply
e-mail and destroy all copies of the original message. Please note that
we do not accept account orders and/or instructions by e-mail, and
therefore will not be responsible for carrying out such orders and/or
instructions.


_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds





Archive powered by MHonArc 2.6.24.

Top of Page