sybperl-l Archive

From: "Rob Lauer" <rlauer at charlesjones dot com>
Subject: Re: fetchrow_hashref
Date: Nov 10 2004 12:09PM

Thanks...that's essentially what I was doing in my loop if I didn't find a
hash element populated that I knew based on the query had to be a non-null
value.


I assumed the current fetch was a "bogus" row , however implementing the
iteration around syb_more_results did not result in the loop getting any of
the data I expected.  The good data never shows up apparently.  Am I missing
something?  I don't mind a code around until I install the new FreeTDS but I
must be doing something wrong.

I've also verified that the syb_result_type = 4043 indicating this is a proc
status and not fetch data.   Do I need to issue the execute again in order
to get a valid statement handle that has SELECT data?

BTW...thank you for your efforts on this project.  It's amazing the effort
that must have gone into creating an interface like this and then putting it
into the open source community.


----- Original Message ----- 
From: "Michael Peppler" 
To: "Rob Lauer" 
Cc: 
Sent: Wednesday, November 10, 2004 1:54 AM
Subject: Re: fetchrow_hashref


> On Wed, 2004-11-10 at 04:54, Rob Lauer wrote:
> > Excuse me if this is already posted....
> >
> > I've searched the list and googled with my best googling but I don't
> > seem to 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
> >
> > COL(1) => 0
> >
> > when I'm expecting the values from the query.  I've implemented the
> > 'syb_more_results' code, but I still seem to get bogus results from a
> > fetch.
>
> I got the same thing the other day. Apparently MS-SQL 2k will sometimes
> return a "status" result if the index statistics have been recomputed
> (or for other reasons). I believe that the FreeTDS folks have fixed this
> in the CVS version of the code.
> My work-around was to check for the syb_result_type, and if I had issued
> a normal SELECT and I got a CS_STATUS_RESULT type back then pull the
> data but ignore it.
>
> Michael
> -- 
> Michael Peppler                              Data Migrations, Inc.
> mpeppler@peppler.org                       http://www.peppler.org/
> Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
> long term contract positions - http://www.peppler.org/resume.html
>