DataGrip DBMS_OUTPUT: How to See PUT_LINE Output in Your Console

To see DBMS_OUTPUT.PUT_LINE results in DataGrip you enable the DBMS_OUTPUT option on the query console you run the code in, because Oracle only returns the output when it is switched on for that session.

The classic symptom is a script that runs without error and prints nothing. The cause is nearly always a switch that is off, or output sent to a window you cannot see.

Table of contents

• Why the output goes missing
• Step by step: enable it for a console
• A minimal block to test with
• Checklist when it still prints nothing
• Alternatives to PUT_LINE for debugging
• Where this fits when you run your own databases
• Formatting output so it is readable
• How this fits the rest of the stack
• FAQ

Why the output goes missing

DBMS_OUTPUT is an Oracle package. PUT_LINE writes text into a buffer inside the database session. It does not print anywhere. A client tool must ask the database to return that buffer after the call finishes and then display it. In SQL*Plus you turn that behaviour on with SET SERVEROUTPUT ON.

DataGrip is a different client, and SET SERVEROUTPUT ON is a SQL*Plus command that it does not process. So a script that works in the old command line client silently outputs nothing in DataGrip. This is the cause of most of the forum threads on the subject.

DataGrip has its own switch. The documentation describes an Enable DBMS_OUTPUT option, applicable to Oracle and IBM Db2 LUW, that turns on collection for new sessions, and a console toolbar control that does it for an individual console. When it is on, DataGrip asks the database for the buffer after each execution and shows the text in the Output tab of the Services tool window.

So there are really two things to confirm: the option is on for the session you are using, and the Services window is configured to show output. Missing either produces the same empty result.

If your problem is the second kind, nothing is wrong with the SQL at all, which is a relief and a reason to check settings before rewriting code.

Step by step: enable it for a console

For a SQL file that is not yet attached to a console, the order matters.

1. Open your .sql file.
2. Associate it with a console for the Oracle data source. Use the data source selector at the top of the editor.
3. Open that console and click the control that enables DBMS_OUTPUT in the toolbar. In current versions it appears as an option for the Oracle session.
4. Go back to your file and run the code.
5. Open the Services tool window and look at the Output tab.

The accepted answers on the community site describe exactly this sequence: associate the file with a console, turn on the option in the console, then run from the file. The option belongs to the session, so running in a different console, or after the session was reconnected, means turning it on again.

To avoid doing it every time, enable the default in the settings under the database output and results section. The setting makes DBMS_OUTPUT on for new sessions, so you only have to think about it once. Then reconnect so a fresh session picks it up.

A minimal block to test with

Test with the smallest possible code so you can separate setup problems from code problems.

BEGIN
  DBMS_OUTPUT.PUT_LINE('hello from datagrip');
END;

Execute the whole block. In DataGrip, put the cursor inside the block, or select it, and run the statement. If the editor splits it at the semicolon, the block fails with a syntax error. Selecting the entire text before running is the reliable approach, and a slash on its own line after the block is the standard terminator in many Oracle tools.

DECLARE
  v_total NUMBER := 0;
BEGIN
  FOR r IN (SELECT salary FROM employees WHERE department_id = 50) LOOP
    v_total := v_total + r.salary;
    DBMS_OUTPUT.PUT_LINE('running total: ' || v_total);
  END LOOP;
END;
/

If hello appears in the Output tab, the setup is right and any later silence is a code issue. If nothing appears, work through the checks in the next section. Note that output appears after the block completes, not while it runs, because the buffer is fetched at the end. A long-running loop will not stream lines as it goes.

Checklist when it still prints nothing

Work down the list in order.

• The option is off for this console. Toggle it on and rerun. Remember it is per session.
• Wrong tool window setting. In settings, check when the Services window shows query output. If it is set to never or to result sets only, output may not surface.
• The block did not run. Look for a syntax error or a statement split at a semicolon.
• Buffer too small. The default buffer can overflow with large output. You may see an error about the buffer. Raise it with DBMS_OUTPUT.ENABLE(buffer_size => NULL) to make it unlimited in modern versions.
• A recent update broke it. Community threads report the option misbehaving after particular releases. Update to the latest version, or check the issue tracker.
• Wrong data source. The option only applies to Oracle and Db2 LUW connections. A Postgres or MySQL data source ignores it.

BEGIN
  DBMS_OUTPUT.ENABLE(NULL);
  DBMS_OUTPUT.PUT_LINE('buffer is unlimited');
END;

If you are still stuck, invalidate caches and restart the IDE, which clears odd state, then reconnect and try the minimal block again.

Alternatives to PUT_LINE for debugging

PUT_LINE debugging is quick and has limits. Output arrives only at the end, long lines are truncated at a size limit, and it vanishes in scheduled jobs where there is no client to receive it.

For anything persistent, write to a log table instead. An autonomous transaction lets the log entry survive a rollback of the main work:

CREATE OR REPLACE PROCEDURE log_msg(p_text VARCHAR2) AS
  PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  INSERT INTO app_log (logged_at, message) VALUES (SYSTIMESTAMP, p_text);
  COMMIT;
END;
/

For step-by-step inspection, use the debugger built into the IDE. It lets you set breakpoints in stored code and examine variables, which beats scattering print statements.

Other engines have their own equivalents. PostgreSQL, for instance, uses RAISE NOTICE inside PL/pgSQL, and DataGrip displays those notices in the same output area without extra setup:

DO $$
BEGIN
  RAISE NOTICE 'row count is %', (SELECT count(*) FROM orders);
END $$;

That difference trips people moving between databases. The package name changes, the habit does not.

Where this fits when you run your own databases

DBMS_OUTPUT is part of working with Oracle, a database RunxBuild does not host. Managed instances on RunxBuild are MySQL and Postgres, so if you are moving procedural code to a hosted Postgres instance, the translation is from PL/SQL to PL/pgSQL, and PUT_LINE becomes RAISE NOTICE.

DataGrip connects to a Postgres instance like any other client, using the host, port, user and password from the connection details, so the same IDE workflow carries over. The database user management docs cover creating a user for your tools, and the network security docs explain how access is restricted.

Use a dedicated database user with limited rights for your IDE rather than the admin account, and keep production credentials out of shared project files. A debugging session is a good moment to be careless, which is exactly why the habit is worth setting up first.

Formatting output so it is readable

Once output works, make it useful. Raw lines scattered through a script are hard to scan, so give each message a consistent prefix and include the variable names you care about. Print a label with every value, and print markers at the start and end of a procedure so you can see which block produced what.

DBMS_OUTPUT.PUT_LINE('[orders] start, customer=' || p_customer_id);
DBMS_OUTPUT.PUT_LINE('[orders] rows processed=' || v_count);

Watch the data types. Concatenating a NULL value with a string produces just the string, which can hide a missing value rather than reveal it. Wrap values in NVL with a visible placeholder so a null is obvious in the output.

Keep the line length in mind. Older Oracle versions limit a single PUT_LINE to a few hundred bytes, and longer text raises an error. Split long strings across calls, or log to a table when you need the full content. And remove or guard the debug output before the code goes to production, since printing from a heavily used procedure wastes memory in the session buffer.

How this fits the rest of the stack

Debugging tools cost nothing, but the databases behind them do, and a development database left running adds up. Check what a small managed database costs in the RunxBuild hosting calculator. When you want a Postgres or MySQL instance to point your IDE at, the RunxBuild dashboard is where you create one.

Useful related references:

• DBMS vs Database: The Distinction That Actually Matters in Practice
• Linux tee: See the Output and Save It at the Same Time
• kubectl List Pods: All Namespaces, by Label, and JSON Output
• Services on RunxBuild

FAQ

Why does DBMS_OUTPUT.PUT_LINE print nothing in DataGrip?

The output option is probably off for your console session. SET SERVEROUTPUT ON is a SQL*Plus command that DataGrip does not process. Enable DBMS_OUTPUT for the console and check the Output tab in the Services window.

Does DBMS_OUTPUT work for databases other than Oracle?

DataGrip’s option applies to Oracle and IBM Db2 LUW. For PostgreSQL use RAISE NOTICE, which DataGrip shows in the same output area.

Why does the output appear only after the script finishes?

The buffer is fetched from the database after execution completes, so lines are shown at the end rather than streamed during a long loop.

How do I avoid buffer overflow errors?

Call DBMS_OUTPUT.ENABLE(NULL) at the start of the session to remove the buffer limit in modern versions, or reduce how much you print.

Is there a better way to debug stored procedures?

Yes. Use the IDE debugger with breakpoints, or write to a log table using an autonomous transaction so entries survive a rollback.