Skip to content

DB Explorer

Filter

The filter feature gives you precise control over which database objects appear in your explorer view, helping you focus on just the objects that matter for your current work.

Filter works one container at a time, showing or hiding its immediate children. To look through the whole tree for an object by name, see Search instead.

DB Explorer Filter in action

Right-click on any item that holds other objects in the DB Explorer (databases, schemas, tables, views, etc.) and select Filter to control which child items are displayed.

This includes the connection itself. Right-click a connection to choose which databases appear beneath it. Filtering databases does not change the connection’s default database, so the catalog you connect to stays selected either way.

Filters are saved with the connection, so they persist across restarts and travel with the connection when it is synced or shared. Once a filter is applied, the item is labelled “filtered”, and you can adjust it by choosing Filter again or remove it with Clear Filter.

Some items - scheduled jobs and tables - offer more than one way to filter. Right-click one of these and choose Filter; a picker appears first, letting you choose By name… (the selection list and pattern matching described below) or filter by an attribute of the items themselves, such as status or row count.

When you activate the filter, a list of available items will be presented, allowing you to:

  • Select specific items to display
  • Quickly include or exclude multiple items at once

For more advanced filtering, type a SQL-style pattern into the input box instead of picking items. The pattern must begin with like or not like:

PatternMatches
like api%Items starting with “api”
like %apiItems ending with “api”
like %api%Items containing “api”
not like %temp%Everything except items containing “temp”

A few details worth knowing:

  • The like or not like keyword is required. A bare pattern such as %api% is treated as ordinary search text, not as a filter.
  • Matching is case-insensitive, so like API% and like api% behave the same.
  • If you leave off the trailing %, one is assumed. like api is the same as like api%.
  • Quotes are optional. not like '%temp%' and not like %temp% are equivalent.

As you type, the list narrows to preview what the pattern matches. To save the pattern itself, press Enter without selecting any items. If you do select items, the filter is saved as that explicit list rather than as the pattern.

A filter is either a list of items or a single like / not like pattern. You cannot combine an include list with an exclude pattern, or apply more than one pattern to the same item.

For scheduled job nodes - SQL Server Agent jobs, pg_cron jobs, MySQL events, Snowflake tasks, Oracle Scheduler jobs, and similar - choosing Filter → Status opens a multi-select list of the job states your database reports. Pick any combination of states to show; picking none or all of them clears the status filter. Most drivers offer Enabled / Disabled; Oracle’s Scheduler exposes its full set of states: Scheduled, Running, Completed, Disabled, Retry Scheduled, Broken, Failed, and Succeeded.

For a tables node, choosing Filter → Row Count offers:

  • Hide empty (rows > 0) - show only tables that contain at least one row
  • Only empty (rows = 0) - show only tables with no rows
  • Minimum rows… - enter a custom threshold; tables with at least that many rows are shown

A table whose row count hasn’t been fetched yet stays visible rather than being hidden by the filter. This matters most with Progressive Loading enabled: row-count filtering only evaluates counts DBCode has already fetched, not the full unloaded table list, so a table appears until its count arrives.

  • Reduced Clutter: Hide rarely-used objects that get in your way
  • Better Focus: Display only relevant objects for your current task
  • Faster Navigation: Find what you need without scrolling through long lists
  • Context-Specific Views: Create different filtered views for different projects or tasks

This feature is particularly useful when working with large databases that contain hundreds of tables, views, or other objects.