USoft Rule Language and Table Constraints |
|
|
|
When writing table constraints, you can choose between expressing the business logic in SQL syntax or in USoft Rule Language syntax. Both are entered in the same way and in the same place, on the Statement tab or edit area of the (Table) Constraints tab or Info Window. Both are treated similarly by the constraint checker. The result of the check is displayed as SQL on the read-only SQL Equivalent tab of the (Table) Constraints window. This is the code that is actually executed by the Rules Engine. Here is a constraint example using standard SQL Syntax
Here is the same business logic expressed in USoft Rule Language Syntax
Both result in the same SQL Equivalent after you press the Check button:
The SQL Equivalents tab is useful because: •When constraints have been expressed in USoft Rule Language rather than SQL, developers must still be able to cut and paste the SQL equivalent to, for example: •SQL Command windows to check for violating records in the runtime application. •Production scripts, e.g. for upgrading an existing production database so that it complies with a new UPDATE constraint. •A batch definition context if they decide that existing constraint logic should now be treated asynchronously. •For advanced users who study USoft constraint handling, inspect Benchmark profiles, etc. the SQL equivalent is essential for a clear understanding of the USoft algorithm Developers of existing applications can continue writing SQL if they wish, and never use the USoft Rule Language syntax. It is also possible to write a mixture of USoft Rule Language statements and SQL statements within an application. See Also |
|
