#Relational Tables

I created a Custom Search Table that extends EnsLib.HL7.Search Table. I saved, compiled, and rebuilt the index however when I go into Message Search to try to use the Search Table, within the conditions the proper fields are not showing up that was defined. It is showing the fields from EnsLib.HL7.SearchTable. I did a build index on both EnsLib.HL7.SearchTable and OSU.HL7.SearchTable.

I had a need for a Filter, but did not want to recreate the wheel by creating another Data Lookup Table, so instead I created a Linked Table that points to a MS SQL Table outside of IRIS.

Once I had the Linked Table, I created a Class Method Function that would query the Linked Table and return a 1 if a result came back.

I have a need to create a specific Search Table outside of the EnsLib.HL7.SearchTable specifically for HL7 MFN messages in HealthShare Provider Directory.

Our Code is created in a different namespace then the main HSPD namespace and is mapped within the HSPD namespace mapping. 

I created a copy of EnsLib.HL7.SearchTable, named OSU.HL7.SearchTable what all needs mapped to make this new search table available in HSPD namespace?

If I go to Global within the Custom Code Namespace, I cannot see my new Search Table being created.

While starting with Intersystems IRIS or Cache, developers often encounter three core concepts: Dynamic Objects, Globals & Relational Table. Each has its role in building scalable and maintainable solutions. In this article, we'll walk through practical code examples, highlight best practices, and show how these concepts tie together. 

1. Working with Dynamic Objects:

Dynamic objects (%DynamicObject and %DynamicArray) allow developers to manipulate JSON-like structures directly in Objectscript. They are especially useful for modern applications that need to parse, transform or generate JSON.

This article describes a significant enhancement of how InterSystems IRIS deals with table statistics, a crucial element for IRIS SQL processing, in the 2025.2 release. We'll start with a brief refresher on what table statistics are, how they are used, and why we needed this enhancement. Then, we'll dive into the details of the new infrastructure for collecting and saving table statistics, after which we'll zoom in onto what the change means in practice for your applications. We'll end with a few additional notes on patterns enabled by the new model, and look forward to the follow-on phases of

Here at InterSystems, we often deal with massive datasets of structured data. It’s not uncommon to see customers with tables spanning >100 fields and >1 billion rows, each table totaling hundred of GB of data. Now imagine joining two or three of these tables together, with a schema that wasn’t optimized for this specific use case. Just for fun, let’s say you have 10 years worth of EMR data from 20 different hospitals across your state, and you’ve been tasked with finding….   every clinician within your network      who has administered a specific drug         between the years of 2017-2019