The components that make up the ZIM Framework
The Graphical Object Tab Page shows the hierarchy of the objects currently open in the GUI Designer.
In the Tree View, primary user interface objects, such as forms, displays and menus, appear as top nodes.
Forms are the only children of displays
All other objects
The Attributes Tab Page lists all the different attributes for the currently selected field(s) in the GUI Designer.
The values of all available attributes can from within this tab page.
The Tool Box Tab Page contains a selection of available GUI objects that can be added to the current form.
The Database Tab Page displays all databases currently connected to the current session of Zim IDE.
Each connected database is represented as an expandable node containing all possible database object categories.
Each object category is also represented as an expandable node containing all objects of that category in the database.
To edit an object, right-click on its name to open it in the GUI Designer workspace;
To create an object, right-click on the category of the object you wish to create and enter the required information in the New Object Dialog;
Zim IDE consists of eight separate visual components distributed within five different panels. Some panels are occupied by two different visual components, of which only one is displayed individually when selected by the designer.
The visual components of Zim IDE and their respective display panels are introduced below:
| Component | Display Area |
| Menu Tool Bar | Menu Area |
| Database Tab Page | Left Panel |
| Tool Box Tab Page | Left Panel |
| GUI Designer | Central Panel |
| Document Editor | Central Panel |
| Properties Tab Page | Right Panel |
| Tree View Tab Page | Right Panel |
| The Field View Panel | Field View Panel |
The following images show how the different areas of the Zim IDE fit together during the user interface design process:
In this image, the form fExample_Zim9 is being edited in the GUI Designer workspace, while the database Example_Zim9 + localhost are connected to this Zim IDE session as shown in the database tab page. the form opened in the GUI designer (fExample_Zim9) are shown in the Tree View Tab Page on the right, along with their respective fields.
In this image, the form fExample_Zim9 is being edited in the GUI Designer workspace. A Push Button is currently selected and its attributes are shown in the Attributes Tab Page. The Tool Box Tab Page is also visible, showing the available user interface objects that can be added to the form.
The Document Editor is where documents such as Zim programs, database parameters and configuration files are viewed and edited.
It occupies the same area as the GUI Designer
it offers syntax highlighting customized for the Zim programming language.
Documents can be opened and edited directly from the Database Tab Page:
Click on the Documents node under one of the connected databases and select the document you wish to open and edit.
The Toolbar contains shortcuts to menu items that are frequently used. There are icons for the following menu items:
The Menu Tool bar is divided into the following menu areas:
| Web Browser | Display Internet Tab Page |
 | Display Query Database Tab Page |
 | Display Preferences Tab Page |
| Test Mode | Display Test Mode Tab Page |
| Float | Float Tab Page |
 | Dock Tab Page |
| Auto Hide | Tab Page Auto Hide |
| Auto Hide All | Tab Page Auto Hide All |
 | Tab Page Hide |
| All Document Windows | Tab Page All Document Windows |
| Zim Website | Zim Databases Canada website Tab Page |
 | Zim Developer Library |
 | Check for Update Zim |
 | About Zim Development Environment |
 | Find all objects in the current database by name |
 | Find Previous |
 | Find and Replace |
 | Toggle Bookmark |
 | Next Bookmark |
 | Previous Bookmark |
 | Clear Bookmark |
Zim uses the operating system’s file management system to store entity sets, relationships, programs (source and compiled), database definitions, ZIM directories, and work files. By default, all files are stored in the same area of your file system. You can however, change the locations of the various types of files by, for example, moving the files to different disks, to improve the performance of your application. Zim provides methods for controlling the files that it uses.
To optimize Zim Server performance, it’s crucial to fine-tune the configuration settings in the zimconfig.srv file. Here are detailed technical guidelines for each of the three key factors:
SHARED_MEMORY_BUFFERS: Set this to a high value to ensure ample buffer space.SHARED_MEMORY_AREAS: Increase this to allow more areas to be stored in shared memory.ini
SHARED_MEMORY_BUFFERS=1024
SHARED_MEMORY_AREAS=256
MAX_SHARED_MEMORY: Set this to a value that balances usage without exceeding system limits.SHARED_MEMORY_THRESHOLD: Define a threshold to prevent over-allocation.ini
MAX_SHARED_MEMORY=2048MB
SHARED_MEMORY_THRESHOLD=80%
IO_OPERATION_LIMIT: Set a limit on the number of I/O operations.CACHE_SIZE: Increase the cache size to reduce the frequency of I/O operations.ini
IO_OPERATION_LIMIT=1000
CACHE_SIZE=512MB
top, htop, or custom monitoring scripts can help you keep track of memory usage and I/O operations.By carefully adjusting these settings, you can achieve a well-balanced and high-performing Zim Server environment.
These options define the size of the checkpoint file, which is either the number of blocks or transactions that Zim Server will process before physically committing to disk. Both options refer to transactions that were effectively committed, meaning transactions that successfully finished.
To achieve optimal performance, it’s important to balance these options based on the size of your database and the number of users.
For small databases or a small number of users, use the following settings:
checkpoint buffers = 1000 # Small checkpoint file
checkpoint transactions = 100000 # Unlikely to reach this limit
For larger databases or higher user activity, use these settings:
checkpoint buffers = 10000 # Medium size checkpoint file
checkpoint transactions = 100000 # Unlikely to reach this limit
For even larger databases, consider increasing the checkpoint buffers value further:
checkpoint buffers = 50000 # Larger checkpoint file
checkpoint transactions = 100000 # Unlikely to reach this limit
checkpoint buffers can lead to improved performance by reducing the frequency of checkpoints, but it’s important to monitor and adjust based on actual performance metrics.By carefully adjusting the checkpoint buffers and checkpoint transactions settings, you can optimize Zim Server performance for both small and large databases. Regular monitoring and testing different configurations will help you achieve the best balance for your specific environment.
This option specifies the number of data blocks that Zim Server will keep in shared memory simultaneously. It significantly impacts Zim Server efficiency by optimizing the number of input and output operations. The larger this option, the more efficient Zim Server will be. However, it requires a substantial amount of shared memory. If insufficient real memory is available, the operating system will start swapping, which can drastically reduce performance.
This option determines how many Zim databases will be processed concurrently. The default is 3, but reducing this number to the minimum necessary will decrease the amount of shared memory required.
This option indicates the number of Zim tables (entity sets and relationships with fields) that will be processed across all databases. Keeping this number as low as possible will minimize shared memory usage.
This option sets the maximum number of users allowed to connect to Zim Server, up to the number of Zim licenses purchased. Reducing this number to the minimum needed will conserve shared memory.
These parameters define the wait and timeout durations when attempting to acquire various Zim Server internal objects. Lower values result in faster reactions to resolve issues (usually by deadlocking), allowing other users to proceed. Use the suggested values in the configuration files below.
This option specifies the maximum sizes of transactions in blocks that all users connected to Zim Server can perform simultaneously. If there are 10 users connected but only 5 performing transactions, only these will count. For example, if the average number of blocks processed is 500, the number of entries used will be 2,500. Once a transaction is finished, all entries used in that transaction are released. This number cannot be smaller than Scatter Table Links. A good approach is to calculate 3 to 5 times that number.
This option sets the maximum size for a transaction in blocks, allowing transactions to process different blocks of data up to this limit. For instance, an ADD statement creating a very large Zim file (e.g., 500 MB) will require this parameter to be at least 500,000. However, such commands are not common daily, suggesting a specific configuration for large operations. The larger this number, the more efficient Zim Server will be. A good reference is to multiply Maximum Data Blocks by two or three. This parameter cannot be smaller than Maximum Data Blocks.
blocks per read = 8
buffers per user = 1000
checkpoint buffers = 1000
checkpoint transactions = 100000
datablock timeout = 1
files per transaction = 20
first file to reclaim = 100
maximum blocks per user = 2000
maximum data blocks = 20000
maximum databases = <number>
maximum file locks = 200
maximum locks = 10000
maximum record groups = 2000
maximum tables = <number>
maximum users = <number>
object sleep = 1
object timeout = 1
pending sleep = 5
pending timeout = 5
processors = 1
quick locks = 10
reclaim object size = 1000
record group size = 256
scatter table entries = 70000
scatter table links = 50000
scatter table size = 100
secondary lock group size = 20
secondary lock groups = 7500
server port number = 6002
blocks per read = 8
buffers per user = 1000
checkpoint buffers = 10000
checkpoint transactions = 100000
datablock timeout = 1
files per transaction = 20
first file to reclaim = 100
maximum blocks per user = 2000
maximum data blocks = 50000
maximum databases = <number>
maximum file locks = 200
maximum locks = 10000
maximum record groups = 2000
maximum tables = <number>
maximum users = <number>
object sleep = 1
object timeout = 1
pending sleep = 5
pending timeout = 5
processors = 1
quick locks = 10
reclaim object size = 1000
record group size = 256
scatter table entries = 150000
scatter table links = 100000
scatter table size = 100
secondary lock group size = 20
secondary lock groups = 7500
server port number = 6002
blocks per read = 8
buffers per user = 1000
checkpoint buffers = 50000
checkpoint transactions = 100000
datablock timeout = 1
files per transaction = 20
first file to reclaim = 100
maximum blocks per user = 2000
maximum data blocks = 100000
maximum databases = <number>
maximum file locks = 200
maximum locks = 20000
maximum record groups = 4000
maximum tables = <number>
maximum users = <number>
object sleep = 1
object timeout = 1
pending sleep = 5
pending timeout = 5
processors = 1
quick locks = 10
reclaim object size = 1000
record group size = 256
scatter table entries = 800000
scatter table links = 250000
scatter table size = 100
secondary lock group size = 20
secondary lock groups = 7500
server port number = 6002
By carefully adjusting these settings, you can optimize Zim Server performance for different database sizes. Regular monitoring and testing different configurations will help you achieve the best balance for your specific environment.
Each Zim database has its own object dictionary. All objects (i.e. entity sets, forms, variables, and so on) that are described in the object dictionary are created in a Zim directory. Normally, an application developer creates the Zim directories that are used within one particular database. A foreign directory, on the other hand, is a Zim directory that is defined by one database, but is used by other databases. By accessing a foreign directory, you gain access to all objects created in that directory.
There are many situations in which a foreign directory can be useful. One common example is the toolbox, a database containing application programs that are useful in, and therefore shared among, many different databases.
For example, while developing an application, you might have created a directory containing utility programs. These utilities could be useful in other situations, but you do not want to re-create them for each new database. By following the procedures described below, the utility directory can be defined as foreign in the other databases. The directory can then be used in databases other than the one in which it was created.
The procedure described below is an overview of how foreign directories are used. The remainder of this section describes this in more detail.
In general, the use of a directory from one database (the host database) within another database (the connecting database) involves five steps:
Note: A connecting database can access many foreign directories simultaneously, provided each directory has a unique directory ID number (dirID). A single directory can be accessed as a foreign directory simultaneously by many databases.
Note2: If a single ZimServer manages different databases and at least one of them has foreign directories, all directories, local or foreign, must have unique dirID across all databases.
A foreign directory consists of two components. The first component is the original directory created in the host database. It is this directory that is accessed by users of other databases. The second component is a directory that is created as foreign in the connecting database.
If a particular directory is to be used from within other databases, the directory must be created in the host database, using the procedure described below. The directory is created essentially in the normal way; however, it must be assigned a special directory ID number.
Note: The root directory (namely Zim) cannot be used as a foreign directory. You should ensure that the directory to be used in other databases is a sub-directory.
To enable users of another database to connect to an existing (foreign) directory, continue the above procedure with the following steps:
Note: The DirName and DirId of the foreign directory must be the same as the DirName and DirId in the host database.
Before a user of the connecting database can employ the ACCESS command to connect to a foreign directory, the connecting database must contain a foreign directories (dirs.zim) file with an entry describing the location of each foreign directory. To create this file, use a text editor at the operating system level. The file should be stored in the operating system directory that contains the connecting database.
Each entry in the foreign directories file has the format:
dirid file# path
where
dirid is the dirid of the foreign directory
file# is the number of the file that corresponds to the directory in the host database (i.e. nnnn to zimnnnn). To determine the file#, run the ZIMFILES utility against the host database or use the command
output $filename (directory-name)
For example, the entry
11 126 usrtools
means that the directory whose dirid is 11 can be found in the file usrtoolszim0126.
Once a foreign directory has been defined and created in the host and connecting databases, and the foreign directories file exists with the appropriate entry, the foreign directory is accessible from within the connecting database. To access the foreign directory, use the following procedure:
access Utilities read
All objects defined in the foreign directory are now available from within the connecting database.
Note: Foreign directories can be accessed only in read mode.
The dirs.zim file specifies the location of the operating system (OS) file that corresponds to the foreign directory. But where does the system look for the files that correspond to the entity sets, relationships, programs and so on that are defined in the foreign directory?
By default, Zim looks for these files in the path specified in the dirs.zim file for the foreign directory file itself. It is possible, however, to distribute these files to other parts of the file system by using an areas file with special document file names in the host database. The procedure for using an areas file in a host database is exactly as described for independent databases in Distributing Database Files.
An areas file for a foreign directory can distribute some or all of the associated database files (i.e. EntitySets, relationships, compiled programs, and so on). Documents defined in a foreign directory can use the special file name prefixes – including the double quotation mark and the right parenthesis – to locate associated files in the database directory and work directory belonging to the connecting user.
To illustrate, let’s look at a Utilities example. Consider the following background information:
>list all docs
Docname FileName DirName
DictReport dict.rep Utilities
ReportOut )report.out Utilities
UserLog “user.log Utilities
UtilEnt1 (stored in operating system file ZIM0129)
UtilEnt2 (stored in operating system file ZIM0130)
129 C:UTZIM
30 117 D:UTILPROG
Given this situation, the connecting and host databases both contain an areas file that relocates the files associated with entity sets. In the connecting database, a foreign directories file establishes D:UTILPROG as the default location for all files associated with objects in the foreign directory Utilities. The foreign object ReportOut (a document) is defined as being located in the connecting user’s work directory; similarly, UserLog is defined as being located in the connecting user’s database directory.
By connecting to a foreign directory, you gain access to the data in the EntitySets and relationships with fields that are defined in that directory.
To obtain read/write access to foreign database fields, you can declare those files as non-shared in the areas file associated with the host database. For example, to obtain read/write access to a foreign EntitySet called UtilEnt whose corresponding operating system file has the name ZIM0185, you would place the entry
185 D:UTILPROG % This is a Zim on Windows example.
185 /usr3/utilprog/ % This is a Zim on UNIX example.
in the areas file associated with the host database.
In Zim 9, foreign databases can be read or written as any normal database.
The following limitations apply to the user of foreign directories:
English 
Portuguese