Based on my reading of 2014.1 code the Exists method in Ens.Util.FunctionSet doesn't check locks when testing for the existence of the entry.

I think the Save button from Portal leads to the SaveLookupTable method of EnsPortal.LookupSettings. That method obtains an exclusive lock on the subtree of ^Ens.LookupTable where the LUT gets stored. It then kills the entire LUT and re-files each entry one by one. Once finished it releases the lock.

All of that is protected by a TSTART / TCOMMIT but this is not sufficient to prevent another process momentarily detecting the absence of an entry that would normally exist.

I assume you want the subscripts of the global always to collate as strings. If so, here's how you can specify the collation type of a global when you create it. Note that the global must not exist to start with:

USER>w $D(^a)
0
USER>s sc=##class(%Library.GlobalEdit).Create(,"a",133)
 
USER>w sc
1
USER>s ^a("1.0012")=""
 
USER>s ^a("1.0011")=""
 
USER>s ^a("1.0010")=""
 
USER>zw ^a
^a("1.0010")=""
^a(1.0011)=""
^a(1.0012)=""
 
USER>

To get a list of collation codes (which is where I found 133):

%SYS>d ^COLLATE
 
Status       Number   Abbrev   Name
----------   ------   ------   ----------------------
Built-in        0     OANS     ISM Pre-6.2
Built-in        1     ANSI     ISM 6.2->6.4
Built-in        2     COBR     Ipsum/Cobra
Built-in        3     DTMC     DTM-compatible
Built-in        4     CBR2     Ipsum/Cobra-2
Built-in        5     UNIC     Cache standard
Not loaded     10     GER1     German1
Not loaded     11     POR1     Portuguese1
Not loaded     12     POL1     Polish1
Not loaded     13     GER2     German2
Not loaded     14     SPA1     Spanish1
Not loaded     15     DAN1     Danish1
Not loaded     16     CYR1     Cyrillic1
Not loaded     17     GRE1     Greek1
Not loaded     18     CZE1     Czech1
Not loaded     19     CZE2     Czech2
Not loaded     20     POR2     Portuguese2
Not loaded     21     FIN1     Finnish1
Not loaded     22     JAP1     Japanese1
Not loaded     24     POL2     Polish2
Not loaded     27     FRE1     French1
Not loaded     28     FIN2     Finnish2
Not loaded     29     HUN1     Hungarian1
Not loaded     30     GER3     German3
Not loaded     31     POL3     Polish3
Not loaded     32     SPA2     Spanish2
Not loaded     33     DAN2     Danish2
Not loaded     34     GRE2     Greek2
Not loaded     35     FIN3     Finnish3
Not loaded     36     LIT1     Lithuanian1
Not loaded     37     CYR3     Cyrillic3
Not loaded     38     SLO1     Slovenian1
Not loaded     39     SLO2     Slovenian2
Not loaded     40     TUR1     Turkish1
Not loaded     41     DAN3     Danish3
Not loaded     42     UKR1     Ukrainian1
Not loaded     43     CYR4     Cyrillic4
Not loaded     44     CZE3     Czech3
Not loaded     46     MAL1     Maltese1
Not loaded     48     MAL2     Maltese2
Not loaded     49     SPA4     Spanish4
Not loaded     50     SLO1     Slovak1
Not loaded     51     SPA5     Spanish5
Not loaded     52     FIN4     Finnish4
Built-in      128     OSTR     ISM Pre-6.2 string
Built-in      129     NSTR     ISM 6.2->6.4 string
Built-in      133     USTR     Cache standard string
 
%SYS>

If you don't want to have to bother with setting the global to use String collation rather than the default (which will be what's sometimes called Numeric collation), then prefix all your subscripts with a character that will force them to be interpreted as a string. Cache SQL uses this trick internally, adding a leading space (" ") to the subscripts it creates.

It's now been confirmed that the relevant parsers will not be ported to OpenVMS. So it'll never be possible to roundtrip all classes in UDL from that platform.

Also worth noting that GetTextAsFile appears to pre-delete the class it's about to import before it encounters the parse error and aborts the import. So you're left without a copy of the class in your namespace. Oops!

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.
 

Based on our comment thread I think the most likely cause is that the pInput %Library.GlobalCharacterStream (originating from the Value property of the object that was returned when you Invoke your webmethod) starts with an XML header claiming that its encoding="UTF-8" but I suspect that the characters within that global stream are actually Unicode rather than UTF8-encoded.

To test this theory I suggest you create a new %Library.FileCharacterStream, set its TranslateTable property to "UTF8", then use its CopyFromAndSave method to fill it with the contents of pInput. Now pass your FileCharacterStream to your %XML.Reader's OpenStream method and see if you still get the SAX error.

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.

Please clarify what you mean by "browse the file contents".

Are you opening c:\TEMP\SoapTree.xml in a text editor?

Maybe that editor is assuming that the file is UTF8-encoded.

Can you view it in a tool that shows you the byte values it contains?

Did you have a particular reason for choosing to write the file using an instance of %Stream.FileBinary instead of %Stream.FileCharacter?

Also, be aware that the WebMethod classmethod of %SOAP.WebBase is tagged as "Internal" and commented thus:

/// This method is used internally by Caché. You should not make direct
/// use of it within your applications. There is no guarantee made about either
/// the behavior or future operation of this property.
 

What is the nature of the failure?

Perhaps when you save your LUT changes there's a small time window during which no LUT entries exist. This is pure speculation on my part, as I haven't investigated. But if it's true then I can imagine this could cause problems in the production. In which case, perhaps you need to suspend at least the relevant parts while you save the change.

%Admin_Task is a Resource, as are %Admin_Manage and %Admin_Operate.

In contrast, %All is a Role.

Access to SQL tables is controlled either at the Role level or at the individual User level.

If your user has permissions on the %Admin_Task resource because they hold a role, then it may be appropriate to grant the necessary SQL permissions to that role. By doing this, anyone else holding the role will also be able to access the table.

To grant the SQL permissions, edit the role (or user) definition. Go to the "SQL Tables" tab. Set the namespace dropdown to "%SYS" and check the box to include system items:

In my example above the %Operator role has no permissions on SQL tables in %SYS.

Use the Add Tables button to add a row that gives this role permission to perform a SELECT on the %SYS_Task.History table .