I'd like to see records added to the stored procedure language of SQA. One of the biggest complaints from my developers when moving code from Oracle to SQLA is the lack of records. With Oracle you can create records in two ways:
All three of the above will declare 2 records, one based upon a type that was created, the next based upon the table structure, and the third based upon a cursor result set. Access to the variables is based upon dot notation.
One of the nicest features is that you can fetch into a record. This reduces the number of variables to type up and also allows you to add columns to cursors without needing to find and update all the fetches. An additional nicety is that if you change your tables to increase the width of columns the definition within your code is automatically increased as well. Although this can cause other side effects so still needs to be watched carefully. The number of parameters you need to send to procedures can be reduced dramatically as well with records, which may or may not help with performance. |
This is surely no trivial feature (both implementing and using). But when I think of the long lists of variables declared in nested procedure levels a record would come in handy. Of course there has to be some calling convention to pass records as references, avoiding the need to copy all members to and fro. There seems to be something like that already silently working for long varchars. |
FWIW, that request has been realized with SA 16 - confine the ROW (and ARRAY) data type constructors. I'm not aware of the ORACLE implementation - so I guess the exact usage and syntax will differ in SA. |
With respect to cursors with lots of fetch variables, SQL Anywhere's ANSI-compliant FOR statement might be used to reduce much of the discussed overhead with long variable lists. It also omits the need for explicit fetch statements and as such, can be schema-agnostic as long as columns are only added but not re-named or deleted (unless they aren't used in the loop). For example:
When you prefer particular variable names (e.g. to distinguish them from column names), you can use according alias names in the select list, such as
Of course, the FOR statement doesn't help to package long variable lists that are to be passed to different procedures so this is only a partial solution. |