Quote: ...or is there a list of characters that will upset a Sesame search, even though they are just included in text strings?
On Sesame, the "key string" is not an ordinary "text string". It uses the retrieve spec syntax. If you need to test a "key string" against the external data - you can do so using an retrieve spec in that database.
That being said, I created a Customers.db with "Malvern (Ohio)" and "Los Angeles (Ohio)" in the City LE. I then built an @XLookup in Gems.db:
//----------------
var str as string
str = @Xlookup("Customers.db", "Malvern (Ohio)", "City", "City")
writeln(str)
//----------------
It produced twelve "Malvern (Ohio)"s in the writeln window, one for each Gem_Types record. If I use:
//----------------
var str as string
str = @Xlookup("Customers.db", "Malvern (..", "City", "City")
writeln(str)
//----------------
It matches no records. But if I use:
//----------------
var str as string
str = @Xlookup("Customers.db", "Malvern (..)", "City", "City")
writeln(str)
//----------------
It matches "Malvern (Ohio)" without a hitch. This is exactly the same behavior I get if I build the same search specs in the City LE of Customers.db directly.
When you ask as to what characters "are not allowed" - the rules are the same as for a search spec. It isn't a question of what is allow, so much as question as to what characters have "special meaning" to a the search - essentially they are commands, like ".." meaning wildcard or range. These would include:
From Q&A:
..
<
>
[]
;
>=
<=
=
\
~
&
/
min
max
From Regular Expressions, we literalize (put a "\" in front of):
*
^
$
From Regular Expressions, we accept:
(
)
Parenthesis, in a search spec allows the grouping of operators, because:
(XX="1" and YY="2") or (WW="3" and ZZ=4")
is different from:
XX="1" and (YY="2" or (WW="3" and ZZ="4"))
Pages: 1
Send Topic 
Print
XLU won't work when parentheses in the ext key? (Read 1807 times)
