Just in case it's relevant, what is your $ZV string?

w $zv

I think you could simplify your first approach a little by reverting to calling OpenStream on your reader object rather than using OpenFile:

  // 1st approach - it succeeds, so the file errorOpenFile.xml is NOT generated
  //    
  d msg.Value.Rewind()
  set fs=##class(%Stream.FileCharacter).%New()
  set fs.Filename="D:\DATABASES\OVPATH\temp\test.xml"
  set fs.TranslateTable = "UTF8"
  set tSC=fs.CopyFrom(msg.Value)
  set tSC=fs.%Save()
    
  s reader=##class(%XML.Reader).%New()

  d fs.Rewind() // might not be necessary, but won't hurt
  Set sc = reader.OpenStream(fs)

Anyhow, the fact that you don't get an error confirms my hypothesis that the original stream (msg.Value) contains Unicode data but the reader treats it as though it is UTF8-encoded.

In your code above I think you can also omit the line where you set fs.Filename and instead allow the stream to generate its own temporary file. Explicitly naming the file may be handy when debugging, but it will cause problems if more than one process runs this code concurrently.
 

There's no BOM, and the XML header claims that the content is UTF-8 encoded. But on your other post you reported that your content contains a left-single-quote character and that the SAX parser choked on a character, which I suspect was this character in Unicode form rather than UTF-8 encoded.

So, what originally wrote the pInput stream's content? Did it actually UTF-8 encode the data it wrote to the stream?

What does the start of the pInput stream contain? One quick but ugly way of checking this would be to write it to a scratch global before the call to OpenStream which errors, e.g.

Set ^tMurillo=pInput.Read(255) Do pInput.Rewind()

Then afterwards run the following in Terminal:

w ^tMurillo

w $a(^tMurillo,1),!,$a(^tMurillo,2),!,$a(^tMurillo,3)

This should show us whether the creator of the stream started it with a BOM character or sequence, and also whether there is an XML header specifying an encoding.

That information is apparently important to the %XML.SAX.StreamAdapter used by %XML.SAX.Parser, which in turn is what the OpenStream method of %XML.Reader uses.

I'll repeat what I wrote on the previous DC thread you opened about this issue:

I think you need to focus on the input stream. What type of stream is pInput ? You can get its classname using pInput.%ClassName(1)

If it is a file stream, what wrote it? Does its file contain a BOM at the start?

Aha! I have changed those two settings and I now see the extra columns of checkboxes.

Thanks Eduard. I'd add, this has to be done from the %SYS namespace.

I think this limitation is unfortunate. Encountering the "Service unavailable" when you're trying to evaluate Caché for the first time might discourage you from continuing.

Sorry to hear about your experience with Deltanji. I've not been able to find any sign that you contacted us at George James Software for assistance. Given the chance, we're generally helpful folk.

Also, the $ZF calls made by Studio via your source control class will operate with the server credentials that the InterSystems superserver (port 1972, typically) uses. On Windows that's the logon account of the Caché/Ensemble/HealthShare service. Whereas when you launch a Caché terminal onto you local instance from your Windows desktop, your $ZF calls will use the credentials you logged in to the Windows desktop with. Similarly on non-Windows platforms.