Search
Find where a table, a global or a string is actually used
Server-side search across every class and routine of a namespace, plus schema search by table, view and column name on any connection.
Unique to SQL DATA LENS
- Server-side, nothing downloaded
- Plain text or regular expression
- Where is this used? on a table or a global
- Schema search on every connection
- Ctrl+Shift+F from anywhere
"What breaks if I change this table?" is the question that stops a change from being made. On IRIS and Caché the honest answer lives in the class and routine code of the namespace — and until now, getting at it from a SQL client meant exporting the namespace to XML and grepping it, or opening Studio, or asking whoever still has Studio open.
Version 4.01 puts the search where the schema already is. It runs on the server, across every class and routine of a namespace, and never downloads the source to search it.
Three ways in
- The search field at the right of the main toolbar, or Ctrl+Shift+F from anywhere.
- Right-click a namespace in the Server Navigator and choose Search….
- Where is this used? on a table, or on a global in
the Global Browser — which is the
one that changes how the day goes. It opens the search pre-filled with the
table's underlying class name, or with the global name, leading
^and subscripts already stripped.
That last route closes a loop the rest of the product had already opened. A table names its class and its globals in the Table Viewer; the Class Viewer shows what the class does. Where is this used? answers the remaining question — who else touches it.
The search mask
| Field | What it does |
|---|---|
| Namespace | Loaded from the server when the tab opens, and always editable — if the list cannot be loaded, the status line says why instead of leaving an empty dropdown, and you can type the namespace yourself. |
| Search text | Plain text by default, matching anywhere on a line. Your last 30 searches are kept in a dropdown that survives a restart; remove one with Delete, or clear the lot. |
| Regex | Treat the search text as a regular expression. An invalid one comes back as the server’s own plain-text message, not a stack trace. |
| Case sensitive | Checked by default, matching the server’s own behaviour. Uncheck to find DimDate, dimdate and DIMDATE together. Remembered across searches and restarts. |
| Documents | Comma-separated file masks with wildcards — defaults to *.cls, *.mac, *.int, *.inc. Narrow it to Ens* when you only care about interoperability code. |
| Include system code | Also search %-classes and other system-owned code. Off by default. |
| Include generated code | Also search code the compiler generated, for example for a persistent class. Off by default. |
| Max results | A hard limit passed to the server, 200 by default. A truncated result says so — a cut-off list never looks like the whole answer. |
Results list one row per match: the document, the class member or routine label the match sits in, the line number and the matched line. Select a row and the source is previewed read-only beside the list, jumped to that line; click through several results and the preview follows without opening anything. Double-click instead and the document opens in its own tab, so you can keep it while you look at the rest.
When it finds nothing, it says what it looked for
A bare "0 matches" is the least useful thing a search can say, because it cannot be told apart from a search that did not run. So a search with no hits reports the whole question back to you — search text, namespace, case-sensitivity, the document filter, and whether system and generated code were included:
No matches for 'SetHeader' in namespace 'USER' (documents: *.cls,*.mac,*.int,*.inc, case-sensitive, system code excluded, generated code excluded).
The two usual causes are named in that sentence. A hit limit works the same way: when the server's limit is reached the banner says the result was truncated, so a cut-off list never looks like the complete answer.
The other half: searching the schema, on any connection
The same entry points now also search the schema itself — tables, views and columns by name, across every schema of a namespace or catalogue — and that half works on every connection: PostgreSQL, SQL Server, MariaDB, DuckDB and any other JDBC source, not just InterSystems. It reads the connection's own JDBC metadata, the same source the Server Navigator reads, and never touches the data rows.
On an IRIS or Caché connection you get both, as two tabs: Metadata for the schema and Source code for the classes and routines. On a generic JDBC connection there is only the first, because there is nothing to switch to. Earlier releases offered Search source code… on those connections too, where it could never find anything; this replaced it.
Where it fits
A search is worth as much as what you can do with the answer. Once you know which class references a table, the Class Viewer reads it, and — since 4.01 — export, import, copy and compile work on IRIS as well as Caché. If you are searching in order to change something on a system where a mistake is expensive, classify that connection first: see environments and read-only.
Questions about the search
Does it download the source code to search it?
No. The search runs on the server, over the classes and routines as they sit in the namespace, and only the matching lines come back. Nothing is copied to your machine, no export is written, and no working directory fills up. That is also why it is fast on a namespace with thousands of classes: the work happens where the code already is.
What does it need on the server?
A reachable web server on the instance — the same Atelier REST endpoint the Source Code tab and the class actions use, named by the Webserver and Webserverport fields on the connection's Server tab. Nothing is installed: no agent, no helper classes, no routines deployed into a namespace. If that endpoint is not reachable, the namespace list cannot be loaded and the status line tells you so rather than failing silently.
Why is my search finding nothing?
The search says so in a full sentence rather than showing a bare "0 matches": the search text, the namespace, whether the search was case-sensitive, the document filter and whether system and generated code were included. The two usual causes are named right there — a namespace that is not the one you meant, and a case mismatch, since the search is case-sensitive by default. The same sentence replaces the result list, so a search that genuinely found nothing looks different from a tab where no search has run yet.
Does the search work on PostgreSQL or SQL Server?
The schema search does, on every connection: tables, views and columns by name, across all schemas of the catalogue. The source-code search does not, because there is no equivalent — a PostgreSQL server has no namespace full of class and routine source to search. Before 4.01 the menu entry appeared on those connections anyway and did nothing, which was worse than not offering it.
Can I keep several searches open?
Yes. Each search opens as its own tab in the main content area, like a query editor, and the tab is labelled with the namespace it searches — so three searches against three namespaces stay apart without hovering over each one. The rest of the application stays usable while a search runs, and Cancel stops one.
Next step
Pick the table you are most afraid to change, right-click it, and choose Where is this used?. Download SQL DATA LENS — the answer takes about four seconds, which is the point.
Explore your IRIS data from SQL down to globals
Download, unzip, connect. Your first namespace is on screen in about three minutes.
Windows 10, 11 and Windows Server (64-bit) · ~130 MB · version 4.01 · full 30-day Pro trial included