|
|
|
|
|
|
Once coded, your SP, UDF, or trigger needs to be compiled and “deployed” to a server. Right-click it in Solution Explorer and choose Deploy to Server. One or more SP, UDF, or triggers can be deployed at the same time.
You are notified if any problems are encountered while the code is compiled and deployed to a FairCom DB SQL server.
|
|
|
A stored procedure can be run to test its behavior by right-clicking in Solution Explorer and choosing Test Procedure. A window appears allowing you to set the stored procedure’s parameters, execute it, and see the result generated.
|
|
|
By right-clicking in Solution Explorer and choosing Debug Server it is possible to debug a SP, UDF, or trigger while the server runs it.
The server must be active and reachable while debugging. For simplicity, the server should be running on the same machine, although it is possible to debug a remote server using Microsoft remote debugger.
You can set a breakpoint in the code, launch a debug server (not necessarily in this sequence), and execute your stored procedure via external tools such as FairCom DB SQL Explorer, your own program, or Test Procedure as described above.
|
|
|
In V11 and later, server-side stored procedure execution logging can be turned on and off using the TPESQLDBG environment variable. TPESQLDBG is an array of 'Y'/'N' characters that determine which debug options are enabled.
Prior to this revision, this was achieved by setting the 11th element (offset 10, java_debug) in the TPESQLDBG environment variable. The logging produced in this way is quite verbose and included information that was useful only to FairCom Technicians.
The interpretation of TPESQLDBG (and other methods setting the same debug features) has been modified as follows:
Note that activating element #11 (java_debug) activates internal logging and log() method for ANY stored procedure language, not just Java.
