headers
Ken Collins | 4 Sep 2011 04:29
Gravatar

Cannot Use DBVERSION_72 With DBLIB In 0.91 Release


I just recently found out that I have been testing TinyTDS using DBVERSION_71/DBVERSION_80 on all my
databases versions from 2000-2008 & Azure and I decided I needed to try out the DBVERSION_72 since my main
focus is on 2005 and up. I have run into the following issues:

1) I can not configure FreeTDS --with-tdsver="7.2". Is this an oversight?

2) I found out that dbsetversion is basically a no-op that sets a global. 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. Should it be patched like so?

--- dblib.c
+++ (clipboard)
 <at>  <at>  -5801,8 +5801,8  <at>  <at> 
 	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:

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?
(Continue reading)

Permalink | Reply |
headers
James K. Lowden | 4 Sep 2011 15:54

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release

On Sat, 3 Sep 2011 22:29:43 -0400
Ken Collins <ken <at> metaskills.net> wrote:

> 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.  

> 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.  

> 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"?  

> Should it be patched like so?
> 
> --- dblib.c
> +++ (clipboard)
>  <at>  <at>  -5801,8 +5801,8  <at>  <at> 
>  	case DBVERSION_42:
>  	case DBVERSION_46:
(Continue reading)

Permalink | Reply |
headers
Ken Collins | 4 Sep 2011 16:21
Gravatar

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release


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"?
(Continue reading)

Permalink | Reply |
headers
James K. Lowden | 4 Sep 2011 18:11

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release

On Sun, 4 Sep 2011 10:21:57 -0400
Ken Collins <ken <at> metaskills.net> wrote:

Hi Ken, 

> Kudos to your hard work. Just observing things from the outside in,
> FreeTDS is a monument to awesomeness.

On behalf of everyone in AUTHORS, thanks.  

> 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 (re)discovered myself something I later read about the Unix guys'
experience with documentation: once they started including man pages
for the utilities and standard library, they sometimes decided to fix
behavior instead of documenting it.  

> 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. 

Because my database work uses numbers, not long strings, I didn't
follow the development of varchar(max) very carefully.  As we speak I'm
not perfectly sure how SQL Server 2005 sends a varchar(max) column to a
TDS 7.1 client.  Microsoft's MS-TDS protocol documentation says
datatype 0xA5, what we call XSYBVARBINARY, represents both VARCHAR(n)
and VARCHAR(max), and that for the latter the length is described by
PARTLEN, introduced in 7.2.   Because TDS 7.1 clients don't
(Continue reading)

Permalink | Reply |
headers
Frediano Ziglio | 5 Sep 2011 09:17
Picon

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release

2011/9/4 James K. Lowden <jklowden <at> freetds.org>:
> On Sun, 4 Sep 2011 10:21:57 -0400
> Ken Collins <ken <at> metaskills.net> wrote:
>
> Hi Ken,
>
>> Kudos to your hard work. Just observing things from the outside in,
>> FreeTDS is a monument to awesomeness.
>
> On behalf of everyone in AUTHORS, thanks.
>
>> 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 (re)discovered myself something I later read about the Unix guys'
> experience with documentation: once they started including man pages
> for the utilities and standard library, they sometimes decided to fix
> behavior instead of documenting it.
>
>> 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.
>
> Because my database work uses numbers, not long strings, I didn't
> follow the development of varchar(max) very carefully.  As we speak I'm
> not perfectly sure how SQL Server 2005 sends a varchar(max) column to a
> TDS 7.1 client.  Microsoft's MS-TDS protocol documentation says
> datatype 0xA5, what we call XSYBVARBINARY, represents both VARCHAR(n)
> and VARCHAR(max), and that for the latter the length is described by
(Continue reading)

Permalink | Reply |
headers
James K. Lowden | 8 Sep 2011 06:52

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release

On Sun, 4 Sep 2011 10:21:57 -0400
Ken Collins <ken <at> metaskills.net> wrote:

> >> 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.

Confirmed, Ken.  dbsetversion() should call tds_set_version().   The
code you found was probably a placeholder once upon a time that never
got finished.  Most people don't care, you see, because freetds.conf
and TDSVER cover the same territory.  (I wonder how many db-lib
programs ever called dbsetversion() or dbsetlversion().  I used
Microsoft's db-lib for over 10 years without setting the version.)

> If anyone has advice on why dbsetlversion() is not doing what I
> expect, I'd love to hear it. I was thinking it would set the version
> in the login structure and work exactly like setting the TDSVER
> environment variable or "tds version" in a external conf file.

It should work that way, but it looks like it doesn't.  dbsetlversion()
correctly calls tds_set_version(), which is used by ct-lib and db-lib.
Likely as not the tds_version of the login record is overwritten by
tds_config_verstr() when the connection is made.  That whole process
has always been more complicated than it needs to be, attracting
gnats.
(Continue reading)

Permalink | Reply |
headers
Jackson, Craig | 8 Sep 2011 07:07
Favicon

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release


> > 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.

> Confirmed, Ken.  dbsetversion() should call tds_set_version().   The
> code you found was probably a placeholder once upon a time that never
> got finished.  Most people don't care, you see, because freetds.conf
> and TDSVER cover the same territory.  (I wonder how many db-lib
> programs ever called dbsetversion() or dbsetlversion().  I used
> Microsoft's db-lib for over 10 years without setting the version.)

> --jkl

dbsetversion() was/is needed for Sybase to get access to the numeric and decimal datatypes, according to
the documentation. Our code calls it.

DBSETLVERSION() appears to be a Microsoft-ism with similar semantics. Correct?

Craig Jackson
Permalink | Reply |
headers
LacaK | 8 Sep 2011 07:58
Picon
Favicon

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release


>
> Confirmed, Ken.  dbsetversion() should call tds_set_version().   The
> code you found was probably a placeholder once upon a time that never
> got finished.  Most people don't care, you see, because freetds.conf
> and TDSVER cover the same territory.  (I wonder how many db-lib
> programs ever called dbsetversion() or dbsetlversion().  I used
> Microsoft's db-lib for over 10 years without setting the version.)
>   
I use it also.
(set default if no freetds.conf or TDSVER is presented)

-Laco.
Permalink | Reply |
headers
Ken Collins | 8 Sep 2011 15:02
Gravatar

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release


I do use it and set it, it just has no affect when freetds.conf or TDSVER is not present. I'll just document
this on the TinyTDS readme as a workaround.

 - Ken

On Sep 8, 2011, at 1:58 AM, LacaK wrote:

> 
>> 
>> Confirmed, Ken.  dbsetversion() should call tds_set_version().   The
>> code you found was probably a placeholder once upon a time that never
>> got finished.  Most people don't care, you see, because freetds.conf
>> and TDSVER cover the same territory.  (I wonder how many db-lib
>> programs ever called dbsetversion() or dbsetlversion().  I used
>> Microsoft's db-lib for over 10 years without setting the version.)
>> 
> I use it also.
> (set default if no freetds.conf or TDSVER is presented)
> 
> -Laco.
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS <at> lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
Permalink | Reply |
headers
LacaK | 20 Sep 2011 09:49
Picon
Favicon

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release

Hi *,
I checked this again and for me it PARTIALY works!
If I use *dbsetlversion*(login, DBVERSION_71 or DBVERSION_70) and I have 
no freetds.conf (TDS) nor TDSVER set, then
 TDS protocol version is set correctly (looking at return value of 
*dbtds* or in freetds log file)
But when I use *dbsetlversion*(login, DBVERSION_72) then in freetds log 
file appears "TDS version downgraded to 7.1!"
(IMO it happens because of this code in login.c:
    /* disable tds9 if iconv wanted, currently not supported */
    if (IS_TDS72_PLUS(connection) && tds->use_iconv) {
        connection->tds_version = 0x701;
        tdserror(tds->tds_ctx, tds, TDSEVERDOWN, 0);
    }
)
But it happens always also when I compile without iconv support!

So it seems to me, that error is related to protocol version 7.2 and it 
does not matter if it is set using dbsetlversion or TDSVER or freetds.conf.

-Laco.
P.S. it is true, that *dbsetversion* does not accept DBVERSION_72:
so it can be added:
    case DBVERSION_70:
-   case DBVERSION_80:
+  case DBVERSION_71:
+  case DBVERSION_72:
        g_dblib_version = version;
...
(but it seems, that g_dblib_version is not used)
(Continue reading)

Permalink | Reply |
headers
Ken Collins | 20 Sep 2011 14:21
Gravatar

Re: Cannot Use DBVERSION_72 With DBLIB In 0.91 Release


Please see this thread. TL;DR, use 7.1, under the hood the supported 2005/2008 data types work.
http://lists.ibiblio.org/pipermail/freetds/2011q3/027306.html

 - Ken
Permalink | Reply |

Gmane