Execute Stored Procedure

**NOTE: This plug-in is deprecated and no longer recommended for use for sites running on Appian 22.1 or later. The functionality of this component is available in Appian without installing the plug-in. You can use a!executeStoredProcedureForQuery(), a!executeStoredProcedureOnSave(), or the Execute Stored Procedure Smart Service in Appian 22.1 or later.**

Overview

This plug-in provides a Smart Service and Function for executing stored procedures. The Smart Service can be used to execute stored procedures that modify data. Result sets are returned as CDTs. As custom functions cannot have side-effects, it must not be used to execute stored procedures that modify data. It is only safe to use the Smart Service with stored procedures that modify data. Following SQL Statements should not be used by the stored procedures executed with the function:

  • INSERT
  • UPDATE
  • DELETE
  • TRUNCATE
  • CREATE TEMPORARY TABLE
  • SELECT... INTO (when the input target is not an input or output variable)

Key Features & Functionality

  • Works with both complex and simple data types
  • Tested with: MySQL, SQL Server, and Oracle
  • See the instructions document provided with the download for an example and how to configure
  • (New) Total row count column added to trace log
Anonymous
Parents
  • Hi James, we are seeing massive performance differences with fn!executestoredprocedure vs the Execute Stored Procedure Smart Service.  Typically, 9 seconds for the function vs 0.1 seconds for the Smart Service, when calling the same procedure. Our guess is this could be related to the Run Validation parameter not being available on the function.  Could this be the case, and if so, are there any plans to add a run_validation input on the function?  In our case (validating over 100 grid rows with a procedure), the function is not usable due to the performance issue. Any input would be great, thanks!

  • +1 on this.

    We're starting to rely heavily on stored procedures, given that the query generated by queryEntity function seems to be overly complicated with subqueries.

    Reviewing SP trace log, we can see that chunk of the SP runtime comes only from the validation. We're also starting to see performance impact on the DB itself due to the volume of the validation queries executed.

Comment
  • +1 on this.

    We're starting to rely heavily on stored procedures, given that the query generated by queryEntity function seems to be overly complicated with subqueries.

    Reviewing SP trace log, we can see that chunk of the SP runtime comes only from the validation. We're also starting to see performance impact on the DB itself due to the volume of the validation queries executed.

Children
No Data