#System Administration

This past weekend we ran into something odd. When we failed over our mirror from 2022.1.3 to 2025.1.3 the one of the Business Rules that was on what became the Primary (2025.1.3), had a rule within it that was removed back in January. When the Failover occurred, we had to scramble to backup, disable, and remove the Rule that shouldn't have been there. 

Both the Data and Code live within the same IRIS.dat that is the main MIRROR database for that Namespace. 

If this happened to one Class file, could it happen to others we do not know about?

While reviewing our Orphan messages, we noticed that there are some Orphans that look like they are the start of an HL7 message.

MSH|^~\&

Since this does not link to any Message Header, and most of the information in EnsLib_HL7.Message is NULL, is there a way to track down what Object maybe creating these so we can nip it in the bud.

Only way that I know of is to go through each of our Schema's and make both the MSH and Encoding Characters optional.

We are trying to track down significant growth within our Namespaces, one big culprit is Ens.AppData (EnsLib.SQL.Snapshot). 

Within many of our BPL's we use EnsLib.SQL.Snapshot to return Results from External SQL Stored Procedures or Query's. The same EnsLib.SQL.Snapshot context variable is used for many of these calls within a BPL. 

Is there something we should be doing at the end of the BPL to ensure that EnsLib.SQL.Snapshot gets cleaned up and purged from Ens.AppData?