Category: ZIM User Documentation

Although Zim Technology has always made the best efforts to keep compatibility between versions, technical evolution is inevitable which leads to building bridges between one existing version to the next introduced version.

A brief history of Zim Technology and its migration possibilities:

1. Zim versions up to Zim 9.00: these versions may include Zim 4.x, Zim 7.x, Zim 8.20, Zim 8.50, and Zim 9.00. They are distributed by another company and are solely based on 32-bits platforms. According to its proper documentation, old versions can be migrated to newer versions using their own migration tools. If no technical evolution is required, such Zim databases can stay in Zim 9.00 for the time needed or until Zim 9.00 is available;
2. Zim 9.10 and Zim 9.50 (and upward): these versions are far more modern releases using a true 64-bit platform being produced and distributed by Zim-X Corporation, for Windows, Linux INTEL, Linux ARM, and Androids. The migration from Zim 9.10 to Zim 9.50 is transparent and automatic which only requires running the latest version on top of the previous one. However, the migration to Zim 9.50 from earlier versions like Zim 9.00 does require a more detailed step-by-step process, described below, due to their binary incompatibility and due to the more evolved capabilities of Zim 9.50.

Conventions

. OLD DATABASE: it’s the existing Zim database requiring migration;

. NEW DATABASE: it’s a Zim 9.50 ready to accept the migration from the old database or the one after such migration.

Warning

A) Migrate your Old Database to at Least Zim 8.50

If your database is not in versions Zim 8.50 or Zim 9.00, you will need to migrate to one of them (whichever is available to you), preferably Zim 9.00. This is a requirement because the differences between very old versions of Zim and Zim 8.5 or Zim 9.00 are big, big enough to make the conversion to Zim 9.50 impossible.

To perform this migration, you will need to follow the instructions provided by these Zim versions and the documentation provided by the distributor.

B) Export Data and Database Definitions From the Old Database

Once your old database is running either Zim 8.50 or Zim 9.00, you will export all database definitions and all data from the old database using the tools and utilities from the corresponding Zim version:

1. Start ZimServer;
2. Start a ZimQTC session to get the Zim prompt;
3. From the prompt, run “ZOMENABLE” to access the ZOM tools;
4. From the prompt, run “ZOMEXPORT *” to export all database definitions;
5. From the prompt, run “ZOMDATASAVE *” to export all existing data;
6. Kill ZimServer using the option “-k”.

To be on the safe side, back up your old database again to guarantee that files created in this process are saved.

C) Clean the Old Database

Certain files need to be deleted (removed) from the old database to make room for the new one:

1. Remove all files with the name “ZIMxxxx” where “xxxx” ranges from “0000” to “9999”;
2. Remove the operating system directories identified by “ZIMxxxx.WS”;
3. Remove the operating system directories identified by “yyyyy” where “yyyyy” ranges from “00001” to “99999”;
4. Remove the operating system directories named “DCRT” and “DPSRT”.

D) Install ZIM 9.50

Using the ZIM:X Full Installer, perform its installation on your computer following the installer guidelines.

E) Start ZimServer

After Zim 9.50 was installed, start ZimServer.

F) Create the New Database

Using the administrative tool ZimAdmin, you are going to create (initialize) the new database. From this point on, this database is going to be referred to as the “New Database”.

1. Run ZimAdmin;
2. Right-click on “Zim Servers”, select “Add Server…” and then click OK on the Add Server dialog box;
3. Click on the just added server (usually “localhost:6002”) and click OK on the Login Form. A (+) will appear on the left of the server;
4. Expand the (+) and right-click on “Databases” to “Create a Database”;
5. Provide a database name, a database path (it MUST be one you just cleaned), and a database number. Click “Create”;
6. Once you get a confirmation message, you are ready to go to the next step.

G) Import the New Database Definitions

This step will import all database definitions to the new database:

1. Start ZIMQTC on the new database;
2. Run “ZOMENABLE”;
3. Run “ZOMIMPORT” to import all database definitions.

Should errors arise during the import, carefully inspect these errors and decide:

1. The errors need to be corrected immediately: In this case, you will have to restore the database backup, correct the errors and then repeat steps B, C, E, F, G, and H;
2. If the errors are minor or could be ignored for the moment, proceed to the next step.

H) Import all Database Data

Run the following steps after importing the database definitions:

1. Copy (save) the operating system directory “ZOMSAVING” to “ZOMSAVING.SAVE” which is located in the database. This copy is important; otherwise, the database data will not be imported;
2. Run “ZOMDATASAVE *” to create the structure to load the data. It will process zero records for all entity sets;
3. Remove the operating system directory “ZOMSAVING”;
4. Copy back the saved directory “ZOMSAVING.SAVE” to “ZOMSAVING”;
5. Run “ZOMDATALOAD *” to import the database data.

Warning: Zim versions up to Zim 9.00 weren’t able to correctly export data. In particular, the presence of new lines in the middle of text fields would produce errors and omissions. These errors need to be investigated and, probably, the new lines fixed before exporting the data in step E.

Another potential error is the inability to recognize entity sets per user which leads to import errors. There is no sense in exporting and exporting data from entity sets per user and these errors can be ignored safely.

I) Final Checks

The migration process to ZIM 9.50 is now completed. You may still perform the following tasks:

1. Stop ZIMSERVER with the option -k;
2. Make a backup of your new database;
3. Start ZIMSERVER again along with ZIMQTC;
4. Compile your ZIM programs if applicable;
5. Check your data and your database definitions;
6. Run your application.

Viewing User Connections

The User Connection utility lists all users connected to the selected Zim Server and provides an interface for disconnecting users from the server.

The column headers in the User Connections grid are described in the table below:

Disconnecting Users

To disconnect a user, right click on the user number and then click on Yes in the pop-up dialog

The selected user connection will be terminated and the list of connected users will be updated

Sets properties of selected objects.

Syntax

ZOMSet object specification [option..]

Options

Comments

This service has no special function of its own. ZOMSet selects the specified objects and sets any properties according to the given processing options. ZOMSet is convenient for setting object properties without doing any further processing on those objects.

Examples

The following command sets the object “Customers” to be locked.

ZOMSet Customers ;p l

The following command sets all objects that are compiled to be compilable.

ZOMSet +p ca ;p c

The following command sets the DataSave property for all objects that have the Data property set.

ZOMSet +p da ;p ds

The following example deletes the keyword “Sales_System” from all objects keyworded by the keyword “Sales_System.”

ZOMSet +k Sales_System ;k Sales_System!

Imports dictionary descriptions of objects from documents.

Syntax

ZOMImport [<option>…]

Options

Comments

This command checks the set of objects to be imported over for locked objects prior to executing. If there are locked objects to be affected, the command issues an error and exits. An object is considered to be locked if it is locked itself, or is in a locked directory. For information about setting and clearing locks, refer to ZOMSet.

This command touches any objects imported once its action has completed. This results in the object’s status and dependency information being updated. For more information, refer to ZOMTouch.

Examples

The following command imports the objects contained in the Z50 format files.

ZOMImport

The following command imports the objects in DT4 format.

ZOMImport ;f DT4

Activates ZIM products and provides information about the activated products in your system.

Syntax

ZIMACTIV [action] [serial number] [activation key] [company name]

Parameters

Comments

The ZIMACTIV utility performs various operations in regards to the current activation key or in regards to the currently activated and licensed ZIM products. Specifically, the ‘-a’ option activates the ZIM product being installed, enabling the product to run.

The ZIMACTIV utility is invoked from the operating system prompt. To be run, ZIMACTIV requires at least the action parameter; if not present, you are prompted to enter it. You are prompted for any other required parameter as well.

The company name must be entered in quotation marks if blank spaces are part of the name. Lower and upper case, as well spaces, are ignored in this parameter; the company name cannot exceed of 50 characters.

The ZIMACTIV utility has a graphical version named ZIMACTIW that runs only on Windows. The ZIMACTIV utility runs on both Windows and UNIX.

Example

zimactiv –a 12345 ABCD-ABCD-ABCD-ABCD ”My Company Name”

Indicates whether an index is to be maintained on the field.

Valid Values

As shown in the table below:

Remarks

Index is ignored for fields that belong to documents.

A time stamp indicating when it was created

Remarks

A time stamp indicating when it was created

The name of the owner of the database table on the database server if the table is not owned by the user or included in his or her schema.

Remarks

The name of the owner of the database table on the database server

The name of the database table on the database server, if different than the EntitySet name. RemoteName is normally used when there is a naming incompatibility between Zim and the database server.

Remarks

The name of the database table on the database server

Whether this Document is defined to be per user.

Valid Values

“yes” or “no” (the default value is “no”).

Remarks

Normally, Documents are located in a place pointed by its FileName field. However, with DocPerUser set to “yes”, the corresponding document has the following behaviour:

. They are handled by the current session and their information is lost after the session finishes;

. They are located in the $WorkPath directory;

. They don’t exist at the beginning of the session and must explicitly be generated on the fly by the application.

Note: In previous versions of Zim, per user Documents were indicated by the “)” mark in the FileNome of the document. In Zim 8 and up, the DocPerUser field must be set to “yes” and the “)” mask must be there as well for compatibity issues. In future versions, this mark will be removed.