Category: ZIM User Documentation

The Zim “COMPILE” command is capable of compiling application programs in one of the same three modes as described for program execution:

The default mode of operation is SERVERMODE. For all database servers except Zim Integrated Server, SERVERMODE and SQLMODE behave identically. In SERVERMODE, a Zim client accessing tables on Zim Integrated Server sends Zim commands to the server instead of SQL commands which greatly improves performance. In SQLMODE, the ZIM client determines the optimal SQL syntax to send to the server by inspecting the values for “EntType” or “RelType” in the Object Dictionary for the tables specified in the command.

Therefore, for each EntitySet or data relationship, either standard Zim compiled code or, ZIS/SQL database specific compiled code is generated depending upon the “EntType” and/or “RelType” values. In addition, when compiling under SERVERMODE or SQLMODE, if at least one command causes an SQL reference to be generated, then the compiler flags the entire compiled program file as compiled for an SQL database. If there are no ZIS/SQL references generated, then the compiled file is flagged as compiled for Zim. You do not have to be connected to the SQL server to compile in standard Zim mode.

The mode in which the Zim compiler operates may be set by the command:

SET COMPILEMODE [ SERVERMODE | SQLMODE | ZIMMODE ]

where SQLMODE is the default setting. For example, if the command:

set compilemode zimmode

were executed, then the Zim “COMPILE” command would revert to generating standard Zim compiled code and would also flag the compiled program file as being compiled for Zim. All members of the Zim product families can execute such compiled programs.

The “SET COMPILEMODE” command is ignored by the Zim runtime products.

The application is compiled using the “compilemode” option “sqlmode” and conversion to a Zim Client-Server application is complete.

If the application is to be developed for execution against a pre-existing SQL server database, then the Zim application should be compiled using the “compilemode” option “zimmode” to test the application for functionality and performance. Then the application can be compiled using the “compilemode” option “sqlmode”. If the application is being compiled in the default “sqlmode” with the sqlcompile setting “on”, then you must be connected to the SQL server.

In order to access relational databases, Zim client-server generates SQL statements. You can see the statements generated by setting SQLTRACE on. Statements are generated when Zim statements containing references to SQL tables are parsed, compiled, or executed interpretively. Previewing the SQL statements generated provides an insight into the type or amount of work the database is going to be doing. This option is set using the command:

set sqltrace [on | off]

The default setting for SQLTRACE is OFF.

Zim is capable of executing database commands in either of these three modes:

The default mode of operation is SERVERMODE. For all database servers except Zim Integrated Server, SERVERMODE and SQLMODE behave identically. In SERVERMODE, a Zim client accessing tables on Zim Integrated Server sends Zim commands to the server instead of SQL commands which greatly improves performance. In SQLMODE, the ZIM client determines the optimal SQL syntax to send to the server by inspecting the values for “EntType” or “RelType” in the Object Dictionary for the tables specified in the command.

The mode in which Zim operates may be set by the command:

SET EXECUTEMODE [ SERVERMODE | SQLMODE | ZIMMODE ]

where SERVERMODE is the default setting. For example, if the command:

set executemode zimmode

were executed, then Zim would revert to executing standard Zim code. If the program had been compiled in SQLMODE, it would revert to interpreting the program source file but issue error and warning messages.

Zim generates SQL statements to access entity sets and relationships that are stored in relational databases. To execute these statements (i.e. your application), you must be connected to the relational database. In order to support “off-line” development Zim enables you to turn off SQL statement generation, in effect generating standard Zim code. Zim ignores “EntType” and “RelType” and considers everything to be under Zim’s control. This enables you to develop and maintain applications without connecting to the database. In fact, development can proceed independent of the particular database vendor.

A dynamic configuration setting called "block factor" can be used to tune performance. This factor is the number of records retrieved by Zim each time it fetches records from the database. The larger the number, the fewer times Zim has to query the database, and the more time it takes to retrieve a block. So, the number must be adjusted to an appropriate value and not one that is arbitrarily large.

Continue reading “Block Fetching”

The “SET SQLCOMPILE” Command

Zim is designed to take advantage of many characteristics of a given SQL server. Many SQL servers provide compile time facilities to increase performance at runtime. A compile time option enables you to control when the database server does certain compilation functions such as statement parsing. If SQLCOMPILE is OFF, then these functions are performed at Zim’s runtime. If SQLCOMPILE is ON, these function are performed as Zim compiles the application, if possible. This option is set using the command:

SET SQLCOMPILE [ ON | OFF ]

The default setting for SQLCOMPILE is OFF.

In order to take advantage of these facilities, you must be connected to the SQL server at compile time. If this option is turned off, all work is done at run time and you do not have to be connected at compile time.

Different applications being compiled against the same SQL server database can have programs with the same name (i.e. “MAIN”). To avoid conflicts that can arise when compiling several applications against the same SQL server database, each application should be flagged with a unique identifier. The “config.zim” entry is

SQL DATABASE NAME xxx

where “xxx” is a three-character ID. Zim makes use of this ID when compiling. It should be noted that SQLCOMPILE can be turned on or off for a single statement if desired.

All SQL servers require that some type of connection be established between a client program and the server before any database operations can be attempted. In Zim, a connection between a Zim application and an SQL server is established by the “CONNECT” command and removed by the “DISCONNECT” command.

During the execution of any Zim application, a CONNECT command must have been executed prior to the execution of any Zim command requiring database operations to be performed by the SQL server. Connections can be multiple or single as explained below.

Single Connections

When SQL database servers are accessed one at a time, a connection is always followed by a disconnection. Example:

connect to “JDBCSAM” using (“SalesDB”, “sqlserver”, “admin”, “”, “1422”, “172.16.20.33”)

…

disconnect from “JDBCSAM”

…

connect to “JDBCSAM” using (“Marketing”, “oracle”, “scott”, “tiger”, “1501”, “www.mycompany.com”)

…

disconnect from “JDBCSAM”

…

Notice that each CONNECT statement is followed by a DISCONNECT statement. In the above example, the first connection is different from the second one but it can be the same as well.

Multiple or Concurrent Connections

In this scenario, more than one connection is established and maintained at the same time without an intervening disconnection:

connect to “JDBCSAM” using (“SalesDB”, “sqlserver”, “admin”, “”, “1422”, “172.16.20.33”)

connect to “MYJDBC” using (“Marketing”, “oracle”, “scott”, “tiger”, “1501”, “www.mycompany.com”)

…

disconnect from “MYJDBC”

disconnect from “JDBCSAM”

Now, the second connection is performed not to JDBCSAM anymore but an alias to it called MYJDBC. The reasoning behind this difference is that all ZIM objects need to reference a specific type of object (for Entity Sets, it is the EntType; for Relationships, it is the RelType and so on) and Zim needs to know which object belongs to each type.

The aliases are defined in the “zimalias.zim” configuration file as described in the Servers Alias Configuration File.

Obviously, an alias could have been used in the example for single connections as well.

If you are developing a Zim application to run against an existing SQL database, you must create an equivalent representation of that data in Zim. Zim’s definition interface translates SQL definitions into equivalent definitions in Zim.

The mapping of SQL tables to Zim EntitySets or data relationships is straight-forward. A Zim developer must first establish a clear understanding of the characteristics of each table in the SQL database. Do this by examining the SQL statements (in particular, the join conditions of “select” statements) in existing application code to successfully identify the relationships relevant to the database.

SQL tables that exhibit the same properties as Zim EntitySets (i.e. contain data about “things” only) can be mapped directly to Zim EntitySets. Tables that appear to contain information representing interactions between other tables are candidates for mapping to either data relationships or EntitySets. In Zim, a binary data relationship “r”, defined between the EntitySets “e1” and “e2”, can be decomposed into an EntitySet called “e3” and two non-data binary relationships “r1” between “e1” and “e3” and “r2” between “e3” and “e2”. SQL statements in existing application code (in particular the join conditions of “select” statements) should be examined to identify potential non-data relationships and the relationship conditions for all relationships.

If you have developed an application in Zim and want to maintain a portion of the data in an SQL database, the definitions of those objects must be maintained in the SQL database as well as in Zim. Zim’s SQL definition interface translates Zim definitions into equivalent definitions in the SQL server environment. Refer to Importing and Exporting SQL Definitions topics. An EntitySet in the E-R model maps directly to a table in the relational model. Thus a Zim EntitySet maps to an SQL table with the same field (column) structure. Relationships, however, are explicitly represented in the E-R model and implicitly in the relational model. A Zim relationship with no fields is not represented in a relational database. Zim generates SQL join statements when the relationship is referenced. If a relationship is defined to own fields (a data relationship), then the relationship maps to a table in the SQL server environment with the same field (column) structure. The associated relationship condition is handled in the same manner as for relationships without fields – that is, it contributes to SQL join conditions in the generated SQL statement(s).

If the Zim application being developed is based on an existing SQL database, then the Zim definition interface needs to be executed in order to import the definitions of the relevant tables from the SQL server and populate the Zim data dictionary so that the application can be developed.

Conversely, if the Zim application has been developed, but the database is not already resident in the SQL server, then the Zim definition interface would be invoked to export the Zim EntitySet and data relationship definitions to the SQL server. For some SQL servers, this requires a new database on the server. This is accomplished using a utility program/facility provided with the SQL server.

The Zim definition interface only imports and exports definitions. There is no facility to keep the Zim definitions and the SQL servers definitions in sync after they have been imported or exported. Any changes to definition in one must be made explicitly in the other. Failure to do so leads to unexpected results and errors.