On Wed, 28 Mar 2001, Alexander Farber (EED) wrote:
> Curt Russell Crandall wrote:
> > No that wasn't the case here. Each select only produces 1 result row.
>
> Are you really sure it was 1 row?
>
That has been verified. It is a small table containing only 7
rows... for now.
> > So, I just did a
> >
> > $sth->execute(....) or die(...);
> > $href = $sth->fetchrow_hashref();
>
> I would try
>
> while ($href = $sth -> fetchrow_hashref)
>
> instead.
>
Well, there's no need for that with there being only one row... if there
is more than one row, then there is a problem because that would conflict
with a business rule.
If only one row is returned (which IS the case here), there is NO reason
why DBD::Sybase/Sybase should be issuing the warning:
DBD::Sybase::st execute failed: OpenClient message: LAYER = (1) ORIGIN =
(1) SEVERITY = (1) NUMBER = (16)
Message String: ct_param(): user api layer: external error: This routine
cannot be called while results are pending for a command that has been
setn to the server.
> > In the method... the method is executed in a loop within the caller.
> > With Sybase, it was necessary to insert a finish after the call to
> > fetchrow_hashref...
>
> I never seen that and will believe it only if I see some code.
> You don't have to call finish if you have fetched _all_ results.
>
The code is too large to post here and I'd have to clean out proprietary
names, etc. to post. It suffices to say that I prepare a statement
handle, then in a loop, that statement handle is executed and the single
row is fetched. Even when a single row is returned, the current
configuration of Sybase, Perl, and DB* causes me to something like adding
a call to finish or what you had suggested with some sort of a loop.
> > from what I recall, the error happened at compile time
> > and didn't even attempt execution (I could be wrong about that, though).
> >
> > So for me, there were 2 morals of the story here. First, in regards to
> > the original question, it's not necessary to keep doing a prepare just
> > because you call finish on the statement handle. Second, avoid Sybase
> > whenever possible.
>
> Sybase is a nice database, I don't understand why are you saying this.
>
EVERYONE I've worked with who has used Sybase dispises it. EVERY client I
have worked for that has used or is using Sybase is/has switch(ing) to
something like Oracle unless they have too much invested in Sybase to
economically switch to something else. My personal experience working
with Sybase after working predominantly with Informix has been rather
negative.
To quote my last PM who has worked with databases for 15+ years and with
DBI for 3+ years "Sybase sucks. Get a real database. Or a smarter client
:) Only suckers have fallen for Sybase in recent history; everyone else
wised up years ago." I wouldn't call anyone who uses Sybase a
"sucker" since obviously there are those that like it. MY EXPERIENCE has
been that most do not... but that's only my opinion.
> > I've been doing most of my DBI development with
> > Informix and when I started working with Sybase it's been one problem
> > after the other... i.e. no placeholders in statements executing stored
> > procs, can't have multiple statement handles open on a db handle with
> > AutoCommit off, etc. etc. Some of this may be due to the fact that the
> > Sybase driver is not current (I have no choice),
>
> What hinders you to install the current Perl module (DBD::Sybase or
> Sybperl)? You can always do that (for example in your home dir).
>
The client. Installing something my home directory is mostly a waste of
time since it cannot be used in production. As frustrating as it can be
not to have the latest and greatest of everything, the reality is that
many clients, particularly in the financial industry, do not (cannot
?) regularly upgrade compilers, interpreters, libraries, OS's etc.
Thanks for all of the input. I had forgotten about using do {} while
($sth->{syb_more_results} which will come in handy in my next app.
--Curt
