 |
|
|
 | Database Application (SCHEMA) | Application (SCHEMA) Export and Distribution |  |
602SQL includes interactive design wizards for simple development of individual application objects (tables, queries, domains, sequences, transports, and diagrams). The integrated text editor is used for developing procedures and triggers.
Each object created using the Developing Client can be validated (check for syntax errors). Stored procedures and triggers may also be debugged using the built-in debugger and profiled using the internal profiler.
The SQL console window is available for the execution of ad-hoc SQL statements. Tools are also available to enter input variables and check output variables to check procedure execution.
Logs can be defined to trace situations or operations with specific objects. The Monitor window and Trace tab are used to define the contents of the log. You can also watch and control many other server operations here.
Application components go through many changes during development, therefore temporary inconsistencies may occur. For example, when a column is removed from a table and another column is added to the table, the query working with the removed column will be inconsistent, until the definition is corrected.
If one should strictly obey the SQL standard, all inconsistent objects should be deleted. 602SQL allows temporary inconsistencies during the application development to exist. 602SQL contains tools that recognize inconsistencies and will warn you about them.
Using the Validate syntax command from an application pop-up menu, you can execute the syntax check for all objects in the schema. All objects that contain a problem will be displayed in the Output window.
Database tables can be used during development even when an error occurs in the default value of a column, internal integrity constraint or trigger. These errors are called errors in background objects. A developer may trace these errors to a log and learn more about the application inconsistency.
In 602SQL, database objects can be used and modified at the same time. When an object is modified, the new version is used in most cases.
However, there are situations where an object version inconsistency may occur. Let us assume that procedure A is calling procedure B. One client is executing procedure A on a server. At the same time, another client modifies procedure N (e.g. adds a new parameter to the header). When procedure A calls procedure B, the action cannot be performed since the parameter count is not valid. The following error will occur: OBJECT_VERSION_NOT_AVAILABLE or "Object modified".
If procedure A was called after the modification of procedure B, the error would have been detected on compilation of procedure A and the procedure itself would have not been executed at all. The OBJECT_VERSION_NOT_AVAILABLE error occurs when an object referring to a modified object is used. Another example of this situation is a modification to function F at the same time a table that is calling function F inside the integrity constraint is used.
If this error still occurs, you must restart the server.
You can open an explicit transaction from the client developer interface. However, it cannot be guaranteed that this transaction will survive" the interactive work when developing and using an application. It is probable that the next action will cause a default rollback or commit and the transaction will be terminated.
| Database Application (SCHEMA) | Application (SCHEMA) Export and Distribution | |