USoft Rule Language and Table Constraints

Previous Next

See Also

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 of the (Table) Constraints 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 used by the Rules Engine.

 

For example: the two examples of constraint statements on the Statement tab illustrated below, the first in USoft Rule Language, the second in SQL, will result in identical output on the read-only SQL Equivalent tab, when the constraint is checked.

 

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.