Category: Publish an Application

Zim supports the specification of decimal places for fields whose internal representation is in the form of integers (data types “int”, “longint” and “vastint”). This is done by maintaining the logical position of the decimal point external to the physical storage of the data. SQL servers do not do this – integer data types contain integer data only. If the data for a field has either explicit or implicit decimal places, then it must be defined with the appropriate SQL data type (DECIMAL, NUMERIC, NUMBER, FLOAT, DOUBLE PRECISION, etc.). To formalize the translation of field definitions between Zim and SQL, Zim insists that fields of data type “int”, “longint” and “vastint”, which have non-zero decimal places, also have an appropriate value (greater than zero) in the “Length” field of the Data Dictionary entity set “Fields”. The value ranges for the “Length” field are

The values specify the maximum number of significant digits that the field is required to support. This number is the sum of the number of digits to the left of and to the right of the (implied) decimal point. For example, if it is known that data values for a particular field range from 0.01 to 9.99, then in standard Zim, the definition of the field could be

Type = ‘int’ Length = 0 Decimals = 2

For SQL tables, the definition must be expressed as

Type = ‘int’ Length = 3 Decimals = 2

In SQL servers, these two numbers are generally referred to as the “Precision” (Length) and “Scale” (Decimals) for columns of data type NUMERIC, DECIMAL, and so on.

The specification of a non-zero value for the “Length” in Zim is not a concern.  For these data types, Zim ignores the “Length” value. On the other hand, for SQL tables, Zim checks to ensure that the “Length” value lies within the ranges stated above. The Zim Definition Interface uses the “Length” values to translate Zim number field definitions to the appropriate SQL definitions and vice versa. Even though an “int” value has limited support for 5 digits (i.e. up to 32767), it cannot support up to 99999 and accordingly, its real maximum precision is 4. Consider an SQL data type of DECIMAL(5,2). Such a definition can support values from -999.99 to 999.99. A Zim data type of “int” cannot support this complete range. The Definition Interface translates such a definition into a Zim “longint” data type with a “Length” of 5 and “Decimals” of 2.

To a Zim application developer, the impact of this requirement is relatively small. For all fields of type “int”, “longint” and “vastint” which have a “Decimals” value greater than zero, a “Length” value from the ranges listed above must also be specified. The “Length” value must also be sufficiently large to support the maximum expected number of significant digits for data values for the field.

Indexed Fields in WHERE Clauses

In Zim, developers use expressions in the form

WHERE clauses retrieve data in either (a) ascending or (b) descending sequence of the data values in . This technique is used instead of an explicit sort because it takes advantage of a physical characteristic exhibited by Zim. However, there is no guarantee that any given SQL server behaves in the same manner. The use of indexed fields in expressions of the above form whose sole purpose is to deliver data in a particular sequence should be avoided. Instead, an explicit sort expression should be included in the set specification.

“Unrelated” and “Complete”

The performance of Zim set specifications qualified by “unrelated” or “complete” against SQL servers can be seriously affected, if that SQL server does not provide explicit support for the outer join operation. In such cases, use the following guidelines:

• Inspect the application code to determine if any set specifications including the “unrelated” or “complete” qualifiers exist. Determine if these are functionally altered if the qualifiers were removed.
• Performance can be improved by splitting a “complete” set specification into the union of the same set specification with the “complete” removed (the normal “related” case) and the same set specification using “unrelated”.

“DATE” Data

For date type fields, Zim accepts NULL values, true date values (like 20021031, etc.) and non-date values (like -1, 0, etc.). However, SQL servers do not accept non-date values. “DATE” data types should be restricted to valid dates and NULL values to ensure compatibility. If your application uses such non-date values and it will be difficult to change it, you can use the ”mapdate” file to map date values from ZIM to SQL and vice-versa.

SET manipulation

Sets built using Zim tables are different from sets built using Zim tables connected to a SQL server. In the following example:

set executemode zimmode

find States -> StateSet

set executemode sqlmode

list StateSet

The LIST statement will raise an error because it will try to list the records existing locally but referenced remotely, which is inconsistent. The opposite is also an error.

DB2 SAM Comparisons with Constants

The following construction:

FIND MyEnt WHERE MyField = 111 OR 1 = 2

Although valid in ZIM and in other SQL servers, this construction should be avoided because it brings an error from DB2. The reason is that DB2 requires object types to be cast all the time. and DB2 (thus raising the error), .

Despite thorough testing, an application can experience operational problems. These problems can result from faulty coding or they can be environmental in origin (e.g., stemming from the interaction of the application and the operating system). In either case, the approach to troubleshooting an application uses the same three-step process:

1. Reproducing the Situation

A fundamental rule of problem-solving in any software system is that if you are unable to reproduce the problem, you are unable to solve it.

Some problems can be difficult to reproduce, but the following guidelines make reproduction simpler.

If a problem arises while you are running an application, make note of what was being done with the application at the time.

When you are ready to attempt to reproduce a problem, make the following preparations:

Back up all files.

Reproduce the external environment as closely as possible. If other processes were running, make sure they run during your test.

Try to carry out the same steps that you were performing when the error occurred. Remember to back up your files before each attempt to reproduce the error. Some problems are data dependent, and using the correct initial data can be crucial to successfully reproducing the error.

If you cannot cause the error to occur, the problem could also depend on commands executed earlier in the session. Try again, making sure to run through exactly the same steps that you did when the error first occurred.

During this phase, it is very important to make careful notes of all your actions; you want to be able to repeat, again and again, the exact situation that caused the problem. You should not be concerned at this point with eliminating unnecessary steps; you can deal with that question when you try to isolate the cause of the problem.

2. Isolating the Cause

Once a problem is reproducible, you can attempt to isolate its cause. Isolation involves eliminating potential causes until you have pinpointed exactly what causes the error to occur.

The following strategies can be used to determine the cause of an environmental problem:

Run the application on another computer system. This process helps to determine if hardware problems are involved.

Remove external processes from your system. If the problem does not recur, it could have been a result of system stresses created by these external processes, or the external processes could be interfering with your application.

Reduce memory requirements by changing various options in the configuration files (e.g., sort buffers,  maximum forms, etc.).

If possible, try changing your operating system configuration (e.g., system limits on resources, such as the number of files, number of locks, and so on) before running your application.

Try these strategies one at a time. If your problem disappears, you may have discovered its cause.

The object of the isolation process is to pinpoint the problem. For example, do not worry if reducing memory usage affects performance. If memory usage is causing the problem, at least you can trade some performance for correct operation.

3. Solving the Problem

Once you have isolated the problem, proceed with solving it.

If you have a hardware problem, components of your computer system can be repaired or replaced. Problems stemming from the operation of external processes can be prevented by ensuring that the external processes do not run simultaneously with the application. If the problem stems from memory usage, changes to the configuration files or memory allocation could be required.