HP-UX 11i
Ingres 2.6

I have some really strange behavior with a statement using an in(...)
clause in a cgi script. At this point I'm not sure if the problem is
ingres, DBI or DBD :-(. I don't think it's ingres in and of itself -
I'm just posting here because hopefully someone has seen this before
using ingres in a cgi environment.

Only the last item in the in-clause is being acted on when I'm sure that
more than one item meets the requirements. If I use the same in-clause
in isql all relevant items in the in-clause are acted on :-( Another
odd behavior is that if I manipulate the perl script to generate the
same in-clause and run it from the command line all relevant items in
the in-clause are acted on.

The obvious conclusion would be that something in the cgi environment is
causing this. But why wouldn't the whole statement fail instead of just
the last item in the in-clause be acted on? A $DBI::lasth->{statement}
shows a valid sql statement. If I put only one item in the in-clause
then it works (but then it might as well be an equality, and would be
extremely time consuming to iterate over hundreds of items as a
singleton query).

The cgi form lets the user input hundreds of items if needed, but when
processed it's broken up into smaller chunks to avoid a stack overflow
problem with a huge in-clause. The problem I'm seeing has only 5 items
in the in-clause.

No errors are returned, no errors in the httpd error log, no error
messages in the ingres error log, no error in $DBI::err, etc.

I'm really grasping at straws at this point, but I'm really struggling
to isolate where the problem is :-(. Any points, suggestions, hints,
etc., would be appreciated.

If it should make a difference, the db connections are to vnodes. In
all cases but one, the connection is from 2.6->2.6. In one case it's
from 2.6->6.4, but the behavior is the same.

Thanks

Dennis

d underscore roesler at agilent dot com

I guess it's not proper etiquette to reply to your own post, especially
with egg on you face :-), but...

I was using an unintended array to generate the in-clause list. I have
one array that is the list the user entered, and another that holds
validated items from the input list. I was using the input array and
not the array with validated items.

What still confuses me is that in this case they were both identical, so
in theory either should have worked. In fact, the
$DBI::lasth->{Statement} showed a valid sql statement with the correct
in-clause list when I used the input array.

I should have done what I eventually did (and usually do)... walked away
from it and came back later to look at the problem :-(

Cheers

Dennis


Dennis Roesler wrote:
> HP-UX 11i
> Ingres 2.6
>
> I have some really strange behavior with a statement using an in(...)
> clause in a cgi script. At this point I'm not sure if the problem is
> ingres, DBI or DBD :-(. I don't think it's ingres in and of itself -
> I'm just posting here because hopefully someone has seen this before
> using ingres in a cgi environment.
>
> Only the last item in the in-clause is being acted on when I'm sure that
> more than one item meets the requirements. If I use the same in-clause
> in isql all relevant items in the in-clause are acted on :-( Another
> odd behavior is that if I manipulate the perl script to generate the
> same in-clause and run it from the command line all relevant items in
> the in-clause are acted on.
>
> The obvious conclusion would be that something in the cgi environment is
> causing this. But why wouldn't the whole statement fail instead of just
> the last item in the in-clause be acted on? A $DBI::lasth->{statement}
> shows a valid sql statement. If I put only one item in the in-clause
> then it works (but then it might as well be an equality, and would be
> extremely time consuming to iterate over hundreds of items as a
> singleton query).
>
> The cgi form lets the user input hundreds of items if needed, but when
> processed it's broken up into smaller chunks to avoid a stack overflow
> problem with a huge in-clause. The problem I'm seeing has only 5 items
> in the in-clause.
>
> No errors are returned, no errors in the httpd error log, no error
> messages in the ingres error log, no error in $DBI::err, etc.
>
> I'm really grasping at straws at this point, but I'm really struggling
> to isolate where the problem is :-(. Any points, suggestions, hints,
> etc., would be appreciated.
>
> If it should make a difference, the db connections are to vnodes. In
> all cases but one, the connection is from 2.6->2.6. In one case it's
> from 2.6->6.4, but the behavior is the same.
>
> Thanks
>
> Dennis
>
> d underscore roesler at agilent dot com