>>>...
>>>>>Thanks, reckon I'm on the right track now but still stuck. I have the code read into a variable and I have the following so that it removes the first x characters.
>>>>>

lcContent = SUBSTR(lcContent,AT("<",lcContent,1), LEN(lcContent) - (AT("<",lcContent,1) - 1))

>>>>>I show this to screen and it looks okay. But if I try to use it I get the adapter.tables.Count = 0. If I StrToFile and then read it back in I get the same Unicode BOM error.
>>>>>~M
>>>>
>>>>The document encoding is different from the one that is declared (UTF-16) and the parser is complaining at thar. If no one else steps in, I'll come back to you later, unless you find a solution for yourself (I'll have to go offline for a few hours).
>>>The file should have been sent to me in utf-8 and I thought that the utf-8/utf-16 string was a flag to show how it was to be interpreted rather than a storage format that modified the file itself.
>>>As it said utf-16 what I'm doing is using FileToStr and reading in the file. Then doing a StrTran to replace the utf-16 with utf-8. I'm also doing a StrConv(StrConv( , 11 ) , 2 ) to bring the file back to single byte format. Finally I'm doing a SubStr() of the file to exclude any characters before the first

<

. I then save the file as file1.txt and use FileToStr of this file but no joy. I know that I'm hovering around the solution and it does work if the data is in the prg file rather than coming from a variable so it's close but just can't get the last part over the line.
>>
>>If the file has the wrong BOM, just replace it the right one. Just google out "UTF-16 BOM" and replace the Unicode BOM with the proper one (i.e. remove the initial 2 or 3 bytes and prefix the file with the proper bytes for UTF-16) and try that way.

>Had a look and the BOM chars are from utf8 despite the text saying utf 16. Still no joy but after some testing with may own files it worked with an inbuilt schema as encoding 1252.
>Edit: scrap that, a different test file is encoded as utf 16. Looks like I'm getting back a mix of file formats.
>~M

So, summing up: a reasonable approach would be to (a) always read the file contents into a string, (b) fetch and strip off the BOM, if there is one, (c) check for file contents consistency (that is, match between actual file encoding and declared XML encoding), (d) force consistency, if needed, by transforming the string, and then (e) .LoadXML() the result of previous steps.