Up Prev Next
From: Michael Peppler <mpeppler at peppler dot org>
Subject: Re: fetchrow_hashref
Date: Nov 10 2004 1:46PM
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
> 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
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 :-)
> ----- Original Message -----
> From: "Michael Peppler"
> To: "Rob Lauer"
> 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.
> > firstname.lastname@example.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
Michael Peppler Data Migrations, Inc.
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.peppler.org/resume.html