Python API to Talk to a Zim Database

🔌 ZimAPI Developer Guide (Python Edition)

🚀 What Is ZimAPI?

ZimAPI is a Python interface that connects directly to the ZIM database engine. It allows developers to execute ZIM and SQL commands, manage transactions, transfer files, and interact with persistent data sets—all from Python.

But ZimAPI is more than just a connector. It’s a gateway to ZIM’s integrated database, which offers a unique and developer-friendly feature: automatic data set creation and session-based persistence.


🧠 Why ZIM Is Different

Unlike traditional SQL databases like MySQL or PostgreSQL, ZIM automatically creates a data set every time a query is executed. These data sets behave like dynamic views and remain available for the entire session—no need to define or manage them manually.

In other systems, a Python developer must explicitly request a view or cache query results. In ZIM, this happens automatically:

 

FIND 5 Customers -> sCustomers

 

This creates a set named sCustomers containing up to 5 customer records. You can interact with this set throughout the session:

 

DELETE 1 FROM sCustomers

 

Once the API session ends, ZIM automatically drops the data set. When a new session begins, a fresh set is created based on the new query context.


🛠️ Installation

After completing the full ZIM installation:

  1. Locate zimapi.py in your ZIM installation directory.
  2. Copy it to the directory where your Python scripts will run.

Tip: Keep zimapi.py in a shared utilities folder if you’re working across multiple projects.


🔗 Connecting to ZIM

Basic Setup

 

import zimapi
import os

zim = zimapi.Zimapi()
zim = zim.connect(
    dbname="your_database_name",
    host="localhost",       # Optional
    port=6002,              # Optional
    user="ZIM",             # Optional
    password=""             # Optional
)

print(zim.state)
zim.close()

 

Inline Connection

 

zim = zimapi.Zimapi(
    dbname="your_database_name",
    host="localhost",
    port=6002,
    user="ZIM",
    password=""
)
print(zim.state)
zim.close()

 

Note:

  • dbname is required.
  • host defaults to "localhost"
  • port defaults to 6002 (must match zimconfig.srv if changed)

🧩 Core Methods

zim.execute(command)

Executes a ZIM or SQL command.

 

if zim.execute("DELETE 1 Customers WHERE CustCode = 1") == 0:
    print("Executed successfully.")
elseif zim.state == 1001:
    print("Record not found.")
else:
    print("Error executing statement. Error Code =", zim.state)
endif

 


zim.transaction(), zim.commit(), zim.rollback()

Control explicit transactions for atomic operations.

 

zim.transaction()
zim.execute("UPDATE Customers SET Status = 'Active' WHERE CustCode = 1")
zim.commit()

 

Or roll back if needed:

 

zim.rollback()

 


zim.callproc(procedure_name, arguments)

Call a ZIM procedure with input/output parameters.

 

args = ("12", 7, "?", "?")
res = zim.callproc("MyProc", args)

if res[1] and res[2]:
    print("Result:", res[1], res[2])
else:
    print("Procedure returned no output.")
endif

 


zim.putfile(source, destination, format)

Upload a file from your local machine to the server.

 

zim.putfile("local.txt", "/server/data.txt", "/A")  # Text file

 


zim.getfile(source, destination, format)

Download a file from the server to your local machine.

 

zim.getfile("/server/data.txt", "local_copy.txt", "/A")  # Text file

 


🧵 Cursors & Sets: ZIM’s Secret Weapon

ZIM’s automatic data sets are one of its most powerful features. These sets persist for the duration of the session and behave like dynamic views.

Create and Use a Cursor

 

cur = zim.cursor("FIND 5 Customers")

while cur.rowcount() > 0:
    row = cur.fetchone()
    print(row)
endwhile

 

Or:

 

cur = zim.cursor()
cur.execute("FIND 5 Customers")

 


Cursor Utilities

MethodDescription
cur.close()Closes the cursor.
cur.rowcount()Number of rows available.
cur.fetchone()Fetches the next row.
cur.rownumber()Current row number.
cur.getname(index)Field name by index.
cur.describe(name)Field metadata.
cur.scroll(amount)Scrolls cursor by rows or to "TOP" / "BOTTOM"

📦 Sets: Persistent Views of Data

Sets are logical collections of rows that persist across the session. They behave like views and can be reused across multiple operations.

Create a Set

 

cur = zim.cursor("FIND 5 Customers -> sCustomers")

 

Manipulate the Set

 

zim.execute("DELETE 1 FROM sCustomers")

 

Use sets to:

  • Cache filtered data
  • Perform batch operations
  • Share views across procedures

🧪 Real-World Use Cases

🔄 1. Transactional Integrity

Wrap multiple operations in a transaction to ensure atomicity.

📞 2. Business Logic via Procedures

Trigger backend logic stored in ZIM procedures—like calculating discounts or validating credentials.

📁 3. Secure File Sync

Automate secure file transfers between client and server for compliance logs or audit trails.

📊 4. Dashboard Integration

Pull live data from ZIM into a Python-based dashboard using cursors and sets.


🧭 Summary

ZimAPI for Python is a powerful and developer-friendly interface that brings ZIM’s integrated database and automatic data set creation into your Python applications. It simplifies data access, enhances performance, and reduces boilerplate code—making it ideal for enterprise automation, smart dashboards, and intelligent safety systems.

Whether you’re modernizing legacy infrastructure or building new solutions, ZimAPI gives you the tools to do it efficiently and elegantly.

C-Sharp API to talk to a Zim Database

🔌 ZimAPI Developer Guide (C# Edition)

🚀 What Is ZimAPI?

ZimAPI for C# is a powerful interface that connects your .NET applications directly to the ZIM database engine. It enables developers to execute ZIM and SQL commands, manage transactions, transfer files, and interact with persistent data sets—all within a C# environment.

But ZimAPI is more than just a connector. It’s a gateway to ZIM’s integrated database, which offers a unique and developer-friendly feature: automatic data set creation and session-based persistence.


🧠 Why ZIM Is Different

Unlike traditional SQL databases like MySQL or PostgreSQL, ZIM automatically creates a data set every time a query is executed. These data sets behave like dynamic views and remain available for the entire session—no need to define or manage them manually.

In other systems, a developer must explicitly request a view or cache query results. In ZIM, this happens automatically:

 

FIND 5 Customers -> sCustomers

 

This creates a set named sCustomers containing up to 5 customer records. You can interact with this set throughout the session:

 

DELETE 1 FROM sCustomers

 

Once the API session ends, ZIM automatically drops the data set. When a new session begins, a fresh set is created based on the new query context.


🛠️ Installation

After completing the full ZIM installation:

  1. Locate zimapi.cs in your ZIM installation directory.
  2. Copy it to the directory where your C# application will be developed.
  3. Reference the compiled ZimAPI.dll in your project.

🌐 Globals

ZimAPI provides several global constants for convenience:

ConstantDescription
TOPIndicates the first record in a set
BOTTOMIndicates the last record in a set
UTF8Indicates a UTF-8 encoded ZIM database
ANSIIndicates an ANSI encoded ZIM database
NO_ERRORIndicates no error occurred

🔗 Connecting to ZIM

Basic Setup

 

using ZimConnection;

ZimAPI Conn = new ZimAPI();
Conn.Connect("DatabaseName", "localhost", 6002, "ZIM", "");
System.Console.WriteLine(Conn.State);
Conn.Close();

 

Inline Constructor

 

using ZimConnection;

ZimAPI Conn = new ZimAPI("DatabaseName", "localhost", 6002, "ZIM", "");
System.Console.WriteLine(Conn.State);
Conn.Close();

 

Note:

  • DatabaseName is required.
  • HostName defaults to "localhost"
  • PortNumber defaults to 6002 (must match zimconfig.srv if changed)
  • UserName defaults to "ZIM"
  • Password defaults to ""

🧩 Core Methods

Conn.Execute(command)

Executes a ZIM or SQL command.

 

if Conn.Execute("DELETE 1 Customers WHERE CustCode = 1") == 0
    System.Console("Executed successfully.")
elseif Conn.State = 1001
    System.Console("Record not found.")
else
    System.Console("Error executing statement. Error Code is = " + Conn.State + ".")
endif

 

Conn.Transaction(), Conn.Commit(), Conn.Rollback()

Control explicit transactions for atomic operations.

 

Conn.Transaction();
Conn.Execute("UPDATE Customers SET Status = 'Active' WHERE CustCode = 1");
Conn.Commit();

 

Or roll back if needed:

 

Conn.Rollback();

 

Conn.Callproc(procedure)

Call a ZIM procedure with input/output parameters.

 

string[] Result = Conn.Callproc("MyProc(\"12\", 7, \"?\", \"?\")");

if Result[1] != null and Result[2] != null
    System.Console("Result: " + Result[1] + ", " + Result[2])
else
    System.Console("Procedure returned no output.")
endif

 

Conn.Putfile() / Conn.Getfile()

Transfer files between client and server.

 

Conn.Putfile("local.txt", "/server/data.txt", "/A");  // Upload text file
Conn.Getfile("/server/data.txt", "local_copy.txt", "/A");  // Download it back

 

Conn.ErrorMessage() / Conn.ErrorCode()

Retrieve the last error message or code.

 

System.Console("Error: " + Conn.ErrorMessage());
System.Console("Code: " + Conn.ErrorCode());

 


🧵 Cursors & Sets: ZIM’s Secret Weapon

ZIM’s automatic data sets are one of its most powerful features. These sets persist for the duration of the session and behave like dynamic views.

Create and Use a Cursor

 

ZimAPI.ZimCursor MyCursor = Conn.Cursor("FIND 5 Customers");

while MyCursor.RowCount() > 0
    string row = MyCursor.FetchOne();
    System.Console(row);
endwhile

 

Or:

 

ZimAPI.ZimCursor MyCursor = Conn.Cursor();
MyCursor.Execute("FIND 5 Customers");

 

Cursor Utilities

MethodDescription
MyCursor.Close()Closes the cursor.
MyCursor.RowCount()Number of rows available.
MyCursor.FetchOne()Fetches the next row.
MyCursor.RowNumber()Current row number.
MyCursor.ValueOf(name)Gets field value by name.
MyCursor.ValueOf(index)Gets field value by index.
MyCursor.GetName(index)Gets field name by index.
MyCursor.FieldCount()Number of fields in the record.
MyCursor.Scroll(amount)Scrolls cursor by rows or to TOP / BOTTOM.

📦 Sets: Persistent Views of Data

Sets are logical collections of rows that persist across the session. They behave like views and can be reused across multiple operations.

Create a Set

 

ZimAPI.ZimCursor MyCursor = Conn.Cursor("FIND 5 Customers -> sCustomers");

 

Manipulate the Set

 

MyCursor.Execute("DELETE 1 FROM sCustomers");

 

Use sets to:

  • Cache filtered data
  • Perform batch operations
  • Share views across procedures

🧪 Real-World Use Cases

1. Smart Form Logic

Use ZimAPI to dynamically change UI elements based on backend data.

🔄 2. Transactional Integrity

Wrap multiple operations in a transaction to ensure atomicity.

📞 3. Business Logic via Procedures

Trigger backend logic stored in ZIM procedures—like calculating discounts or validating credentials.

📁 4. Secure File Sync

Automate secure file transfers between client and server for compliance logs or audit trails.

📊 5. Dashboard Integration

Pull live data from ZIM into a C#-based dashboard using cursors and sets.


🧭 Summary

ZimAPI for C# is a powerful and developer-friendly interface that brings ZIM’s integrated database and automatic data set creation into your .NET applications. It simplifies data access, enhances performance, and reduces boilerplate code—making it ideal for enterprise automation, smart dashboards, and intelligent safety systems.

Whether you’re modernizing legacy infrastructure or building new solutions, ZimAPI gives you the tools to do it efficiently and elegantly.

Python Connection

#pip3 -> python 3.9
# - Instalar com pip3
#pip3 install JayDeBeApi --user
#pip3 install JPype1==0.6.3 --user

import jaydebeapi

#variables to connect to zimjdbc8.jar


jclassname='zim.jdbc.ZJ_Driver'
jdbc_driver_loc = r'C:\Users\xxx\Documents\p01\zimjdbc8.jar'
jdbc_driver_name = 'zim.jdbc.ZJ_Driver'
host='localhost:6002'
#url and login variables
url='jdbc:zim://' + host + '/zimdb01'
login="ZIM"
psw=""

#sql to be executed at the Zim's side.
sql = "SELECT codie, name from test"

#connection to the JDBC driver
conn = jaydebeapi.connect(jclassname=jdbc_driver_name,
url=url, 
driver_args=[login, psw],
jars=jdbc_driver_loc)
#open the cursor
cur = conn.cursor()
#execute the SQL statement
cur.execute(sql)
#print the result 
print(cur.fetchall())...

DDE Services

Zim provides DDE services for applications through the function $DDEFunction. These DDE services include the ability to send data to another application, retrieve data from another application, and pass commands to another application. While you can write your own implementation of $DDEFunction, Zim provides a standard implementation in the form of a Dynamic Link Library (DLL) and several Zim programs that provide an easy-to-use interface to the services of the DLL.

Using the DDE Services Provided by ZIM
The actual name of the DLL accessed by $DDEFunction is defined by the DDEFUNC entry in the registry. If you do not have a DDEFUNC entry, the name of the DLL is assumed to be z32dde.dll and the file is assumed to be in the same directory in which your Zim software was installed. Upon Zim installation, the registry value of DDEFUNC is not set because Zim automatically assumes the required values on its absence.

Using Special DDE Services Provided by the User

If you want to use your own special DDE services support, you must build a DLL that follows the same standards as any $UserFunction and set the DDEFUNC registry like this example before starting your Zim for Windows session:

DDEFUNC=C:\MYCODE\MYDDE.DLL

Invoking the DDE Services
The standard DDE services provided by Zim can be accessed in two ways:

through the set of Zim programs that provide an interface to the DDE DLL (z32dde.dll)
by calling $DDEFunction directly (always referencing z32dde.dll)
These two ways distinguish from each other from the fact that the Zim programs are easier to deal with because they provide all error handling and parameter checking and converting. On the other side, the $DDEFunction usage can provide more flexibility but requires more attention from the programmer.

Invoking the DDE Services

Invoking the DDE Services Through the Zim Interface Programs
Your Zim installation provides a set of Zim programs as a means of an easy interface to DDE services. These programs are located in the $DeployServices directory that must be accessed via the command prior to any reference to these programs:

access $DeployServices

The programs are all compiled, but the corresponding source code is located in the operating system directory “dpserv/dpsdocs”. They implement five different operations against the DDE services as follows:

DDEConnect, which connects to the desired service;

DDEExecute, which executes a specific operation on the service;

DDEPeek, which gets some value from the service;

DDEPoke, which sets any values to the service;

DDEDisconnect, which disconnects and ends to conversation to the service.

Please refer to the corresponding documentation of each of these commands for more details.

Syntax

Invoking the DDE Services Directly Through $DDEFunction
The DDE services can be accessed by invoking the Zim function $DDEFunction directly. $DDEFunction is invoked with the syntax

$DDEFunction ( p1, p2, p3, ... )

where p1, p2, and so on, indicate the desired DDE service and the data required by that service. Specifically, p2 passes the desired operation to be performed against the DDE services. The operations are exactly the same as those provided by the Zim Interface Programs.

See Also

$DDEFunction

The Benefits of $ServerFunction

The benefit of $serverfunction is the ability to code server functions that Zim does not support. Often there are similar functions in Zim and the server, but the mapping is not exact. As a result, the function is not present in the .sql file, forcing Zim to retrieve the entire table and evaluate the where clause on the client side. Sometimes functions are missing from the .sql file.

Users can code the equivalent server function instead of waiting for updates to the .sql file.

If $ServerFunction() is executed against a Zim table or with ExecuteMode set to ZimMode, the value returned by $ServerFunction is the value of the first argument.

ZimWeb Architecture

ZimWeb Connection Architecture

Web applications can be implemented in Zim, using a Java Servlet program called ZIIServlet, provided as part of ZimWeb. A Java Servlet must be executed on a Java Servlet Container, such as Apache’s Jakarta Tomcat.

ZIIServlet works together with Zim Server to process requests from the client, whose interaction with the end user occurs through a web browser. In particular, request parameters (e.g. HTML form field values) are passed as parameters to a Zim program that is executed on Zim Server. That program is responsible for processing the request and constructing the response. Although the response can be sent directly back to the client, ZimWeb includes a variety of options for processing it.

ZimWeb communicates with Zim Server using TCP/IP. Zim Server and ZimWeb, can run on the same or different systems, provided that there is a network connection between the them.

The following diagram shows the basic components of a Web application using ZimWeb:

ZimWeb Components

ZimWeb is composed of four components: the ZIIServlet, the Java Servlet Container, the Zim Database Agent and a web browser.

Java Servlet Container

Also known as a Java Servlet Engine. An environment in which Java Servlets can be executed. Tests were done with Apache’s Tomcat, which is the official reference platform for Java Servlet Containers. A Java Servlet Container can be run independently, or it can be integrated with a Web Server. The ZimWeb Reference Platform includes Tomcat, but a variety of alternatives are available.

ZIIServlet

ZIIServlet is a Java Servlet. It can be loaded automatically by the Java Servlet Container when the first request is received, or alternatively it can be loaded in advance so that it is ready beforehand.

Zim Database Agent

The Zim Database Agent is part of Zim Server. It is a process that runs on a specific machine and accesses a specific database. ZimWeb can communicate with any number of databases on any number of database machines. However, a Zim Database Agent is always connected to a specific database.

Web Browser

Typical web browsers include Microsoft Internet Explorer on Windows, Safari on MacOSX and iOS, Chrome, Firefox and Opera on serveral platforms, from desktops to tablets and smartphones. The web browser is not supplied with ZimWeb. End users will connect to ZimWeb using any available web browser in their machines

Bibliography

XML Technologies

The following books will be particularly useful in explaining the XML technologies that are crucial to using the ZimWeb effectively:

 

Java

If you want to learn about Java then take a look at these books:

General Java programming

Server-side Java programming

ML Processing with Java

ZimWeb Administration

ZIIAdmin servlet is ZimWeb‘s administration tool. It can be used to manage ZimWeb either from the web or from a command line or script, which can be scheduled.

Web Administration

If you invoke the ZIIAdmin servlet from a web browser, you will see a page with various parts under different headings:-

Database StatusAllows you to monitor, start and stop the Zim Database Agent sessions e.g. if you want to prevent access to the Zim application for maintenance purposes.
The current status of the Zim Database Agent sessions is indicated as “Database connections are RUNNING” or “… NOT RUNNING”.
If the connections are running, then an adjacent button allows you to “Shutdown Database Connections”; if they are not running, then the button allows you to “Start Database Connections”.
Debug StatusIndicates whether client debugging capability is enabled or disabled – press the adjacent button to toggle the status as necessary.
Initialisation ParametersShows the values of the startup parameters for the ZimWeb .
XSLT Stylesheet cacheIndicates the current contents of the XSLT stylesheet cache.
If you need to clear the cache – e.g. if you have changed an XSLT stylesheet which is cached into memory and thus will not be read – then click the adjacent button “Clear XSLT Stylesheet Cache”.
Page Template cacheIndicates the current contents of the page template cache.
If you need to clear the cache – e.g. if you have changed a page template which is cached into memory and thus will not be read – then click the adjacent button “Clear Page Template Cache”.
FOP driver poolIndicates the current number of FOP (Apache Formatting Object Processor) driver instances and the number checked out (in active use at the time that you start the web-administration tool).
If the ZII receives more than one request for XSL-FO rendering at the same time then it will automatically increase the number of driver instances available.
If you need to reset the FOP driver pool then click the adjacent button “Reset FOP Driver Pool”.

Command line or scripted administration

The ZIIAdmin servlet can also be invoked from the command line or by a script. The servlet itself requires two parameters:

✓ action – set to indicate what query or action the servlet is to perform. Permitted actions include:

  ✓ conn-status – return the status of the Zim Database Agent connections.

  ✓ conn-start – attempt to start the Zim Database Agent connections.

  ✓ conn-stop – attempt to stop the Zim Database Agent connections.

  ✓ debug-status – return the debug capability status.

  ✓ debug-enable – enable the debug capability.

  ✓ debug-disable – disable the debug capability.

  ✓ clear-style-cache – clear the XSLT stylesheet cache.

  ✓ clear-page-template-cache – clear the page template cache.

  ✓ reset-xslfo-driver-pool – reset the XSL/FO driver pool.

✓ content – set to text so that the servlet will return plain text instead of HTML.

CallURL utility

To enable the ZIIAdmin servlet to be called from the command line or a script, ZimWeb includes the CallURL utility to enable calls to a URL, with BASIC authentication details, if necessary.

The full syntax for CallURL is:

java -cp /zii.jar biz.zim.util.CallURL [ ]
to invoke the URL , optionally with BASIC authentication for user and password .

For example: To start the database connections on a local running ZimWeb installation or a default Tomcat installation, if the ZimWeb file zii.jar is in the current directory, and the ZIIAdmin servlet has security requiring the username admin and password friend, you could use the command:
java -cp zii.jar http://localhost:8080/ZII/servlet/ZIIAdmin?action=conn-start&content=text admin friend

Configuring ZimWeb

If you are using Tomcat, and have installed the ZimWeb in the manner described in the installation instructions, then the servlet configuration (servlet initialisation parameters) will be in the web.xml file in the [TOMCAT_ROOT]/webapps/ZII/WEB-INF directory. If you are using a different servlet engine, then you will have to consult its documentation to see how to configure it.

 

Here are the configuration parameters, organized by function type:

 

Automatic servlet loading
load-on-startup
(Tomcat configuration parameter)
This controls whether the ZII servlet is loaded automatically when the Tomcat Java servlet engine starts. This means that the servlet is loaded and ready to run when the first client request arrives.
Read the Tomcat documentation for more details on this subject.
Note: This is not an initialisation parameter for the ZII servlet – it is a configuration parameter for the servlet. If you are using a different servlet engine then consult its documentation.
Automatically starting database connections
auto-startThis controls whether the ZII will automatically start the Zim Server agent sessions when the ZII servlet is loaded.
If this equals yes (the default), then they are; it it is no, then they are not.
If the ZII receives a client request, and the agents are not started, then the client will receive an error indicating that the database connection have not been started.
Configuration and log files
config-fileThis gives the file name of the Zim Server agent configuration file – the same file that the ZimCGI uses.
Consult the ZimCGI documentation and Configuration file extensions for more details on this subject.
log-fileThis gives the file name of the log file that the ZII write – equivalent to the zimcgisrv.log file that the ZimCGI generates.
Consult the ZimCGI documentation for more for more details on this subject.
verboseThis controls whether certain aspects of the logging features of the ZII are more verbose than usual (and necessary!).
If it is yes, then the logging is more verbose. If it is no (the default), then your logs are not so verbose.
Consult the ZimCGI documentation for more for more details on this subject.
Controlling XSLT processing
use-xslt-output-typeThis controls how the ZII sets the mime content type of the response, if the output is passed through the XSLT processor and there is no content-type: command.
If it is no (the default), then the content type is assumed to be text/html.
If it is yes, then the XSLT processor will extract the content type from the clause in the stylesheet.
If you set this to yes and you do not have an clause in the XSLT stylesheets, then the XSLT processor will usually assume the content type is XML (text/xml), which may not be what you want.
I don’t think there is a good reason for you not to put an clause in all of your XSLT stylesheets.
N.B. for more details on this subject please see documentation on XSLT.
Session and cookie management
default-session-timeoutThis is the default session timeout in seconds.
If not specifed, ZII will default to a 1 hour timeout.
This can be overridden for a particular session by using the session-timeout: command.
default-cookie-timeoutThis is the default cookie expiry time in seconds.
If not specifed, ZII will default to a 1 year expiry.
This can be overridden for a particular cookie by using the cookie-timeout: command.
Persistent Zim sessions
zim-session-securityThis controls the security of persistent Zim sessions; the various options are:-

  • open – insecure, as with the previous ZimCGI – the client can initiate a Zim session through the SESSIONID parameter without restriction.
  • disable-start – ignore requests to start a persistent Zim session in the input parameters (i.e. a blank SESSIONID parameter). You can start the persistent Zim session with the start-zim-session command instead.
  • restrict-start – ignore requests to start a persistent Zim session in the input parameters (i.e. a blank SESSIONID parameter) if the parameter TEMPLATE does not include the SESSIONID parameter. This is the default setting, which should work with existing ZimCGI applications. This should be combined with specifying all the parameter templates in the “Security” declarations in the configuration file, of course.
  • restrict-continue – prevent starting or continuing a persistent Zim session in the input parameters (i.e. a SESSIONID parameter – blank or not – without also an ENDSESSION or CANCELSESSION parameter) if the parameter TEMPLATE does not include the SESSIONID parameter.
  • http-session – the input parameters SESSIONID, ENDSESSION and CANCELSESSION are ignored; instead, ZimWeb stores the SESSIONID automatically in the HTTP session; and it is the exclusive responsibility of the Zim application to start and stop persistent Zim sessions through the start-zim-session, end-zim-session and cancel-zim-session commands; also, it is not necessary to have the SESSIONID in the parameter TEMPLATE, nor output the SESSIONID into a hidden field.
  • disable – the input parameters SESSIONID, ENDSESSION and CANCELSESSION are ignored.
Debugging
allow-debugThis is the default state of the client debug capability.
If yes then the client debug capability will initially be enabled when the ZII is started; if no (the default value) them it will initially be disabled.

Configuration File Extensions

Specified parameter templates
SecurityWith ZimCGI, you can specify the Zim procedures that may be executed in a list following the Security tag(s) for each connection.
In addition, the ZII allows you to specify the parameter template in parentheses after the procedure name.
e.g. Security MyProc(CC) specifies that MyProc is an allowed procedure, and that the parameter template is (CC), eliminating the need to specify a TEMPLATE parameter.
If a parameter template is specifed in the configuration file, this will override any TEMPLATE parameter in the request.
pt_BRPortuguese