Categoria: ZIM User Documentation

text font name name

where name is the name of the font used to display text in the application window (BACKSCREEN).

– Valid Settings

name = alphanumeric entry up to 64 characters

Important Notes Before Running Zim 9 Applications

. Existing databases: Existing Zim databases (that is, pre-version 8) cannot be run directly in Zim 9 but must be first converted to Zim 9 (pre-Zim 9 databases contain less information in their data dictionary and will not be properly understood by Zim 9 and will probably result in corruption). You must follow the conversion steps described in Migrating to Zim 9 documentation;

. Zim executables: Zim 9 no longer has ZimMU, ZimRT, ZimRTMU, ZimQRT, ZimQRTMU, ZimPRT and ZimPRTMU;

. Zim architecture: Zim 9 has a Client/Server architecture, with Zim Server being the server and the clients being Zim (for Windows and Unix) or ZimTC (for Windows only). See steps below on how to run Zim 9 applications;

. Release Notes: All Release Notes for Zim 9 must be read in the Zim help file as many changes were introduced in Zim 9. However, all existing applications remain compatible.

. Unix Painter: The Zim 4.2 Painter for Unix is not available in Zim 9 because the file structure in Zim 9 is different than previous versions of Zim.  A new cross-platform Painter is being developed and will be available soon. Until this new painter is released, you can use one of the following options for painting forms on UNIX:

1) Use the 7.x screen painter.

2) Develop your user interface from your previous version of Zim, and when completed, export the forms definitions to Zim 9.x.

. Configuration Files: Configuration files have significantly changed for simplification (there are no more config.zim, config.db, config.srv and config.def) but rather zimconfig.zim (for the database) and zimconfig.srv (for the server). Refer to the section Types of Configuration Files for more information;

. Work Path: Zim 9 changed the way work paths and database paths are handled in a much simpler way (there is no config.zim anymore). Refer to the documentation of zimdb.zim, Work Path and User Name Directory.

Create your zimdb.zim File

Before you do anything in Zim 9, you must create your zimdb.zim file which is a configuration file that tells Zim Server which databases will be processed.

The chapter Zim Databases Configuration File describes all the details concerning the creation of this file. In essence, entries like this one:

22; Example; /usr/zim/example

tell the Zim Server that the database called Example is located in the operating system directory /usr/zim/example and has the number 22.

Create the Basic Zim Server Configuration

Zim Server always read a configuration file called zimconfig.srv to adjust internal structures and parameters in order to accommodate the size of shared memory and related functionality.

Of significant importance in order to start Zim Server, you can address the following parameters:

maximum databases           5          % tells how many databases will be handled
maximum tables             500          % how many tables there are in all databases
maximum users              100          % how many users will be connected to the databases

scatter table entries  100000          % how many blocks users will use simultaneously

scatter table links       50000          % maximum size of a single transaction in blocks

The above numbers are just suggestions for this configuration file. Evidently, Zim Server can be started with default parameters but, depending on the requirements, Zim Server might detect a lack of resources later.

After running your Zim applications for a while, you might need to fine tune Zim Server. This is described in detail in the section titled Performance Tuning.

Start ZimServer

You can now start ZimServer (the chapter ZimServer gives more details on this).

If everything is alright for ZimServer, it will start with a proper message. Otherwise, it will say that there is  an error and the file zimsvlog.zim (located where Zim was installed) will describe what was the problem that prevented Zim Server from starting.

Once Zim Server has started, you can run a Zim session, described in the following steps.

Run your Zim Application in Zim 9

If your Zim application was originally written in a previous version of Zim, this database must have been converted first to Zim 9 in order to be run in Zim 9. See the above notes and how to convert a database in the chapter Migrating to Zim 9.

Normally, a Zim client session does not need any specific configuration because the default configuration is good enough for all Zim applications. However, if you need to configure something very specific for a specific database being handled by Zim Server, you can create a zimconfig.zim file as described in Database Configuration File. One such situations is when the number of Zim directories exceeds the default number of open Zim directories.

On Unix, you always develop and run using the ZIM executable as described in the ZIM documentation.

Both on Windows and Linux you develop your application using the ZIMIDE utility but you run your Zim application using the ZIMQTC executable.

Usually, these commands are enough to run ZIM or ZIMTC:

zimqtc -n example

where example is the name of the database you want to run as provided in zimdb.zim for Zim Server.

Stop Zim Server

Normally, Zim Server can be left running. If needed, refer to Zim Server documentation on how to stop it.

Behavioral Differences Between Zim 7 and Zim 9

Zim 9 was built to behave exactly the same way previous versions of Zim were behaving in terms of the Zim applications perspective. However, small differences may happen in the following circumstances:

a) Zim Windows with AutoSize attribute set to off might present scroll bars if the forms being displayed are bigger than the size of the window. Normally, Zim executables up to Zim 7.11 wouldn’t present the scroll bars. ZimQt Client, on the other hand, follows the Microsoft Windows standards and present the scroll bars.

To solve this situation, you can paint again the form, this time checking the AutoSize attribute.

b) Input and Output Masks in FormFields: if there is either an input or an output masks in FormFields but its length is smaller than the real length of the field, than a FORM DISPLAY will present the masking characters “?” filling the remaining of the field.

We welcome your feedback. Please send any general or specific comments to:

What is Zim?

Zim is a fully integrated, full-stack enterprise software program designed to streamline and enhance business operations. It provides a comprehensive solution that includes database management, user interface design, development tools, and natural language processing capabilities. Zim is built to support the creation and deployment of robust, feature-rich applications tailored to meet specific business needs. Its architecture ensures scalability, performance optimization, and security, making it ideal for mission-critical applications across various industries.

Key Components of Zim

Zim Server

• Efficient Database Management: Handles the creation, maintenance, and management of ZIM databases, ensuring efficient data sharing and transaction processing.
• Client/Server Architecture: Operates in a client/server mode where Zim Server acts as the server, and ZIM or ZIM Thin Client are the clients.
• Cross-Platform Compatibility: Runs on both Windows and various Linux distributions.

User Interface (UI)

• Intuitive Design: Provides a user-friendly interface that simplifies interaction with the system.
• Customizable: Allows for customization to meet specific business needs and preferences.

Fourth Generation Language (4GL)

• Development Support: Integrates a powerful Fourth Generation Language (4GL) to streamline the development process.
• Feature-Rich Applications: Enables the creation of robust, feature-rich applications tailored to business requirements.

Integrated Development Environment (IDE)

• Development Tools: Works alongside ZIM IDE, assisting developers in building and deploying applications efficiently.
• Administrative Utility: Includes tools like ZimExplore for comprehensive administrative functions, such as database creation, user management, and performance monitoring.

Natural Language Processing (NLP)

• User-Friendly Interaction: Leverages natural language processing to allow users to interact with the system using everyday language, making it easier to query databases, manage data, and perform administrative tasks.
• Enhanced Accessibility: Improves accessibility for users, enabling more intuitive and efficient interactions.

Transactions

• Implicit Transactions: Each Zim command that accesses the database (read-only or read/write) is associated with an implicit transaction. Upon command completion, all acquired locks are released, and any database updates are committed. If the command fails (e.g., due to a deadlock), Zim automatically removes partial updates and releases all locks.
• Explicit Transactions: Support database updates involving multiple commands that must be committed or removed as a single “logical unit of work.” Initiated by the transaction command and ended by either endtransaction (commits updates) or quittransaction (cancels updates). If a command within an explicit transaction fails, all partial updates are removed, and all locks are released.

Physical Structure of a Zim Database

• Database Directory: By default, Zim stores all database files, audit files, and document files in one operating system directory, known as the database directory[1].
• Working Directory: Zim stores all working files in a sub-directory of the database directory, named based on the user connected to the database[1]. This can be customized using configuration options in the zimconfig.zim file[1].
• Directory Relationship: Zim directories contain definitions of database objects and are independent of operating system directories[1]. For example, the Zim root directory is stored as a file called zim0001, and each Zim directory has a corresponding operating system directory for compiled programs[1].
• Special Document File Names: Zim recognizes special file names with specific prefixes for documents[1].

Scalability and Performance

• Scalability: Designed to scale with your business needs, handling increasing amounts of data and user interactions efficiently.
• Performance Optimization: Optimized for high performance, ensuring quick response times and efficient data processing.

Security Features

• Data Security: Implements robust security measures to protect sensitive data.
• User Authentication: Supports user authentication and authorization to control access to the database.

Use Cases

• Enterprise Applications: Ideal for developing and running professional, mission-critical applications.
• Multi-User Environments: Suitable for environments where multiple users need to access and interact with the database simultaneously.
• Embedded IoT Systems: Perfect for embedded IoT systems on the edge, providing reliable data management and processing capabilities for connected devices.

Zim is essential for organizations looking to develop and run professional, mission-critical applications by integrating a lean relational database with powerful development tools, a Fourth Generation Language (4GL), natural language processing capabilities, robust transaction support, and a well-structured physical database architecture.

A keyword is a user-defined string that is associated with an object. Any number of keywords can be assigned to an object; keywords can be added and deleted at any time. You can then use the keywords to select objects to process. For more information on methods for assigning and deleting keywords, see Processing Options.

Keywords have many uses. Most often keywords are used to classify the objects in an application. For example, you can assign different keywords to identify the objects in the different subsystems of your application.

ZOMSet *Contracts* ;k Contract_System

ZOMSet *Receivables* ;k Receivable_System

You can classify your objects based on type, as shown in the example below:

ZOMSet +t Win, Form ;k UserInterface

ZOMSet +t Ent, Rel, Role ;k Database

However, keywords can also be used as a quick means of accessing a specific set of objects. For example, the following example associates the keyword “Just_ReCreated” to the objects processed by the ZOMReCreate service:

ZOMReCreate +t ent,role ;k Just_ReCreated

This gives you quick access to this set of objects for further processing,  as shown in the following example:

ZOMList +k Just_ReCreated

Keywords can be used in many other contexts; you are limited only by your imagination.

You can lock an object so that its definition cannot be changed by any ZOM service (until it is unlocked). When an object is locked, it cannot be erased, deleted, destroyed, recreated, moved, renamed, and so on. Locking an object is similar to write protecting the object.

You can set and reset the locked property for an object(s) using the ‘L’ property indicator and the ZOMSet service. For example, to lock all objects named Employees, enter

ZOMSet Employees ;p l

To unlock the same objects, use the negation indicator (!) as shown below:

ZOMSet Employees ;p l!

If you lock a Zim directory object, all the objects belonging to that directory are implicitly locked as well. Thus, the following example locks all objects in the Release3 directory:

ZOMSet Release3 ;p l

Unlocking a directory object implicitly unlocks all objects belonging to that directory that have not been explicitly locked individually.

Note: A ZOM lock locks the object only as far as the ZOM services are concerned. A ZOM lock does not prevent the object from being changed directly using the standard CREATE, ERASE, and RENAME commands. However, changes made in the Development Center, where ZOM is always enabled, respect any object locks.
Locks in ZOM are separate from locking enabled in multi-user applications to control concurrent access to a database.

ZOM provides many services and features that have been described above for inspecting and manipulating the objects in your application to resolve problems (finding dependent, depending and unreferenced objects and objects that do not exist, for example). In addition, ZOM provides two special services to help you analyze problems in your application:

ZOMDiagnose, ZOMViewLog

The ZOMDiagnose command analyzes the objects in your entire application and their interdependencies. Any inconsistencies discovered are reported to you for further action. For example, suppose an attempt to recreate an EntitySet, Employees, has failed, leaving several relationship and role objects that depended on the EntitySet in an invalid state. ZOMDiagnose discovers these problems and reports them to you. A report is presented that itemizes the objects requiring attention. A sample of this report is shown in ZOMDiagnose.

The ZOMViewLog command enables you to browse the ZOM activity log. In the log are progress reports from the ZOM services you have executed as well as any error messages encountered. You can peruse the activity log to discover why certain operations did not succeed.

For example, to find out why the EntitySet mentioned above was not recreated after executing, enter

ZOMReCreate Employees

To inspect the activity log, enter

ZOMViewLog

The error messages in the log lead you to the problem. If many objects were processed, iterate through the objects until all are processed properly.

Note: In the case of creation failures, you can also try to create all objects that do not exist (on the assumption that the create operation failed for these objects), then look at the activity log for all these objects at once. This bulk create can be accomplished by entering
ZOMCreate +pe!

ZOM tags each object with a unique key called the object key. The ObjectKey uniquely identifies an object, even in computing environments where the development tools are not live-linked by means of a network.

Some characteristics of the ObjectKey are as follows:

• ObjectKeys are hidden from the user.

• ObjectKeys are automatically generated by the tools when an object is created. Once an object is created, it keeps the same key for its entire existence.

• When an object is destroyed, its ObjectKey is never re-used.

• ObjectKeys have no semantic content. They describe nothing at all about the object they point to, but instead serve only as a unique identifying string.

• If the same object exists in more than one tool or environment, its ObjectKey is the same value in all tools that manipulate or reference the object.

Two advanced selection criteria are described for selecting objects when using the ZOM services.

SELECTING BY QUERY PROGRAM

The Query Management Services (e.g., DPSMakeQuery) can be used by advanced ZOM users to write programs that select objects for use by ZOM services. These queries must be written such that they produce a set of ObjectList entities named “InputCLObjSet”.

An example of such a query, called “Find_ZZZ” is shown below. It finds all objects starting with the string “ZZZ.” It is created using the command DPSMakeQuery.

%% Query: Find_ZZZ

all ObjectList where ObjectList.ObjectName like “ZZZ%” -> InputCLObjSet

This is then used to list the objects found as shown below:

ZOMList +q Find_ZZZ

The query option can also be used in conjunction with other criteria. The following command finds all EntitySets, except those found by the query Find_ZZZ:

ZOMList +t Ent -q Find_ZZZ

ZOM stores and manipulates information in the Zim Object Dictionary. This information is stored in fields in the Object Dictionary tables, and additional tables.

ZOM Fields in the Object Dictionary

ZOM uses the following fields in the Object Dictionary EntitySets EntitySets, Relationships, Roles, Fields, Documents, Windows, Displays, Forms, Menus, Directories, Variables, NamedSets and Constants:

The ObjectList EntitySet

The ObjectList contains the registration data for an object in ZOM. It also stores a number of status values and flags which are maintained by ZOM as it performs its actions. The fields in ObjectList are:

The Keywords EntitySet

The Keywords EntitySet records the keywords assigned to objects.

The Dependencies EntitySet

The Dependencies EntitySet records interdependent object keys, indicating that a given object depends on another object. This information is deduced at runtime by the ZOM services and should be considered read-only by all other users and processes.

The Shadow Object Dictionary

A number of EntitySets, known collectively as the Shadow Object Dictionary, implement an exact duplicate of the Zim Object Dictionary. Each table starts with “sh”, followed by the name of the Object Dictionary table it duplicates, ShEntitySets for example. The Shadow Dictionary is used by ZOM to compare different descriptions for objects (for example, in the ZOMDiff command) and as a staging area for importing and exporting object descriptions.