Thanks Jeff!

This is an important update for our customers -

On one hand making them aware they now also have the CD releases as non-container kits, while on the other hand reminding them regarding the limitations of these kind of CD releases.

Working with Yakov on this, we saw that for SCOPE_IDENTITY() to work on the SQL Serve side it needs to be in the same "scope" of the INSERT (for example in the same Stored Procedure), see here for reference.

So what Yakov ended up doing was encapsulating the INSERT and SELECT SCOPE_IDENTITY() into a Stored Procedure which returns the newly inserted Row ID, and call the SP via the Adapter, thus inserting the new record and getting back the new ID.

Congratulation to all winners!

And especially to our local representative - @Yuval Golan!

Yuval last year you were 3rd place, and this year up to 2nd... Bravo! @Kevin An beware next year wink

Thanks Bob, yes, indeed JDBC/ODBC and using Couchbase's N1QL queries (and JSON results) is another connectivity option.

If someone "wrapped" such connectivity into some Adapter that could also be interesting.

I was able to get in, for example:

$ docker-ls tags --registry intersystems/irishealth ...
requesting list . done
repository: intersystems/irishealth
- 2019.1.1.615.1
- 2020.
- 2020.1.1.408.0
- 2020.
- 2020.
- 2020.4.0.547.0
- 2021.
- 2021.2.0.617.0

Ok, Carig, so sorry about the superfluous explanation about the SQL Package to Schema name mapping...

But now I do understand the problem better -

First, as you realized you don't need the asterisk (*), just the name of the schema.

And second you need to use the term SCHEMA in your statement before the schema name, or else we expect a table name (hence the error you got - table ... not found).

So per the example I quoted originally above from the documentation:


In your example this would be:


I just added the word 'SCHEMA' before the schema name.

Hope this will get it to work for you.

Hi Craig,

I'm not 100% sure this is the problem you are seeing (you might be aware of this already) - but worth a try - 

When you define an OO package name (and sub-packages) for your classes, these "project" to SQL Schema names a little differently, so instead of "dots" (.) in your full package name you would have underscores (_) in your schema name.

For example PackageA.PackageB.Class would be PackageA_PackageB.Class - so the schema name would be PackageA_PackageB (and not PackageA.PackageB).

See here for example about this in the Documentation.

Hi Craig,

Perhaps this could help -


You can use SCHEMA schema-name as the object-list value to grant the object-privilege to all of the tables, views, and stored procedures in the named schema, in the current namespace. For example, GRANT SELECT ON SCHEMA Sample TO Deborah grants this user SELECT privilege for all objects in the Sample schema. This includes all objects that will be defined in this schema in the future. You can specify multiple schemas as a comma-separated list; for example, GRANT SELECT ON SCHEMA Sample,Cinema TO Deborah grants SELECT privilege for all objects in both the Sample and the Cinema schemas.

I'm not sure if I fully understand your question Eduard, but the token itself, internally, is built by the original request's Message Header ID (and the Production name; concatenated with a pipe - |)

E.g., from the code (in Ens.Host):

Method GetDeferredResponseToken(pMessageHeader As Ens.MessageHeader) As %String
    Quit pMessageHeader.%Id()_"|"_$$$EnsRuntime("Name")

ClassMethod SendDeferredResponse(pDeferredResponseToken As %String, pResponse As %Library.Persistent) As %Status
    Set tSC=$$$OK
    Try {
        Set tMessageHeaderId=$p(pDeferredResponseToken,"|",1)
        Set tProductionName=$p(pDeferredResponseToken,"|",2)

Note this is of course internal implementation, and I don't think it is documented or supported (i.e. might change in future versions without notice).