[freetds] TDS Fragmentation

Thompson, Bill D (London) bill_d_thompson at ml.com
Mon Jun 28 11:15:58 EDT 2004


Tomer,

It shouldn't be too difficult.

If you want to *send* such a fragmented TDS message, you should just submit
a piece of SQL that's larger than the packet size.
by default the packet size is 512 bytes.
If you can't think of a big SQL statement, just put loads of little ones
together e.g.
"select * from table select * from table select * from table" etc.

It would be much easier to *receive* such a message - just do a "select *
from table" that has a few hundred rows...

I hope this is what you mean...

Bill

> -----Original Message-----
> From:	Tomer Levy [SMTP:tomerl at checkpoint.com]
> Sent:	28 June 2004 16:02
> To:	freetds at lists.ibiblio.org
> Subject:	Re: [freetds] TDS Fragmentation
> 
> 
> 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
> ***************************************
> 
> _______________________________________________
> 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/>

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




More information about the FreeTDS mailing list