Back to all posts

Finding a Value Across Every Table in SAP

André Schärpf
sapabapdebuggingdatabase

You have a GUID. Or a specific string, a document number, a timestamp. You know the value exists somewhere in the system. You do not know which table holds it.

SE16N cannot help here. It requires a table name upfront. If you already knew the table, you would not be searching.

SE16S: search everywhere

SE16S searches for a given value across all fields of all tables in the system. No setup, no indexing. Enter the value, optionally restrict to a table name pattern (e.g., Z* or BKPF), and run it.

It supports exact match, pattern match (using * wildcards), and fuzzy search. The results show which tables contain the value and in which fields.

This is the blunt instrument. It checks everything that matches your table selection, which makes it thorough but slow. On a system with tens of thousands of tables, expect it to take a while.

SE16SL: search with a hint

SE16SL takes a different approach. Instead of scanning every field, it narrows the scope to fields matching a given field description or field name pattern. If you know the value is a material number, you can restrict the search to fields described as "Material" or named MATNR.

This makes SE16SL significantly faster than SE16S for most use cases, but it requires you to have some idea of what the field might be called. If your guess is wrong, it will not find anything.

Availability

Both transactions require the SAP_FIN software component. If you do not see them in your transaction list, the component is likely not installed on your system.

When to use these

A few situations where cross-table search is worth the runtime:

  • Tracing data flow. You have a document number and want to know every table it touches, from header to line items to change documents.
  • Debugging. A value shows up in the UI but you cannot find it through the usual table relationships. Searching across all tables reveals where SAP actually stores it.
  • Post-migration cleanup. After a data migration, you need to verify whether orphaned references to old values still exist somewhere in the system.

A word of caution

These transactions scan a lot of tables. On a production system with large datasets, this can generate significant database load. Run them on a test system or a quiet client when possible. If you must use production, restrict the table name pattern as tightly as you can to limit the scope.

Further reading

SAP Note 2002588 documents SE16S, SE16SL, and the related SE16S_CUST transaction in detail, including configuration options and known limitations.