13.01.2013 Views

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

RDBMS Stored Procedure Details<br />

3–4<br />

As previously noted in Table 3–1, you can pass data types in the RUN STORED-PROCEDURE<br />

statement using the PARAM phrase. Table 3–2 lists issues that occur when you pass certain data<br />

types as parameters.<br />

Table 3–2: Argument data types <strong>for</strong> stored procedures<br />

<strong>OpenEdge</strong> MS <strong>SQL</strong> <strong>Server</strong> data source<br />

DECIMAL<br />

INTEGER<br />

INT64<br />

Note these stored procedure points:<br />

The <strong>Data</strong><strong>Server</strong> converts each of these data types in the schema image<br />

to the equivalent default <strong>OpenEdge</strong> data type as follows:<br />

• DECIMAL=DECIMAL(default), or Float<br />

• INTEGER=INTEGER<br />

• INT64=BIGINT<br />

However, you can use the <strong>Data</strong> Dictionary to update the data type and<br />

<strong>for</strong>mat in<strong>for</strong>mation in the field property sheet <strong>for</strong> the parameter.<br />

CHAR The data source represents this type as a VARCHAR parameter. Its size<br />

cannot exceed the VARCHAR size limit <strong>for</strong> the associated data source. If<br />

the VARCHAR parameter exceeds this limit, it causes an error.<br />

DATE If you pass a DATE data type as an input parameter and use it in an<br />

equality test, the test might fail. In this case, use DATEPART() or<br />

DATEDIFF() in the Transact-<strong>SQL</strong> of your native stored procedure to<br />

isolate parts of the date structure <strong>for</strong> which you might want to test.<br />

DATETIME You can specify a DATETIME data type in a temp table used to receive<br />

results from a stored procedure using the LOAD-RESULT-INTO phrase.<br />

• Input and output parameters are displayed as fields.<br />

• Stored procedures called from within <strong>OpenEdge</strong> applications cannot return Boolean<br />

values to LOGICAL data types.<br />

• If you are running several stored procedures, run them serially and process all the results<br />

from one stored procedure and close the procedure be<strong>for</strong>e you run a second one. By<br />

default, the <strong>Data</strong><strong>Server</strong> allows one active request <strong>for</strong> running a stored procedure. It is not<br />

necessary to specify the PROC-HANDLE phrase when procedures are run serially.<br />

When you run stored procedures concurrently, the <strong>Data</strong><strong>Server</strong> uses one connection to the data<br />

source per procedure. If different stored procedures attempt to update the same record from a<br />

single client’s requests, the connections could block each other or a deadlock might occur.<br />

Notes: You must define a PROC-HANDLE phrase <strong>for</strong> each stored procedure phrase that is<br />

simultaneously active. This technique provides a CLOSE STORED-PROC statement that<br />

can identify the targeted open procedure and close it.<br />

In contrast, since a stored procedure executed with the LOAD-RESULT-INTO phrase<br />

implicitly closes the procedure once the execution ends and the data retrieved is placed<br />

into temp tables, it essentially runs serially and has no use <strong>for</strong> a PROC-HANDLE.<br />

• When you create or update your schema image, the stored procedures appear in the list of<br />

accessible objects along with tables, view, and sequences. <strong>OpenEdge</strong> allows you to run the<br />

stored procedures that you create in data sources using the procedure definitions in your

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!