[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