Re: fetchrow_hashref

On Wed, 2004-11-10 at 13:09, Rob Lauer wrote:
> 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 don't actually know what the problem is - I've only used FreeTDS (and
MS-SQL) sporadicly.

You might try re-issuing your query in this situation and see if you get
the correct results on the second try...

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

Maybe - though I don't really know why that might be the case. You might
want to take this up on the freetds list.

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

I've used a lot of freeware over the last 15-20 years - my way of saying
thanks... and you're welcome :-)

Michael


> ----- Original Message ----- 
> From: "Michael Peppler" <[email protected]>
> To: "Rob Lauer" <[email protected]>
> Cc: <[email protected]>
> 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.
> > [email protected]                       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
> >
-- 
Michael Peppler                              Data Migrations, Inc.
[email protected]                       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