Hi Eduard,

This is basically same approach as mine, but straight with one single SQL operation.

Even if it works (it does, I've tested), in a database with potentially millions of records it seems to me that we would be missing background and multi-thread capacities. But by looking at the documentation I've been unable to find any method for that purpose.

Thanks for the answer, anyway! :-)

Finally opened a WRC and got an answer: update to 2021.1 as categories have much improved.  :)

Hi Marcio!

You did a hell of a job here! :-) But I was looking for a specific in-build solution.

Hi Sean,

Sorry for the delay. You were absolutely right, I wasn't forwarding port 1972 but 51773! I just added 1972 and call the JDBC using this port and now it works like a charm.


Hi Dmitriy,

Correction: it's not ODBC by JDBC

Actually, when the container is running the error is different than when it's stopped, so I guess my python script really reaches the jdbc server but somehow is not accepted.

Container running:

java.sql.SQLException: java.sql.SQLException: [InterSystems IRIS JDBC] Communication link failure: Communication error:  Server closed communication device

Container stopped:

java.sql.SQLException: java.sql.SQLException: [InterSystems IRIS JDBC] Communication link failure: S’ha refusat la connexió (Connection refused)

Answering myself:

For a system with 8 cores, we will be allowed to use maximum 16 workers. So, to be able to do it and let other processes work with the default queue, we we just need to set the global:

 s ^%SYS("WQM","MaxActiveWorkers","User.Testing")=16

so, when creating the queue it can be done attaching the workers to this queue:

  set queue=$SYSTEM.WorkMgr.%New("/multicompile=1",16,"User.Testing")

Hi Brendan,

I wanted to use it to have an index not based on the Keys. Finally, I've solved it by storing the values as Array Of %String, and into the string I got the values separated by # so I can access them via $p. And using as a array key what I needed to be indexed.

It works quite well :-)

Thanks anyway for reporting it :-)

Ok then, I understand :-) JDBC works out of the box then, I can stop this JDBC gateway server right? And the users will be taken from the standard users database, exactly the same as when they access via ODBC. Am I correct?

Wow, what a big misunderstanding from my part :D


Yes, no problem with SMP. Do I understand from your message than even if the JDBC gateway servers is set up at port 53773 users need to point their JDBC to 51773 (superserver port?)