Hello Gabriel,

It seems that updates to the other database (PostgreSQL) need to be "close to real-time," though a slight delay is acceptable. What matters most to you is ensuring stability and preventing any loss of updates.

I would consider the following:
1. Using the "SQL Gateway Connection" capability to connect remote tables directly to Cache. The benefit is that you have all logic on Cache side (having a remote REST/API will need also some remote logic to return the status of the operation in case of local updates failures)
2. Loosely coupling the local updates (Cache) with the remote updates:
a. Create a "staging area" (which could be a global or a class/table) to hold all updates to the remote table. These updates will be set by a trigger, ensuring that updating the local object/table in Cache is not delayed by updates to the remote database, The staging area delete its entries only on successful update (when failing they will be kept) - so you might need a monitor process to alert when the staging area is cleaning (e.g. remote DB is down, or network issues)
b. Use a separate (dependent) component to handle the updates. If you have interoperability (Ensemble), this might be easier to implement. However, it’s not mandatory; you could also use a background job (or a task) to periodically scan the "staging area" and perform the updates  

 

to be able to handle endStr in any length you should have:
S value = $E(text, start, end-$L(endStr)-1)

VS-Code will not delete on server. you need either to do that from studio, or use the d $System.OBJ.Delete() on terminal

Hello,

If you have audit enabled, and the item "%System/%Login/JobEnd" is enabled, you may know which user killed a process

Does your class have a relationship property to another class?
In that case you might want to consider to use: "CompileAfter"  or "DependsOn" keywords (those might help the compiler to have a correct order when compiling). 

maybe there are dependencies for that class? (e.g. class depends on another class(es) that need to be compiled before). try to add "r" (recursive) flag, so your flags will look like: "ckr"

You have other 2 options:
1. With SQL against the %SYS.Task class/table (delete from %SYS.Task where id=taskID)
2. Set sc = ##class(%SYS.Task).%DeleteId(taskID)

you are correct, but what I've suggested a way to check also that the interoperability is running, on that specific server

the SMP portal "about" page, has an option to choose the language. However, this persists for the current session only (in %session object). I would try to go with the solution proposed by @Raj Singh 
to use a browser add-on that can modify HTTP headers: (e.g. the:  HTTP_ ACCEPT_LANGUAGE CGI variable).

Intersystems could think of adding a user defined language, but not on the user profile since non local users (e.g. LDAP) are non persistent, so a global like ^ISC.someName(user)=Language could be the "best" way.
We don't want to (or can't) modify classes for the portal (some of them doesn't have sources).
This is a good candidate for the "intersystems ideas"

If some of those 3000 classes are divided to different packages, I would try to do the load in "segments" (using the queue manager, to have this done in parallel). This might speed things up a bit.

According to Snowflake documentation (https://docs.snowflake.com/en/user-guide/intro-key-concepts) is seems that you may use ODBC and JDBC, so SQL gateway can be used (SQL Gateway Connections | InterSystems Programming Tools Index | InterSystems IRIS Data Platform 2019.1)

There are also native connectors (e.g. Python). embedded python is not available on IRIS 2019.2 you may consider an upgrade to IRIS 2021.2 

Hello,
When several instances are connected to remote DB, then all their locks are managed in the IRIS instance where this DB is local (lets call this "the source")
I recommend increasing the "gmheap" parameter at "the source" to have more space on the lock table.

There are utilities to check the lock table free space, or full.
 

The global IRIS.WorkQueue is located (mapped to) in the IRISLOCALDATA DB, which stores internal IRIS temporary data, including queue manager data.
This DB is being cleaned/purged at IRIS startup, but you may compact and truncate this DB while IRIS is running (either manually or programically)