OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
RDBMS Stored Procedure Details<br />
Overview<br />
3–2<br />
From the viewpoint of an ODBC-compliant data source, a stored procedure is a predefined<br />
procedure or set of statements or program that is defined <strong>for</strong> a specific data source according to<br />
that data source’s rules. By executing the stored procedure, you execute these statements or<br />
programs without having to enter their individual statements or code at each execution.<br />
Note: This chapter uses the phrase RDBMS stored procedure and stored procedure<br />
interchangeably.<br />
Enhancements to stored procedure techniques also allow you to extend your code in new ways<br />
and effectively employ more ABL features and functionality. For example, you can retrieve data<br />
from a <strong>for</strong>eign data source through a stored procedure and load this result set into a temp-table.<br />
Also, this technique is especially useful if you elect to further manage and manipulate your<br />
result set using Pro<strong>Data</strong>Set capabilities.<br />
Stored procedures can allow you to improve your dataserver’s per<strong>for</strong>mance because they utilize<br />
the <strong>for</strong>eign data source’s native capabilities. Stored procedures can be an efficient, productive<br />
approach to obtain data from a <strong>for</strong>eign data source or execute native business rules and<br />
procedures. In general, using stored procedures can help reduce network traffic, promote better<br />
per<strong>for</strong>mance, and improve response time because the server-side processing of the stored<br />
procedure can be accomplished without sustained communication with the client; once this<br />
processing is completed, the server returns the data results to the requesting client.<br />
The first task to effectively employ any stored procedure technique or approach is to determine<br />
what in<strong>for</strong>mation you want to receive or process you want to run. Once you know your data<br />
requirements, you can proceed to define the stored procedure details.<br />
Note: A complete discussion of creating and using native stored procedures is beyond the<br />
scope of this chapter. For this type of in<strong>for</strong>mation, see your <strong>Microsoft</strong> <strong>SQL</strong> <strong>Server</strong><br />
documentation.<br />
Defining native stored procedures to ABL<br />
The first time you run a stored procedure, the data-source management system creates an<br />
execution plan <strong>for</strong> it and stores the plan in the database. The next time you run the stored<br />
procedure, it runs the precompiled procedure, assuming it is still cached in the database. This<br />
makes access to the database quicker and more efficient than when you access it with new<br />
queries each time.<br />
The <strong>Data</strong><strong>Server</strong> allows you to use ABL to run native MS <strong>SQL</strong> <strong>Server</strong> stored procedures. All<br />
pre-defined stored procedures initiated on behalf of the MS <strong>SQL</strong> <strong>Server</strong> are executed from<br />
within ABL, using the RUN STORED-PROCEDURE statement. You define specific ABL language<br />
elements to the RUN STORED-PROCEDURE statement to match the profile or signature of your<br />
native stored procedure. You can also provide additional ABL statements subsequent to the RUN<br />
STORED-PROCEDURE statement to handle result sets from stored procedures.
Change language