The "X" commands compile the data on the server, and don't take client settings (like the string array separator setting) into account. I may change it so that it is one of the parameters sent from the client to the server when string array "X" commands are called.

In the meantime, there are two approaches that might serve you. You could filter the data in the external application, replacing the ';' with a known character that is less likely to appear, then replacing that character with the semicolon before the data is displayed on the client. This can be done on data entry on that app, and a mass update can repair the existing data.

If that is out of the question, or too inconvenient, you can place a field in that external database that contains a known and unlikely value. Then when you call the "X" source list command, "brace" the fields that may contain a semicolon between (or at least followed by) the field with the known value. That way if you run into a extra semicolon between the start of the field and the known value, you know that it is part of the data.

I'll see if I can get the client's choice for string array separator over to the server (in a way that does not upset the other clients!)

Carl,

While you might not need it, here is an example of the second idea outlined above:

ar aa as string
var bb as string
var cc as int

aa = @XLookupSourceList(@fn, "..", "Company", "KEY;one;First;one;Last;one;Company;one;City")
SetStringArraySeparator("|")
// strip away extraneous semicolons
for cc = 1 to 5
	bb = @AccessStringArray(aa, cc)
	if(cc = 1)
	{
		bb = @Left(bb, @Len(bb) - 1)
	}
	else if(cc = 5)
	{
		bb = @Right(bb, @Len(bb) - 1)
	}
	else
	{
		bb = @Mid(bb, 2, @Len(bb) - 2)
	}
	writeln(bb)  // write out the resulting string
next
 

The LE "one", of always contains a "|".