User-Defined SQL Functions

Previous Next

See Also

USoft Developer supports the use of user-defined functions in constraints, batch jobs, decisions, etc. This functionality can be used on RDBMSs with only few native functions, as well as, for example, by Oracle users, to call PL/SQL functions directly.

The syntax is:

RDBMS.[$$RDBMSUSER$$ | $$RDBMSOWNER$$.]<user-defined function>([<argument> [, <argument> ...]])

<argument> ::= { <expression> | LITERAL STRING }

<user-defined function> ::= IDENTIFIER


· "RDBMS" is a keyword that indicates that a user-defined function is specified.


· "$$RDBMSUSER$$" is the current RDBMS user. This is a pseudo column that is not specific for user-defined functions and can be optionally used.


· "$$RDBMSOWNER$$" is the current owner of the application. This is a pseudo column that is not specific for user-defined functions and can be optionally used.


· "<user-defined function>" is an identifier for the user defined function.


· "LITERAL" is a keyword.


· "<expression>" is any expression supported in SQL.


· "IDENTIFIER" is any name with the exception of keywords and reserved words. Reserved words are words that are reserved words in the context of the SQL parser. This may differ for the various RDBMSs. Note that column names, table names and function names are all IDENTIFIERS to the SQL parser. So this will only prevent you from using words like SELECT and FROM which have a special meaning to the SQL parser.


· "STRING" is a single-quoted string.

USoft will pass the user-defined functions through to the RDBMS. If LITERAL is used, USoft will pass the contents of the string through to the RDBMS. For the following statement, for example:

rdbms.EXTEND(SYSDATE, LITERAL 'hour to minute')

the RDBMS statement will look like:

EXTEND(SYSDATE, hour to minute)

Please take note of the following aspects and guidelines when using this feature:

· The USoft SQL parser is case-insensitive, so keywords like LITERAL and RDBMS may also contain lowercase characters.


· LITERAL can only be used in the arguments of a user-defined function. It cannot be used in normal expressions or as the argument of other functions. The SQL parser will not allow you to do so.


· LITERAL should only be used for those arguments that have an exceptional syntax that is not supported by the USoft SQL parser. LITERAL should only be used where you cannot do with normal expressions.


· The string used with the LITERAL keyword is not analyzed by the rules engine. So, if you use column names in the string, the rules engine will not be aware of that. For example, when used in a constraint, the rules engine can not use that information to determine when to evaluate the constraint. Columns used in other arguments can be recognized by the rules engine.

If you want to specify a string within the LITERAL syntax you can use the string escape sequence. For example:

LITERAL 'keyword ''my string'''

will result in:

keyword 'my string'

· The USoft SQL parser will not perform any checking on the user-defined functions or the LITERAL arguments. These will be passed through to the RDBMS. If anything is wrong, the end-user will get a runtime error. The USoft SQL parser will not notice these errors.