Run Statement vs. Run Script: Choosing the Right Execution Path in SQL Developer

You have a worksheet full of SQL and PL/SQL, and you need to see the results. You likely alternate between Ctrl+Enter and F5, but the difference isn't just about how much code gets executed—it is about which engine is processing your request. Using the wrong one can lead to missing DBMS_OUTPUT messages, unexpected popup dialogs for variables, or the inability to run a sequence of setup steps.

The Execution Divide: Grid vs. Text

SQL Developer provides two distinct paths for executing code. Run Statement typically Ctrl+Enter targets the specific statement where your cursor is resting. It submits that single command to the database via JDBC and returns the data into the Query Result grid. This grid is a powerful analysis tool; it allows for client-side filtering, sorting, and, if the table has a primary key, direct editing of the data.

Run Script typically F5 treats the entire worksheet or a selection as a script. It passes the code through a client-side engine that mimics SQL*Plus. The results are streamed as plain text into the Script Output tab. While you lose the interactive grid, you gain the ability to execute a logical sequence of operations—such as truncating a table, inserting seed data, and verifying the count—in one click.

Handling PL/SQL and DBMS_OUTPUT

One of the most common frustrations in SQL Developer is a PL/SQL block that finishes successfully but shows no output. This happens because DBMS_OUTPUT.PUT_LINE writes to a buffer on the server, not directly to the client.

When using Run Statement, the script engine is bypassed. To see output, you must manually open the DBMS Output window, View > DBMS Output, click the green plus icon, and select your connection to tell the IDE to poll the server for that buffer.

When using Run Script, you can control this behavior directly in the code using SQL*Plus-style commands. Adding SET SERVEROUTPUT ON; at the top of your script instructs the engine to fetch and display the buffer automatically in the Script Output tab.

Bind Variables and Substitution

The two modes handle variables fundamentally differently:

• Run Statement: When the engine encounters a bind variable e.g. :dept_id, it pauses execution and opens a graphical dialog box asking you to provide a value and a data type.
• Run Script: The script engine can resolve variables internally. By using VARIABLE declarations or DEFINE statements, you can create self-contained scripts that don't require manual user input during execution.

Worked Example: Seeding a Test Environment

Consider a scenario where you need to reset a small lookup table for testing. If you use Run Statement, you would have to click and execute four separate blocks manually. Using Run Script allows you to automate the flow.

-- Run this using F5 (Run Script)
SET SERVEROUTPUT ON;
SET FEEDBACK ON;

-- 1. Clean up existing data
DELETE FROM app_config WHERE config_key = 'TEST_MODE';

-- 2. Seed new value
INSERT INTO app_config (config_key, config_val) VALUES ('TEST_MODE', 'TRUE');

-- 3. Verify with a PL/SQL block
DECLARE
  v_val VARCHAR2(10);
BEGIN
  SELECT config_val INTO v_val FROM app_config WHERE config_key = 'TEST_MODE';
  DBMS_OUTPUT.PUT_LINE('Verification: TEST_MODE is now ' || v_val);
END;
/

COMMIT;

Verification: After pressing F5, check the Script Output tab. You should see the row counts for the DELETE and INSERT operations, followed by the "Verification: TEST_MODE is now TRUE" message. If you ran this with Ctrl+Enter, you would only execute the specific line where the cursor was placed, and the SET commands would be ignored as invalid SQL.

Trade-offs and Limitations

Feature	Run Statement (Ctrl+Enter)	Run Script (F5)
Output Format	Interactive Grid (Sortable/Exportable)	Plain Text (Read-only)
Execution Scope	Current Statement/Selection	Entire Worksheet/Selection
SQL*Plus Commands	Ignored	Supported (SET, DEFINE, etc.)
Variable Input	GUI Popup Dialog	Script-defined variables

Warning: Be cautious with the editable grid in Run Statement. If you have the appropriate permissions, changing a cell in the grid modifies the data in the database once you click the Commit button. For production environments, it is safer to use a read-only connection or stick to Run Script to avoid accidental DML.

Summary Decision

Use Run Statement when you are exploring data, need to export a result set to CSV, or are debugging a single query. Use Run Script when you are building repeatable deployment steps, running complex PL/SQL blocks with DBMS_OUTPUT, or executing a sequence of dependent DDL/DML commands.