Skip to Content.
Sympa Menu

freetds - RE: [freetds] TDS Fragmentation

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] TDS Fragmentation
  • Date: Mon, 28 Jun 2004 16:15:58 +0100

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

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





Archive powered by MHonArc 2.6.24.

Top of Page