FreeTDS Development Group

[Ken Collins <ken AT metaskills.net>]

This is a cross post from an issue filed on GitHub. Not sure which is 
preferred.

https://github.com/FreeTDS/freetds/issues/30

This is in regards to the TinyTDS (Ruby C Extension) gem. Our dblib C code 
works fine for 0.91 but while testing v0.95 we get unusable connections after 
running an invalid SQL batch like SELECT * FROM [foobar]. Error returned when 
trying to issue the next batch of SQL would be:

The request failed to run because the batch is aborted, this can be caused by 
abort signal sent from client, or another request is running in the same 
session, which makes the session busy.
Below is some dump output from v0.95.65. Any recommendations that stand out?

dblib.c:1338:dbcmd(0x7fce5ab9bff0, SELECT * FROM [foobar])
dblib.c:1344:dbcmd() bufsz = 18
dblib.c:5845:dbfreebuf(0x7fce5ab9bff0)
dblib.c:6817:dbsqlsend(0x7fce5ab9bff0)
mem.c:648:tds_free_all_results()
util.c:165:Changed query state from IDLE to WRITING
util.c:165:Changed query state from WRITING to PENDING
packet.c:740:Sending packet
0000 01 01 00 4a 00 00 01 00-16 00 00 00 12 00 00 00 |...J.... ........|
0010 02 00 00 00 00 00 00 00-00 00 01 00 00 00 53 00 |........ ......S.|
0020 45 00 4c 00 45 00 43 00-54 00 20 00 2a 00 20 00 |E.L.E.C. T. .*. .|
0030 46 00 52 00 4f 00 4d 00-20 00 5b 00 66 00 6f 00 |F.R.O.M.  .[.f.o.|
0040 6f 00 62 00 61 00 72 00-5d 00                   |o.b.a.r. ].|

dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:4625:dbsqlok(0x7fce5ab9bff0)
dblib.c:4654:dbsqlok() not done, calling tds_process_tokens()
token.c:549:tds_process_tokens(0x7fce5ab4ca90, 0x7fff5f584794, 
0x7fff5f584790, 0x6914)
util.c:165:Changed query state from PENDING to READING
packet.c:639:Received packet
0000 04 01 00 6c 00 33 01 00-aa 54 00 d0 00 00 00 01 |...l.3.. ªT.Ð....|
0010 10 1d 00 49 00 6e 00 76-00 61 00 6c 00 69 00 64 |...I.n.v .a.l.i.d|
0020 00 20 00 6f 00 62 00 6a-00 65 00 63 00 74 00 20 |. .o.b.j .e.c.t. |
0030 00 6e 00 61 00 6d 00 65-00 20 00 27 00 66 00 6f |.n.a.m.e . .'.f.o|
0040 00 6f 00 62 00 61 00 72-00 27 00 2e 00 06 53 00 |.o.b.a.r .'....S.|
0050 53 00 32 00 30 00 31 00-34 00 00 01 00 00 00 fd |S.2.0.1. 4......ý|
0060 02 00 fd 00 00 00 00 00-00 00 00 00             |..ý..... ....|

token.c:564:processing result tokens.  marker is  aa(ERROR)
token.c:115:tds_process_default_tokens() marker is aa(ERROR)
token.c:2344:tds_process_msg() reading message 208 from server
token.c:2416:tds_process_msg() calling client msg handler
dbutil.c:76:_dblib_handle_info_message(0x7fce5ab845d0, 0x7fce5ab4ca90, 
0x7fff5f584620)
dbutil.c:77:msgno 208: "Invalid object name 'foobar'."
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:4865:dbdead(0x7fce5ab9bff0) [alive]
dblib.c:3203:dbcancel(0x7fce5ab9bff0)
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
token.c:2429:tds_process_msg() returning TDS_SUCCESS
token.c:564:processing result tokens.  marker is  fd(DONE)
token.c:2080:tds_process_end: more_results = 0
    was_cancelled = 0
    error = 1
    done_count_valid = 0
token.c:2097:                rows_affected = 0
token.c:2100:tds_process_end() state set to TDS_IDLE
util.c:165:Changed query state from READING to IDLE
util.c:83:logic error: cannot change query state from IDLE to PENDING
util.c:165:Changed query state from IDLE to IDLE
dblib.c:4687:dbsqlok() end status is FAIL
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0)
dblib.c:4865:dbdead(0x7fce5ab9bff0) [alive]
dblib.c:4625:dbsqlok(0x7fce5ab9bff0)
dblib.c:4654:dbsqlok() not done, calling tds_process_tokens()
token.c:549:tds_process_tokens(0x7fce5ab4ca90, 0x7fff5f5847b4, 
0x7fff5f5847b0, 0x6914)
token.c:552:tds_process_tokens() state is COMPLETED
dblib.c:3203:dbcancel(0x7fce5ab9bff0)
query.c:2186:tds_send_cancel: not in_cancel and idle
>From david AT qore.org  Tue Nov  3 06:56:58 2015
Return-Path: <david AT qore.org>
X-Original-To: freetds AT lists.ibiblio.org
Delivered-To: freetds AT lists.ibiblio.org
Received: by lists.ibiblio.org (Postfix, from userid 20217)
        id 38F3B205D; Tue,  3 Nov 2015 06:56:58 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 
mailman1.ibiblio.org
X-Spam-Level:
X-Spam-Status: No, score=0.6 required=5.0 tests�YES_00,DKIM_SIGNED,
        DKIM_VALID,URIBL_DBL_ABUSE_BOTCC autolearn=no version=3.3.1
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com 
[74.125.82.53])
        by lists.ibiblio.org (Postfix) with ESMTP id 621E8204C
        for <freetds AT lists.ibiblio.org>; Tue,  3 Nov 2015 06:56:53 -0500 (EST)
Received: by wmeg8 with SMTP id g8so12702218wme.1
        for <freetds AT lists.ibiblio.org>; Tue, 03 Nov 2015 03:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=qore_org.20150623.gappssmtp.com; s 150623;
        h=content-type:mime-version:subject:from:in-reply-to:date
        :content-transfer-encoding:message-id:references:to;
        bh=vS5ycwBV70b+odDSWYqeuRb24+1BeKQ1nlGXcMR8MCo=;
        b=KpcLENK31XIW1OFo17EMaY7kd1zFla1MFTzDa47lyl6/9Z3uP7qGx6NbCSgDKsEoj5
        TVNANhs1LxI19v3abof51jxsFZ3o3BicYHsSQPTnga/tJxRvzy8CNZ6DlNviLPkw8x5J
        3m0h3KXvXIOoJ3D8mnsbdyHuK5o6ppIwaDDKhdnCSWqlqtZ6iT3YrBpLABHGaX5r+fMy
        HWyBfFnIz5ev5Ea9CMzIDfKXqO6VFexbIDvw4eKjg6OJnKhYK7B/+BqwcIRRjEcrU1a4
        73QP02MA0U+tjdAr748Rnxih3U3B4ze7QsiWRzZEeb+xDU3oaImskJU1gRQga6JhOoog
        DPNQ=X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d100.net; s 130820;
        h=x-gm-message-state:content-type:mime-version:subject:from
        :in-reply-to:date:content-transfer-encoding:message-id:references:to;
        bh=vS5ycwBV70b+odDSWYqeuRb24+1BeKQ1nlGXcMR8MCo=;
        b=nMFVJCla6Uy57EVnDEB/NIrY3srJSnQv8olAAAIA//y5JNaNjAJOKqDqs5ZvV7nsJU
        xB28hOd7FtjZarf5tqTH3mIxjmQBKmqFxnNd4XjzjAynWs8TJQ2i6gS4uiuct37iYOV9
        qjWJleJmCvjybpfIItiWun7s9pc4Oi/DKY9oV8nSOT/hW0/gM3KAVK2mvnYZPz6HAf0M
        X6Loz+OOwIxyJDzEls10fhtHbLoqeP7oOfx6L89SGaCaGIl4Ku6OeRW3zL4b8rLBJHhx
        kwoK3m8+KDfee5rUOnvIqRYp2fGVpf9YdQnctXfXCa1k/ZBeMujAQfR0E2Gvo2rZWKAy
        mU+Q=X-Gm-Message-State: 
ALoCoQmbkNYhY81pRHGSN1YuPiFTqtIX4fv+avVPYWNt/Eq6dt2fhSlQOZladxFNsOcOj80Jfln8
X-Received: by 10.28.18.3 with SMTP id 3mr20382748wms.67.1446551812945;
        Tue, 03 Nov 2015 03:56:52 -0800 (PST)
Received: from quasar.prague.qoretechnologies.com (44.181.broadband18.iol.cz.
        [109.81.181.44]) by smtp.gmail.com with ESMTPSA id
        71sm22956185wmt.15.2015.11.03.03.56.51
        for <freetds AT lists.ibiblio.org>
        (version=TLSv1 cipher�DHE-RSA-RC4-SHA bits8/128);
        Tue, 03 Nov 2015 03:56:51 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: David Nichols <david AT qore.org>
In-Reply-To: <C31DA23C-686B-4094-B2F3-9B87DF2BAC20 AT qore.org>
Date: Tue, 3 Nov 2015 12:56:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B564962A-9C0B-4377-9F60-AA1AB6A3F1E6 AT qore.org>
References: <A9755B12-8F2B-4DFD-9770-A806DFF7FC32 AT qore.org>
        <CAHt6W4d8Nhz4YeZczy+0ZhrxxdObzWhzEPU3xN3F3nSFBggM0Q AT mail.gmail.com>
        <CE3CB2BA-2D3C-482A-8C74-56AED0A59D8A AT qore.org>
        <CAHt6W4dp1C2Yg+DcTv=gPkKiSpNfFbc4V1npnBM=Jy_WHgR-RA AT mail.gmail.com>
        <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B AT qore.org>
        <CAHt6W4ejaHF=ctn6arHydBcdR12QMqUU4agd5oQdgC-DhwnE_Q AT mail.gmail.com>
        <A6D8455D-F624-42AC-87D1-ABEDCA10E9CE AT qore.org>
        <CAHt6W4ce2ryonJYU28xSdZBDKhL=K5H6voJAstV4rqnrRAX_ow AT mail.gmail.com>
        <C31DA23C-686B-4094-B2F3-9B87DF2BAC20 AT qore.org>
To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
X-Mailer: Apple Mail (2.3096.5)
X-Mailman-Approved-At: Tue, 03 Nov 2015 07:44:49 -0500
Subject: Re: [freetds] affected rows after insert
X-BeenThere: freetds AT lists.ibiblio.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: FreeTDS Development Group <freetds.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/options/freetds>,
        <mailto:freetds-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/freetds/>
List-Post: <mailto:freetds AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/freetds>,
        <mailto:freetds-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 11:56:58 -0000

On Oct 20, 2015, at 11:17 AM, David Nichols <david AT qore.org> wrote:
> 
>> 
>> On Oct 20, 2015, at 9:12 AM, Frediano Ziglio <freddy77 AT gmail.com> wrote:
>> 
>> Il 20/Ott/2015 09:09, "David Nichols" <david AT qore.org> ha scritto:
>>> 
>>> On Oct 19, 2015, at 10:20 PM, Frediano Ziglio <freddy77 AT gmail.com> wrote:
>>>> 
>>>> 2015-10-19 13:35 GMT+01:00 David Nichols <david AT qore.org>:
>>>>> 
>>>>>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio <freddy77 AT gmail.com>
>> wrote:
>>>>>> 
>>>>>> 2015-10-19 11:16 GMT+01:00 David Nichols <david AT qore.org>:
>>>>>>> 
>>>>>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio <freddy77 AT gmail.com>
>> wrote:
>>>>>>>> 
>>>>>>>> 2015-10-16 12:23 GMT+01:00 David Nichols <david AT qore.org>:
>>>>>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek <ondrej.holecek at
>> qoretechnologies.com <http://lists.ibiblio.org/mailman/listinfo/freetds>>:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> I made a test with the same code but sybase lib and it works like
>>>>>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please
>> check
>>>>>>>>>>> my patch?
>>>>>>>>>>> 
>>>>>>>>>>> thx,
>>>>>>>>>>> 
>>>>>>>>>>> Ondrej
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Actually works and ctlib tests seems to pass.
>>>>>>>>>> 
>>>>>>>>>> However DONEINPROC is returned in a lot of cases, for instance if
>>>>>>>>>> database execute some trigger on the table so your patch can catch
>>>>>>>>>> some strange results too.
>>>>>>>>>> 
>>>>>>>>>> Which database version are you using?
>>>>>>>>>> 
>>>>>>>>>> Frediano
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Ondra has not been working on this for quite some time, but I’d
>> like to pick up this issue again please.
>>>>>>>>> 
>>>>>>>>> We are using MS SQL Server 2008 - using tds version = 7.2  - with
>> the patch we are able to get the affected rows reliably - without it, we
>> are not.
>>>>>>>>> 
>>>>>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0
>> DB, it also gives correct results (with tds version = 5.0)
>>>>>>>>> 
>>>>>>>>> I would be happy to continue helping with this issue if there’s a
>> chance it could be included in freetds (or some other equally effective
>> fix).
>>>>>>>>> 
>>>>>>>>> thanks,
>>>>>>>>> David
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> A fix was written for this case. Do you still have some code that
>>>>>>>> fails? Did you update FreeTDS?
>>>>>>>> 
>>>>>>>> Frediano
>>>>>>> 
>>>>>>> yes, I tried it with freetds from freetds-0.95.12 and git master -
>> both failed my tests and with the patch as provded by Ondra the tests then
>> passed.  Sorry I did not mention this in the original email.
>>>>>>> 
>>>>>> 
>>>>>> Please try a more recent version (like 0.95.21). Also you should sent
>>>>>> some extract of your tests. Can you post an updated patch?
>>>>>> 
>>>>> sorry it was a typo on my side - it was 0.95.21 that I tried.  Anyway
>> since it failed in git master then I would assume that would be more
>> relevant than the last stable release.
>>>>> 
>>>>> Attached please find a patch to git master sources that makes my tests
>> work.  Please note that we are using ctlib from freetds to build a DBI
>> driver for the Qore programming language to talk to SQL Server and Sybase
>> DBs; the same source builds with both the sybae libs and ctlib from
>> freetds.  Currently my tests are written in the Qore programming language,
>> so there are quite a few layers between the Qore code that’s executed and
>> freetds’s ctlib.
>>>>> 
>>>>> When this simple test works (ie only with a patch ctlib); the output
>> looks like this:
>>>>> 
>>>>> dnichols@manatee:~/src/qore/git/module-sybase/src$
>> simple-rows-affected-test.q
>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64)
>>>>>      Jul  9 2008 14:17:44
>>>>>      Copyright (c) 1988-2008 Microsoft Corporation
>>>>>      Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601:
>> Service Pack 1)"
>>>>> insert: 1
>>>>> n delete: 0
>>>>> sel: {id: [1]}
>>>>> delete: 1
>>>>> insert: 1
>>>>> delete: 1
>>>>> 
>>>>> When it doesn’t work (ie with an unpatched ctlib), the output looks
>> like this:
>>>>> dnichols@manatee:~/src/qore/git/module-sybase/src$
>> simple-rows-affected-test.q
>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64)
>>>>>      Jul  9 2008 14:17:44
>>>>>      Copyright (c) 1988-2008 Microsoft Corporation
>>>>>      Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601:
>> Service Pack 1)"
>>>>> insert: 0
>>>>> n delete: 0
>>>>> sel: {id: [1]}
>>>>> delete: 0
>>>>> insert: -1
>>>>> delete: -1
>>>>> 
>>>>> The Qore source to this simple test is attached for your reference.
>>>>> 
>>>> 
>>>> I applied the patch and improved a test to catch this issue. I changed
>>>> the patch slightly to check for TDS_NO_COUNT instead of <0 and
>>>> returning CS_CMD_SUCCEEDED as ct_res_info documentation
>>> 
>>> My test fails with your patch; if I change it back to:
>>>                               case _CS_RES_INIT:   /* command had no
>> result set */
>>>                                       if (tds->rows_affected !=
>> TDS_NO_COUNT) {
>>>                                               *result_type =
>> CS_CMD_DONE;
>>>                                               cmd->results_state =
>> _CS_RES_INIT;
>>>                                               return CS_SUCCEED;
>>>                                       }
>>>                                       break;
>>> 
>>> then it succeeds - please note that his is a hack from my side, I’m not
>> saying that the original approach is correct, just that my test fails
>> unless I set CS_CMD_DONE
>>> 
>>> thx
>>> David
>>> 
>> 
>> Cs_cmd_succeeded is a valid value and is expected to have rows number
>> attached so upper layer should handle it
> 
> OK, I see what you mean, however please note that with ctlib from 
> Sybase/SAP ASE 16, I get the rows updated correctly with the same driver 
> code as I use with freetds, and now it seems that I’ll need to update the 
> driver to have a separate code path when it’s built with freetds - which 
> seems to defeat the purpose of freetds’s ctlib.  Is it not possible to fix 
> this issue and provide 100% backwards-compatibility with Sybase’s ctlib?
> 

@Frediano: sorry to bother you with this issue, but since it’s important for 
me, can you please let me know about the above - should I plan on having 2 
code paths in my DB driver - one for Sybase and one for FreeTDS, or should 
there ideally be a way that compatibility between Sybase’s ctlib and 
FreeTDS’s ctlib can be provided regarding this issue?

thx
David


> thx
> David
> 
>> Frediano
>>> 
>>>> Frediano
>>>> 
>>>>>>> BTW I had to comment out the reference to AM_ICONV in configure.ac
>> to get freetds to build from git master on Linux
>>>>>>> 
>>>>>> Quite odd. Could be you miss some package on your system. Which error
>>>>>> did you get? Could be you have an old autoconf package.
>>>>> 
>>>>> I compiled it on fedora 22 with autocont 2.69.  However I just did a
>> search and found that AM_ICONV is installed with the gettext-devel package,
>> which I’ve now installed, and now freetds from git master can be built
>> without any hacks to configure.ac on Fedora.
>>>>> 
>>>>> thx
>>>>> David
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Frediano
>>>>>> 
>>>>>>> thx
>>>>>>> David
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek
>>>>>>>>>>> <ondrej.holecek at qoretechnologies.com <
>> http://lists.ibiblio.org/mailman/listinfo/freetds>> wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> I have a problem obtaining number of affected rows while
>> inserting.
>>>>>>>>>>>> The problem occurs when I pass the values by ct_param() call.
>>>>>>>>>>>> So, this command order works well:
>>>>>>>>>>>> 
>>>>>>>>>>>> ct_cmd_alloc()
>>>>>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number)  VALUES(5)")
>>>>>>>>>>>> ct_send()
>>>>>>>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call...
>>>>>>>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't
>> read
>>>>>>>>>>>> the affected rows number.
>>>>>>>>>>>> 
>>>>>>>>>>>> ct_cmd_alloc()
>>>>>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number)
>> VALUES(@par1)")
>>>>>>>>>>>> ct_param("@par1", 1)
>>>>>>>>>>>> ct_send()
>>>>>>>>>>>> ct_result() // the result type is CS_END_RESULT
>>>>>>>>>>>> // can't do anything here :-(
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> The row is inserted in both cases correctly just in the second
>> case I
>>>>>>>>>>>> can't read the number of affected rows.
>>>>>>>>>>>> 
>>>>>>>>>>>> I did some ctlib debugging and I created the patch which would
>> fix
>>>>>>>>>>>> this behavior. However, I just changed the code blindly (based
>> on the
>>>>>>>>>>>> debugging) not knowing what is the real purpose of the case.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> in ct_result() function I changed the case _CS_RES_INIT:
>>>>>>>>>>>> 
>>>>>>>>>>>>            case _CS_RES_INIT:   /* commalindlnd had no result
>> set */
>>>>>>>>>>>>                if (tds->rows_affected > 0) {
>>>>>>>>>>>>                    *result_type = CS_CMD_DONE;
>>>>>>>>>>>>                    cmd->results_state = _CS_RES_INIT;
>>>>>>>>>>>>                    return CS_SUCCEED;
>>>>>>>>>>>>                }
>>>>>>>>>>>>                break;
>>>>>>>>>>>> 
>>>>>>>>>>>> now it seems with the patch it works correctly. But I have no
>> idea if
>>>>>>>>>>>> it is really the correct way.
>>>>>>>>>>>> 
>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> 
>>>>>>>>>>>> Ondrej
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> FreeTDS mailing list
>>>>>>>>> FreeTDS AT lists.ibiblio.org
>>>>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>>>>> _______________________________________________
>>>>>>>> FreeTDS mailing list
>>>>>>>> FreeTDS AT lists.ibiblio.org
>>>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> FreeTDS mailing list
>>>>>>> FreeTDS AT lists.ibiblio.org
>>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>>> _______________________________________________
>>>>>> FreeTDS mailing list
>>>>>> FreeTDS AT lists.ibiblio.org
>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> FreeTDS mailing list
>>>>> FreeTDS AT lists.ibiblio.org
>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>> 
>>>> _______________________________________________
>>>> FreeTDS mailing list
>>>> FreeTDS AT lists.ibiblio.org
>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>> 
>>> _______________________________________________
>>> FreeTDS mailing list
>>> FreeTDS AT lists.ibiblio.org
>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds