New post
AllAccepted answers
John Murray · Mar 15, 2017

Like most DC posts nowadays, this one got auto-crossposted to the intersystems-public-cache Google Group. When I checked this morning there were 5 responses from people trying to help the original poster. But since those answers don't automatically feed across to DC I'm drawing attention to them here. Because unless the OP knows to look there they may never see them.

https://groups.google.com/forum/#!topic/intersystems-public-cache/fngd5j...

John Murray · Mar 3, 2017

Here are some initial suggestions / comments (no particular priority):

  1. Standardize on capitalization in naming. For example classnames EX.example and Sample.Classes, and property names name and Location.
  2. Use singular for your classname, e.g. Class rather than Classes
  3. Use meaningful classnames, e.g. Sample.Employee rather than Sample.Classes
  4. Use meaningful method names. e.g. insert or Insert rather than hello
  5. Avoid namespace switching unless really necessary. Presumably in your case the Sample.Classes class is in the USER namespace and the EX.example is somewhere else (maybe you wrote it in your SAMPLES namespace).
  6. For a REST interface, consider returning results in a structured form, e.g. JSON.
  7. Make good use of indenting. Perhaps you already have done this and the post to DC has mangled it.
  8. Avoid using Z-commands, $Z-functions and $Z if non-Z equivalents are available. For example, SET $NAMESPACE="USER" instead of ZN "USER". Note that you can also preserve the current $NAMESPACE value using NEW $NAMESPACE which will automatically reinstate the value when the stack level is exited.

I hope this is a useful start.

John Murray · Feb 7, 2017

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.

John Murray · Feb 2, 2017

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.

John Murray · Jan 31, 2017

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.