Look Into Using dbsetversion() For Sybase Or Best Practice?

[metaskills]

Currently, we only use dbsetlversion() for the login structure like so in our client.c file.

if (!NIL_P(version))
  dbsetlversion(cwrap->login, NUM2INT(version));

Then I saw this thread http://lists.ibiblio.org/pipermail/freetds/2011q4/027476.html come across the FreeTDS mailing list. Which has this patch to dblib.c so they can have version 100 set in the login structure.

--- dblib.c.ori Thu Aug 18 02:54:40 2011
+++ dblib.c Thu Nov 10 13:45:56 2011
@@ -936,6 +936,9 @@ dbsetlversion (LOGINREC * login, BYTE ve
    case DBVER60:
        login->tds_login->tds_version = 0x700;
        return SUCCEED;
+   case DBVERSION_100:
+       tds_set_version(login->tds_login, 5, 0);
+       return SUCCEED;
    case DBVERSION_71:
        tds_set_version(login->tds_login, 7, 1);
        return SUCCEED;

Below is the documentation for DB-Library. Maybe we should also try to use dbsetversion too? Maybe this would help if FreeTDS was compiled with a lower default --with-tdsver config? If so, it would benefit both us and Sybase.

Function dbsetversion()
Specify a DB-Library version level.

Syntax:

  RETCODE dbsetversion(version)
  DBINT   version;

Parameters:

version – The version of DB-Library behavior that the application expects. 
  The following table lists the symbolic values that are legal for version:

Returns:

  SUCCEED or FAIL.

Comments:

  * dbversion sets the version of DB-Library behavior that an application 
    expects. DB-Library will provide the behavior requested, regardless 
    of the actual version of DB-Library in use.
  * An application is not required to call dbsetversion. However, if 
    dbsetversion is not called, DB-Library provides release 4.6-level 
    behavior.
  * If an application calls dbsetversion, it must do so before calling any 
    other DB-Library routine, with the exception of dbinit.
  * It is an error to call dbsetversion more than once.

[williampratt]

I haven't forgotten about this, I have just been slammed at work. I'm off for 2.5 weeks later in December and this is on my hit list. I had planned on refactoring this part of the code anyway, so I'll look into this at the same time and submit a pull request.

[vjt]

I've done a review of the current freetds TDS version-related code, and I'll cook up a pull request tomorrow (CET) :-).

[vjt]

@metaskills hi, as you've noticed, my proposal is to work around the current FreeTDS' issue in dbsetlversion() by setting the TDSVER environment variable - what do you think?

[metaskills]

Look very interesting. Is this all green in 0.8, 0.91 and 0.92? I recently did some changes that make these really easy to test.

[metaskills]

If you have issues, I can run the tests too.

[vjt]

Yes, please - as I don't have a SQL server at hand. On Sybase ASE 12.5 and 15.0, the only thing that breaks is logging in with TDSVER=4.2 to an iso_1 database with 0.82 - with 0.91 everything works.

There are still a couple of schema tests that still fail, but they were failing before these changes as well.

The main improvement of TDSVER 5.0 on Sybase is proper support for the numeric (decimal) datatype: with 4.2 the DBMS coerces them as floats, losing accuracy.

Best :-),

~Marcello

[metaskills]

As commented in #98, this is not needed anymore with current FreeTDS versions.

[metaskills]

I actually did switch to using dbsetversion. Also added the test helper support too.