I would like to supplement the above with such parameters as STORAGEDEFAULT, SQLTABLENAME, and SQLPROJECTION: Storage and SQL Projection of Collection Properties

However a collection property is actually stored, the property can be projected as a column in the parent table, as a child table, or in both ways (as of release 2022.1, this is true for both list and array properties). To control this, you specify the SQLPROJECTION parameter of the property.

Thanks for the hint, I fixed it.
By the way, your code can be reduced to 173:  f i=$i(r):1:a

There is no limit to perfection.

By the way, your code shows 175 characters, where did the number 174 come from?

Ah, got it.

I improved my score to 179 (see above).

Have you used a test case?

Have you used a test case?

Try this:

ClassMethod test2()
{
  set tKP = ..%New()
  set tIdentifierSerial = ##class(HS.Message.AddUpdateHubRequest).%OpenId(21986071).Identifiers
  zw tIdentifierSerial
  set tKP.IsSerial = 1
  set tKP.IsList = 1
  set tSerial = tIdentifierSerial.GetObjectNext(.tKey)
  for {
    if tKey="" {quit}
    do tKP.SerialList.InsertObject(tSerial)
    set tSerial = tIdentifierSerial.GetObjectNext(.tKey)
  }
  w tKP.%Save()
}

As far as I understand, the author wants to calculate the value of a field based on some list of fields whose names he takes from some table. Right?

Try inserting an apostrophe through concatenation, something like

INSERT INTO MyText
    (text)
VALUES
    ('I visited O' || CHAR(39) || 'Brien before heading out of town.')

I'm getting an error:

ERROR #9406: Unexpected format for value of field, searchCriteria, using class base mapping

After fixing the JSON, the error disappeared:

{"searchCriteria": {..}} ==> {"searchCriteria": [{..}]}

Also note the mapping between the fields professionalId/professionalNif and preparation/actPreparation

Your code does not take into account the numbers, so an incorrect result is given for "L33T C0d3r".

SELECT JSON_ARRAYAGG(json_obj)
  FROM (SELECT TOP 5
            JSON_OBJECT(
              'Name':name
              ,'Age':age
              ,'DOB':to_char(dob,'Day DD Month YYYY')
            ) json_obj
           FROM sample.person
       )

SELECT JSON_ARRAYAGG(json_obj)
  FROM (SELECT JSON_OBJECT(
                'Name':name
                ,'Age':age
                ,'DOB':to_char(dob,'Day DD Month YYYY')
                ) json_obj
       FROM sample.person
       )
  WHERE %VID BETWEEN 1 AND 5

Reduced your code to 137:

ClassMethod ToKeyPad(p) As %String
{
 f i=1:1:$l(p){f j=0:1:9{f l=1:1:$f($p(" 0^1^ABC2^DEF3^GHI4^JKL5^MNO6^PQRS7^TUV8^WXYZ9","^",j+1),$e($$$UPPER(p),i))-1 s r=$g(r)_j}} q r
}

Yes, most likely this is legacy code.
For some reason I thought that since the %JSON package classes appeared only in IRIS, the code would also have to be new.

PS: by the way, can you compile an XData block without a name? Studio doesn't highlight the error?

It is strange that the bug has not been fixed yet, because it is easy to fix it by adding one line to ##class(%JSON.Generator).GenerateMappingFromXdata():

<..>
For i=1:1:count {
  Set xdata=compiledclass.XDatas.GetAt(i)
  Set configName=xdata.Name
  If configName="" Continue ; since the Name field is required, how can it be empty?
  If xdata.MimeType'="text/xml" Continue
<..>

PS: by the way, I didn't quite understand why need to check "configName", given that "Name" is a required field. Any ideas?

For versions of Caché 5.0.x, try the following code:

#include %systemInclude

n

s list=$lb(
  "test",
  "for",
  "searching unknown strings here is a very long piece with enough characters to get a lowercase alpha as a $list marker",
  "items",
  "in",
  "aaatArGetwaaaa",
  "lists",
    $lb(
    "/subs",
    "/values",
    "nested list",
    "did you see that ""w"" before the third piece?",
    "Stuart Strickland",
    "Yaron Munz")
)

s str=$$$UPPER($$cccvt^%Wpglo(list,$$$MaxStringLength,.warn))
; or
; s str=$$$UPPER($$listDump^%Wprim(list,9))

i 'warn {
 s str=$e(str,3,$l(str)-2) ; remove << & >>
 ;s @("LIST="_str) zw LIST
 
 w !,$f(str,$$$UPPER("Targetw"))
}

Result: 162

If you end up searching for globals that use $lb(), then you might find it useful:

• $$gloFind^%Wprog(gref,string,case,.record) - for Caché 5.0.x
• ##class(%Global).Find/Get() - for new versions of Caché/IRIS