sybperl-l Archive

From: "Rob Lauer" <rlauer at charlesjones dot com>
Subject: fetchrow_hashref
Date: Nov 10 2004 3:54AM

Received: from gw.peppler.org (localhost [127.0.0.1])
	by gw.peppler.org (8.12.10/8.12.10) with ESMTP id iAA3uLQb031516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 9 Nov 2004 22:56:21 -0500
Received: (from majordomo@localhost)
	by gw.peppler.org (8.12.10/8.12.10/Submit) id iAA3uLPh031514
	for sybperl-l-outgoing; Tue, 9 Nov 2004 22:56:21 -0500
Received: from INTERSCAN.charlesjones.com (smtpmail.charlesjones.com [12.3.71.167])
	by gw.peppler.org (8.12.10/8.12.10) with SMTP id iAA3uJQa031503
	for ; Tue, 9 Nov 2004 22:56:19 -0500
Received: from DELLROBLAUE ([172.25.140.156])
	by mail1.charlesjones.com (8.11.6/8.11.6) with SMTP id iAA3uGl26512
	for ; Tue, 9 Nov 2004 22:56:16 -0500
Message-ID: <051a01c4c6d8$fe043260$9c8c19ac@DELLROBLAUE>
From: "Rob Lauer" 
To: 
Subject: fetchrow_hashref
Date: Tue, 9 Nov 2004 22:54:34 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-8d39d25f-53d1-4bf8-b7df-773828b2305d"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.11 (gw.peppler.org [127.0.0.1]); Tue, 09 Nov 2004 22:56:21 -0500 (EST)
X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.11 (gw.peppler.org [207.234.209.79]); Tue, 09 Nov 2004 22:56:20 -0500 (EST)
X-Virus-Scanned: ClamAV 0.80/550/Mon Oct 25 11:39:01 2004
	clamav-milter version 0.80j
	on gw.peppler.org
X-Virus-Scanned: ClamAV 0.80/550/Mon Oct 25 11:39:01 2004
	clamav-milter version 0.80j
	on gw.peppler.org
X-Virus-Status: Clean
X-Virus-Status: Clean
X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_BOUND_NEXTPART autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.peppler.org
Sender: owner-sybperl-l@peppler.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-8d39d25f-53d1-4bf8-b7df-773828b2305d
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0517_01C4C6AF.14E64BF0"

------=_NextPart_000_0517_01C4C6AF.14E64BF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Excuse me if this is already posted....

I've searched the list and googled with my best googling but I don't seem t=
o be able to find the answer to this one:

I've been having this odd problem where a "select" query returns a hashref =
that contains=20

COL(1) =3D> 0

when I'm expecting the values from the query.  I've implemented the 'syb_mo=
re_results' code, but I still seem to get bogus results from a fetch.

I sprinkled the syb_more_results, but to no avail.  It's as if the query is=
 getting someone else's result set.

do {
while (my $ref =3D $sth->fetchrow_hashref() ) {
 ..blah blah
} while ($sth->{syb_more_results});

freetds 0.62.1
DBD::Sybase 1.02

..all running on HP-UX 11i

The statement in question is a UNION of two selects and does not use any st=
ored procedures afaik, although I do use a built-in function (convert) to f=
ormat a date.  The probem is intermittent.  The same query wil sometimes wo=
rk perfectly, other times instead of the expected rows, I get the aforement=
ioned result.

I am using 2 statement handles.  An outer loop does a one query and based o=
n those rows an inner query.

Any thoughts?

Robert C. Lauer
Director, Systems Development
Charles Jones Inc.
rlauer@charlesjones.com

------=_NextPart_000_0517_01C4C6AF.14E64BF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Excuse me if this is already=20
posted....
 
I've searched the list and googled with my=
 best=20
googling but I don't seem to be able to find the answer to this=20
one:
 
I've been having this odd problem where a =
"select"=20
query returns a hashref that contains 
 
COL(1) =3D> 0
 
when I'm expecting the values from the que=
ry. =20
I've implemented the 'syb_more_results' code, but I still seem to get bogus=
=20
results from a fetch.
 
I sprinkled the syb_more_results, but to n=
o=20
avail.  It's as if the query is getting someone else's result=20
set.
 
do {
while (my $ref =3D $sth->fetchrow_hashr=
ef() )=20
{
 ..blah blah
} while ($sth->{syb_more_results});

 
freetds 0.62.1
DBD::Sybase 1.02
 
..all running on HP-UX 11i
 
The statement in question is a UNION of tw=
o selects=20
and does not use any stored procedures afaik, although I do use a built-in=
=20
function (convert) to format a date.  The probem is intermittent. =
; The=20
same query wil sometimes work perfectly, other times instead of the expecte=
d=20
rows, I get the aforementioned result.
 
I am using 2 statement handles.  An o=
uter loop=20
does a one query and based on those rows an inner query.
 
Any thoughts?
 

Robert C. Lauer
Director, Systems=20
Development
Charles Jones Inc.
rlauer@charlesjones.com


------=_NextPart_000_0517_01C4C6AF.14E64BF0--


------=_NextPartTM-000-8d39d25f-53d1-4bf8-b7df-773828b2305d--