Standard COBOL stored procedure parameters (arguments) use COBOL data types. SQL CLR stored procedure parameters use .NET data types. To successfully run a COBOL stored procedure in a SQL CLR environment, its input parameters must use .NET data types when the stored procedure is invoked, and its output parameters must also use .NET data types when it returns to the calling application. You have the option to provide
Enterprise Developer with COBOL stored procedures that use either COBOL or .NET data type parameters. Which option you choose might depend on several factors. Consider the following to help you determine the best option:
COBOL Stored Procedures with .NET Data Type Parameters
Providing COBOL stored procedures that use .NET data type parameters can be the correct option depending on your COBOL application.
- Advantages
-
- If you are creating new stored procedures, you can use OpenESQL Assistant to automatically generate the code with .NET data type parameters. For this option, generate the stored procedure from OpenESQL Assistant and then add its artifacts to your
Enterprise Developer project as existing SQL CLR objects. For details, see the
Stored Procedures sub-topic of the
Using OpenESQL Assistant section in this documentation.
Note: While not necessarily an advantage or a disadvantage, you also have the option to manually code new SQL CLR objects using the editor in
Enterprise Developer. New manually coded files are created as part of your
Enterprise Developer project and do not require any advance preparation other than determining how you want to code data type parameters. See
SQL CLR Integration Process for details.
- No SPD file or wrapper program is required to successfully execute the COBOL stored procedure with your COBOL application.
- Disadvantages
-
- If you have existing COBOL stored procedures that use COBOL data type parameters, you must manually edit the code and change them to .NET.
COBOL Stored Procedures with COBOL Data Type Parameters
Similarly, providing COBOL stored procedures that use COBOL data type parameters can be the correct option, again depending on your COBOL application.
- Advantages
-
- This is a convenient option if you already have COBOL stored procedures and you need to migrate them to SQL Server. In this case, you can use your existing code as is.
Note: While not necessarily an advantage or a disadvantage, you also have the option to manually code new SQL CLR objects using the editor in
Enterprise Developer. New manually coded files are created as part of your
Enterprise Developer project and do not require any advance preparation other than determining how you want to code data type parameters. See
SQL CLR Integration Process for details.
- By supplying a Stored Procedure Definition (SPD) file,
Enterprise Developer does the COBOL to .NET conversion for you using a generated COBOL wrapper program. See
COBOL Wrapper Programs for details.
- You can pass COBOL group variable names by defining parameters in the SPD file. For details, see
Stored Procedure Definition (SPD) File.
- Disadvantages
-
- This option does require the additional step of creating an SPD file and using a COBOL wrapper program around your stored procedure. See
COBOL Wrapper Programs and
Stored Procedure Definition (SPD) File for more information.
