FreeTDS Development Group

["Tomer Levy" <tomerl AT checkpoint.com>]

I do not mean a tds packet that is fragmented between a couple of TCP/IP
Packets. What I mean is a case where in the TDS header I will see the "Last
packet indicator" flag (in the TDS header) showing that there are more
packets on the way (value = 0x00). 
I am trying to find a scenario in which such packets will be created.

Message: 1
Date: Sun, 27 Jun 2004 20:16:58 +0300
From: "Tomer Levy" <tomerl AT checkpoint.com>
Subject: [freetds] TDS Fragmentation
To: <freetds AT lists.ibiblio.org>
Message-ID: <200406271717.i5RHHa207688 AT michael.checkpoint.com>
Content-Type: text/plain;       charset="us-ascii"

Hey,
I'm trying to create a fragmented TDS message with no luck...:( Any ideas on
how to create such message which will cause TDS fragmentation and (not
TCP..)
 


------------------------------

Message: 2
Date: Sun, 27 Jun 2004 10:28:37 -0700 (PDT)
From: brian AT bruns.com
Subject: Re: [freetds] TDS Fragmentation
To: freetds AT lists.ibiblio.org
Message-ID:
        <20040627102838.12055.h004.c000.wm AT mail.bruns.com.criticalpath.net>
Content-Type: text/plain; charset=iso-8859-1

Depends what you mean by fragmented TDS message.  Do you mean a netlib
packet that is physically transported in two different TCP packets, a PDU
that stradles two netlib packets, or something different?


Brian

On Sun, 27 Jun 2004 20:16:58 +0300, "Tomer Levy" wrote:

> 
> Hey,
> I'm trying to create a fragmented TDS message with no luck...:( Any 
> ideas on how to create such message which will cause TDS fragmentation 
> and (not TCP..)
>  
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds


------------------------------

Message: 3
Date: Sun, 27 Jun 2004 23:50:02 -0400
From: Steven Orton <sorton9999 AT usa.net>
Subject: Re: [freetds] Cursors in freetds
To: FreeTDS Development Group <freetds AT lists.ibiblio.org>,      "'FreeTDS
        Development Group'" <freetds AT lists.ibiblio.org>
Message-ID: <419iFbDYc7168S10.1088394602 AT cmsweb10.cms.usa.net>
Content-Type: text/plain; charset=ISO-8859-1

Hey Bill,

  This is great news!!  I was one interested party that was great
disappointed to find out that FreeTDS did not have cursors available.  It
hurt so much that I had to scrap plans to use this driver and went to a
commercial vendor.  I would love to see this functionality be incorporated
into the ODBC module as well.  I am not up on the technical issues, but as a
user, it would be good to have multiple resultsets handled with a single
connection.  The API I'm using does not handle this and I'm not even sure
that the commercial driver does either.  The main reason I'm interested in
this is simply one of speed.  We deal in multiple connections with multiple
machines all hitting one backend DB.  It seems pointless to connect and dump
the connection with every query we need to run.  Connect times are typically
the most expensive and it would boost our throughput immensely to re-use the
connection.

  steve---
 

"Thompson, Bill D (London)" <bill_d_thompson AT ml.com> wrote:

> Hi all,
> 
> I've got a patch ready to submit, which gives us full access to server 
> side cursors through the ct-library API.
> This enables us to handle multiple active result sets through a single 
> connection.
> As this is one of the trumpeted features of ADO.NET 2.0 , I think we 
> should be pretty chuffed about being able to do it too!
> 
> I know it sounds like a radical departure, but I would like to "walk 
> through" the design of this with any interested parties before 
> unleashing the patch on an unsuspecting world.
> I'd also like to know how this fit in with the ODBC driver - will it
enhance
> our implementation significantly to have cursors available ?
> 
> I'll prepare an outline document on how I've changed things, and why. 
> I'll forward it to interested parties, so if you consider yourself to 
> be
one
> of those, just let me know.
> 
> Best wishes,
> 
>
$:0`0:$x,88,x$:0`0:$x$:0`0:$x,88,x$:0`0:$x$:0`0:$x,88,x$
> 
> Bill Thompson
> GMI Technology
> Merrill Lynch Europe
> 
> +44 207 995 8307
> 
> For very important information relating to this e-mail please click on 
> this
> link:  http://www.ml.com/legal_info.htm
> 
> 
> 
>
============================================================================
==
> 
> If you are not an intended recipient of this e-mail, please notify the 
> sender, delete it and do not read, act upon, print, disclose, copy, 
> retain or redistribute it.
> 
> Click here for important additional terms relating to this e-mail.
>      <http://www.ml.com/email_terms/>
> 
>
============================================================================
==
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 



-------------------------------
Steven Orton
sorton9999 AT usa.net
--
INEPTITUDE: If you can't learn to do
 something well, learn to enjoy doing
 it poorly.
--
"Put your hand on a hot stove for a minute,  and it seems like an hour.
 Sit with a pretty girl for an hour, and it  seems like a minute. THAT'S
relativity."
        -- Albert Einstein
-------------------------------




------------------------------

Message: 4
Date: Mon, 28 Jun 2004 02:23:49 -0400
From: "James K. Lowden" <jklowden AT schemamania.org>
Subject: Re: [freetds] Cursors in freetds
To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
Message-ID: <20040628022349.661d8caf.jklowden AT schemamania.org>
Content-Type: text/plain; charset=US-ASCII

On Sun, 27 Jun 2004, Steven Orton <sorton9999 AT usa.net> wrote:
> 
>   This is great news!!  I was one interested party that was great
>   disappointed
> to find out that FreeTDS did not have cursors available.  It hurt so 
> much that I had to scrap plans to use this driver and went to a 
> commercial vendor.  I would love to see this functionality be 
> incorporated into the ODBC module as well.  I am not up on the 
> technical issues, but as a user, it would be good to have multiple 
> resultsets handled with a single connection.  The API I'm using does 
> not handle this and I'm not even sure that the commercial driver does 
> either.  The main reason I'm interested in this is simply one of 
> speed.  We deal in multiple connections with multiple machines all hitting
one backend DB.
> It seems pointless to connect and dump the connection with every query 
> we need to run.  Connect times are typically the most expensive and it 
> would boost our throughput immensely to re-use the connection.

Steve, 

I'm a little puzzled by your post, for couple of reasons.  

Just to be sure we're talking about the same thing:
http://www.freetds.org/faq.html#pending

If the API you're using from the commercial vendor doesn't support "multiple
resultsets handled with a single connection", and you opted to use it
because FreeTDS lacks that feature, what advantage does it bring you?  

On the issue of speed.  In most applications, cursors won't buy speed. 
They sometimes offer the programmer convenience he wouldn't have otherwise,
and of course a degree of interaction that serial resultset handling doesn't
provide (which can be useful in support of user interfaces).  But for sheer
speed, most of the time it's best to write the queries such that they return
precisely what's needed, and read the whole resultset in turn.  

It's not necessary to form and drop connections ad hoc; you can maintain a
few connections per user.  With today's hardware, that's rarely a problem.
 

Not that I don't think cursors are fine and dandy in their place.  It's just
that you raised the issues of "competing" functionality and speed, which
don't strike me as their primary advantages.  

--jkl



------------------------------

Message: 5
Date: Mon, 28 Jun 2004 14:36:06 +0100
From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
Subject: RE: [freetds] intermittent empty results
To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
Message-ID:
        <DB1313D61946D1119FB100805F15DA7E1560F94C AT lonim09850.uk.ml.com>
Content-Type: text/plain;  charset=iso-8859-1

David,

> my $dbh = DBI->connect($dsn, $USER, $PASSWORD) or die 'connect'; my 
> $sth = $dbh->prepare($sql); $sth->execute;

At the moment I'm a *little* sceptical (without any hard and fast evidence
yet) of the "prepare" functinality within ct-library.
I'm not familar with using DBI::Sybase myself. 
Is it possible to submit the sql without using "prepare" ?

Bill


> -----Original Message-----
> From: David Barnwell [SMTP:david.barnwell AT well.ox.ac.uk]
> Sent: 25 June 2004 20:08
> To:   freetds AT lists.ibiblio.org
> Subject:      [freetds] intermittent empty results
> 
> Hi,
> 
> We have been using freetds successfully for four months on a website 
> that displays medical research data. The database server runs SQL 
> Server 2000, and the webserver (and database client) is Linux.
> 
> However, the website has an intermittent problem: occasionally, it 
> incorrectly returns an empty data set. It usually returns the correct 
> data if the user clicks again.
> 
> After a lot of investigation, I have managed to reproduce this problem 
> consistently with a simple perl script that prints one column from a 
> table using the following SQL:
> 
>     SELECT assay
>     FROM xxxxxx.xxxxx.assay
>     where [assay description] is not null
>     order by 1
> 
> The script seems to be upset by certain server activity. If I drop and 
> recreate my table on the server, then the first time I run the script 
> on the client I just get one line containing "0". Thereafter, it's OK.
> 
> The problem occurs whether I call the script from CGI or from the 
> command line. It occurs with TDSVER = 4.2, 7.0 and 8.0. It still 
> occurs if I reduce the select to a single line (using SELECT top 1).
> 
> This is what the TDS log shows. In the error case, the server always 
> returns an extra 5 bytes (hex 79 00 00 00 00) at the start of the data 
> stream. The log then shows:
> 
>     processing result tokens.  marker is  79(RETURNSTATUS)
>     ct_results() process_result_tokens returned 1 (type 4043)
>     generating return status row. type = 56(int), varint_size 0
> 
> Shortly after that, a ct_cancel is sent and we get repeated calls of 
> "tds_process_default_tokens" until the incoming data is exhausted, 
> rather than repeated "processing row tokens" that we see in the in the 
> normal case.
> 
> In the error case, the log ends with:
> 
>   tds_process_end: more_results = 0
>     was_cancelled = 1
>     error = 0
>     done_count_valid = 0
>   tds_process_end() state set to TDS_IDLE
>   ct_close()
>   ct_con_drop()
>   ct_cmd_drop()
> 
> Any ideas or help would be gratefully received!
> 
> Many thanks,
> David Barnwell
> 
> Database Developer/Systems Administrator Wellcome Trust Centre for 
> Human Genetics University of Oxford, Roosevelt Drive, Oxford OX3 7BN, 
> UK
> 
> ----------------------------------------------------------------------
> ----
> -
> 
> (1) Server software:
> Windows 2000 5.00.2195 (Service Pack 4) Microsoft SQL Server  2000 - 
> 8.00.818 (Intel X86)
> 
> (2) Client software:
> Red Hat Enterprise Linux 3
> perl 5.8.0
> Apache 2.0.46
> Apache-DBI-0.94
> DBD-Sybase-1.02
> freetds-0.62.1 (loaded from freetds-0.62.1-1.i586.rpm)
> 
> (3) The server SQL that triggers the problem:
> drop table assay
> select * into assay from copy_assay
> grant all on assay to xxxxxx
> 
> (4) The perl script that shows the problem:
> #!/usr/bin/perl -w
> use strict;
> use DBI;
> 
> $ENV{'TDSVER'} = '4.2';
> $ENV{'TDSDUMP'} = "/tmp/dbtest.log";
> $ENV{'TDSDUMPCONFIG'} = "/tmp/dbtest.config";
> 
> my $HOST     = 'xxxxxx.xxx.xxx';
> my $USER     = 'xxxxxx';
> my $PASSWORD = 'xxxxxxxxxxx';
> 
> my $dsn = "DBI:Sybase:server=$HOST" ;
> 
> my $sql = "
>   SELECT top 1 assay
>   FROM xxxxxx.xxxxx.assay
>   where [assay description] is not null
>   order by 1
> ";
> 
> my $dbh = DBI->connect($dsn, $USER, $PASSWORD) or die 'connect'; my 
> $sth = $dbh->prepare($sql); $sth->execute;
> 
> while (my @row = $sth->fetchrow_array) {
>   print join "  ", @row;
>   print "\n";
> }
> 
> $sth->finish;
> $dbh->disconnect;
> 
> ----------------------------------------------------------------------
> ----
> -
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

============================================================================
==

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it.

Click here for important additional terms relating to this e-mail.
     <http://www.ml.com/email_terms/>

============================================================================
==



------------------------------

Message: 6
Date: Mon, 28 Jun 2004 15:22:02 +0100
From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
Subject: RE: [freetds] intermittent empty results
To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
Message-ID:
        <DB1313D61946D1119FB100805F15DA7E1560F94D AT lonim09850.uk.ml.com>
Content-Type: text/plain;  charset=iso-8859-1

Hi David,

some other thoughts on this...

The RETURNSTATUS token, as you may know, is reporting the return status of a
stored procedure.
On the face of it, getting this back from the server is counter-intuitive as
you haven't exec'd a stored procedure...

A couple of possibilities arise. 
The first is that FreeTDS is issuing a stored procedure call to the server. 
We do this sometimes, as much functionality on SQL server is accessible only
through some (undocumented) stored procedures.
"prepare" functionality - SQL with placeholders and parameters - is one
occasion when we do this, hence my previous reply.

The second possibility is that the Server is internally executing a stored
procedure as it processes your statement, and sending the return status to
you.
We have seen this behaviour before, and it might well upset an application
that was not expecting to receive this.

One way of finding out for sure what is going on would be to capture a SQL
server profiler trace for your test scenario. 
That would tell us from the servers point of view everything that's
happening with your session.

Are you familiar with running SQL server profiler traces ?

Bill

> -----Original Message-----
> From: David Barnwell [SMTP:david.barnwell AT well.ox.ac.uk]
> Sent: 25 June 2004 20:08
> To:   freetds AT lists.ibiblio.org
> Subject:      [freetds] intermittent empty results
> 
> Hi,
> 
> We have been using freetds successfully for four months on a website 
> that displays medical research data. The database server runs SQL 
> Server 2000, and the webserver (and database client) is Linux.
> 
> However, the website has an intermittent problem: occasionally, it 
> incorrectly returns an empty data set. It usually returns the correct 
> data if the user clicks again.
> 
> After a lot of investigation, I have managed to reproduce this problem 
> consistently with a simple perl script that prints one column from a 
> table using the following SQL:
> 
>     SELECT assay
>     FROM xxxxxx.xxxxx.assay
>     where [assay description] is not null
>     order by 1
> 
> The script seems to be upset by certain server activity. If I drop and 
> recreate my table on the server, then the first time I run the script 
> on the client I just get one line containing "0". Thereafter, it's OK.
> 
> The problem occurs whether I call the script from CGI or from the 
> command line. It occurs with TDSVER = 4.2, 7.0 and 8.0. It still 
> occurs if I reduce the select to a single line (using SELECT top 1).
> 
> This is what the TDS log shows. In the error case, the server always 
> returns an extra 5 bytes (hex 79 00 00 00 00) at the start of the data 
> stream. The log then shows:
> 
>     processing result tokens.  marker is  79(RETURNSTATUS)
>     ct_results() process_result_tokens returned 1 (type 4043)
>     generating return status row. type = 56(int), varint_size 0
> 
> Shortly after that, a ct_cancel is sent and we get repeated calls of 
> "tds_process_default_tokens" until the incoming data is exhausted, 
> rather than repeated "processing row tokens" that we see in the in the 
> normal case.
> 
> In the error case, the log ends with:
> 
>   tds_process_end: more_results = 0
>     was_cancelled = 1
>     error = 0
>     done_count_valid = 0
>   tds_process_end() state set to TDS_IDLE
>   ct_close()
>   ct_con_drop()
>   ct_cmd_drop()
> 
> Any ideas or help would be gratefully received!
> 
> Many thanks,
> David Barnwell
> 
> Database Developer/Systems Administrator Wellcome Trust Centre for 
> Human Genetics University of Oxford, Roosevelt Drive, Oxford OX3 7BN, 
> UK
> 
> ----------------------------------------------------------------------
> ----
> -
> 
> (1) Server software:
> Windows 2000 5.00.2195 (Service Pack 4) Microsoft SQL Server  2000 - 
> 8.00.818 (Intel X86)
> 
> (2) Client software:
> Red Hat Enterprise Linux 3
> perl 5.8.0
> Apache 2.0.46
> Apache-DBI-0.94
> DBD-Sybase-1.02
> freetds-0.62.1 (loaded from freetds-0.62.1-1.i586.rpm)
> 
> (3) The server SQL that triggers the problem:
> drop table assay
> select * into assay from copy_assay
> grant all on assay to xxxxxx
> 
> (4) The perl script that shows the problem:
> #!/usr/bin/perl -w
> use strict;
> use DBI;
> 
> $ENV{'TDSVER'} = '4.2';
> $ENV{'TDSDUMP'} = "/tmp/dbtest.log";
> $ENV{'TDSDUMPCONFIG'} = "/tmp/dbtest.config";
> 
> my $HOST     = 'xxxxxx.xxx.xxx';
> my $USER     = 'xxxxxx';
> my $PASSWORD = 'xxxxxxxxxxx';
> 
> my $dsn = "DBI:Sybase:server=$HOST" ;
> 
> my $sql = "
>   SELECT top 1 assay
>   FROM xxxxxx.xxxxx.assay
>   where [assay description] is not null
>   order by 1
> ";
> 
> my $dbh = DBI->connect($dsn, $USER, $PASSWORD) or die 'connect'; my 
> $sth = $dbh->prepare($sql); $sth->execute;
> 
> while (my @row = $sth->fetchrow_array) {
>   print join "  ", @row;
>   print "\n";
> }
> 
> $sth->finish;
> $dbh->disconnect;
> 
> ----------------------------------------------------------------------
> ----
> -
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

============================================================================
==

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it.

Click here for important additional terms relating to this e-mail.
     <http://www.ml.com/email_terms/>

============================================================================
==



------------------------------

Message: 7
Date: Mon, 28 Jun 2004 10:37:36 -0400
From: "Bort, Paul" <pbort AT tmwsystems.com>
Subject: RE: [freetds] intermittent empty results
To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
Message-ID:
        <735D404BD9E7EB44B9CDFC27FC88809B01C4DAF8 AT mail2.tmwsystems.com>
Content-Type: text/plain;       charset="iso-8859-1"

Bill, 

For what it's worth, I can report that DBD::Sybase (version 0.91) works with
the prepare method as long as there are no placeholders used. IIRC,
placeholder support was added in a later version. 

Hope this helps.
Paul

> -----Original Message-----
> From: Thompson, Bill D (London) [mailto:bill_d_thompson AT ml.com]
> Sent: Monday, June 28, 2004 9:36 AM
> To: 'FreeTDS Development Group'
> Subject: RE: [freetds] intermittent empty results
> 
> 
> David,
> 
> > my $dbh = DBI->connect($dsn, $USER, $PASSWORD) or die 'connect'; my 
> > $sth = $dbh->prepare($sql); $sth->execute;
> 
> At the moment I'm a *little* sceptical (without any hard and fast 
> evidence
> yet) of the "prepare" functinality within ct-library.
> I'm not familar with using DBI::Sybase myself. 
> Is it possible to submit the sql without using "prepare" ?
> 
> Bill
> 
> 
> > -----Original Message-----
> > From:       David Barnwell [SMTP:david.barnwell AT well.ox.ac.uk]
> > Sent:       25 June 2004 20:08
> > To: freetds AT lists.ibiblio.org
> > Subject:    [freetds] intermittent empty results
> > 
> > Hi,
> > 
> > We have been using freetds successfully for four months on
> a website that
> > displays medical research data. The database server runs
> SQL Server 2000,
> > and the webserver (and database client) is Linux.
> > 
> > However, the website has an intermittent problem: occasionally, it 
> > incorrectly returns an empty data set. It usually returns
> the correct data
> > if the user clicks again.
> > 
> > After a lot of investigation, I have managed to reproduce
> this problem
> > consistently with a simple perl script that prints one
> column from a table
> > using the following SQL:
> > 
> >     SELECT assay
> >     FROM xxxxxx.xxxxx.assay
> >     where [assay description] is not null
> >     order by 1
> > 
> > The script seems to be upset by certain server activity. If
> I drop and
> > recreate my table on the server, then the first time I run
> the script on
> > the
> > client I just get one line containing "0". Thereafter, it's OK.
> > 
> > The problem occurs whether I call the script from CGI or
> from the command
> > line. It occurs with TDSVER = 4.2, 7.0 and 8.0. It still occurs if I 
> > reduce the select to a single line (using SELECT top 1).
> > 
> > This is what the TDS log shows. In the error case, the server always 
> > returns an extra 5 bytes (hex 79 00 00 00 00) at the start of the
> data stream. The
> > log then shows:
> > 
> >     processing result tokens.  marker is  79(RETURNSTATUS)
> >     ct_results() process_result_tokens returned 1 (type 4043)
> >     generating return status row. type = 56(int), varint_size 0
> > 
> > Shortly after that, a ct_cancel is sent and we get repeated calls of 
> > "tds_process_default_tokens" until the incoming data is
> exhausted, rather
> > than repeated "processing row tokens" that we see in the in
> the normal
> > case.
> > 
> > In the error case, the log ends with:
> > 
> >   tds_process_end: more_results = 0
> >     was_cancelled = 1
> >     error = 0
> >     done_count_valid = 0
> >   tds_process_end() state set to TDS_IDLE
> >   ct_close()
> >   ct_con_drop()
> >   ct_cmd_drop()
> > 
> > Any ideas or help would be gratefully received!
> > 
> > Many thanks,
> > David Barnwell
> > 
> > Database Developer/Systems Administrator Wellcome Trust Centre for 
> > Human Genetics University of Oxford, Roosevelt Drive, Oxford OX3 
> > 7BN, UK
> > 
> > 
> --------------------------------------------------------------
> ------------
> > -
> > 
> > (1) Server software:
> > Windows 2000 5.00.2195 (Service Pack 4) Microsoft SQL Server  2000 - 
> > 8.00.818 (Intel X86)
> > 
> > (2) Client software:
> > Red Hat Enterprise Linux 3
> > perl 5.8.0
> > Apache 2.0.46
> > Apache-DBI-0.94
> > DBD-Sybase-1.02
> > freetds-0.62.1 (loaded from freetds-0.62.1-1.i586.rpm)
> > 
> > (3) The server SQL that triggers the problem:
> > drop table assay
> > select * into assay from copy_assay
> > grant all on assay to xxxxxx
> > 
> > (4) The perl script that shows the problem:
> > #!/usr/bin/perl -w
> > use strict;
> > use DBI;
> > 
> > $ENV{'TDSVER'} = '4.2';
> > $ENV{'TDSDUMP'} = "/tmp/dbtest.log"; $ENV{'TDSDUMPCONFIG'} = 
> > "/tmp/dbtest.config";
> > 
> > my $HOST     = 'xxxxxx.xxx.xxx';
> > my $USER     = 'xxxxxx';
> > my $PASSWORD = 'xxxxxxxxxxx';
> > 
> > my $dsn = "DBI:Sybase:server=$HOST" ;
> > 
> > my $sql = "
> >   SELECT top 1 assay
> >   FROM xxxxxx.xxxxx.assay
> >   where [assay description] is not null
> >   order by 1
> > ";
> > 
> > my $dbh = DBI->connect($dsn, $USER, $PASSWORD) or die 'connect'; my 
> > $sth = $dbh->prepare($sql); $sth->execute;
> > 
> > while (my @row = $sth->fetchrow_array) {
> >   print join "  ", @row;
> >   print "\n";
> > }
> > 
> > $sth->finish;
> > $dbh->disconnect;
> > 
> > 
> --------------------------------------------------------------
> ------------
> > -
> > 
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> ==============================================================
> ================
> 
> If you are not an intended recipient of this e-mail, please notify the 
> sender, delete it and do not read, act upon, print, disclose, copy, 
> retain or redistribute it.
> 
> Click here for important additional terms relating to this e-mail.
>      <http://www.ml.com/email_terms/>
> 
> ==============================================================
> ================
> 
> _______________________________________________
> 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


End of FreeTDS Digest, Vol 17, Issue 43
***************************************