SPL Debugger is the interactive debugger for Informix database servers' stored procedures and triggers and provides powerful capabilities usually found only in high level programming languages. It enables you to execute stored procedures and triggers line-by-line, to step into nested procedures or fired triggers, to set breakpoints, to watch and to modify values of procedures' variables and calling arguments, break infinite loops, etc.

SPL Debugger can be invoked from any client application or development tool, such as Visual Basic, PowerBuilder, C++, Informix-4GL, etc. Remote debugging gives you ability to execute calling application from one workstation on the network, while SPL Debugger runs on another. Simultaneous debugging sessions can be initiated from any workstation on the network. Another important feature of SPL Debugger is it's ability to "hook" into stored procedure or trigger that is already executing on the server, enabling you to identify the cause of infinite loop or to pinpoint the slowest portion of the code.

SPL Debugger supports watching and editing all types of variables including UDT, OPAQUE and COLLECTION datatypes.

Typical use of SPL Debugger

· You can verify that a particular stored procedure or trigger was actually executed as a part of application logic and that correct set of parameters was passed.

· You can analyze execution logic of complex SPL code, by executing it line-by-line and monitoring values of variables.

· You can interactively edit values of variables or tables data to force correct execution of the logic when the logical error is found during debugging session, without the need to interrupt the debugging process.

· You can verify that a stored procedure operates with the correct data, by examining values in data tables and views that the procedure’s logic depends on, when execution has been paused on a breakpoint.

· You can break an infinite loop during execution of a stored procedure and proceed with its execution in a step mode, to analyze conditions that lead to the occurrence of this loop.

How To Debug Stored Procedures and Triggers

To be able to use the SPL debugger, you have to install the debugger repository. The repository is a collection of several tables and stored procedures that enable debugging operations. The repository can be installed using Tools -> SPL Debugger -> Manage Repository menu in the Server Studio JE or it can be installed when you attempt to open the debugger for the first time. For additional information on debugger repository see Installation and Configuration topic.

To debug procedure or trigger:

1 In the Server Studio JE Object Explorer highlight the procedure or trigger and select Debugger -> Open from right mouse menu or from the toolbar.

2 The Debugger window will be opened and the selected procedure or trigger becomes the active debugger object. Its name will be displayed in the title bar of the debugger window.

3 Note
If you attempt to debug this object for a first time, the debugging version of the object will be created. See Debugging Version topic for a further information on what is the debugging version of a procedure or trigger.

4 From the Debugger main window Debug menu select Start Debugging Session item.

5 The Start Debug Session dialog box will be opened.

6 From this dialog box select the option how you want to invoke the procedure or trigger on the server.

There are 3 options available:

8 - Enter Parameters
Enter the current procedure parameters' values in the grid and press Debug button to execute the procedure and start the debugging session.

10 - Enter custom SQL
Enter any SQL script, which will invoke the procedure or trigger, and press Debug button. The SQL script will be send to the server and debugging session will be started. If the SQL script will not invoke the procedure or trigger on the server, the debugger window will just display the results of the script’s execution, if any were produced, and status messages.

11 For example, you can use INSERT SQL statement to invoke table’s insert trigger. Or you can use EXECUTE PROCEDURE SQL statement on the main procedure to invoke debugging of the nested procedure currently active in the debugger window.

12 - External launch.
In this mode, the debugger waits for the launch of the active debugger object on the server. You will have to use any external application to execute SQL statement, which will invoke the procedure or trigger on the server. It can be, for example, Informix SQL Editor, your Visual Basic or PowerBuilder program, etc. Optionally, you can specify the host where the procedure will be launched from and the user who will launch the procedure. Default settings are to debug objects launched from the same host where the debugger is running (your local host) and start debugging when the object is launched by any user.

13 If you selected "External Launch" mode is Step 2, execute procedure or the SQL statement, which will trigger execution of the debugger’s active object. You can do this, for example, using Server Studio JE SQL Editor or any other external application.

14 When the debugger will find the launch of the procedure, the calling application will be blocked and the debugger Source View Panel will highlight the first executable line of the procedure. You will also see the yellow arrow pointer on the left margin area of the source view panel that points to this line. After you see this pointer, you can perform an interactive debugging using all available debugging operations, such as Step, Step Into, Run, etc.

16 After the end of the procedure is reached, the debugger will display a message "Debugging session was successfully completed."

17 If you were not using "External Launch" mode, all results produced in the procedure will be displayed in the Output tabs of the debugger window. All error messages are displayed in the Messages tab of the debugger window. If you were using "External launch" mode then at this point the calling application is unlocked and continues execution. To repeat debugging session, go to the Step 2.

19 To stop debugging session, select Stop Debugging Session from the Debug menu. If you are currently in the middle of the debugging, you will get message with two options:

20 - Stop the SPL object that is currently being executed

21 - Continue execution

22
If you select to interrupt the execution, the calling application will stop with the exception -213: "The statement is interrupted by the Debugger." If you select do not interrupt, the calling procedure will continue execution from the point where it stopped in the debugger.

How To Edit Stored Procedures and Triggers in the Debugger

You can edit stored procedures and triggers displayed in the Source Editor area of the Debugger main window when the debugger is not within the active debugging session. All standard editing operations such as Copy, Paste and Cut are supported. To save modified source in the database, use File -> Save in Database top-level menu. The program will automatically re-create a debugging version of the modified object so that you do not have to explicitly create a debugging version of this object after each modification. When you start the debugging session using Debug -> Start Debug menu, the Source Editor panel switches to Read Only mode to prevent modifications that might effect the active session.

Note

If you use any external editor to edit stored procedure or trigger after it’s debugging version was created, the object will lose instrumentation and the debugging version has to be explicitly re-created using Debug Version popup menu in the Source Browser object tree.

How To Organize Procedures and Triggers in Project Folders

Virtual Projects allow you to logically organize stored procedures and triggers. It helps you to speed up access to a group of logically related objects.

For example, you can create a project folder Accounting System that contains 5 procedures and 3 triggers that have to be debugged as part of the accounting project. Next time you need any of these objects to edit or create a debugging version, you can go just to a single place rather than browsing hundreds procedures and triggers in the database folders. You can create public and private folders with any level of folder nesting. Folders can contain shortcuts on objects of any type and from any database.

Virtual Projects are displayed in the Debugger main window Source Browser panel.

To create a virtual project folder

1 From right mouse menu, select Create Folder when PROJECTS folder or any other user folder is highlighted in the object tree view. The User Folder Properties dialog box will be opened.

2 In User Folder Properties dialog box specify the folder name and optional comments. Press OK button. The folder with the given name will be displayed under PROJECTS folder or the selected user folder.

To create an object shortcut

1 Highlight the object for which you want to create a shortcut in PROCEDURES, TABLES, TRIGGERS or VIEWS folders and select Copy As Shortcut from right mouse menu.

2 Highlight the user folder where you want to place a shortcut and select Paste Shortcut from right mouse menu.

4 You can create a shortcut on the same object in more than one folder.

To delete an object shortcut, highlight this shortcut in the user folder and select Delete Shortcut from right mouse menu.

Deleting shortcut DOES NOT drops underlying object from the database. It just deletes a reference to this object from the user folder.

Current Debugger Limitations

The debugger does not fully supports syntax of some SPL extensions introduced in IDS 9.3 and 9.4.

Installation and Configuration

The SPL Debugger component is available only under Windows platforms. It does not have a separate setup and is installed as part of Server Studio JE full installation.

In order to use the SPL Debugger, you have to install the debugger repository. The repository consists of 7 tables and 4 stored procedures. It is used to maintain information about SPL objects available for debugging and virtual user folders. The debugger can not be used in databases created with “ANSI compatibility” option. You can use it only with Informix native databases that have either “with logging” or “no logging” mode. If you use mix of logging and non-logging databases, you should install 2 instances of the debugger repository: one in any logging databases and one in any non-logging database.

To install the debugger repository:

1 Choose Server Studio JE Tools -> SPL Debugger -> Manage Repository top-level menu.

2 The Connect dialog box will be opened. Connect to a database where you want to install the repository (it should be the database of the same type – “logging” or “non-logging” - where stored procedures, which you want to debug, are located. It does not have to the same database where procedures are located.

3 In the Debugger Repository Setup dialog box, press Install button.

Also the Debugger repository Setup dialog box is automatically opened when you attempt to debug a stored procedure and there is no debugger repository found on this database server.

SPL Debugger

Debugging Version of the Procedure or Trigger

Debugging Version of SPL object is a modified version of the original stored procedure or trigger that contains debugging instrumentation code. For each debugging version of a procedure or trigger a support procedure is automatically generated. Names of all support procedures start with the prefix <deb_> followed by a number. Support procedure is generated in the same database as the original SPL object during Create Debug Version operation.

Debugging version of SPL object behaves exactly the same way as the original object when executed from outside of the debugger but provides additional functionality when executed in the debugger.

You do not have to create and remove debugging instrumentation from the SPL object every time you do a debugging. You can keep it there if you are planning to continue debugging this object later. The debugger automatically maintains all current object privileges when it creates a debugging version or recovers original version so every user who had permissions to execute the original SPL object will have permission to execute debugging version.

Only object owner can create a debugging version of the SPL object. Every developer who has ‘execute’ permissions on the object can perform debugging after the debugging version of an object was created.

When debugging version of the procedure is displayed in Debugger main window Source View panel, the debugging instrumentation code is hidden and original procedure’s syntax is displayed. You can edit this syntax in the Source View panel as you would do in a regular SQL Editor. After you modify the source in the Source View panel, you should save the changes in the database by using File -> Save in Database menu item from the Debugger top-level menu. When you perform any modifications of the debugging version of the object in the Source View and apply these change to database, a new debugging version is created on the fly so that you do not have to re-create debugging version explicitly.

Active Debugging Object

The active debugger object is the object that the debugger waits to be launched to start a debugging session. Both procedures and triggers can become active debugger objects.

For example,

There are 2 stored procedures proc_A_main and proc_B_nest and proc_A_main calls proc_B_nest.

Let us assume that you have opened the debugger on the procedure proc_A_main and set breakpoints in both proc_A_main and proc_B_nest. The procedure proc_A_main becomes the active debugger object. After you select Start Debug Session from Debug menu, the debugger will wait for the launch of proc_A_main and will start interactive debugging session. At this point all breakpoints in proc_B_nest are active so when proc_A_main calls proc_B_nest, the debugger will stop in proc_B_nest. But if you try to launch proc_B_nest directly, for example, using EXECUTE PROCEDURE proc_B_nest, the debugger on proc_B_nest will not be invoked because proc_B_nest is not the active debugger object. You have to make proc_B_nest the active debugger object to force debugger wait for the launch of this procedure.

When the debugger reaches the end of the active debugger object, the interactive debugging session is finished and you have to explicitly start debugging session again if you want to repeat it.

The object, which you open the Debugger with from the Server Studio JE Object Explorer, automatically becomes the active debugger object. If you want to change the active debugger object after the Debugger window was opened, highlight the debugging version of the procedure or trigger in the Source Browser panel of the main Debugger window and select Debug from right mouse menu. The debugger should not be in middle of the debugging session, to change active debugging object. If you have interactive debugging session in progress, stop it first before you can change the active debugger object in the debugger window.

Note

Changing of the source in Source View, for example, when you step into nested procedure or when you open another object from the Source Browse tree in order to see its syntax using Open Source popup menu, does not change the active debugger object. You have to change it explicitly using the Debug popup menu.

Starting Debugging Session

Start Debugging Session dialog box is opened when you select Start Debug session from the Debug menu. This dialog box allows you to provide procedure's parameters or SQL statements to invoke the procedure/trigger that you want to debug on the server. Also it allows you to select "External Launch" mode when debugger will wait until the procedure or trigger is executed on the server by means of any external application such as Visual Basic, Powerbuilder, C++ or Informix 4GL.

Last entered parameters or SQL calling script are automatically saved between debugging sessions for any procedure or trigger.You can also explicitly save a set of parameters or calling SQL script in the file to be able to use multiple set of calling parameters for the particular procedure/trigger later on.

Enter parameters

This option is available only for stored procedures and provides a fastest and simplest way of starting a debugging session.

You enter a stored procedure parameters' values into a grid. The parameter value can be either a constant or an expression. For constants, the program automatically adds single quotes around CHAR/VARCHAR and DATE values. If you want to specify an expression or a function call like, for example, TODAY or NULL value, click on the EXP checkbox to force the program not to add quotes.

The bottom part of the window displays the generated EXECUTE PROCEDURE statement. This statement is updated as you type parameters' values. You have to provide values for all procedure's parameters to be able to start debugging.

When all parameter's values are entered, the Debug button becomes enabled. Press Debug button to start a debugging session. The debugger window will display "Active Session" in the title bar when your debugging session is finished initializing and you can start interactive debugging.

If the procedure produces the result set or error messages, they will be displayed in Output and Messages tabs of the debugger window located in the right bottom panel.

Enter custom SQL

This option allows you to enter any SQL statement or SQL script to invoke a procedure or trigger on the server.

For example, you need to debug a procedure ABC but you might want to use for invocation the procedure DEF that calls ABC.

To debug a trigger, you have to type INSERT/UPDATE or DELETE statement to fire this trigger or it can be EXECUTE PROCEDURE statement that contains statement that will fire the trigger.

You can use any script of multiple SQL statements separated by ";" character.

All result sets and runtime error messages produced by this script will be displayed in Output tabs of the debugger window located in the right bottom panel of it.

Press Debug button to start a debugging session. If there are syntax errors in your source, the message will be displayed and the error position in your source will be highlighted.

External launch

This option gives you an ability to debug a procedure or trigger executed from third party application. For example, you can debug a Informix stored procedure called from your Visual Basic application.

When you press Debug button, debugger window will switch to the waiting mode and will wait until the procedure or trigger is launched on the server. You should use any other application capable of executing Informix SQL to issue the EXECUTE PROCEDURE or any other statement which leads to invocation of the procedure you want to debug on the server. You can also use a second instance of SPL Workstation as a calling application.

For triggers you have to launch any SQL statement that fires that trigger, for example, UPDATE, INSERT or DELETE statement or any procedure that executes these statements. Once the procedure or trigger is launched on the server, the debugger window will intercept this procedure call and start interactive debugging session.

The host computer from where you launch the procedure and login user should correspond with the settings for Host and User fields.

The active debugger object can be launched on a server from the same host workstation where the debugger is running or from any other host on the network. It can be launched by the same user who is currently running the debugger or by any other user.

The external launch debugger options allow you to specify the instance of the procedure or trigger that should be intercepted by the debugger when launched.

You can specify the following interception options for the host:

- Any host on the network.

- Local host

- Selected host

You can specify the following interception options for the user:

- Any user on the server

- The current debugger user

- Selected user

All result sets produced during debugging session will be displayed in the calling external application.

Saving parameters' values or SQL script in the file

To save procedure's parameters' values or SQL script in the file, press Save As button and enter the file name. If the currently active option is "Enter parameters" then data will be saved in a parameter's file with extension PRM. If the currently active option is "Enter custom SQL" then the script will be saved in SQL file.

The program automatically saves and restores the last parameter's set or SQL script used for the procedure or trigger that is being debugged.

Restoring parameters' values or SQL script from the file

To restore a particular parameter set or SQL script, press Restore button and select parameter file name or SQL script file. If the structure of the procedure has changed since the moment you had saved parameters, for example, you have added or removed procedure's parameters, then the program attempts to recover only values of parameters that have not changed.

Debugging Operations

Run until a breakpoint

This operation execute the stored procedure or trigger until next breakpoint is found or until the end. You have to set some breakpoints before you use this operation.

Step Over

The Step Over operation executes one SQL statement in the procedure or trigger. If there are several logical SQL statements on the same source line, you have to use Step operation as many times as there are statements on the line.

The Step Over operation executes calls to a nested stored procedure or a statement which fires a trigger as one logical statement unless there are breakpoints in the nested procedure or trigger.

Step Into

The Step Into operation executes one SQL statement in the procedure or trigger. If there are several logical SQL statements on the same source line, you have to use Step Into operation as many times as there are statements in the line.

The Step Into operation always goes inside of a nested stored procedure or a body of trigger if the current statement fires a trigger. It stops on the first executable line of a nested procedure or a trigger.

Break

The Break operation forces the procedure that is currently running to stop and switch into Step mode. For example, if you press Run and procedure never stops at the breakpoint because of the infinite loop, you can use Break operation to force it to stop at the line where it is currently being executed.

Stop Debugging Session

Use this operation to stop "wait for launch" mode or interrupt the currently active debugging session in the middle. There are two options available that affect the way how the debugging procedure will continue the execution.You can either stop just an interactive debugging session and let the procedure to run until it finishes or you can interrupt the debugging procedure where it stopped in the debugger and raise special exception condition.

Breakpoints

You can maintain breakpoints in the Breakpoints or Source View panel of the Debugger window. Breakpoints can be in an enabled or disabled state. If a breakpoint is in disabled state, it is removed from the Source View but is still available in the Breakpoints View.

List of breakpoints is saved between debugging sessions. The debugger always attempts to apply all existing breakpoints to the active debugging session. If the breakpoint can not be applied because of a change in a source, it is removed.

To toggle a breakpoint for the procedure in the current Source View:

Click on the gray margin area of the Source View at the line where you want to toggle a breakpoint. If there was no breakpoint at this line, the line will be highlighted and the breakpoint indicator will be displayed in the margin area.
If there was a breakpoint at this line, the breakpoint is removed.

Left click on the line in the source where you want to toggle a breakpoint and select Toggle Breakpoint from the right mouse menu.

To toggle a breakpoint for the procedure that is not in the current Source View:

1 In the Object Browser tab of the Breakpoint Panel highlight the debugging version the object where you want to toggle a breakpoint. Select Open Source from right mouse menu. The source of this object will be opened in the Source View panel.

3 Follow the steps described in the previous paragraph to set breakpoints.

To clear a breakpoint, highlight the breakpoint you want to clear in the Breakpoints tab of the Breakpoint panel and select Clear from the right mouse menu.

Select Clear All to clear all existing breakpoints.

To disable a breakpoint:

Click on the breakpoint indicator (filled red circle) in the Breakpoints tab of the Breakpoints panel. Indicator will be changed to a not filled circle and the breakpoint will disappear from the Source View.

In the Breakpoints Tab of the Breakpoint panel, highlight the breakpoint you want to disable and select Disable from the right mouse menu.
Select Disable All to disable all existing breakpoints.

Viewing and Modifying Variables

You can view variables by using the Variable Panel or Variable Watch Panel of the Debugger window.

The Variable Panel has three tabs to display local, global variables and procedures input arguments. For each variable the name, datatype and current value is displayed. The values of variables are updated every time the debugger stops at a breakpoint or as a result of Step operation.

If there are too many variables in each variable's category and it becomes difficult to scroll the variable list to find the variable you want to watch, you can use Variable Watch Panel.

The Variable Watch Panel allows you to create a custom list of variables and input arguments. All categories of variables are displayed in the same list.

Notes

If a variable has Universal Server OPAQUE type and there is no support function providing casting from this datatype to LVARCHAR, the value of variable will be displayed as "not accessible". If there is no support function providing casting from LVARCHAR to this type, you will be able only view these variable's value but not edit it.

Local variables defined within nested BEGIN … END blocks are not displayed in the Variables panel of the Debugger window. The workaround is to define local variables on the top level. In that case even if they are re-declared in a nested level BEGIN … END block, their correct values are always shown in the Variables panel.

To add a variable to the watch list:

Select the variable in the Variable Panel and drag-and-drop it to the Variable Watch Panel.

To modify variable:

Double-click on the variable in the Variable panel. The Modify Variable dialog box will be opened.

Doubleclick on the variable in the Variable Watch panel. The Modify Variable dialog box will be opened.

“Hooking” Into Running Object

Debugger can be invoked on a procedure that is already running on the server. For example, such a need might arise if the procedure entered an infinite loop. Invoking a Debugger in this case can help to break the procedure out of the infinite loop.

Hooking into Running Procedure

1 Create debugging version of the procedure and launch this procedure from any external application or from Server Studio JE SQL Editor.

2 Open the Debugger window for procedure that you want to hook into.

3 Choose Start Debug Session from the Debug menu.

4 Select "External Launch" option and press Debug button.

5 At this point Debugger will intercept the procedure if it runs on the server and will highlight the current executed line. Once the Debugger highlights the current executed line, the procedure is stopped and awaiting user's commands.

Note

To be able to hook into a running procedure, a debugging version of the object should be created previously to execution.

Debugger Main Window

The Debugger window allows to debug SPL stored procedures and triggers to the source code level.

Debugger window has four resizable panels:

Source View Panel
This panel displays the source of the SPL object, active breakpoints and line that will be executed next. Source View Panel displays either source of the object that is currently executed or the source of the object opened from Source Browser tab of the Breakpoint Panel. To toggle a breakpoint at the source line you can click on the gray margin area at left of the source.

You can edit the object source in this panel when the debugger is not running an active debugging session. To save changes in the database use File -> Save in Database top-level menu.

Variable Panel
The Variable panel displays names, datatypes and current values for all procedure's local, global variables and calling arguments. It has three tabs for each variable type - Local, Global and Arguments. You can double-click on the variable name to open Modify Variable dialog box.

Variable Watch and Results Panel
This panel is located in the bottom right corner. It has Variable Watch tab and also Messages and multiple Output tabs. Variable Watch tab can display a subset of local and global variables or procedure arguments. You can create a custom variable watch list by dragging variable from any tab of Variable Panel and dropping it on the Watch Panel. To remove variable from watch panel just drag and drop it back to Variable Panel. To open Modify Variable box, doubleclick on the variable name in watch list.
Message tab and Output tabs are dynamically created if a procedure or the calling SQL script returns data and you are not using "External launch" mode to start debugging session. Messages tab contains chronological list of status and error messages generated by the procedure or script.
Each Output tab contain SQL statement which produced an output in the top part and the grid with the data in the bottom part.

Breakpoint Panel

Breakpoint Panel has three tabs.
Source Browser tab displays tree view of database procedures and triggers. It allows opening of debugging versions of SPL objects in Source View Panel and changing the active debugging object. You can use this tab to set breakpoints in objects different from the one that is currently being executed.

- To open another object in the Source View panel, select an object in the Source Browser and choose Open from right mouse menu. The object should have a debugging version to be able to open it. If it does not have a debugging version, create one using Debug Version right mouse menu.

- To change the active debugging object, select an object in the Source Browser and choose Debug from right mouse menu. The object should have a debugging version to be able to make it an active debugger object. If it does not have a debugging version, create one using Debug Version right mouse menu.
- To create debugging version of an object, select an object in the Source Browser and choose Debug Version from right mouse menu.
Breakpoints tab displays the list of breakpoints set in the current and previous debugging sessions.
Break History tab displays object names and source line numbers where the debugger stopped during the current debugging session.

Start Debug Session Dialog Box

Last entered parameters or SQL calling script are automatically saved between debugging sessions for any procedure or trigger. You can also explicitly save a set of parameters or calling SQL script in the file to be able to use multiple set of calling parameters for the particular procedure/trigger later on.

Enter parameters

This option is available only for stored procedures and provides a fastest and simplest way of starting a debugging session.

If the procedure produces the result set or error messages, they will be displayed in Output and Messages tabs of the debugger window located in the right bottom panel.

Enter custom SQL

This option allows you to enter any SQL statement or SQL script to invoke a procedure or trigger on the server.

For example, you need to debug a procedure ABC but you might want to use for invocation the procedure DEF that calls ABC.

To debug a trigger, you have to type INSERT/UPDATE or DELETE statement to fire this trigger or it can be EXECUTE PROCEDURE statement that contains statement that will fire the trigger.

You can use any script of multiple SQL statements separated by ";" character.

All result sets and runtime error messages produced by this script will be displayed in Output tabs of the debugger window located in the right bottom panel of it.

Press Debug button to start a debugging session. If there are syntax errors in your source, the message will be displayed and the error position in your source will be highlighted.

External launch

This option gives you an ability to debug a procedure or trigger executed from third party application. For example, you can debug a stored procedure called from your Visual Basic application.

The host computer from where you launch the procedure and login user should correspond with the settings for Host and User fields.

The external launch debugger options allow you to specify the instance of the procedure or trigger that should be intercepted by the debugger when launched.

You can specify the following interception options for the host:

- Any host on the network.

- Local host

- Selected host

You can specify the following interception options for the user:

- Any user on the server

- The current debugger user

- Selected user

All result sets produced during debugging session will be displayed in the calling external application.

Saving parameters' values or SQL script in the file

The program automatically saves and restores the last parameter's set or SQL script used for the procedure or trigger that is being debugged.

Restoring parameters' values or SQL script from the file

Variable Editor Dialog Box

Use the Modify Variable dialog box to view and change the value of variables during a debugging session.

Double-click the variable you want to modify either in the Variable Panel or Variable Watch Panel of the debugger window.

Enter a new value for the variable or click the Set Null check box to set the value to null.

Press OK to change the value and close the Modify Variable Dialog Box or press Cancel to leave the value unmodified.

To add a new item to a collection data select the collection node in the tree and choose Add Item or Insert Item from right mouse menu.
To delete item from the collection, select the item and choose Delete Item from right mouse menu.

To edit existing value in the complex structure, select the item you want to edit and type new value in the bottom part of the Cell Editor window.

Note

The Debugger allows editing only variable’s values, which size does not exceed 2 Kbytes.

If a variable’s value exceeds this limit, only first 255 bytes will be displayed and the value will be Read Only in the debugger.

Limited Debugging Version Dialog Box

To support interactive debugging, the product has to add debugging instrumentation to the original source code of a procedure. Unfortunately, IDS has 64Kb limit for a procedure size, which restricts amount of debugging information that can be added to the code.

In most of the cases, you do not need to edit all variables during debugging or you might want to be able to step through just a particular part of the procedure.

SPL Debugger provides the option to explicitly specify these parameters, when it runs into the size limitation.

Create Limited Debug Version Dialog Box will automatically appear when the debugger runs into 64Kb size limit.

1 To select variables for editing or viewing, highlight any number of variables in the left variable panel and press the Right Button. Only variables in the right variable panel will be enabled for debugging. Check Read Only box to mark selected variables as read only. This will allow you to see the variable values and decrease twice the size of debugger instrumentation code.

2 You can select multiple variables, using Ctrl+Click or Shift+Click buttons.

3 To unselect any number of variables, highlight them in the left variable panel and press the Left Button.

4 To select an area of the code, which you want to be able to step through or set breakpoints, highlight it using the mouse in the syntax panel on the bottom of the dialog box. The numbers in the Start From Line# and End At Line# will display the beginning and ending line numbers which you selected for debugging.

You can use both above methods to decrease the size of the instrumentation. Use the estimation for variable and line numbers displayed on the top of the dialog box to determine the maximum number of variables and the number of code lines you can debug.

Debugger Repository Setup Window

The Debugger Repository Setup window allows you to install the repository in the selected database or uninstall the existing repository.

It also shows you all procedures and triggers, for which debugging versions were created, and allows removing the instrumentation for selected or all objects.

Use Install button to install repository in the selected database. You have to install it only in one repository of “WITH LOGGING” type and in one database of “NO LOGGING” type (if you actually use both types of databases)

All stored procedure that reside in database of the same type automatically share the same version of the repository.

Press Remove Instrumentation button to remove instrumentation for objects selected in the “Objects that have debugging instrumentation” grid.