See what is actually stored beneath your tables

Sooner or later a question arrives that SQL cannot answer. A row exists in the global but the class query does not return it. A property reads as null through the object layer while the data is visibly there. A legacy routine wrote directly to storage twenty years ago and nobody remembers in which format. At that point you need to look at the global itself, and the usual options are a terminal session with ZWRITE or asking someone with server access to do it for you.

Why globals matter even when you only write SQL

Every piece of data in an InterSystems IRIS database is stored in an efficient, tree-based, sparse multidimensional array — a global. Globals underpin both the object and the SQL interfaces of the platform: one data dictionary, reachable as tables, as objects, as multidimensional arrays or as documents, all resting on the same storage. You never have to work with them directly, but understanding how IRIS uses them is what turns an unexplainable result into a diagnosis.

Data can be stored in a global under any number of subscripts, and subscripts are typeless. One subscript at a given level might be the integer 34 while its neighbour at the same level is the string "LineItems". A stock inventory application holding item, size, colour and pattern might be laid out like this:

^Stock(item,size,color,pattern) = quantity

with data such as:

^Stock("slip dress",4,"blue","floral") = 3

That flexibility is exactly why generic SQL clients have nothing to show you here: there is no fixed row and column shape to render. The Global Browser renders the tree instead.

Navigating the tree

Globals in a namespace are listed as a folder in the Server Navigator, with an accurate item count, and expand level by level. You descend one subscript at a time, seeing the subscripts that actually exist at each level rather than guessing at a range, and the value at any node is shown as soon as you select it. The subscript path is displayed in a form you can copy straight into a terminal or into ObjectScript, so what you found in the browser is reproducible elsewhere.

Because subscript levels can mix data types on the same level, the browser sorts and displays numeric and string subscripts side by side without collapsing one into the other — a case that used to be handled incorrectly and is now explicit.

$LISTBUILD values, resolved

IRIS and Caché store the properties of an object in a compact binary representation built with $LISTBUILD, so a single global node typically holds an entire row. Dumped raw, that node is a run of unprintable bytes with the occasional recognisable string in it. The Global Browser decodes the list and shows the elements as individual, numbered fields, which you can then line up against the storage definition of the class to see which property sits in which position.

This is the single most useful thing the tool does with globals. It is how you confirm that the value really is in slot 7 but the class expects it in slot 8, or that a property was written as a string where the storage definition says integer.

When the data is not what it claims to be

Legacy systems that bypass the SQL and object layers introduce failures that are hard to see from above: values that cannot be read at all, values that look valid but do not match the metadata, and values that get silently coerced to fit an expected type. The Global Browser is deliberately honest about them. If you ask it to interpret a node as $LISTBUILD and the node is not in that format, it tells you the format is invalid and shows you what is actually there, instead of rendering plausible nonsense or failing with a stack trace.

That behaviour pairs with the read-error handling in the SQL editor: the editor finds you the row and column of a value that does not match its metadata, and the Global Browser tells you what is stored there.

From table to storage and back

The route into a global usually starts from a table. The Table Viewer's IRIS storage and index tabs name the globals a table and its indexes actually live in, together with their sizes, so you can go from "this table is 14 GB" to the specific global holding it, then walk into that global here. Working in the other direction is just as common: find an orphaned subscript in the browser, then go back to SQL to work out which application wrote it.

Sizes are worth watching on that route. A table whose index globals have grown larger than its data global is usually a story about a redundant index, and that is a question for the performance tools.

Being able to read your own storage changes how quickly odd data gets explained — a ten-minute look instead of a ticket to whoever holds terminal access. The Global Browser is in every edition, including the free one. Download SQL DATA LENS and open a global on a test namespace to see what your tables really look like underneath.