>>>Actually XML conversion and white space treatment in general is a big problem if you want to maintain data integrity. Real easy to lose carriage returns in strings in particular as XML turns all CR/LF to CHR(10)s which then requires manual fixups. Especially bad for memo type data from databases especially with XmlAdapter/XmlToCursor.
>
>I agree that loading big blocks of text into an XML segment can turn real bad, especially when you encounter one of the non-MS XML implementations that set maximum segment size of as little as 32Kb. ;-)
>
>But what about the OP's example of an array of integers and strings with email address given as a sample? I thought that the XML for that sort of array would be lightweight and fairly trouble-free... and maybe even overkill, since a delimited string would be very easy at both ends, even if some munging is needed.

That works as long as you have control over the .NET code and you can control what the .NET code returns or sets. :-)

Personally I use wwDotNetBridge for those scenarios - it just wraps the array and keeps it in .NET and returns only the elements to FoxPro. It's actually fast too because the array as a whole is never converted - only the elements. Little more verbose syntax for those calls that return arrays (or other special types that don't work with plain Interop) but it outweighs the extra command length easily.

+++ Rick ---