Home/ Questions/Q 3843864
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T15:59:55+00:00

We have an internal application which generates ASP code to call Oracle and SQL

  • 0

We have an internal application which generates ASP code to call Oracle and SQL Stored procedures.

This application queries the respective data dictionaries, and is able to determine parameter information, and construct the call accordingly. A developer using this application can include the code in their project, and pass data to it using a dedicated DTO (also generated by the app).

In Oracle, we can happily determine if a recordset is returned, as we use refcursors, and these show up in the parameter list on the Oracle DDL.

This not the case for for SQL Server. Currently the developers themselves have to know whether the SQL Server SP returns a recordset, and tick an option on the interface. This, in turn, determines whether the code generates contains ExecuteQuery or ExecuteNonQuery.

While this is ok, it would be nice no to have that option. Is there a way that his can be determined programatically by inspecting the data dictionary or by some other means?

Thanks,

James

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can inspect the resultset format produced by a SQL statement using SET FMTONLY [ON|OFF].
    MS tools such as Reporting Services use this technique to determine the structure of output resultset(s).

    This is tricky for stored procedures because the number and structure of the output result sets could vary depending on the input parameter values. This is difficult to get around – even with strict coding standards – if your procedure code is non-trivial.

    I’ve seen other approaches (such as using extended parameters), but none are infallible. Having the developers tick a box may be the best solution.

    • 0