> Problems with #1: a collate clause is not legal syntax in a search

condition. That string should be

>
> 'FIELD1 CONTAINING ''abc'''
>
> If you need to force a collate order onto FIELD1, you might get away

with using a CAST:

> 'CAST(FIELD1 AS VARCHAR(99) CHARACTER SET WIN1250 COLLATE PXW_PLK)

CONTAINING ''abc'''

> (substituting 99 for the declared length of FIELD1, of course!

Collate clause is legal in where condition. And it works ok when applied
directly to where clause.
The problem is that parser adds an extra useless 'AND' between 'collate'
and 'containing' while converting from filter to where clause:
WHERE (FIELD1 collate pxw_plk AND CONTAINING ''abc'').
Collate is necessary for correctly filtering diacritical characters.

> >#2
> Could you try adding that pair of external parentheses yourself, to

see how the parser handles them in each case? i.e.

>
> '(c(FIELD1)||c(FIELD2)||c(FIELD3) containing ''abc'')'
>
> and also
> '(c(FIELD1)||c(FIELD2)||c(FIELD3)) containing ''abc'''

All cases raise exception as in original case.

> BTW, I can see that expression causing problems at the server if any

of those operands is nullable - although the IBO parser can't know
that...


c() is an udf function that returns empty string if a field value is
null, so it does not cause any problems at server.


Regards, Tomek



[Non-text portions of this message have been removed]