The server is designed to accommodate the broadest possible range of SQL applications. Accordingly, the API encourages connector programs to generate SQL requests during run-time rather than rely on predefined, hard-wired commands. The major technical implication of this design philosophy is that servers bind and execute SQL requests dynamically.
In contrast, ISO SQL requires that SQL requests be hard-coded in the application programs that invoke them. Although the server, with its dynamic orientation, is not ISO-compliant in this sense, it adheres very closely to the standard. The syntax of every statement is patterned directly on the ISO SQL model and most statements are exactly the same.
SQL Translation Services has what might be called a "read-mostly" emphasis. It supports full ISO SELECT syntax and semantics. But certain features of SQL-CREATE TABLE, CREATE VIEW, INSERT, UPDATE, and DELETE-to be specific, are subject to restrictions. The lifetime of a table or view, for example, is limited to a single session, and a table or view manufactured by one user is not generally accessible to any other user. Finally, all database objects that come into being through the translator mechanism are managed by the server.
Such restrictions are in line with the read-mostly emphasis of SQL Translation Services. A table is regarded as a temporary repository for information extracted from a production database rather than an integral part of that database. SQL Translation Services invites the user to create one or more tables, populate them with data selected from production databases, and query them in the knowledge that they will disappear at the close of the session.
| iWay Software |