AllAccepted answers
Enrico Parisi · Feb 28

To get the XML rule definition from SQL you can write/define a stored procedure that returns the XML rule definition, then....parse the XML. Something like:

Class Community.Rule.XDATA
{
ClassMethod GetXML(RuleName As %String) As %String(MAXLEN="") [ SqlProc ]
{
    Set xdataOBJ = ##class(%Dictionary.XDataDefinition).IDKEYOpen(RuleName,"RuleDefinition")
    Quit xdataOBJ.Data.Read($$$MaxLocalLength)
}
}

Then from SQL:

select Community_Rule.XDATA_GetXML('Your.Rule.Name')

Enrico Parisi · Feb 25

From documentation:

General Rules

Every identifier must be unique within its context (for example, no two classes in a given namespace can have the same full name).

Identifiers preserve case: you must exactly match the case of a name; at the same time, two classes cannot have names that differ only in case. For example, the identifiers id1 and ID1 are considered identical for purposes of uniqueness.

Enrico Parisi · Feb 18

@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?

Enrico Parisi · Feb 17

@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)?
 

Enrico Parisi · Feb 14

Whatever you use,  portal, code or SQL, I'd suggest NOT to delete the suspended messages. If you delete a message, only the message header will be deleted, leaving all the associated requests/responses orphaned.

I suggest discarding the messages using SQL.

Be careful doing so with a single update SQL statement for 2M messages, with more that 1000 records lock escalation will lock the entire Ens.MessageHeader table/class and your production will have big trouble. To avoid it use %NOLOCK.

Using Display mode:

Update %NOLOCK Ens.MessageHeader set Status ='Discarded' where Status = 'Suspended'

Using Logical or ODBC mode:

Update %NOLOCK Ens.MessageHeader set Status = 4 where Status = 5

Enrico Parisi · Feb 12

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