I got syntax error at end of the query near ; SQLCODE=-131, ODBC 3 State='42000' I believe the error stems from using ...dba.$Regex_Match(...
where dba.$Regex_Match is defined as
and the corresponding clr member is
I have used successfully other members from the dll for clr proc. this is my first time using clr function. |
I think the error comes from the fact that you treat the bit datatype as a boolean value which is not valid in SQL Anywhere - cf. that sample which also raises -131 (SQLE_SYNTAX_ERROR):
In contrast, the following comparison with 0 or 1 will work:
So I guess you just might have to change the second condition to "...or dba.$Regex_Match(acct_type_short_name, @excludeSubAcctAliasRegexPatternLst) = 0" FWIW, there's not boolean datatype in SQL Anywhere. |
To restate Volker's correct answer: bool maps to BIT in SQL Anywhere, and BIT is an integer data type, NOT a boolean TRUE/FALSE or TRUE/FALSE/UNKKNOWN datatype. There is no boolean data type for variables in SQL Anywhere. Predicates (comparisons) can return boolean values, of course, but you cannot store or pass around those values. Perhaps you can code it this way... or not ( dba.$Regex_Match(acct_type_short_name, @excludeSubAcctAliasRegexPatternLst) = 1 ) if 1 is the true bool value that is mapped to integer bit (I don't know, you tell me :) |
Aside: You might also use SQL Anywhere's builtin regular expression support, i.e. SIMILAR TO and/or REGEXP, and note, those can be used as boolean values, i.e.
I guess the .NET RegexOptions can be mapped to according patterns/flags.
thx
I failed to find flags for clr compatiabiilty of regex in silmilar to and regexp for SA 11... ( found the online syntax:http://dcx.sybase.com/1101/en/dbreference_en11/rf-sqllanguage-s-4915351.html)
if you wonder why clr regex match, the filter is actually a list of ansi like expression reformatted as regex
Sorry, my last sentence was misleading. SIMILAR TO and REGEXP do not use flags but I guess the .NET RegexOptions flags can be expressed with according patterns and/or the different behaviour of SIMILAR TO vs. REGEXP - e.g. SIMILAR TO uses the database collation (and therefore will use "ignore case" semantics in a case insensitive database) whereas REGEXP will use case sensitive semantics - cf. this overview from the v11.0.1 "What's New" pages...