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
NAMEorSCHEMA.NAME. As you type, DBKraft 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.
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; DBKraft 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.