Pathname support for stored procedures

If your application includes any stored procedures, you should include a procedure named SQLScriptPath in your application. If any of your stored procedures are stored in a database other than your application’s default database, you must include this procedure in your dictionary. The SQLScriptPath procedure adds pathname information to the stored procedure name.

The call sproc statement passes a stored procedure name to the SQLScriptPath procedure, which then adds the appropriate pathname information to the beginning of the stored procedure name. This script ensures that the call sproc statement sends the command to execute the stored procedure to the proper location. If this script isn’t included in your application, Dexterity will search only the default database for all called stored procedures.

The SQLScriptPath procedure is much like the SQLPath procedure. It has similar syntax, and adds pathname information to the beginning of a resource name. However, this procedure is used to add that information to the names of stored procedures.

SQLScriptPath procedure parameters

The SQLScriptPath procedure uses four parameters; three in parameters and one out parameter. The out parameter specifies the pathname added to the stored procedure name.

The cores and their corresponding integer values are listed in the following table:



1 – Financial

3 – Purchasing

5 – Payroll

7 – System

2 – Sales

4 – Inventory

6 – Project




This example shows a SQLScriptPath procedure written for use in an application that accesses a data source in which the stored procedures for all databases associated with the data source are located in a single database, StoredProcs, created by user JWILCOX.

in integer product_ID;
in integer core_ID;
in integer procedure_ID;
out string data_path;

data_path = "StoredProcs/JWILCOX/";

If the owner name weren’t included in this script, Dexterity would have used the current SQL user ID as the default owner name.

Documentation Feedback