Skip to Content.
Sympa Menu

freetds - Re: [freetds] Cannot Use DBVERSION_72 With DBLIB In 0.91 Release

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Ken Collins <ken AT metaskills.net>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Cannot Use DBVERSION_72 With DBLIB In 0.91 Release
  • Date: Sun, 4 Sep 2011 10:21:57 -0400


Hey James,

>> 1) I can not configure FreeTDS --with-tdsver="7.2". Is this an
>> oversight?
>
> Yes, maybe. It's not fully supported, as you've found out.

I think that's fine, but I had users telling me they were compiling
--with-tdsver to 7.2 and I had to map this out to see what was both default
configureable and usable. Sadly, I don't think most people understand that
--with-tdsver is just a default which can be defined more appropriately in a
few other places, client, freetds.conf, TDSVER env, etc.

>> 2) I found out that dbsetversion is basically a no-op that sets a
>> global.
>
> Sorry? A "no-op that sets a global" is a contradiction.

Maybe a bad term on my part, the code comment said it has "No effect on
behavior". It does set the global and that global is not used anywhere from
my code search too.

>> However, it has not been updated with DBVERSION_72 and was
>> throwing a bunch of "FreeTDS: db-lib: exiting because client error
>> handler returned INT_EXIT for msgno 20206" which was misleading.
>
> Message 20206 is SYBEIVERS, "Illegal version level specified." (I
> don't like "illegal", but that's what Sybase uses.)
>
> Acknowledged, this behavior is surprising and db-lib's non-support of
> TDS 7.2 isn't documented. Is that what you mean by "misleading"?

Yes. To be fair tho 8.0 (now 7.1) has always worked for me for every data
type I tested, including varchar(max), and nvarchar(max) in both 0.82 and
0.91. I have been getting a lot of support requests where I see people both
saying they are compiling with 7.2 and setting tds version to 7.2 because
that is what FreeTDS.org says to use for SQL Server 2005 support. Which from
my perspective is not true. On top of possible now too :)

It has led to them not being able to use TinyTDS, see below in for more...

>> Should it be patched like so?
>>
>> --- dblib.c
>> +++ (clipboard)
>> @@ -5801,8 +5801,8 @@
>> case DBVERSION_42:
>> case DBVERSION_46:
>> case DBVERSION_100:
>> - case DBVERSION_70:
>> - case DBVERSION_80:
>> + case DBVERSION_71:
>> + case DBVERSION_72:
>> g_dblib_version = version;
>> return SUCCEED;
>> default:
>
> No. 7.0 is a valid version, and 80 is an alias for 71:
>
> sybdb.h:78 #define DBVERSION_80 DBVERSION_71

Understood, I saw that. Now that I know 7.2 is not fully supported, the
existing code makes sense.

>> 3) Even if I do not use dbsetversion and avoid the problem above and
>> instead rely on dbsetlversion(DBVERSION_72), I can not get a
>> connection. The message is "TDS version downgraded to 7.1!" and it is
>> driving me nuts. I consistently get this error weather I use the
>> TDSVER environment variable, freetds.conf setting, etc. Any insight?
>
> That error *message* is courtesy of yours truly. Previously, the
> downgrade occurred silently.
>
> The reason for the message is "explained" in login.c:
>
> /* disable tds9 if iconv wanted, currently not supported */
>
> I have not had time to investigate what that really means, or whether
> the downgrade is necessary and, if so, what might be done. I accept
> that iconv could be involved, and I've concluded that charset
> conversion should be removed from libtds.

Re the error I mentioned above. To get TinyTDS ruby wrapper working, I simply
had to return INT_CONTINUE for that message above. Now all is good and tests
green. So in short, people can continue to think that compiling and setting a
tds version to 7.2 is actually controlling everything all the way up to
TinyTDS and in actuality I'll be doing the right thing and setting a tds
version (DBVERSION_71 - number 5) wit the dbsetlversion() function.

> libtds is undergoing major change, possibly even a rewrite if I am able
> to demonstrate feasibility and efficacy. When iconv is removed from
> FreeTDS and libtds supports TDS 7.3 (yes, 7.3), we'll be in a position
> to support all datatypes in db-lib, including Unicode types.

I think that is great. Kudos to your hard work. Just observing things from
the outside in, FreeTDS is a monument to awesomeness.

In closing, I am going to put some notes up on my project's README to try and
educate people about the old 8.0/9.0 and new 7.1/7.2 and why they need to
worry about configuring and both setting things to 7.2. I'll also try
educating them that even tho we are using 7.1 does not mean we are not able
to correctly work with the SQL Server 2005 data types. Something that goes a
bit against this. Where people are setting it to 7.2 thinking they need to.

http://www.freetds.org/userguide/choosingtdsprotocol.htm

> These changes will require, are requiring, significant effort both
> interesting and difficult. To anyone reading this who wants to be a
> part of it: please join. There is much to do, and learn by doing.

I think I'm already in (in my own way). I'll continue to do what I can and
provide feedback and contribute to code when time allows :) Thanks for taking
the time to chat!


- Ken







Archive powered by MHonArc 2.6.24.

Top of Page