@David.Satorres6134 , you asked:

We have reviewed the documentation but were unable to find a method or API that provides the correct compilation order for the cubes.

I gave the documentation links on how to provide the correct compilation order for classes.

In most cases the compiler does take care of dependencies and build/compile in correct order.
In my experience I have very, very rarely (maybe a couple of times) used DependsOn or CompileAfter Class keywords (I don't do cubes/DeepSee).

I'm not familiar with multiple cubes compilation, but evidently your implementation has some particular dependency that the compiler is unable to identify and take care of it.

Maybe  (just guessing here) you have some cross dependency that is "resolved" with multiple compilations?

I've seen that message too and.....I ignored it since everything works fine.

It would be nice to know without opening a WRC for something that, apart of that message, just works! 😁

If that directory is required for Web Gateway cache, then it looks like a bug in the GW installation script.

I don't have experience with SQL SP from IRIS but I believe the SQL syntax should be something like:

call ExternalDB.DB.StoredProcName(?)

I'm not sure named parameters are supported. I don't think they are.

@David.Satorres6134 , in the class EnsPortal.SuspendedMsg,  DeleteMessage() is an instance method and cannot be invoked directly.

Anyway, what it does is simply invoking:

Set tStatus = ##class(Ens.MessageHeader).%DeleteId(pHeaderId)

But, as explained in my previous post, this leave orphaned messages and should be avoided.

I suggest to add to your classes DependsOn or CompileAfter Class keywords.

I'm no sure it it makes any difference, but....what IRIS version are you using?

@Jeffrey Drumm , it's too late, he has already deleted the headers so the bodies are already orphaned.

@Kirsten Whatley , there is no query using the Ens.MessageHeader that can return orphaned message bodies info/reference. The very definition of orphaned messages is that have lost the link form Ens.MessageHeader.

Do you know the MessageBodyClassName of the messages you have deleted?
If it's a custom defined persistent class, can you provide some detail of the message(es) class(es)?
 

Embedded SQL build the cached query ONCE while you compile

This is no longer true since some time/version, please check relevant documentation:

Embedded SQL is not compiled when the routine that contains it is compiled. Instead, compilation of Embedded SQL occurs upon the first execution of the SQL code (runtime). First execution defines an executable cached query. This parallels the compilation of Dynamic SQL, where the SQL code is not compiled until the SQL Prepare operation is executed.

As a result, some assumptions, even in the main post, are no longer accurate.

My suggestion is to read the article in this community from @Benjamin De Boe :

New in 2020.1: the Universal Query Cache

That's not the WebGateway port, it's the web server port, so you can change it in the web server configuration.

From the port you mentioned (57773) It seems you are using PWS (aka Private Web Server) that used to be installed with IRIS before version 2023.2 (if I recall it correctly).

Since you are using version 2024.3 my guess (I can be wrong) is that your system was upgraded from a previous version, so the PWS is still installed.

If so (you are using PWS), I suggest to install a proper "web server" (Apache or, if Windows, IIS) and use it instead of the deprecated, no longer installed, PWS.

It has been announced that future version (2025.??) PWS will be removed during IRIS install.

Well...it's still valid for old versions 😉

You may want to edit and add at the beginning that IRIS can use VSS with a link to documentation.

Yes, absolutely true, if you are not using an old version/product like Caché/Ensemble.

Windows VSS support was introduced few years ago, maybe with IRIS?

So, if your backup solution has VSS quiescence enabled, you can simply rely on it and you are good to go without any script/freeze/thaw. It's authomatic.

You can check messages.log file during backup, look for something like:

[Utility.Event] Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: e:\intersystems\iris\mgr\journal\20250210.004
[Utility.Event] Backup.General.ExternalFreeze: System suspended
[Generic.Event] VSS Writer: OnThaw
[Utility.Event] Backup.General.ExternalThaw: Resuming system
[Utility.Event] Backup.General.ExternalThaw: System resumed

Backup.Task is a system class located in %SYS, I'm not sure if creating a Backup.Task in another namespace (hopefully!!) address his issue.

What are you using to read the csv file in IRIS?

Can you provide a small sample code?

To support longer then 500 lines you may use an hash instead of the actual line.

If you want/need to keep the generated .int, then:

set sts = ##class(%Routine).CompileList("*.int","/keepsource=1")

or

set sts = ##class(%Routine).CompileList("*.int","k")

Please follow the documentation starting from Visual Studio Code (VS Code) Introduction

First thing to decide if you want to use client-side editing or server-side editing. server-side editing is more similar to working with InterSystems Studio.

Then, if you encounter problems, please come back and provide details on what you have done, what the problem you encountered, any error you get etc.

Please translate to English or publish your question in French Community