[ic] Long-lived co=1 bug

Grant emailgrant at gmail.com
Wed Mar 10 19:06:11 UTC 2010


>> > > > There has been a long-lived bug that doesn't allow something like this
>> > > > to work properly:
>> > > >
>> > > > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
>> > > > [loop-data orders order_number]
>> > > > [/loop]
>> > > >
>> > > > Even though the shipment_notification_sent field is set to 1 for every
>> > > > record in the table, this has a ton of output, maybe all the orders.
>> > > > Adding co=1 fixes it, but this isn't a coordinated search.
>> > > >
>> > > > I've reported this bug before, and someone told me it's a known bug.
>> > > > I'm using IC 5.2.  Is there any hope of this being fixed?
>> > >
>> > > At least it is weird behaviour and I don't like it as well. But I think we
>> > > need the expertise of Mike Heins who can tell us what would break if we
>> > > fix this somehow :-)
>> > >
>> > > Bye
>> > >         Racke
>>
>> I'm having a hard time pinning this down so I know when I need to use
>> co=1 for a non-coordinated search.  Does anyone know when that is
>> necessary?
>
> I think if the op= parameter is given.
>
> Bye
>        Racke

About 5 1/2 years later, I think I've got this more nailed down.
Adding co=1 seems to be necessary unless there is only one sf/se block
and op=eq is in affect.  Is this really a bug, or am I
misunderstanding mv_coordinate?

This document:

http://docs.icdevgroup.org/cgi-bin/online/search/search_reference.html

says:

"the so-called "coordinated" search allows for multiple search options
to be stacked on top of each other"

but it seems to be necessary even when there is only one sf/se block
unless using op=eq.

- Grant



More information about the interchange-users mailing list