@Enrico Parisi , with Global Masters, we get a few points for having an answer marked as correct on the community. People often only mark the first correct answer they see. So if the user who posted the question didn't see this thread before the AI bot's post appeared, it's somewhat likely that the bot's post will be marked as the correct answer even though a human user answered the question first. That's all. Seems just a little unfair to me.

@DC AI Bot 
When I checked on this post earlier today, Vitaliy's correct answer was here, but the AI Bot's was not. Now it's showing here as if the AI Bot's answer was first. That is troublesome, particularly if Vitaliy is a Global Masters user.

The specific issue here is probably that when you tried to set text = type.%Get("text"), the variable "type" wasn't an object because it didn't exist or wasn't a dynamic object/array within the original object. You might want to try:

set iter = identifiers.%GetIterator()
     while iter.%GetNext(.key, .value, .type ) {
        set type = value.%Get("type")
        if $ISOBJECT(type){
            set text = type.%Get("text")
        }
        else{
            set text = ""
            //Or whatever you wanted to do if type wasn't an object.
        }

Maikel, if your variable is named var in your ObjectScript code, then you would use where xyz = :var in the embedded query. The colon marks that this is a host variable.  

You can set this up using your routine mappings. You can have each namespace have a different database for its globals but share a database for the routines. Then they'll all have their own data, but be running off of the same code.

I only have back to Cache 2018, not 2017, but can you try:

set myproc = ##class(%SYS.ProcessQuery).%OpenId($J)
if myproc.ClientExecutableName = "CSTUDIO.EXE"{
    //You are in Cache Studio
}
else{
    //You are not in Cache Studio
}

I'm not totally clear on what you're trying to do, but I have a feeling you might want to replace "quit" with "return status". Inside a catch block, a quit command will quit just the catch block and code execution will continue after it. Replacing that with return status would make the code execution stop right there, returning the error.

Here's my small but useful contribution:

Add an "Add Server to VS Code" Option to System Tray Icon

Calling the methods this way is effective for testing the methods, yes. You just want to get really familiar with the %CSP.Request class. This approach isn't a good way to troubleshoot issues with your routes, or with authentication, though, as it bypasses those steps. For that, you'd probably have to define %request appropriately, then call some of the methods your API inherits from %CSP.REST, but I'm not as familiar with those.

And in addition to all of that, one of the workarounds people seem to like using is to have things comma-separated and enclosed in " to make sure it's getting the right commas, but I'm working on ERP software for the millwork industry in America. We're still allergic to metric here, and we use " to mean inches and ' to mean feet, so we can't use those either!

I know it's odd, but I've had three separate companies ask me for data formatted this way in the past couple of years. I'm not sure why, other than that the pipe is less common to run into within the data than commas.

We have had a few people ask for a CSV using a pipe as a separator. If you run into that and need to open it in Excel, you do that by going to the data tab, then click From Text/CSV. It may detect the separator character automatically, but if not there is a place where you can set it. (You may want to right click on the GIF and open in new tab if it's too fuzzy.)

@Stephen Canzano , when you are testing you can also manually define %request and give it a body and whatever else it needs before you call your class method. For instance:

set %request = ##class(%CSP.Request).%New()
set %request.ContentType = "application/json"
set %request.Method = "POST"
set %request.Content = ##class(%CSP.CharacterStream).%New()
set json = {}.%New()
set json.firstname = "David"
set json.lastname = "Hockenbroch"
do %request.Content.Write(json.%ToJSON())

Then you can call your class methods and the %request object you usually manipulate in those methods will be defined.

@Evgeny Shvarov it's like this:

try{
    //Do things here
}
catch ex{
    do ex.Log()
    return ex.AsStatus()
}

If you do this, then the error gets logged in the application error logs in the system management portal, and a JSON representation of the exception gets returned through the API.

You can create and log exceptions so that they show up in the application error logs in the SMP. That's how I prefer to do things.

@Theo Stolker I'm not sure what you mean by, "I never liked the different behavior of embedded sql, like when you have no result, you have no easy way to find that out." When you run an embedded query, it sets a variable called SQLCODE. If SQLCODE = 0, query completed with results. If SQLCODE = 100, query completed with no results. If SQLCODE < 0, there was an error with the query.

FYI, in your "Building SQL In Strings" section, you can also still use %SQL.Statement like this:

set stmt = ##class(%SQL.Statement).%New()
// Note the question mark in the query.
set query = "SELECT Name, Age FROM Patient WHERE ID=?"
set sc = stmt.%Prepare(query)
// You can add error handing here if the above status results in an error
// Providing variables to the %Execute method will insert them where the question marks are in the query, in order
set rs = stmt.%Execute(id)

Really you'd want to set a variable equal to the $TLEVEL at the start of your try, then in the catch calculate the difference between the starting $TLEVEL and the current $TLEVEL, then do that many TROLLBACK 1s.