Stored Procedures

Execute database stored procedures with IN/OUT/INOUT parameters and result set capture

BoxLang provides comprehensive support for executing database stored procedures through the bx:storedProc component. You can pass parameters, capture return values, retrieve multiple result sets, and handle complex procedure logic.

📋 Overview

Stored procedure support in BoxLang includes:

  • Parameter Types - IN, OUT, and INOUT parameters

  • Multiple Result Sets - Capture all result sets returned by a procedure

  • Return Codes - Retrieve procedure return status codes

  • NULL Handling - Proper NULL value support for parameters and results

  • Type Safety - Strong typing with SQL type declarations

  • Database Agnostic - Works across MySQL, PostgreSQL, Oracle, SQL Server, and more

🔧 Basic Stored Procedure Execution

Simple Procedure Call

Script Syntax:

bx:storedProc
    procedure="sp_GetEmployees"
    datasource="myDB"
    result="procResult" {

    bx:procResult name="employees" resultset="1";
}

// Access the result set
writeOutput( "Found #employees.recordCount# employees" );

Template Syntax:

You can use the template syntax within code islands

or if you are within a .bxm template:

📥 IN Parameters

IN parameters pass values into the stored procedure:

Script Syntax:

Template Syntax:

IN Parameter with NULL

Script Syntax:

Template Syntax:

📤 OUT Parameters

OUT parameters retrieve values from the stored procedure:

Script Syntax:

Template Syntax:

🔄 INOUT Parameters

INOUT parameters can pass values in AND retrieve values out:

Script Syntax:

Template Syntax:

📊 Multiple Result Sets

Capture multiple result sets returned by a single procedure:

Script Syntax:

Template Syntax:

🔢 Return Codes

Capture the return code (status) from a stored procedure:

Script Syntax:

Template Syntax:

🎯 Complete Example

Here's a comprehensive example showing all features:

Script Syntax:

Template Syntax:

🛠️ Component Attributes

bx:storedProc Attributes

Attribute
Type
Required
Description

procedure

string

Yes

Name of the stored procedure to execute

datasource

string

No

Datasource name (uses default if not specified)

result

string

No

Variable name to store execution metadata (default: "bxstoredproc")

returnCode

boolean

No

Capture procedure return code (default: false)

debug

boolean

No

Enable debug output (default: false)

username

string

No

Override datasource username

password

string

No

Override datasource password

bx:procParam Attributes

Attribute
Type
Required
Description

type

string

Yes

Parameter type: "in", "out", or "inout"

sqltype

string

Yes

SQL data type

value

any

Conditional

Parameter value (required for IN and INOUT)

variable

string

Conditional

Variable name for OUT/INOUT results

null

boolean

No

Set to true for NULL values (default: false)

maxLength

integer

No

Maximum length for string types

scale

integer

No

Decimal scale for numeric types

bx:procResult Attributes

Attribute
Type
Required
Description

name

string

Yes

Variable name to store result set

resultset

integer

Yes

Result set number (1-based)

📝 SQL Data Types

Common sqltype values for parameters:

SQL Type
Description
BoxLang Type

varchar

Variable-length string

String

char

Fixed-length string

String

integer

32-bit integer

Numeric

bigint

64-bit integer

Numeric

decimal

Fixed-point number

Numeric

numeric

Fixed-point number

Numeric

float

Floating-point number

Numeric

double

Double precision float

Numeric

bit

Boolean value

Boolean

date

Date only

Date/DateTime

time

Time only

Date/DateTime

timestamp

Date and time

Date/DateTime

binary

Binary data

Binary

blob

Large binary object

Binary

clob

Large character object

String

🗄️ Database-Specific Examples

MySQL

Script Syntax:

Template Syntax:

PostgreSQL

Script Syntax:

Template Syntax:

SQL Server

Script Syntax:

Template Syntax:

Oracle

Script Syntax:

Template Syntax:

💡 Best Practices

Security

  • Use stored procedures for complex business logic

  • Validate parameters before passing to procedures

  • Limit database permissions to only required procedures

  • Handle OUT parameters carefully to avoid information disclosure

Error Handling

  • Always check return codes when returnCode="true"

  • Wrap procedure calls in try/catch blocks

  • Capture error messages via OUT parameters

  • Log procedure execution for debugging

Performance

  • Use procedures for complex multi-query operations

  • Minimize result sets - only return needed data

  • Index procedure parameters in the database

  • Monitor execution time with result metadata

Code Quality

  • Document parameter purpose with comments

  • Use consistent naming for variables

  • Handle NULL values explicitly

  • Test with edge cases (empty results, NULLs, errors)

🚫 Common Pitfalls

Not handling NULL values

Ignoring return codes

Last updated

Was this helpful?