|
|
sybperl-l Archive
Up Prev Next
From: Michael Peppler <mpeppler at peppler dot org>
Subject: RE: ct-lib printing extraneous row
Date: Mar 9 2001 3:22PM
Wechsler, Steven writes:
> That's pretty much what I suspected. Now, is there any way to eliminate it?
> Since the script doesn't know whether it's running a select statement or a
> stored proc, there's no way for it to know whether or not to drop the last
> line.
Here's a patch:
*** CTlib.pm.in 2000/05/13 22:50:56 1.30
--- CTlib.pm.in 2001/03/09 15:19:28
***************
*** 900,905 ****
--- 900,911 ----
$fail = 1 if ($res_type == &CS_CMD_FAIL);
next unless $fetchable{$res_type};
+ if($Sybase::CTlib::ct_sql_nostatus && $res_type == &CS_STATUS_RESULT) {
+ while ($data = $db->ct_fetch(0, 1)) {
+ ; #skip return codes from procs...
+ }
+ }
+
while ($data = $db->ct_fetch($flag, 1)) {
if (defined $sub) {
if($flag) {
You can patch the installed CTlib.pm directly, or patch the source
CTlib/CTlib.pm.in file.
To enable, set $Sybase::CTlib::ct_sql_nostatus = 1.
Michael
> > -----Original Message-----
> > From: Michael Peppler [mailto:mpeppler@peppler.org]
> > Sent: Friday, March 09, 2001 10:02 AM
> > To: SybPerl Discussion List
> > Subject: RE: ct-lib printing extraneous row
> >
> >
> > Friedman, David writes:
> > > I believe that's the return code of the stored proc.
> >
> > You are correct - that is what is happening.
> >
> > Maybe ct_sql() needs an option to store any CS_STATUS_ROW data in the
> > $dbh handle instead of returning it to the caller...
> >
> > Michael
> >
> > > -----Original Message-----
> > > From: Wechsler, Steven [mailto:steven.wechsler@wsaccess.com]
> > > Sent: Thursday, March 08, 2001 4:19 PM
> > > To: SybPerl Discussion List
> > > Subject: ct-lib printing extraneous row
> > >
> > >
> > > I have a CT-library script that retrieves rows of data
> > from a database based
> > > on a SQL query, and outputs it in a BCP-style format. When
> > it calls a stored
> > > proc rather than executing an ad-hoc query, I get a row
> > with a '0' on it,
> > > which screws up the format of the file. Ad-hoc queries
> > seem to work fine.
> > > Here's the part that does the data retrieval and writing
> > (most of it stolen
> > > from the examples on Michael's web page, since I'm new to
> > CT-Library):
> > >
> > > while(($rc = $source_handle->ct_results($restype)) == CS_SUCCEED) {
> > > next if($restype == CS_CMD_DONE || $restype == CS_CMD_FAIL ||
> > > $restype == CS_CMD_SUCCEED);
> > > die "Error returned from SQL Server\n" if $DB_ERROR;
> > > $cols = int($source_handle->ct_col_types());
> > > undef $\;
> > > print "retrieving data" if $debug;
> > >
> > > while(@row = $source_handle->ct_fetch) {
> > > next if (@oldrow eq @row && $opt_d);
> > > @oldrow = @row;
> > > $count = 0;
> > > foreach (@row) {
> > > $count++;
> > > print OUT "$_";
> > > print OUT $opt_t unless $count == @row;
> > > }
> > > print OUT $opt_r;
> > > }
> > > }
> > >
> > > opt_t and opt_r are column and row terminator,
> > respectively. Any ideas as to
> > > what could be causing that trailing '0'?
> > >
> > > Thanks,
> > >
> > > Steve
> > > --
> > > Steve Wechsler/Application Manager/Wall St. Access
> > > Steven.Wechsler@wsaccess.com
> > > "There is no reason anyone would want a computer in their home."
> > > -- Ken Olson, president, chairman and founder of DEC, 1977
> > > Support Anti-Spam legislation: http://www.cauce.org
> > >
> >
> > --
> > Michael Peppler - Data Migrations Inc. - mpeppler@peppler.org
> > http://www.mbay.net/~mpeppler - mpeppler@mbay.net
> > International Sybase User Group - http://www.isug.com
> > Sybase on Linux mailing list: ase-linux-list@isug.com
> >
>
--
Michael Peppler - Data Migrations Inc. - mpeppler@peppler.org
http://www.mbay.net/~mpeppler - mpeppler@mbay.net
International Sybase User Group - http://www.isug.com
Sybase on Linux mailing list: ase-linux-list@isug.com
|
