Re: fetchrow_hashref

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" <[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
>