Categoria: ZIM-X Basics

Errors generated during the Zim Server Connectivity activity can be checked via the system variables $SQLErrCode and $SQLErrMsg. The first one contains the error number and the second one the message text corresponding to that error number.

When developing client-server database applications, it is important to consider the location of the data. Any data under the control of the database server contributes to both the load on the network as well as load on the server machine. Because of this, it is important to analyze the data associated with a given application and determine the best location (or locations).

Static data, or data that does not change, can be duplicated and distributed over the client workstations to reside under Zim control. This type of data is typically part of the application. A table of help screen text messages is an example of static data that can (or should) be located on the client workstation.

Data that changes on a monthly, weekly, or even daily basis can be located on both the client and server workstations. An application can down load this data (or part of it) to a local copy at an appropriate time. The single server copy would be updated as required and client workstations would pick up any updates automatically.

Finally, there is dynamic shared data that resides on the server and is shared by the client workstations. This type of data resides under the SQL database’s control and be accessed and manipulated from within Zim.

In Client-Server applications, you do not have to do anything special to access or manipulate data stored in the SQL database. The data definitions of objects under Zim’s control and the data definitions of objects not under Zim’s control are exactly the same. To an application, Zim manipulates both in exactly the same way.

The development of a Zim Client-Server application can be performed in isolation from the SQL database; it can in fact take place on an entirely different computing platform. Zim does not have to be connected to the server through the development phase. This “off-line” development capability eliminates the heavy load that can be placed on SQL servers by development activities.

In order to access SQL database tables, Zim must have a definition of the table. The table must be defined in two places: in Zim and in the SQL database. EntitySets and relationships are flagged as being under the control of Zim or under the control of the SQL database. The definitions of those EntitySets and relationships under control of the SQL database are either exported to the SQL database or imported from the SQL database. You must ensure that the definitions in Zim and the SQL database are compatible. Zim’s SQL definition interface provides the means to easily import and export definitions.

Figure 1

In Figure 1, the table “Customers” is defined both in Zim and in the SQL database. If “Customers” is defined as a Zim EntitySet or if Zim is running in ZIM mode, then all references to customers are directed to the Zim EntitySet. If, however, “Customers” is defined to be an SQL table and Zim is running in SQL mode (the default), then all references to customers result in the generation of the appropriate SQL code which is sent to the SQL database.

Zim requires that each EntitySet and data relationship to be managed by the SQL database have at least one unique index defined for it. The unique index is a primary key for the SQL table to which the EntitySet or data relationship corresponds. A primary key is necessary to directly access any record (row) of any SQL table. It does this by generating select statements which specify values for the primary key column(s) of the table. For more information, see Primary Keys.

Zim supports two types of transactions: implicit and explicit. An implicit transaction is associated with each individual Zim command that accesses the database in some manner (either read/only or read/write). When the command ends, all locks that were acquired are released and any database updates are committed to the database. If the command fails (e.g. a deadlock condition), then Zim automatically removes any partial updates and releases all locks.

Explicit transactions are provided in order to support database updates associated with multiple database access commands that must either be all committed or all removed as a single “logical unit of work” (or “logical unit of recovery”). An explicit transaction is initiated by the command “transaction” and ended either by the command “endtransaction” (that commits any database updates) or by the command “quittransaction” (that cancels any database updates). Both commands release all held locks. Should any database access command inside an explicit transaction fail (e.g. by a deadlock condition) then all partial updates to that point are removed and all held locks are released.

Zim supports this “transaction” functionality against an SQL server database.

Zim application programs can be compiled in ZIMMODE, SERVERMODE, or SQLMODE depending the type of the data dictionary objects used (fields EntType, RelType or DocType). See details in the Zim command SET COMPILEMODE.

Zim applications can operate in ZIMMODE, SERVERMODE, or SQLMODE by means of the use of the command  SET EXECUTEMODE which controls the way an application runs.

There are two ways of tracing the activity of the Zim Server Connectivity:

1) At the client side: when accessing a remote database, Zim translates Zim commands syntax into an appropriate syntax for execution on the remote server. In general, Zim commands are executed through a combination of processing at the server (or at several servers) and within the application itself. The syntax being generated for the server can be seeing by using the command SET SQLTRACE. With this option on, all Zim commands display their corresponding syntax that is going to be sent to the server;

2) At the server (remote) side: Zim or SQL commands effectively sent to the remote database can be logged and viewed in the file zimsvlog.zim by means of the configuration option “server request tracing yes”.  

The use of Zim Server Connectivity in an application has an impact on performance. There are several factors to consider:

1. Client-server configurations introduce additional overhead that is not present when an application is using a local database. The most obvious overhead is that every database request must be translated into a server request, the request must be transferred to the server (which can introduce communications delays), and the returned data must be transferred back to the client. If this overhead was introduced only once per Zim command, it would not be too serious a concern but this is not always the case. For example, the Zim command

change all Customers let Discount = 0.10

results in a single server request being sent and the overhead is very low.

On the other hand, if Customers is an entity set managed by a remote database and Orders is an entity set managed on the client side, the Zim command:

change all Customers Issue Orders let Discount = 0.20

results in each Customer record being retrieved from the server, joined with any Orders at the client, and then an UPDATE request being sent back to the server. Here the server overhead is introduced hundreds or even thousands of times.

2. Zim commands that are executed in integrated server mode result in a single server request with low overhead. Commands that handle a combination of local and server data or data from different servers cannot be executed in integrated server mode.
3. The use of Zim Server can also improve performance and throughput. For example, a multi-user application might be running on a small UNIX machine. If this application was moved to client-server where the server was placed on a larger high performance UNIX system, then overall performance is likely enhanced.
4. The use of the configuration option “server request tracing yes” results in lots of printing and might introduce some delays in the command execution.

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).

Zim Server has many possible configurations. multi-user single-user  

Zim Integrated Server

Usually, the Database Agent process accesses a local Zim database (local refers to relationship to the server). The Database Agent process is started much like any version of Zim: it has its own working directory; it uses Zim directory files to look up object names used in client requests; it uses areas.zim and dirs.zim in the standard way; and so on.

While a Zim database is being accessed by one or more Database Agent processes, it can also be accessed directly from a local multi-user Zim application, such as from a full Zim system, a query runtime system, or a runtime system.

When the Database Agent process receives a request to access a specific table, that table name is looked up in Zim directories. If the table is defined to be managed by another server (e.g. Oracle or another Zim Integrated Server), the Database Agent process uses the appropriate Server Access Module (SAM). For example, a Zim application running on Windows could access a table being managed by Zim Integrated Server running on an IBM platform. That server, in turn, could detect that the table is, in fact, managed by another Zim Server on an HP platform, so the request would be passed to the HP one. The Zim Server there could detect that, in fact, the table is really managed by Oracle running on a Linux environment, and so the request would be passed (by means of an Oracle SAM running on the HP) to Linux. See the diagram below.

Example of Possible Server Configurations

Client

A client process can connect to one or more Zim Servers at the same time. However Zim Database Agent processes (which can be on different machines) do not provide support for distributed deadlock detection or distributed transaction commit. As a result, two clients can deadlock each other. In addition, if a transaction updates information across more than one server, failures at either server or in communications could result in the transaction not being completely committed.

Because of Zim’s multi-server capability, a Zim application can concurrently access a local Zim database (local to the application), zero or more Zim databases managed by Zim Integrated Server, and zero or more third party databases (such as Oracle, DB2/2, etc.).

Example of Other Client Configurations

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.