No idea what the standard says but I was surprised to find that POS does not honor the fact that the column is ANSI_CI and requires the text to match case.

Roy Lambert

Roy,

> No idea what the standard says but I was surprised to find that POS does not honor the fact that the column is ANSI_CI and requires the text to match case.

Good to know! I wouldn't have expected that, too.

Uli

Roy,

<< No idea what the standard says but I was surprised to find that POS does
not honor the fact that the column is ANSI_CI and requires the text to match
case. >>

I'll have to double-check, and the standard may be mute on this topic, but
AFAIK, none of the functions operate based upon the collation of the columns
being passed in to them.  IOW, functions act just like functions in any
development language - it's just a string coming in.  Plus, this would
break, or render partially-inoperable, custom functions that don't have any
way of expressing the collation aspects of incoming strings.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< No idea what the standard says but I was surprised to find that POS does
>not honor the fact that the column is ANSI_CI and requires the text to match
>case. >>
>
>I'll have to double-check, and the standard may be mute on this topic, but
>AFAIK, none of the functions operate based upon the collation of the columns
>being passed in to them. IOW, functions act just like functions in any
>development language - it's just a string coming in. Plus, this would
>break, or render partially-inoperable, custom functions that don't have any
>way of expressing the collation aspects of incoming strings.

Looking in EDBManager's OLH I can see four functions where collation might have any impact POSITION, OCCURS, REPLACE and TRIM.

Based on the amount of disruption that may occur if any changes are made I'd probably just bung a nice big comment in the manual

Roy