PL/SQL Debugger

A true source-level debugger. It attaches to your procedure through Oracle’s DBMS_DEBUG package and gives you breakpoints, stepping, live variable values, watch expressions and a call stack.

#20.1Prerequisites

Requirement	Why
An Oracle connection	The debugger uses `DBMS_DEBUG`; it is Oracle-only.
`DEBUG CONNECT SESSION` privilege	Required to attach a debug session.
The program compiled with debug information	`ALTER PROCEDURE my_proc COMPILE DEBUG;` (or `PLSQL_DEBUG=TRUE`). Without it Oracle reports no line information and stepping will not stop where you expect.
`DEBUG ANY PROCEDURE`, or ownership	To debug code in another schema.

#20.2Starting a session

The toolbar in the idle state has three controls:

Procedure Name — type the program’s name. Accepts NAME or SCHEMA.NAME. As you type, DBCraft loads the source automatically (after a short pause) so you can set breakpoints before you start. It tries PROCEDURE, then FUNCTION, then PACKAGE. The ⟳ button next to the field reloads on demand.
Execution SQL Block — the anonymous block that calls your program, e.g.

sql

BEGIN my_proc(103, 10); END;

Start Debug — attaches the session and runs to the first breakpoint (or the first executable line).

#20.3Breakpoints

Click in the gutter — the narrow column to the left of the line numbers — to toggle a breakpoint. A red dot marks it.

Breakpoints can be added and removed while execution is paused; DBCraft registers the change with the running session immediately and logs the fact to the console.

#20.4Stepping

While paused, the toolbar offers:

Button	Meaning
Resume	Continue to the next breakpoint or to the end.
Step Over	Execute the current line; do not descend into calls.
Step Into	Descend into the called program.
Step Out	Run to the end of the current program and return to the caller.
Stop	End the debug session.

The current line is highlighted amber with a ► marker in the gutter. If Step Into takes you into a program whose source is not the one on screen, the highlight is suppressed and the status badge tells you which program you are actually in — Paused at L42 in INNER_PROC.

The status badge on the right shows Paused at Ln (amber, pulsing), Running… (blue) or Completed (green).

#20.5The inspection panel

Three tabs down the right side:

Variables — every in-scope variable and its current value, refreshed at each stop. Additionally, any variable name appearing in the source is highlighted inline; hover it to see its current value in a tooltip. This is often faster than reading the list.

Watch — type a variable name or expression and press Enter (or the +). Watches are evaluated at every step. Values that are NULL or unavailable are shown greyed. Hover a watch to reveal its delete button.

Call Stack — the frames, current frame first with a ► marker, each showing the program name, type badge, line and depth.

#20.6The Debug Console

The strip along the bottom logs every event with a timestamp: session attach, step results, dynamic breakpoint changes, DBMS_OUTPUT from your program, and errors. Colour-coded — green for success, red for errors, amber for program output, grey for informational.

#20.7Exporting a debug log

Export on the toolbar writes a plain-text file debug_<PROC>_<timestamp>.txt containing the console log, the final variable values, all watch expressions and values, the call stack, and the execution block. Useful for attaching to a defect report.

#20.8The offline simulator

If no live database connection is available, Start Debug falls back to a built-in simulator that walks through a sample procedure. Every console line is prefixed [SIMULATOR]. This exists for demonstration and for learning the interface; it does not touch a database.

#20.9Launching the debugger from elsewhere

A failed test in the Unit Test Manager offers a Launch in Debugger button that switches to this module with the procedure name and execution block already filled in.