The following query produces zero results:

select bar.name from foo join bar on bar.id %INLIST MyBars

This is because MyBars is stored as a $lb($lb(id1),$lb(id2),...,$lb(idN)), and you try to query the data stored in the form $lb(id1,id2,...,idN).

Your query need some change to make it work, namely:

select name from foo join bar b on $listbuild(b.%ID) %INLIST MyBars

For passing array by reference try to use the class $system.WorkMgr instead of job.

Sample:

Class demo.test Abstract ]
{

ClassMethod Test(arrayAs %Status
{
  ^CacheTempUser.dbg
  ^CacheTempUser.dbg($zp)=array
  ^CacheTempUser.dbg($zp,"$j")=$j
  q $$$OK
}

}

demo()
  queue,arr

  arr(1)="qwe"
  arr(2)="asd"
  
  "$j = ",$j,!
  queue=$system.WorkMgr.Initialize("/multicompile=1",,1)
  queue.Queue("##class(demo.test).Test",.arr)
  queue.WaitForComplete()
  
  zw ^CacheTempUser.dbg
  q

Result:

USER>^demo
$j = 7600
^CacheTempUser.dbg(8488,1)="qwe"
^CacheTempUser.dbg(8488,2)="asd"
^CacheTempUser.dbg(8488,"$j")=8348
"$ZTZ=",$ztz,!

#define 2utc(%t) $tr($zdt($zdt($zdth($system.SQL.TOTIMESTAMP(%t,"YYYYMMDDHHMISS"),3),-3),8,1)," :")

s t="20160105125915"
"Winter time: ",t," -> ",$$$2utc(t),!

t="20160705125915"
"Summer time: ",t," -> ",$$$2utc(t)

Result (GMT+02:00, Chisinau):

USER>^test
$ZTZ=-120
Winter time: 20160105125915 -> 20160105105915
Summer time: 20160705125915 -> 20160705095915

Note:

  • Takes into account summer/winter time
  • Is taken into account to option of OS for automatic daylight saving time

For example, if in the OS to disable automatic daylight saving time, the result will be different:

USER>^test
$ZTZ=-120
Winter time: 20160105125915 -> 20160105105915
Summer time: 20160705125915 -> 20160705105915

In addition to the above.

Fill the array tArray can be charged a method %ListOfDataTypes:BuildValueArray().
But I still prefer the next option (unless you count every tick of CPU :) ):

list=##class(%ListOfDataTypes).%New()
list.InsertList(tInputList)
 
; method #1
key="" {value=list.GetPrevious(.key)while (key'="")
 
; method #2 (better way)
key=list.Size:-1:1 value=list.GetAt(key)

You can fix this error directly now, if you don't want to wait for the release of version 2018.1.1.

To do this, follow these steps:

  1. make export the locale "deuw"
    %SYS>Locales("deuw")="" d $system.OBJ.DisplayError(##class(Config.NLS.Locales).ExportList("loc_deuw.xml",.t,.Locales)) zw Locales,t
  2. fix the file loc_deuw.xml (by default located in the folder %CACHEHOME%\Mgr)
    Name of subtable
    (Where to insert)
    New lines
    (That to insert)
    Add the following lines to the appropriate subtables:
    COL-German3-Unicode <FromToItem FromToKey="55,55,1">83,83;</FromToItem>
    <FromToItem FromToKey="55,55,2">7838;</FromToItem>
    <FromToItem FromToKey="55,55,3">83,7838;</FromToItem>
    COL-Unicode-German3 <FromToItem FromToKey="7838">55,55;2</FromToItem>
    <FromToItem FromToKey="83,83">55,55;1</FromToItem>
    <FromToItem FromToKey="83,7838">55,55;3</FromToItem>
    LowerCase-Unicode-Unicode <FromToItem FromToKey="7838">223</FromToItem>
    UpperCase-Unicode-Unicode <FromToItem FromToKey="223">7838</FromToItem>
  3. import fixed loc_deuw.xml:
    %SYS>d $system.OBJ.DisplayError(##class(Config.NLS.Locales).ImportAll("loc_deuw.xml",.t,1+2+4)) zw t
    %SYS>d $system.OBJ.DisplayError(##class(Config.NLS.Locales).Compile("deuw"))
    %SYS>Locale^NLSLOAD("deuw")

    Just in case, restart Caché.

Now, run a small test

#include %systemInclude
#include %occErrors
#include %syNLS
test() public {
  
  #dim ex As %Exception.AbstractException

  try {
    $$$AddAllRoleTemporaryInTry
    n $namespace
    s $namespace="%SYS"
    
    oldLocale=$$$LOCALENAME
    w "Old locale = ",oldLocale,!
    ##class(Config.NLS.Locales).Install("deuw")
    "Current locale = ",$$$LOCALENAME,!!
    
    ^||low,^||up

    w="wei"_$c(223)_"er","weiter","weiser" {
      ^||low($zcvt(w,"L"))=1
      ^||up($zcvt(w,"U"))=1
    }
    zw ^||low,^||up
    
    low=$c(223)
    up=$zcvt(low,"U")
    zw low,up
    zzdump low,up
    
  }catch(ex{
    "Error "ex.DisplayString(),!
  }
  ##class(Config.NLS.Locales).Install(oldLocale)

}

My result:

USER>d ^test
Old locale = rusw
Current locale = deuw
 
^||low("weiser")=1
^||low("weißer")=1
^||low("weiter")=1
^||up("WEISER")=1
^||up("WEIẞER")=1
^||up("WEITER")=1
low="ß"
up="ẞ"
 
0000: DF                                                      ß
0000: 1E9E                                                    ẞ

There is a method $system.Memory.Clean(<cleancache>, <defragment>), but unfortunately it appeared only with version 2011.1.

Try this code (consider that LONGVARCHAR = %Stream.GlobalCharacter) Read a CLOB through JDBC:

try
{
  ByteArrayOutputStream bos = new ByteArrayOutputStream();
  Statement st = dbconn.createStatement();
  ResultSet rs = st.executeQuery("Select ID,Text from eprinstance.isegment");
 
  while (rs.next())
  {
    int len;
    Reader reader = rs.getCharacterStream("Text");
    while ((len = reader.read()) != -1)
      bos.write(len);
 
    System.out.println(bos);
 
    reader.close();
    bos.reset();
  }
 
  bos.close();
  st.close();
  rs.close();
 
  System.out.println("OK!");
} finally
{
  dbconn.close();
}

I didn't know that Caché allowed to use JOINs without specifying FROM.

JOIN or SELECTOptional FROM Clause?

But it should be noted that for JOIN not all usages are supported, for example:

Supported:

SELECT * FROM 
  
(select 'aaa' Column1,'bbb' Column2 union select 'ccc','ccc' union select 'xxx','yyy' union select 'hhh','zzz'Table1
LEFT OUTER JOIN
  
(select 'ggg' Column1,'hhh' Column3 union select 'xxx','zzz'Table2
ON Table1.Column1=Table2.Column3

Not supported:

SELECT * FROM 
  
(select 'aaa' Column1,'bbb' Column2 union select 'ccc','ccc' union select 'xxx','yyy' union select 'hhh','zzz'Table1
INNER JOIN 
  
(select 'ggg' Column1,'hhh' Column3 union select 'xxx','zzz'Table2
USING (Column1)

  1. Non-optimal plan does not necessarily mean low speed. I have had cases where the query with the best plan to work longer than a query with worse plan.
  2. Now the optimizer is pretty advanced. Important to periodically make tuning table and add an index on each field involved in the search.
  3. When unknown parameters >5, is easier to do one query than to write a bunch of code.

Possible do on-other, namely to write one "universal" query:

select * from person where 
(lastname=:lastname or :lastname is null) and
(
age :age or :age is null)

That is:
sql "select * from person where (lastname=? or ? is null) and (age > ? or ? is null)"
resultset statement.%Execute(param1param1param2param2)

The solution with ##class(%xsd.hexBinary).LogicalToXSD works, but be careful, it only works when all characters in the string have codes <256.

All right, because the function works with an array of bytes (binary).
Therefore pre-to need lead N-byte string to single-byte string and only then do the conversion, for example:

trantable="SAME","UTF8" {
 "-------",!,trantable,!
 xN="π=3.14159..." zzdump xN !
 x1=$zcvt(xN,"O",trantablezzdump x1 !!
     
 hex=##class(%xsd.hexBinary).LogicalToXSD(x1)
 zw hex
     
 w $zcvt(##class(%xsd.hexBinary).XSDToLogical(hex),"I",trantable),!!
}

USER>^test
-------
SAME
 
0000: 03C0 003D 0033 002E 0031 0034 0031 0035                 π=3.1415
0008: 0039 002E 002E 002E                                     9...
 
0000: C0 03 3D 00 33 00 2E 00 31 00 34 00 31 00 35 00         À.=.3...1.4.1.5.
0010: 39 00 2E 00 2E 00 2E 00                                 9.......
 
hex="C0033D0033002E00310034003100350039002E002E002E00"
π=3.14159...
 
-------
UTF8
 
0000: 03C0 003D 0033 002E 0031 0034 0031 0035                 π=3.1415
0008: 0039 002E 002E 002E                                     9...
 
0000: CF 80 3D 33 2E 31 34 31 35 39 2E 2E 2E                  Ï.=3.14159...
 
hex="CF803D332E31343135392E2E2E"
π=3.14159...
l=$lb("",,,,,"",,,"BOOLEAN","0",2,2,"1",,"bla",$lb(,,"bla","20050502123400"),"",1,"bla",,0)
jsonStr=[(l)].%ToJSON()
jsonStr,!!
   
obj=[].%FromJSON(jsonStr)
list=obj."0"
zw list

Result:
["\u0002\u0001\u0001\u0001\u0001\u0001\u0002\u0001\u0001\u0001\t\u0001BOOLEAN\u0003\u00010\u0003\u0004\u0002\u0003\u0004\u0002\u0003\u00011\u0001\u0005\u0001bla\u0019\u0001\u0001\u0001\u0005\u0001bla\u0010\u000120050502123400\u0002\u0001\u0003\u0004\u0001\u0005\u0001bla\u0001\u0002\u0004"]
 
list=$lb("",,,,,"",,,"BOOLEAN","0",2,2,"1",,"bla",$lb(,,"bla","20050502123400"),"",1,"bla",,0)

Hi Uri.

In my opinion, this possible hear only empirically through load testing on specific hardware.
It is also important and the interface between Caché and the world .NET, namely the number of calls made to a DLLBetter performance.

Sometimes the performance gain is observed when .NET refers to Caché (ADO.NET, eXTreme .NET Provider), and not vice versa (.NET Gateway). But it always requires a revision of the architecture.

By the way, for .NET Provider/ADO.NET there is Connection Pooling

Personally, I prefer to use all out of the box, so as not to produce zoo libraries/technologies/languages, etc.

Really, both operations possible to execute at a time, for instance so:

w $$$FormatText("Create a signature and convert it to base64 (%1)",file64),!
cmd=$$$FormatText("openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign %1 %2 | openssl base64 -out %3 -nopad",fileKey,fileMsg,file64)
cmd,!!
d $zf(-1,cmd)