[freetds] Cannot Use DBVERSION_72 With DBLIB In 0.91 Release
ken at metaskills.net
Sun Sep 4 10:21:57 EDT 2011
>> 1) I can not configure FreeTDS --with-tdsver="7.2". Is this an
> 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
> 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;
> 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.
> 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!
More information about the FreeTDS