MATCHES and LIKE
Informix®
Informix supports MATCHES
and
LIKE
operators in SQL statements.
MATCHES
expects *
and ?
wild-card characters,
while LIKE
uses the %
and _
wild-cards as
equivalents.
( col MATCHES 'Smi*' AND col NOT MATCHES 'R?x' )
( col LIKE 'Smi%' AND col NOT LIKE 'R_x' )
MATCHES
accepts also brackets notation, to specify a set of matching characters
at a given position:
( col MATCHES '[Pp]aris' )
( col MATCHES '[0-9][a-z]*' )
Microsoft™ SQL Server
Microsoft SQL Server does not provide an equivalent of
the Informix MATCHES
operator.
The LIKE
operator is supported.
The LIKE
operator of SQL Server does not evaluate to true with
CHAR/NCHAR
columns, if the LIKE
pattern is provided as a UNICODE
string literal (with the N prefix), and the search pattern matches the value in the column (without
an ending % wildcard for example).
See the following test:
CREATE TABLE mytable ( k INT, nc NCHAR(20) )
INSERT INTO mytable VALUES ( 1, N'abc' )
SELECT * FROM mytable WHERE nc = 'abc' -- one row is returned
SELECT * FROM mytable WHERE nc = N'abc' -- one row is returned
SELECT * FROM mytable WHERE nc LIKE 'abc' -- one row is returned
SELECT * FROM mytable WHERE nc LIKE N'abc' -- no rows are found
SELECT * FROM mytable WHERE nc LIKE N'abc%' -- one row is returned
This can be an issue because the SQL Server driver will by default automatically add an N prefix before all string literals in SQL statements.
See Microsoft SQL Server documentation for more
details about the LIKE
semantics regarding blank padding and see also CHARACTER data types for the N prefix usage
and single-char or wide-char mode usage.
Solution
The database driver is able to translate Informix
MATCHES
expressions to LIKE
expressions, when no [
]
bracket character ranges are used in the MATCHES
operand.
MATCHES
to LIKE
expression translation is controlled by the
following FGLPROFILE
entry:dbi.database.dbname.ifxemul.matches = { true | false }
[NOT] MATCHES
followed by a search pattern provided as
a string literal can be converted by ODI drivers. A [NOT] MATCHES
followed by a ?
question mark parameter place holder is not translated!For maximum portability, consider replacing the MATCHES
expressions with
LIKE
expressions in all SQL statements.
Avoid using CHAR(N)
types for variable length character data (such as name,
address).
LIKE with UNICODE string literals on CHAR/NCHAR columns
Pay attention to UNICODE string prefixes N'...' in the LIKE
expressions when
used with CHAR/NCHAR
columns: You might want to always add a %
wildcard at the end of the LIKE
expression, or use the equal operator when doing a
query with exact values.