The Mimer Administrator

The Mimer Administrator is used to set up and alter the parameter settings for Mimer SQL databases and any ODBC data sources associated with them.

Use the tab control to select which type of item to display in the list. You can select:

  • Local Mimer SQL Databases
  • Remote Mimer SQL Databases
  • User Specific Mimer ODBC Data Sources
  • System Wide Mimer ODBC Data Sources
  • Mimer SQL License Keys

A new item of the type displayed can be created by selecting Add. Select an item in the list, and use Remove to dispose of its definition or Configure to alter its parameter settings. When a local database definition is removed the actual database files are not deleted.

Under Windows 2000/XP/Vista:

You must be a Windows Administrator if you wish to manage System Wide ODBC data sources, Local, or Remote databases. User specific ODBC data source management may be performed on a per-user basis and may be undertaken by any user.


Local Mimer Databases

Local Mimer SQL Databases

A local Mimer SQL database is one that resides on the machine you are using. The local definition of a database sets the parameters that may be adjusted for tuning purposes.

You can manage local Mimer SQL databases when these have been selected as the type of item to be listed by the Mimer Administrator. The list will display the local Mimer SQL databases that have been defined using the Mimer Administrator.

You set up a new local Mimer SQL database definition by selecting Add and specifying the parameter settings.

You can alter an existing local Mimer SQL database definition by selecting it in the list before using Configure and specifying new parameter settings. If the database is running, it must be stopped and restarted before any parameter adjustments will take effect.

You can remove the definition of a local Mimer SQL database by selecting it in the list before using Remove to dispose of it. The database files are not deleted by this operation.


Local Database General Parameters

The definition of a Local Mimer SQL Database involves the following parameters:

  • Database name
  • Description
  • Home directory
  • Databank check option
  • Maximum number of users
  • Create System Data Source

Some of the parameters are not shown when the dialog appears. Clicking on the "Server", "Memory" or "Communication"tab will show additional parameters.

When you are changing an existing local database definition, the current parameter settings are shown and may be altered. When you are creating a new local database definition, suggested settings are supplied for all the parameters except Database Name and Description. The database description is an optional parameter, so it may be left blank.

When creating a new database definition, all the parameters for the "Server" and "Bufferpool" tabs will have suitable suggested values supplied, so changing these values is optional.

Select Apply or OK to set up the local database definition with the specified parameters, or Cancel to close the dialog without creating or changing anything.

All the required parameter settings should be specified before OK is selected.

All the required parameter settings must be specified before Apply can be selected.

Note that if you have adjusted the parameters for a database that is running, the new settings will not take effect until the database is stopped and restarted.

To begin using a database, it must have a local database definition, its databanks must have been successfully created during the definition process and it must have been started.

Under Windows 2000/XP/Vista:

When a database is created, a Windows service is created for it and is called

"MIMER-<database_name>". It is this service that is started when the database is started.

See also: stopping and starting Mimer SQL databases servers.


Local Database Name

Database Name

This is the name that is used to refer to a database after its definition has been created. The database name appears in the list of databases when creating a Mimer ODBC data source and it is the name that must be specified when defining remote access to the database.

See also: other general database parameters


Local Database Description

Database Description

This string provides descriptive information about a database definition. This is not a required parameter, so you may leave it blank.

See also: other general database parameters.


Home Directory

This path defines the base directory for a database. The system databank SYSDB is created in this directory by a utility (SDBGEN), which is automatically invoked when a local database is created. At the same time, locations are specified for the other system databanks and these are created. Databank location information is stored in SYSDB. Diagnostics about database crashes and logging information may also be stored in, or below, the home directory.

You can either fill in a path for the home directory, or use the browse button to specify it.

If you are creating or changing a local database definition, and specify a home directory that does not exist, you will be asked if it should be created. Select Yes to create it or No to specify an alternative.

If the specified directory does not contain the system databank SYSDB, you will be asked if it and the other system databanks are to be created. Select Yes to create them, otherwise select No.

If you specify a pathname for a databank that already exists, the system databank creation operation will fail and it will be necessary to manually clean up any databanks that were actually created. You can then set the Home Directory again to repeat the creation of system databanks.

The home directory is really the foundation of the database because all the database data is found by working from this directory. If you specify a new home directory for an existing database definition, a new set of system databanks will be created, effectively setting up a new database with no knowledge of the data it had earlier.

See also: specifying a path, other general database parameters.


Specifying a Path

Example: "C:\MIMER\DB1"

A path is usually composed of a drive specification and the directory specification. In the example shown above, the drive specification is "C:" and "\MIMER\DB1" is the directory specification. You must specify an absolute directory path for the database home directory, i.e. a path that starts with a "\", otherwise a relative path below the current directory is assumed. Since the default directory of the database server is usually not known a relative path may not use the intended location.


Databank Check Option

Whenever a database is started, its databanks are checked to find out if they were properly closed when it went down. If a databank is found that was not properly closed, an internal check is performed on it. This parameter controls whether both the index and data pages of a databank are checked, or just the index pages. Checking just the index pages is faster but any corruption in the data pages will not be detected.

Check All Pages performs a full check of both index and data pages.

Check index pages only perform a faster check that does not check the data pages.

See also: other general database parameters.


Maximum Number of Users

This defines the maximum number of users who can connect to a database concurrently. Note that your Mimer SQL license places a limit on the total number of database users permitted at your installation.

The number of users are allocated at run-time. If you have several database servers they may run out of users if the total number of users in all systems exceeds the number allowed by your Mimer SQL license.

Example:

The Mimer SQL license for an installation permits a total of 250 concurrent database users. Database 'A' is defined with maximum number of users set to 100, and Database 'B' is defined with maximum number of users also set to 200. The system will allow both servers to start, since none of them exceeds the limit 250. However, when 250 connections have been made in both servers together no more users are allowed until someone logs out.

See also: other general database parameters.


Create Data Source

Create System Data Source

If you check the check box, a system wide data source will be automatically created and associated with the local Mimer SQL database that is being created. The data source will be given the same name as the database. The description for the database is inherited by the data source.


Local Database Server Parameters

The following local database parameters can be viewed by using the "Server" tab after the dialog displaying local database parameters first appears:

  • Request threads
  • Background threads
  • Server priority class
  • Request thread priority level
  • Background thread priority level
  • Startup setting
  • Server restart setting

See also: general database parameters, memory parameters, communication parameters


Request Threads

These are the database request threads that execute users' database requests. Increasing the number of them can improve database performance where database request demand is high. The number of concurrent threads may be limited by the bufferpool size because each thread requires approximately 5 pages of each size from the bufferpool.

Note that is necessary to stop and restart the database after changing this parameter, before the new value will take effect.

A user request typically employs a request thread for a fraction of a second, but a request may also span over several seconds or even minutes. Practical tests have shown that 6 to 8 request threads can support hundreds of users. The initial value suggested when a database definition is created is 8.

The actual number of request threads required depends on the level, and type, of demand for database access. You can use MIMINFO, and choose Performance in the view menu, to display the current number of request threads.

See also: the bufferpool, stopping and starting the database, request thread priority level, other database server parameters.


Background Threads

These are background database server threads that perform housekeeping tasks, such as:

  • Writing transactions to LOGDB
  • Updating databanks
  • Updating shadow databanks
  • Forcing transaction updates to disk

There should be enough background threads to perform such tasks as quickly as possible. Generally the suggested number (3) is sufficient, but if the database uses databank shadowing or very large transactions this number may have to be increased.

You can determine the most appropriate number of background threads by increasing their number and restarting the database. Check the loading on each background thread by using MIMINFO with the performance option, or by monitoring their CPU usage using operating system tools. If some of the background threads are not being used, their number can be reduced.

See also: background thread priority level, stopping and starting the database, other database server parameters.


Server Priority Class

This sets the priority class of a database server process. The Windows scheduler uses this setting to determine when the database server and its threads get CPU time relative to other processes running at the same time.

The database server will get CPU time in preference to processes with a lower priority class, and will be pre-empted by processes with a higher priority class. The priority classes are:

Idle - the lowest priority class, which is not recommended for a database server in normal use. A process with this priority class will only get CPU time when the system is idle (screen savers typically have this priority class).

Normal - the most usual priority class, and the one suggested for the database server.

High - this priority class is normally given to a process performing time-critical tasks which must be performed immediately. It is generally only recommended where the tasks are of short duration. A process with this priority class, and a high CPU requirement, is likely to starve other processes of CPU time.

Realtime - the highest priority class, which is not recommended for a database server in normal use. A process with this priority class can pre-empt some operating system processes and produce effects like, failure to flush disk caches or a lack of mouse response.

The priority class of the database server process determines the base priority level for its request and background threads.

See also: thread priority levels, other database server parameters.


Thread Priority Levels

The priority level for a thread is a scheduling weighting that is applied within the priority class of its owning process.

The thread priority levels are:

  • Idle
  • Lowest
  • Below Normal
  • Normal
  • Above Normal
  • Highest
  • Time Critical

The combination of process priority class and thread priority, defines a range of scheduling priorities with some overlap. The lowest thread priority in a priority class gives the same scheduling priority as the highest thread priority in the priority class that is one lower.

See the Win32 Programmers Reference for a more detailed discussion of thread priorities.


Request Thread Priority Level

This determines the relative scheduling priority for the request threads of the database server. The request threads are the threads that perform the actual work requested the database clients. The scheduling priority for a request thread is defined by the database server priority class and its own scheduling priority.

See Thread Priority Levels for the different settings you may select.

See also: request threads, other database server parameters.


Background Thread Priority Level

This determines the relative scheduling priority for the background threads of the database server. The background threads perform work such as performing the actual database updates, securing data on disk and The scheduling priority for a background thread is defined by the database server priority class and its own scheduling priority.

See Thread Priority Levels for the different settings you may select.

See also: background threads, other database server parameters.


Startup Setting

This determines when the database is started.

Under Windows 2000/XP/Vista:

The settings are:

Autostart - the database is started when the node it resides on gets re-booted

Manual - the database must be started manually

Disabled - the database cannot be started.

Under Windows 98/ME:

The settings are:

Autostart - the Mimer SQL database server starts automatically when a connection to the database is requested.

Manual - the Mimer SQL database server must be manually started.

Disabled - the database server cannot be started.

See also: starting databases, server restart setting, other database server parameters.


Server Restart Setting

This determines what happens after an uncontrolled database server shutdown

The settings are:

Automatic - Restart the database server automatically

Manual restart - The database must be restarted manually

When Automatic is used no dialog box will be presented to the user when the server fails. I.e. the user may not start Dr. Watson or a debugger to capture additional information about the failure. However, in most situations the database server stores all relevant information in dedicated dump directories and in the event log (on Windows 2000/XP/Vista) or in the MIMER.LOG file (on Windows 98/ME).

See also: starting databases, other database server parameters, startup setting


Local Bufferpool Parameters

Local Database Memory Parameters

The parameters that control memory consumption by the database server are divided into two areas, the bufferpool and the SQLPool. The bufferpool contains pages that hold actual database data and various control information about databanks, tables, and transactions in the system.

The SQLPool contains information about users logged into the database system, compiled SQL statements and procedures, and so on. The SQLPool will automatically allocate additional space if needed. The upper limit for this, is the amount of paging file allocated on the machine or the amount of memory a single process may allocate. It is possible to restrict the amount of memory consumed by the database server by specifying a maximum size for these areas.

  • Bufferpool parameters
  • SQLpool parameters

See also: general database parameters, database server parameters, communication parameters


Local Bufferpool Parameters

Local Database Memory Parameters

The bufferpool contains pages that hold actual database data and various control information about databanks, tables, and transactions in the system. The following bufferpool parameters can be viewed by using the "Memory" tab after the dialog displaying local database parameters first appears:

Parameter | Description
2K bufferpool pages | This sets the number of 2K size pages to allocate to the bufferpool. 2K pages are used to cache tables with short record lengths. The value can be specified as a range (100-500) for servers running in the Windows Mobile environment.
16K bufferpool pages | This sets the number of 16K size pages to allocate to the bufferpool. 16K pages are used to cache tables with intermediate record lengths and also for transaction control. The value can be specified as a range (100-500) for servers running in the Windows Mobile environment.
64K bufferpool pages | This sets the number of 64K size pages to allocate to the bufferpool. 64K pages are used to cache tables with long record lengths. The value can be specified as a range (100-500) for servers running in the Windows Mobile environment.
Transactions | Each active transaction is tracked by the system. A transaction starts when an application initiates a transaction, and ends when the background threads in the Mimer SQL database server has finished processing the transaction. A typical values is 2000 transactions.
Databanks | The databanks are the physical files that store the database information. This parameter controls how many databank files may be held open at the same time.
Tables | This parameter defines the maximum number of tables that may be open concurrently in the database.

See also: Setting the bufferpool size, SQLPool parameters, general database parameters, database server parameters, communication parameters


Setting the Size of the Bufferpool

The bufferpool is the main memory cache used by the Mimer SQL database management system. It is divided into sections with different page sizes. There is a section for 2K pages, a section for 16K pages and a section for 64K pages.

Whenever the bufferpool is full and access to a new page is required, space is released from it by deleting the least-recently used page. Frequent page replacement operations will detract from database performance. In general, maximizing the bufferpool size will give the best database performance.

In practice, however, it is necessary to find a suitable compromise between allocating as much memory to the bufferpool as possible, and keeping enough memory available for applications and operating system tasks.

If there is insufficient memory available for applications and operating system tasks, the resulting virtual memory swapping will also adversely affect performance.

The compromise between allocating memory to the bufferpool or leaving it generally available will be influenced by factors such as: the predominant type of application being run, the number of concurrent database users and the demands of the operating system.

Fine-tuning of the size of the bufferpool should be done when the database is fully set up and operational and should be repeated whenever there is a significant change in the computer workload distribution. The MIMINFO utility should be used regularly to gather bufferpool statistics for tuning purposes.

Whenever there is unused memory available, it is generally a good idea to allocate this to the bufferpool. If more than 5% of all Mimer SQL page requests result in a page fault, the bufferpool size is too small and should be increased.

Care should be taken to ensure that the bufferpool is never subjected to system paging because forced co-operation between the system and Mimer SQL paging algorithms will generally detract considerably from database performance.

If the statistics from MIMINFO show that some pages in the bufferpool are never used, Mimer SQL database performance is not being limited by the bufferpool size. However, performance may still appear adversely affected if insufficient memory is available for applications and the operating system because it is, perhaps unnecessarily, allocated to the bufferpool. In situations like this, the size of the bufferpool should be reduced.

Servers executing in the Windows Mobile environment allow the number of pages in each section (2K, 16K or 64K) to be specified as a range (for example 100-500). The lower limit is the number of static pages allocated initially when the server is started. Additional dynamic pages will be allocated when needed, but the total number of pages will never exceed the upper limit. The additional pages are released if system resources are running low on the device. Note that a low lower limit will make the system slow in the beginning and that a too high upper limit is likely to strain the distribution of memory resources in the system.

See also: bufferpool parameters.


SQLPool

SQLPool Settings

There are two SQLPool parameters: SQLPool initial size and SQLPool maximum size. The initial size is not critical as the pool automatically grows up to the maximum size.

Three things may limit the maximum size:

1) The amount of paging file in the machine.

2) The amount of memory the database server may allocate (The current version of the operating system has a limit of 2 giga-bytes). This includes stacks, code, the bufferpool, the SQLPool, and various other internal data areas of the database server.

3) The maximum number of kilobytes specified in the dialog box.

See also: other memory parameters.


Local Communication Parameters

Local Database Communication Parameters

The communication parameters determines what communication protocols can be used to exchange information with the database server. The parameters also determine how an actual connection is initiated. This is described further for each communication protocol supported.

The following communication parameters can be viewed by using the "Communication" tab after the dialog displaying local database parameters first appears:

  • Local Communication
  • TCP/IP
  • Named Pipes

Local communication uses shared memory to communicate between processes within the same machine. TCP/IP and Named Pipes are used when client computers communicate over a network with a database server on another machine in network.

See also: general database parameters, memory parameters, database server parameters


Local Communication

Currently shared memory is always used to communicate within a machine. It is the most efficient protocol to communicate with the database server. In the Mimer Administrator the settings may be either <Shared Memory> or <Disabled> for this protocol.

You can disable the protocol if your machine is used solely in a client/server environment. Please remember that if you have application or web servers that are located on the same machine they will use local communication as their preferred communication option.

See also: TCP/IP communication, named pipe communication


TCP/IP Communication

The TCP/IP protocol is the machine independent protocol used to communicate with Mimer SQL Database Servers. It is used to access Mimer SQL from Windows, Unix, MAC, and VMS machines.

The TCP/IP protocol uses IP addresses to find the correct machine. To find the database server within the machine a port number is used. Mimer SQL has been allotted the port number 1360. If you have more than one database server on a machine they can both share the port number 1360. This is done by starting a Mimer TCP service which listens for new connections on port 1360. The Mimer TCP service will then pass the connection to the correct database server. This is the default when installing Mimer SQL on Windows 2000/XP/Vista.

If there is only one database server on a machine the server can listen on port 1360. By doing so, the connection to the database server is made slightly faster. I.e. the logon time may decrease somewhat. This is the default on Windows 95 and 98.

In the Mimer Administrator you can choose <Disabled>, <Name Server>, or 1360. Actually, you can use any port number, but then you need to inform all clients of this as they will, as a default, connect to port 1360.

See also: local communication, named pipe communication


Named Pipe Communication

This protocol is used to communicate between different Windows machines. The protocol requires you to have access to the server you want to access. This protocol therefore gives you higher security than TCP/IP. It is also possible to use the OS-login feature in Mimer SQL over a network with this protocol (see CREATE IDENT AS OS_USER in SQL reference manual).

Each database server typically waits for connections on a named pipe with the same name as the database. Because of this the need for a central service is not as evident as for TCP/IP. However, previous versions of Mimer SQL always connected to the named pipe called MIMER. Therefore, to ease migration it is possible to let the Mimer Named Pipe service wait for connections to MIMER and then pass them on to the correct database server.

In the Mimer Administrator you can choose between <Disabled>, <Database Name>, or <Name Server>. Actually, you can enter any name, but in this case all clients must be aware of this fact. Also note, if you choose <Database Name> that you must enter the database name for the service argument for all older versions of Mimer SQL. In version 8 and later this is the default.

See also: local communication, TCP/IP communication


Deleting a Local Mimer Database Definition

Removing a Local Mimer SQL Database Definition

The definition of a local Mimer SQL database can be removed by selecting it in the list of local Mimer SQL databases and choosing Remove.

Use the tab control to get a list of local Mimer SQL databases.

You will be asked to confirm that you wish to remove the local database definition. Select Yes to dispose of it or No to retain it.

Note that only the definition of the database is removed, not the databanks or other physical data. Information about the databanks is held in the data dictionary and the physical storage for a databank is deleted from disk when the databank is dropped.


Local Database Popup Menu

By right-clicking on a local database you gain access to additional commands to control the database server. The following operations are supported:

  • Start Server - Starts the database server. This command is enabled when the database server is stopped.

  • Disable login - No further logins to the database server are alllowed when this option is used.

  • Enable login - Re-enable logins to the database server again.

  • Stop Server - Stops the database server. This command is only enabled when the database server is running.

  • Tools - Databank Check - This command starts the databank check with the home directory for the database as default directory.

  • Tools - Mimer Info - This command starts the Miminfo utility for the selected databank.

  • Tools - Open Home Directory - This command starts the Windows Explorer with the database home directory as default directory.

  • Add - Opens a dialog to create a new database definition.

  • Remove - Removes the database definition.

  • Properties - This command displays the current database settings.

The following additional commands are available when the Mimer SQL Mobile product is installed:

  • Export to handheld/emulation - This command starts the database export wizard. The export copies an entire database to your handheld device or emulation environment. If the target environment is Pocket PC, the target database must have been defined as a remote pocket PC database before the wizard is started. A remote pocket PC database can be defined using the Mimer Administrator by adding a remote database with protocol set to rapi. After defining a new, or configuring an existing definition, the system checks if the database exists when you press the Apply or Ok button. At this point you will be asked to create the database definition on the handheld device.

  • Import from handheld/Emulation - This command starts the database import wizard. The wizards transfers an entire database from your handheld device to the appropriate locations in the file system on your desktop computer. You must have defined a database in the emulation environment for this menu item to be enabled.


Remote Mimer Databases

Remote Mimer SQL Databases

A remote Mimer SQL database is one that resides on another node in the network, not on the machine you are using. Typically it will already be defined, as a 'local database', on the node it resides on.

In practice, you can create the local database definition before or after any corresponding remote database definitions. The purpose of a remote database definition is to set up, on a particular network node, a link with a database that resides elsewhere on the network. The definition for the remote database contains information on how to access the database.

You can manage remote Mimer SQL databases when these have been selected as the type of item to be listed by the Mimer Administrator. The list will display the remote Mimer SQL databases, which are accessible from the node you are using.

You can set up a new remote Mimer SQL database by selecting Add and specifying the parameter settings.

You can alter an existing remote Mimer SQL database definition by selecting it in the list before choosing Configure and specifying new parameter settings.

You can remove the definition of a remote Mimer SQL database by selecting it in the list before choosing Remove to dispose of it.


Remote Database General Parameters

The definition of a Remote Mimer SQL Database involves the following parameters:

  • Database name
  • Description
  • Create System Data Source
  • Node name
  • Protocol

Some of the parameters are not shown when the dialog appears. Clicking on the "Advanced" tab will show additional connection options. These will have suitable default values, so expanding the dialog is not generally necessary.

When you are changing the definition of a remote database, the current parameter settings are shown and may be altered. To create a new remote database definition, you must specify at least: Database Name, Node Name and Protocol.

Note that the Database Name for the remote definition must be the same as that specified for the local definition, thus database names must be unique throughout the network.

Select Apply or OK to set up the remote database definition with the specified parameters, or Cancel to close the dialog without creating or changing anything.

All the required parameter settings should be specified before OK is selected.

All the required parameter settings must be specified before Apply can be selected.

All the required parameter settings must be specified before Apply can be selected.


Remote Database Name

Database Name

This is the name of the database you wish to access remotely. The name you specify must match the name specified when the local definition for the database was created. It will not be possible to connect to the database remotely if the two names differ.

See also: other remote database parameters.


Remote Database Description

Database Description

This is a string that provides descriptive information about the remote database. This is not a required parameter, so you may leave it blank.

See also: other remote database parameters.


Node Name

This is the name of the network node the remote database resides on. This can be a protocol-specific name, e.g. the IP address can be specified for a TCP/IP connection.

See also: other remote database parameters.


Protocol

This is the communications protocol to use when contacting the network node the remote database resides on. You can select one of the protocols provided. Typical protocols are:

  • NamedPipes
  • rapi
  • tcp

NamedPipes is used for Windows-> Windows connections. To use the named pipe protocol you must have the proper access rights in the network/domain you are using.

Rapi, short for Remote Access Programming Interface is used to control a handheld device from a desktop computer. To use rapi you must have your handheld device connected via Microsoft ActiveSync. When this protocol is used to access the handheld device it is possible to control the database server on the handheld device. Right-click on the name in the Mimer Administrator to see available options.

When defining a Remote database with the rapi protocol sequence for the first time a remote database may optionally be set up on the handheld device. Databases may subsequently be exported to the handheld device if Mimer SQL Mobile is installed.

Tcp is used for network access to Unix, VMS, or other Windows systems.

See also: other remote database parameters.


Remote Database Advanced Parameters

The following remote database parameters can be viewed by using the "Advanced" tab after the dialog displaying remote database access parameters first appears:

  • Interface
  • Service

See also: other remote database parameters.


Interface

This is the protocol interface to use when communicating with the remote database. This may be left blank to get the default, or you may select an alternative. You can typically select winsocket as an interface under Windows.

Generally, it is appropriate to accept the default value for this parameter.

See also: other advanced remote database parameters.


Service

This is the service to use when communicating with the remote database. This may be left blank to get the default, or one of the following may be selected:

  • 1360
  • mimer

For tcp/ip, the service corresponds to the port number. Mimer SQL has a registered port number of 1360. For NamedPipes, the service is the name that is used for the named pipe.

Generally, it is appropriate to accept the default value for this parameter.

See also: other advanced remote database parameters.


Deleting a Remote Mimer Database Definition

Removing a Remote Mimer SQL Database Definition

The definition of a remote Mimer SQL database can be removed by selecting it in the list and choosing Remove.

Use the tab control to get a list of remote Mimer SQL databases.

You will be asked to confirm that you wish to remove the remote database definition. Select Yes to dispose of it or No to retain it. Note that only the remote database definition is removed, not the local database definition or its databanks.


Remote Database Popup Menu

By right-clicking on a remote database you gain access to additional commands to control the database server. The following operations are supported:

  • Add - Opens a dialog to create a new remote database definition.

  • Remove - Removes the remote database definition.

  • Properties - This command displays the current remote database definitions.

The following additional commands are available when the Mimer SQL Mobile product is installed:

  • Start Server - Starts the database server on the handheld device. This command is enabled only when the database server is stopped.

  • Disable login - No further logins to the database server on the handheld device are alllowed when this command is used.

  • Enable login - Re-enable logins to the handheld database server again.

  • Stop Server - Stops the handheld database server. This command is only enabled when the database server is running.

  • Export to handheld/emulation - This command starts the database export wizard. The export copies an entire database to your handheld device or emulation environment. You must have defined a database in the emulation environment for this menu item to be enabled. If you have no database defined there, you must first create one by creating a remote database with protocol set to rapi. After defining a new, or configuring an existing defintion, the system checks if the database exists when you press the Apply or Ok button. At this point you will be asked to create the database definition on the handheld device.

  • Import from handheld/Emulation - This command starts the database import wizard. The wizards transfers an entire database from your handheld device to the appropropriate locations in the file system on your desktop computer. You must have defined a database in the emulation environment for this menu item to be enabled.

  • Handheld Properties - This command displays the current database settings on the handheld device or in the emulation environment.


Mimer ODBC Data Sources

An ODBC Data Sources is used to access Mimer SQL databases from the Open Database Connectivity interface. Mimer SQL simply maps an ODBC data source to a Mimer SQL Database. I.e. when defining a data source it is given a name and associated with a database.

There are several types of data sources such as user data sources and system data sources. A user data source is only accessible for the current user while a system data source is available for anyone logged onto the machine.

  • User Specific Mimer ODBC Data Sources
  • System Wide Mimer ODBC Data Sources

You can remove the definition of a Mimer ODBC Data Source by selecting it in the list and choosing Remove to dispose of it.


User Specific Mimer ODBC Data Sources

A User Specific Mimer ODBC Data Source is an ODBC data source that is associated with a local or remote Mimer SQL database. The definition only applies to the currently logged in user. The Mimer Administrator allows you to set up this kind of data source and associate a Mimer SQL database with it. The ODBC Administrator can also be used for this.

If both a user specific and a system wide data source exists with the same name, the user specific data source takes precedence.

You can manage User Specific Mimer ODBC data sources when these have been selected as the type of item to be listed by the Mimer Administrator. The list will display the User Specific Mimer ODBC data sources that have been defined using the Mimer Administrator or the ODBC Administrator.

You define a new Mimer ODBC Data Source by selecting Add and specifying the parameter settings.

You can alter the set-up for an existing Mimer ODBC Data Source by selecting it in the list before choosing Configure and specifying new parameter settings.

You can remove the definition of a Mimer ODBC Data Source by selecting it in the list and choosing Remove to dispose of it.


System Wide Mimer ODBC Data Sources

A System Wide Mimer ODBC Data Source is an ODBC data source that is associated with a local or remote Mimer SQL database. The data source may be used by any user who loggs in on the machine you are using.

You can manage System Wide Mimer ODBC data sources when these have been selected as the type of item to be listed by the Mimer Administrator. The list will display the System Wide Mimer ODBC data sources that have been defined using the Mimer Administrator or the ODBC Administrator.

You define a new System Wide Mimer ODBC Data Source by selecting Add and specifying the parameter settings.

You can alter the set-up for an existing Mimer ODBC Data Source by selecting it in the list before choosing Configure and specifying new parameter settings.

You can remove the definition of a Mimer ODBC Data Source by selecting it in the list and choosing Remove to dispose of it.


Mimer ODBC Data Source Parameters

To set up a user specific or system wide Mimer ODBC data source, a Name and a Description should be specified, and the Mimer SQL database it is to be associated with should be selected. You can select from a list of the local and remote Mimer SQL databases that have been defined using the Mimer Administrator.

When you are configuring the set-up for an existing Mimer ODBC data source, the current parameter settings are displayed and may be changed.

Select OK or Apply to set up the data source definition with the parameter settings you have specified, or Cancel to close the dialog without creating or changing anything.

A Mimer ODBC data source definition requires a name and a Mimer SQL database. It will not be possible to select OK until both these parameters have been specified. The Description is optional, so it may be left blank.

If you select <New Local Database> you can create a new Mimer SQL database definition. If you select <New Remote Definition> you can describe how to access a Mimer SQL database server on another machine. It is also possible to view and/or modify an existing database definition by selecting the database and then click with the right mouse button on the database. Then select Properties from the popup menu that appears.


Deleting a Mimer ODBC Data Source Definition

Removing a Mimer ODBC Data Source Definition

The definition of a user specific or system wide Mimer ODBC data source can be removed by selecting it in the list displaying Mimer ODBC data sources and choosing Remove.

Use the tab control to display the list of System Wide or User Specific Mimer ODBC data sources.

You will be asked to confirm that you wish to remove the data source definition. Select Yes to dispose of it or No to retain it. Note that only the definition of the Mimer ODBC data source will be removed, not the database it is associated with.


Entering a New Mimer License Key

Entering a New License Key

Your Mimer SQL license controls various aspects of your Mimer SQL software and is obtained from your Mimer distributor. The parameter settings for your license are coded into the key which must be specified after you have installed your Mimer software and before you can use the software. Typically the Mimer SQL system is distributed with a default key.

All licenses are server based, i.e. the clients do not need to have any license key. Each time a Mimer module is started, the license is checked on the server to make sure the application is permitted to run. If you buy additional modules, or have certain system limits altered, you will be issued with a new license key.

It is possible to have several license keys. The effect of several keys are cumulative.

The Mimer Administrator allows you to enter the new key to enable additional modules or to set new limits.


Wizard Startup Page

Mimer SQL Wizards

The Mimer SQL Wizards are automatically invoked when using the Mimer Administrator. The wizard can also be started by using the popup menus for local and remote databases. To learn more about the different wizards follow the links below:

  • System Databank Wizard
  • Example Databank Wizard
  • Upgrade Wizard

The following wizards are only available in the Mimer SQL Mobile product:

  • Export to Handheld Wizard
  • Import from Handheld Wizard


The System Databank Wizard

The System Databank Generation Wizard

The System Databank Wizard creates the System databanks used by Mimer SQL. There are four system databanks:

Right arrow SYSDB
The System databank is used to store information about all objects in the database system, such as idents, databanks, tables, and so on. This databank is always located in the database home directory.

Right arrow TRANSDB
The Transaction databank stores all information about ongoing transactions. The databank is used to restart the database after uncontrolled shutdown (or machine failure). If possible this databank should be on a separate disk drive.

Arrow right LOGDB
The Log databank stores information about all databanks with LOG option. The information is used to recover a databank after a disk crash. LOG option is therefore only used when a system has three or more disk drives, as LOGDB must be on a separate drive to survive a disk crash.

Arrow right SQLDB
The SQL databank is only used for temporary objects by the system. It contains worktables used for SQL and read-sets used for transaction handling. If complex SQL queries are used which require temporary tables, this databank can grow quite large in order to hold the intermediate results.

The utility scans your system for available hard disk drives. The databanks are spread across the disks according to the following rules:

One disk: All databanks are placed in the database home directory.

Two disks: LOGDB is placed on a separate disk. All other databanks are placed in the database home directory. This is advantageous primarily from a recovery point of view.

Three disks or more: TRANSDB is placed on one disk, LOGDB on the second, and SYSDB and SQLDB in the database home directory. This is advantageous from both a performance and a recovery point of view.

Placing databanks on network drives is not recommended, as this will decrease the performance of your system. Please refer to the Mimer SQL System Management handbook for more detailed information about the system databanks.

Sizes of files in Mimer SQL are specified in number of 2K blocks (2048 bytes). To assist you, each drive referenced has the number of available 2K blocks shown.

The browse button allows you to select the databank filename through an ordinary "Open file"-dialog box.

The SDBGEN utility creates an administrative user called SYSADM. You must set the password for SYSADM. Please note that all passwords in Mimer SQL are case sensitive. Make sure you remember the password for the SYSADM user because there is no way to change the password unless logged in as SYSADM.

Under Windows 2000/XP/Vista:

In addition to the drive letter the disk number is also shown. If a disk has been partitioned into several partitions the same disk number is shown several times. The above discussion only applies to disks and not to partitions. It does not help recovery if LOGDB is placed in one partition, and the other databanks in another partition on the same disk, as a disk crash almost always affect both partitions on the disk. Therefore, use a unique disk number for LOGDB if possible. The actual layout of disks and partitions can be viewed with the Windows disk administrator.

See also: Command line options for SDBGEN


SDBGEN - Command Line

Command line options

The system databank wizard may be customized by calling it with parameters from the command line:

SDBGEN -pSYSADM-PASSWORD Database Sysdb-Size Transdb-FileName Transdb-Size Logdb-Filename Logdb-Size Sqldb-Filename Sqldb-Size

Any parameter where you want to use the default value can be specified as two double quotes (""). All parameters except database-name are optional.

Whenever the -p option is used the program is run in silent mode. In this mode no dialogs are displayed and any missing directories are created automatically. If an error occurs such as disk space exhausted, a dialog is displayed where filenames and/or sizes may be changed. However, the fields for SYSADM password are disabled.

If option -p is not given the values specified will be used as default values in the system databank generation dialog.

Examples of valid command lines assuming a database with the name DB6 exists:

1) | SDBGEN | DB6
2) | SDBGEN | -pSYSpsw DB6
3) | SDBGEN | -pSYSpsw DB6 "" "d:\my directory\TRANS.DBF" 200 e:\logdir\logdb.dbf

In case 1) the ordinary System databank generation is run for database DB6.

In case 2) the program is run in silent mode using the defaults for filenames and sizes as decided by the SDBGEN-program. The password SYSpsw is given to SYSADM.

Finally, in case 3) the default size for SYSDB ("") is used, but the filename for TRANSDB is set to d:\my directory\TRANS.DBF and the size to 200 2K pages. The filename for LOGDB is set to e:\logdir\logdb.dbf. Please note the use of quotes when blanks are included in the file name (for file TRANS.DBF).


Example Environment

Example environment wizard

The Example environment wizard performs two tasks. The first is to create a development user. The development user is used by a programmer who wants to create objects in a Mimer SQL database. The second task is to set up the Mimer SQL example tables and users.

The example environment, MIMER_STORE, contains data used by the fictional business GoodiesRUs. GoodiesRUs sells music, available in various formats and books. An item can be available in various formats, for example a music album may be available in audio CD, cassette, DVD audio, and vinyl. We have created the MIMER_STORE environment to demonstrate how Mimer SQL provides everything from simple to sophisticated functionality. The examples are used throughout the Mimer SQL documentation and provide numerous examples of both simple and advanced features in the system.


Create Development Databank

Mimer SQL uses databanks to store data in the file system. A databank corresponds to a file in the operating system. When creating a table it is possible to specify in which databank the table should be placed.

To get a Mimer SQL system operational the application developer needs access to at least one databank, to store new tables. In a typical Mimer SQL installation the user SYSADM owns all databanks. SYSADM allows other users to store tables in a databank by granting TABLE privilege to the databank.

You need to specify a name for the databank. This name is used in the create databank command. To remove a databank the drop databank command is used.

If no directory is specified, the databank will be placed in the database home directory. Databanks in Mimer SQL have the default file extension .DBF.

Sizes are specified in 2K blocks (2048 bytes). The size is the initial size of the file. If more space is needed, Mimer SQL allocates it dynamically.

The option for the databank specifies the transaction handling for all tables in the databank. Databank option may be NULL, TRANS, or LOG. The default is TRANS option.


Databank options

The databank option decides how transaction handling is used for all tables in the databank. There are three options:

LOG Option

LOG option is the most secure option. Transaction handling is used and all data changes are stored in the log databank (LOGDB). If a disk crash occurs the latest backup can be combined with the log to restore all changes for committed transactions. This option is used when an application is put into production.

TRANS option

TRANS option uses transaction handling for all tables in the databank. The changes are not written to the log databank. This option is typically used during development, as LOGDB maintenance is not needed.

NULL Option

NULL option is used for worktables. The content of a TABLE in a NULL databank is not known after an uncontrolled database shutdown. The tables in a NULL databank are, however, always accessible, it is just not possible to know what rows will be present in a table. Operations are not included in transactions and the changes are made immediately to this type of databank.


Create Development User

The development user is the user you will use for application development. The user will own tables created by the application. The development user will be created by the system administrator SYSADM and will receive TABLE privilege on the databank specified in the previous dialog. The users is also granted SCHEMA privilege. This allows the user to group objects created into different schemas. Please refer to the Mimer SQL Manual for more information.

The password must be at least one character. Passwords are case sensitive in Mimer SQL. When you press OK both the databank and the development user will be created.


Example Wizard - Create Example Users

Create Example Environment Users

The example environment consists of four idents:

In the MIMER_STORE schema most of the objects supported by Mimer SQL are introduced: collations, databanks, domains, idents, sequences, synonyms, tables and views. They are used to demonstrate some of the functionality that is available - constraints; primary, unique and foreign keys; secondary indices, NOT NULL, default values, and column and table check clauses. The schema also includes examples of PSM routines and triggers. This schema contains the following tables: currencies, countries, categories, formats, producers, products, images, items, customers, orders,order_items, stop_words. As the MIMER_STORE user creates the other users he/she can change the password of MIMER_ADM, MIMER_USR, and MIMER_WEB. Because of this it is important for you to remember what password you give MIMER_STORE.

The other idents created show how different users can be given varying level of access depending on who is accessing the system. The user ident MIMER_ADM has access to most database objects and is also allowed to update them. The MIMER_USR ident has read access to the most objects, but cannot make any changes. Finally, the MIMER_WEB ident, has very restricted access and may only see parts of the database.

The passwords must be at least one character. Passwords are case sensitive in Mimer SQL.


Example Wizard - Create Example Databanks

Create Example Environment Databanks

The example environment uses three databanks. They are used to group tables with different attributes into logical groups. Most objects in the example database are owned by the MIMER_STORE ident.

In the dialog you specify where each databank should be placed in the file-system. When determining where to put a databank you usually need to consider how large the file is going to be when tables are fully populated. However, since the sizes of the example databanks are rather limited the is not an issue here. If you do not specify a directory location the files will be placed in the database home directory.


Upgrade database wizard

The Upgrade wizard is used to convert database files from an older versions format to the current version internal database format.

The wizard is typically invoked after a local database definition has been saved in the Mimer Administrator. The system checks if it can find the old database files and asks whether to perform an upgrade or not.The other way to start the wizard is to right-click on the local database, and select the menu-option Upgrade from the popup-menu.


Export Wizard - Introduction

Export to Handheld Wizard - Introduction

This Wizard is part of the Mimer SQL Mobile product.

The Export to Handheld Wizard is used to prepare Mimer databank files for deployment on a handheld device. The actual deployment may be automatically performed by the wizard, or it may be performed manually by the user at a later time. This wizard can automatically deploy databank files to Windows Pocket PC, Smartphone 2003, Symbian UIQ and Symbian Series 60 devices. It is also possible to deploy the databanks in an emulator environment.

An export for a Pocket PC or Smartphone target will copy the databanks to a remote database that must have been defined when the wizard is invoked. The definition is made using the Mimer Administrator

An export for a Symbian UIQ target will copy the database to the device, and optionally create a Symbian installation package (a SIS-file) on the desktop computer, which may be used to deploy the database at a later time.

An export for a Symbian Series 60 target will create a Symbian installation package, which may be installed at once or manually at later time.

The Export Wizard can be started from the Mimer Administrator program by right-clicking on a local or remote database, and selecting the menu-option Export to handheld/emulation from the popup-menu. The Export Wizard can also be executed by running the pdacopyw program (see section Export Command Line Arguments).

The wizard can also be invoked when a definition of a remote Pocket PC database (protocol rapi) is saved by the Mimer Administrator. The system checks if the databases exists, and then asks the user to run the wizard when no database files are found.

To learn more about the emulators see section Handheld emulators.

Choose target environment and click Next to continue using the wizard.


Export Wizard - Source and target specifications

Export to Handheld Wizard - Source and Target Specifications

The sections below describe the source and target specifications for each of the supported environments.

Field | Description
Source Database on desktop computer | Name of source database on the desktop computer. If this field is empty you have no databases defined on the local computer. Use the Mimer Administrator to create a local database.
SYSADM Password | Only the system administrator, SYSADM, may currently perform this operation. Enter the password for the SYSADM user. Please note that case is significant.
Target database on handheld device | This is the name of the database on the handheld device.
Device target directory for database | This is the target directory for the database on the device. If you are exporting to an existing database, this information item cannot be changed.


Export to Handheld Wizard - Options

Export Wizard - Options

Field | Description
Update Statistics | When this option is choosen the SQL command UPDATE STATISTICS is executed before the database files are moved to the handheld device. In addition to giving the SQL optimizer up-to-date information, the command also removes data in SYSDB not needed on the handheld device.
Apply compression to Data only | This option compresses the database files before moving them to the handheld device. It is recommended that you use this option as it will allow data to be stored more efficiently on the device. This option also affects data that is later inserted into the database on the handheld device. If this option is deselected the database server that holds the data must be stopped in order for the wizard to gain direct access to the files. If the option is selected a consistent snapshot of the database is taken online.
Apply compression to System views | System views that are not used are dropped and removed from the system before exporting. Unused system data, such as error message texts that may not occur in a Mimer SQL Mobile server, are also removed.
Apply compress to System views and metadata | When this option is enabled, system metadata, system schema security and error message texts are removed from the system. Unused system views are also removed. Enabling this option will produce the smallest database files and is appropriate for Mimer SQL Micro servers. Note: Database files exported with this option enabled can not be imported, since their original state cannot be recovered.
Overwrite existing database files on handheld | If you are exporting data to a database that already exists, this option will overwrite the old files. An export to a handheld device always collects all database files into a single directory. Therefore it is not possible to overwrite data from another database.


Export Wizard - Completing the wizard

You have now exported a database to the handheld device or emulation environment. This data can now be accessed by applications running on the desktop, or from applications on the handheld device or emulator.

The database server on the handheld device will start automatically when you try to connect to it.

The database can later be moved back to your desktop using the import wizard.


Pocket PC Emulators

Handheld Emulators

Mimer SQL Mobile supports a large number of emulators in the Windows environment. These emulators are used with Visual Studio 2005.

One emulator for Symbian is supported by Mimer SQL Mobile.

Pocket PC emulators and Smartphone 2003 emulators

Emulators from the following software development kits may be used with Mimer SQL Mobile:

  • Windows Mobile 5.0 SDK for Pocket PC
  • Windows Mobile 5.0 SDK for Smartphone
  • SDK for Windows Mobile 2003-based Pocket PCs
  • SDK for Windows Mobile 2003-based Smartphones

To work with an emulator, you perform the following steps:

  1. Start the Device Emulator Manager on the Visual Studio 2005 tools menu.
  2. Right click on an emulator and choose Connect.
  3. When the emulator is running right click again and choose Cradle. At this point ActiveSync should start and connect to the emulator. If it does not, make sure that the Connection Settings on the File menu in ActiveSync allows connections to DMA.
  4. If Mimer does not automatically start a Mimer installation choose Add/Remove programs on the Tools menu in ActiveSync. Install Mimer by checking the appropriate check-boxes.
  5. In the Mimer Administrator create a Remote database with protocol set to Rapi.
  6. You will be prompted to:
    • Create a database definition on the device (emulator in this case).
    • Create a database directory on the device.
    • Export database files to the device.
  7. Test the Mimer installation on the device with, for example, the Mimer Explorer.
  8. Deploy and run your Mimer SQL Mobile applications on the emulator.

Symbian emulator

The Symbian emulator comes with the Symbian SDK (Software Development Kit). This emulator shares environment with the Windows system installed, and partly runs in its own environment.

In particular, the file system and TCP/IP-stack for MIDlets is shared with the Windows system, while other components use the Symbian native TCP/IP-stack.

When Mimer SQL database files are exported to the Symbian emulator, database files should be placed in the emulators \data\Mimer. Once database files has been exported, the Mimer database server may be started. Note however that since the Mimer SQL exporting tool cannot stop and start server you have make sure the emulator server i stopped before attempting to export.

Currently, Mimer cannot import databank files from the Symbian emulator.


Export Wizard - Command line arguments

Export to Handheld Wizard - Command line arguments

The Export to Handheld Wizard may be controlled by calling it with arguments from the command line.

pdacopyw [--architecture=PPC | UIQ | S60]
[--targetdatabase=DeviceDatabaseName]
[--disable=overwrite]
[--disable=statistics]
[--compress=none | data | systemviews | metadata]
 [--password=Password]
 [--silent] SourceDatabase [TargetDirectory]

The long or short form of a switch may be used. In the command above the long form is hown. The following table contains a description of the arguments:

Switch | Description
--architecture=value -a value value: PPC, UIQ, or S60 | Selects target architecture. Microsoft Pocket PC (PPC), Symbian UIQ (UIQ) or Symbian Series 60 (S60) may be specified. If switch is omitted, only the architecture independent parts of the export sequence is performed, and database files are not transferred to the device.
--targetdatabase=value -t value value: Database name | Selects device target database name. If omitted, the same database name as the desktop source is assumed.
--disable=overwrite -d overwrite | Disable Overwrite. Target database files are not allowed to be overwritten if this option is given.
--disable=statistics -d statistics | Disable Update statistics. Updating statistics is not performed if this switch is given. This may affect the size of SYSDB as some information is removed by the update statistics command.
--compress=value -c value value: none | data | systemviews | metadata | Specify level of compression and size optimization. --compress=none will disable compression and no size optimizations will be made. A --compress=data option will compress the databank files. In addition to the compress data, --compress=systemviews will remove unused system views from the system. --compress=metadata will also remove additional system metadata.
--password=value -p value value: SYSADM password | SYSADM password. If omitted, the wizard will ask for the password. If the -s option is used, this option is mandatory.
--silent -s | The wizard runs without prompting for input values.
SourceDatabase | The name of the database to export databank files from. This is either the name of an existing database, or if running in standalone mode a directory containing the system databank file (SYSDB).
TargetDirectory | A directory where to place the exported databank files.

All arguments except --silent affect options that can be set in the wizard. By providing the silent-argument the wizard will automatically execute, i.e. if the arguments supplied are complete and valid. Information about the different arguments can be found in the help for the corresponding wizard page.

The same program, pdacopyw, is used for both export and import. Further information about arguments for pdacopyw can be found in the Import wizard command line description.

Standalone mode

The Export to Handheld Wizard may be executed in standalone mode. Standalone mode disables features that requires Mimer SQL to be properly installed on the desktop. To enable standalone mode, the environment variable MIMER_MODE should be set to STANDALONE before the wizard is started.

When exporting in STANDALONE mode, these features are disabled:

  • Source database lookup by name. The source database must be specified by directory name.
  • Export to target handhelds (no --architecture option is allowed).
  • Target database names (the --targetdatabase option is not allowed).
  • Installation files may not be created.

Examples

Export the databank files from the database with the name THE_DATABASE to the directory c:\EXPORT.

pdacopyw THE_DATABASE c:\EXPORT

Export the databank files from the database THE_DATABASE to the Pocket PC handheld database CE_DATABASE.

pdacopyw --architecture=PPC --targetdatabase=CE_DATABASE THE_DATABASE

Perform the previous operation silently.

pdacopyw --architecture=PPC --targetdatabase=CE_DATABASE --silent THE_DATABASE

Perform the export to directory silently.

pdacopyw --architecture=PPC --silent THE_DATABASE c:\EXPORT

Perform the previous operation silently, and skip the Update Statistics step.

pdacopyw --disable=statistics --architecture=PPC --silent THE_DATABASE c:\EXPORT

In standalone mode, export the databank files from the directory c:\THE_DATABASE to the directory C:\EXPORT. Use maximum compression to reduce database file sizes. Note that this will fail if a running database has these databank files open.

pdacopyw --compress=metadata c:\DATABASE_HOMEDIR c:\EXPORT


Import Wizard - Introduction

This Wizard is part of the Mimer SQL Mobile product.

The Import from handheld environment wizard is used to move database files from a handheld device to a local database on a desktop computer. Both the database on the handheld device and on the desktop must have been defined when the wizard is invoked. Import is supported from the Pocket PC environment and is not supported from the Symbian environment.

The same program, and interface, is used when importing databases from the Pocket PC emulation environment to the desktop.

The wizard is started by right-clicking on a local or remote database, and selecting the menu-option import to handheld/emulation from the popup-menu.

Note: Please be very careful with this function as an entire database on the local computer may be replaced by the database from the handheld device. When this happens the database on the local computer will be lost and you have to revert to your latest backup if you do this inadvertently. The wizard will display extra pages and warn when this is about to occur.

To learn more about the emulators see section Pocket PC emulators.

Click Next to begin using the wizard.


Import Wizard - Source and target specifications

Select whether ActiveSync should be used to transfer the files or if you are using the Pocket PC emulator. If you are unsure, see section Pocket PC emulators for further instructions.

Field | Description
Source database on handheld device | Name of source database on the handheld device or emulator. If this field is empty you have no databases defined on the handheld device. This is done by defining a remote database with the protocol set to rapi in the Mimer Administrator.
Target database on desktop computer | This is the name of the database on the desktop computer. If this field is empty you have not defined any databases on your device. This is done by defining a local database in the Mimer Administrator. Please make sure that you do not inadvertently overwrite a database that contains production data.


Import Wizard - Confirm Database Files Delete

You are importing a database from your handheld device. The database you are importing to on your desktop computer already contains data files. These database files will be deleted and replaced with the files from your handheld device. You should be absolutely certain you want to throw away the existing database files before filling in the check box, to allow the wizard to proceed. If you press cancel no changes will be made.

The name of each databank along with the associated file in Windows is displayed.


Import Wizard - File Copy Conflict

The import wizard has at this point copied the system databank from your handheld device to a temporary location. When examining the contents of the system databank references to files were found that already exist on your computer (presumably because another database has files in these locations).

If you select cancel no changes will have been made by the wizard.

If you proceed to copy the files from the handheld device they will be placed in new locations in order not to interfere with the files already present on your desktop computer. To get the copied database working you have to update the system databank with information where the files are now located. There are two categories of files:

System databanks

To change the filename for the system databanks TRANSDB, LOGDB, and SQLDB you start the database server and then invoke the Batch SQL program (found in the Mimer SQL folder on the start menu). The Batch SQL program will prompt you for the filenames of each system databank that it does not find.

User databanks

Locations of user databanks are updated with the SQL command ALTER DATABANK. In the wizard the actual ALTER DATABANK commands are shown. Take a note of these and perform them from Batch SQL or any other interactive SQL program of your choice.


Import Wizard - Completing the wizard

You have now imported a database to the handheld device or emulation environment. You can now select to have the database server started by the wizard.

If you encountered file copy conflicts during the import operation you should now make updates to the filenames in the system databank.

The database can later be moved back to your handheld device using the export wizard.


Import Wizard - Command line arguments

The Import wizard may be controlled by calling it with arguments from the command line.

pdacopyw --import
 [--files]
 [--silent] LocalDatabase HandheldDatabase

The following table contains a description of the arguments:

Switch | Description
--import -i | Import. Without this argument an export operation is performed instead.
--files -f | Delete existing database files
--silent -s | The wizard runs without prompting for input values.

All arguments except --silent affect options that can be set in the wizard. By providing the silent-argument the wizard will automatically execute if the arguments supplied are complete and valid. In silent mode the wizard fails if the imported database contains files that exist in the file system (that are not part of the database that is replaced, if option --files is used). When running the wizard interactively the system renames the imported files if the user does not cancel this action.

Information about the different arguments can be found in the help for the corresponding wizard page.

The same program, pdacopyw, is used for both export and import. Further information about arguments for pdacopyw can be found in Export wizard command line description.


The MIMINFO Utility

The MIMINFO Utility can be used by the system administrator to generate statistical information about a Mimer SQL database during use. If the MIMINFO output is to be used as an aid to system tuning, it is important to generate it while the system is in full use. The output collected over a period of a few hours or days can provide valuable information about fluctuations in system usage.

Note that under Windows 2000/XP/Vista, the Performance Monitor is also a valuable tool for this kind of monitoring. It is possible to monitor a Mimer SQL database server running on a Windows 2000/XP/Vista, Windows 98/ME or any other platform running a Mimer SQL server with the Windows Performance Monitor.

The output from MIMINFO is presented in a window, which provides Notepad-style functionality. You can select which statistics to display, by choosing the appropriate item from the view menu. It is also possible to select Refresh from the view menu to clear the window and output a new set of statistics.

Statistical information is generated by MIMINFO about the following:

  • Users
  • Performance
  • SQL Pool
  • Bufferpool


User Statistics

User statistics displays information about users currently logged into the database server.

The following user statistics are displayed: Mimer SQL user name, channel number, connection state, start transaction number, name of operating system user, network protocol and client address information.

Channel numbers can be used as parameters to the mimcontrol utility in order to explicitly log out users from the server.

The connection state indicates whether the database server is currently processing a request from the application in which case the text Busy is displayed.

A start transaction number indicates that the user has an active transaction. The number indicates the point in time when the transaction was started.

The name of the operating system user is only provided for local connections.

The network protocol can have the values Local, TCP or Pipe.

The client address information is set to the IP address for TCP/IP clients and to the operating system PID for local clients.


Performance Statistics

Performance statistics includes counters related to a number of different areas:

  • General Statistics
  • Page Management
  • Transaction Management
  • Background Threads
  • Databank Usage
  • Table Usage

It is possible to select Refresh from the view menu to clear the window and output a new set of statistics. The statistics corresponds to statistics generated by the MIMSERV utility in earlier versions of Mimer SQL.

See also: Bufferpool statistics,User statistics


Performance - General Statistics

The following general statistics are displayed in the performance output window:

Statistics | Description
Current date and time | The date and time MIMINFO is run.
Current hardware and operating system. | The hardware platform and the operating system MIMINFO is running against.
Current MIMER/DB version | The release version number of the Mimer SQL database software.
Name of the database | The name specified for the database when it was created using the Mimer Administrator.
Starting date and time | The date and time the database was started.
Status of the database | This is the current status of the database system. If this shows that the database is in an error state, mimcontrol -A should be run before the database is restarted. The Mimer Log should contain information about the cause of the failure.
Error count | This is the number of errors written to the Mimer Log for this database. This value will normally be zero.
Number of request threads | This is the number of Request Threads currently running.
Number of background threads | This is the number of Background Threads currently running.
Number of I/O threads | This value will be 0 under Windows because the request and background threads handle the I/O (there are no dedicated I/O threads under Windows).
Number of users active | This is the number of users logged in to the database.
Number of users denied access | This is the number of login attempts that have been refused because the maximum number of permitted users are already active.
Maximum number of users allowed | This is the maximum number of users permitted to access the database concurrently. This parameter is set for the database using the Mimer Administrator.


Performance - Page Management Statistics

The following page management statistics are displayed in the performance output window:

Statistics | Description
Page buffers per sorter | This is the total number of Mimer SQL pages that a sorting thread may utilize.
Remaining sorters | The initial value is the maximum number of concurrent sorters that are permitted. The current value reflects the number of additional sorters that may be started before no further parallel sorts are allowed. The value will increase if the size of the bufferpool is increased but will never be greater than the number of request threads allowed.
Pages written to disk | This is the number of Mimer SQL pages written to disk and is an indication of the frequency of disk update operations.
Number of file extend operations | This is the number of times databank files have been dynamically extended since the database was last started. For performance reasons, this value should be as low as possible. A databank can be extended manually by using the SQL command ALTER DATABANK.

For each of the buffer sizes (2K, 16K, 64K) the following is displayed:

Statistics | Description
Page buffers | This is the number of page buffers allocated to the relevant bufferpool region.
Page partitions | The buffer pool is divided into separate partitions. Each partition can be accessed concurrently by the request threads. In a tightly-coupled multi-processor system it is desirable, for performance reasons, to have at least as many partitions as there are threads. The number of partitions may be increased by increasing the buffer pool size.
Page requests | This is the total number of times access was required to the buffer pool pages since the database was started.
Page faults | This is the number of page requests that resulted in disk access operations. If this value is more than 5-10% of the total number of page requests, performance can be improved significantly by increasing the buffer pool size.
Pages swapped out | This is the total number of pages which were written to disk when they were swapped out of the buffer pool.


Performance - Transaction Management Statistics

The following transaction management statistics are displayed in the performance output window:

Statistics | Description
Transaction commits | This is the total number of successful read/write transaction commits since the database was started.
Read-only commits | This is the total number of successful read-only transactions since the database was started.
Transaction checks | A high proportion of transaction checks in relation to the total number of transactions may indicate poorly-designed applications, with long transactions which are more likely to give rise to transaction conflicts.
Transaction aborts | This is the total number of transactions that have been aborted by the optimistic concurrency protocol since the database was started. User requested transaction aborts are not counted in this total.
Pending restarts | This is an indication of the amount of information stored in TRANSDB that relates to previous database startups. The number of restarts is counted for each databank used in a transaction. This figure grows larger when shadows are suspended. There should be no pending restarts if all the databanks have been accessed and there are no suspended shadows.


Performance - Background Threads Statistics

The following statistics are displayed, in the performance output window, for each background thread:

Statistics | Description
SWA (Server Work Area) | This is the internal background thread identifier.
State | This is the state of the background thread. Active or Active slave shows that the background thread is currently working with a transaction. Inactive or Inactive slave shows a background thread that is not doing anything. 'I/O processing' means the background thread is flushing one or more transactions to disk and unused means that no background thread is using that slot.
Transaction number | This is the transaction number being processed by the background thread.
Transaction count | This is the number of transactions processed by the background thread. This gives an indication of how many background threads are needed in the system. A background thread never processes any transactions is not needed. See the System Management Handbook for further information on fine tuning the number of background threads.

Also displayed, for the database, are:

Statistics | Description
Pending background threads requests | This indicates how many transactions have yet to be processed by the database background threads. This value will grow if there are too few background threads or the background threads priority is too low.
Application waiting for transaction number | For certain operations (e.g. suspend databank), the application has to wait for the background threads to complete their tasks. If there are too few background threads it may take some time before an operation can be completed. By comparing the transaction number displayed here with those being handled by the background threads, it is possible to see how many transactions are left before the current operation can be completed.


Performance - Databank Usage Statistics

The following statistics are displayed, in the performance output window, for each databank:

Statistics | Description
Name | This is the name of the databank or shadow.
DBANKID / SEQNO | Databank identification. These two values correspond to the columns with the names DATABANK_SYSID and DATABANK_SEQNO in the data dictionary table SYSTEM.DATABANKS.
Type | This displays the databank option: NULL, TRANS, or LOG. The SQLDB databank has the type WORK, and the shadows have the type SHADOW.
Users | This is the number of users currently using the databank.
Access | This is the access mode under which the databank is held opened. If a databank is not open it is not displayed and if it is open but not being accessed, 'none' is displayed.

Also displayed, for the database, are:

Statistics | Description
Number of databanks currently open | This is a count of the number of databanks and shadows currently held open.
Maximum number of databanks concurrently open | This is the setting of the Databanks parameter, set for the database using the Mimer Administrator. It determines how many databanks may be held open at the same time.
Databank verification count | This is the number of databank verifications performed since the database was started. A databank verification is performed whenever a databank is opened after it was not correctly closed. Each time this happens, it is logged in the Mimer Log.
Databank verification option | This information message reflects the setting of the databank check option, set for the database using the Mimer Administrator. The databank check option determines whether all pages of a databank are checked during a databank verification or just the index pages.


Performance - Table Usage Statistics

The following table usage statistics are displayed in the performance output window:

Statistics | Description
Number of tables currently open | This is the number of tables currently open in both master and shadow databanks. This number also includes the read and write sets used by each user.
Maximum number of tables open concurrently | This is the setting of the Tables parameter, set for the database using the Mimer Administrator. It determines the maximum number of tables that may be held open concurrently.


SQL Pool Statistics

SQL Pool Statistics displays the amount of memory allocated from the operating system for the SQL Pool, and the amount of memory that is currently in use by the server.

The SQL Pool is used for server administration of various database resources, such as SQL statements, users and tables.

The initial size and the maximum size of the SQL Pool can be configured using the Mimer Administrator.


Bufferpool Statistics

The output from the bufferpool statistics is similar to the performance statistics but is more diagnostic in nature.

The output from performance statistics is intended for the system administrator at a Mimer SQL installation whereas the output from bufferpool statistics is intended for use by a Mimer agent.

The Mimer Log may also contain information useful to your Mimer agent.

The statistics corresponds to statistics generated by the MIMDUMP utility in earlier versions of Mimer SQL.

See also: Performance statistics


Mimer Controller

The Mimer Controller utility provides functionality to start and stop Mimer SQL database servers, and to enable and disable logins to them on the Windows 2000/XP/Vista platform.

You must be a Windows Administrator in order to use Mimer Controller successfully.

After you specify the network node, and select a Mimer SQL database, up to date status information is displayed describing whether the database is running or not and if logins are allowed.

Note that, by specifying different nodes in the network, you can control databases that are local to machines other than the one you are using.

See also: Mimer Controller Operations


Mimer Controller Operations

It is possible to select a Mimer SQL database that has been set up, using the Mimer Administrator, as a local database on the specified network node.

After you specify the network node, and select a Mimer SQL database, up to date status information is displayed describing whether the database is running or not and if logins are allowed.

You can select from the following functions:

Operation | Description
Start | This starts the selected database and automatically enables logins. You can only select databases located on the node you have specified.
Enable Login | This allows logins to the selected database. You can only select databases located on the node you have specified.
Disable Login | This blocks additional logins to the selected database. You can only select databases located on the node you have specified. The database will remain running, but new connections will be refused.
Stop | This shuts down the selected database. You can only select databases located on the node you have specified.

Some of the functions may not be available, depending on the status of the database (e.g. you cannot select Start for a database that is already running).

The database status information is updated dynamically so it will reflect the outcome of any function selected. Any error information relating to unsuccessful attempts to alter the state of a database will also be displayed. Error information will also be recorded in the Windows Event Log and can be inspected using the Windows Event Viewer or the Microsoft Management Console under Windows 2000/XP/Vista.

When you start a database, Mimer Controller checks to see if the services Mimer TCP and Mimer Named Pipes are running. If they are not running, and are set up for Automatic start, they will be started.

Note that, by specifying different nodes in the network, you can control databases that are local to machines other than the one you are using.


Mimer SQL Database Server

Mimer SQL Database Servers

For each database defined in the Mimer Administrator you must start a database server. On Windows 98/ME each database server is an ordinary windows program. On Windows 2000/XP/Vista the database server is an operating system service. Read more about Mimer database servers in the following topics:

  • Mimer SQL Database Server on Windows 98/ME
  • Starting and Stopping Database Servers
  • The Mimer Log


Mimer Database Server on Windows 98/ME

Mimer SQL Database Server on Windows 98/ME

The Mimer SQL Database Server is used to access a Mimer SQL database under Windows 98/ME. The database server starts automatically when an application tries to access a database. The database server remains active until it is explicitly shut down.

If the Mimer SQL Database Server is run with no parameters, all the local databases currently defined are listed. You can select a database and then select OK to start it.

If the Mimer SQL Database Server is run with a parameter that specifies the database, the specified local database is started.

The File Menu contains standard file functions including those that allow the contents of the Mimer SQL Database Server window to be saved to a file, thus permitting a session record to be saved. Note that information about all startups for the current database is stored in the MIMER.LOG file in the database home directory. If you select Exit from the File Menu, or close the Mimer SQL Database Server window, you will be asked to confirm that a shutdown of the server is to be performed if there are applications currently connected to the database.

The Edit menu contains the usual editing facilities that permit cut/copy and paste to and from the Mimer SQL Database Server window.

The Control menu contains the following options:

Disable Login
This option prevents any further connections to the database. It is typically used before a shutdown which waits until the last database user logs out. The database remains started and existing connections can continue to use the database.

Enable Login
This option allows new connections be established to the database again after the Disable Login option has been used to prevent them.

Shutdown and Exit
This option will shut down the server. You will be asked to confirm that a shutdown of the server is to be performed if there are applications currently connected to the database.


Starting and Stopping Database Servers

Under Windows 2000/XP/Vista:

There are several ways to start and stop database servers:

  1. The Mimer Controller.
  2. The Mimer Administrator.
  3. The command line MIMCONTROL utility.
  4. The operating system Services dialog in the Control Panel.
  5. The operating system command line utilities: NET START and NET STOP.

Using the Mimer Controller utility is generally recommended rather than using operating system tools directly. This allows you to start and stop Mimer SQL databases on any network node. The Mimer administrator allows you to stop and start database on the local machine only. This is done by selecting the tab for Local databases and right clicking on the database. The popup menu, which appears, allows you to perform various actions such as starting and stopping the server.

To start and stop the database server from the command line either MIMCONTROL or the NET START and NET STOP commands are used. MIMCONTROL is available on all Mimer SQL platforms. To learn more about MIMCONTROL use the command MIMCONTROL -?

Whenever the local parameter settings for a database are changed, the database must be stopped and started again before the new settings take effect.

Under Windows 98/ME:

There are several ways to start and stop database servers:

  1. The Mimer Administrator.
  2. The Mimer SQL Icon
  3. The command line MIMCONTROL utility.

In the Mimer Administrator you select the tab for Local databases and right-click on the database. The popup menu allows you to perform various actions such as starting and stopping the server.

When starting the database server with the Mimer SQL icon the database name can be specified as a parameter, or if no parameter is supplied, a list-box with the available databases is used to select the desired one.

Once you have started the database, various options on the Control menu of Mimer SQL database server can be used to enable or disable logins and to shut down the database.

From the command line you can use both the MIMCONTROL utility or the database server directly. The database server is started with the command:

DBSERVER "database-name"

To learn more about MIMCONTROL use the command MIMCONTROL -?


The Mimer Log

This is where important information, especially about failures and errors in the system, is recorded.

Under Windows 2000/XP/Vista:

The Windows Event Log records this information. The Event Log may be viewed, and may be saved to a file, by using the Windows Event Viewer. The information is found under the application log in the event log. The source for the errors is the name of the database service: MIMER-database.

Under Windows 98/ME:

The file MIMER.LOG, located in the database Home Directory records this information, and it may be copied and read.


.topic 53
Select the tab appropriate to the type of item you wish to view and/or administer.

.topic 52
Click this to display an overview of this dialog box.
For help on an item, click '?' at the top of this dialog box and then click the specific item you want information about.

.topic 47
Exits the program.

.topic 66
This is a string that provides descriptive information about the database. This is not a required parameter, so you may leave it blank.

.topic 65
The database name is used to refer to a database after its definition has been created. The database name appears in the list of databases when creating a Mimer ODBC data source and it is the name that must be specified when defining remote access to the database.

.topic 67
If you check the check-box, a system wide data source will be automatically created and associated with the Mimer SQL database that is being created. The data source will be given the same name as the database. The description for the database is inherited by the data source.

.topic 80
If "automatic" the database server will automatically restart after an uncontrolled shutdown. When "manual" is used a dialog box is displayed when the server fails, and the user must manually restart the server.

.topic 68
This sets the number of 2K size pages to allocate to the bufferpool. 2K pages are used to cache tables with short record lengths. Intervals (128-512) can be specified for Windows Mobile servers, allowing additional pages to be allocated dynamically when needed. The lower limit is the number of static pages. The upper limit restricts the total number of pages.

.topic 69
This sets the number of 16K size pages to allocate to the bufferpool. 16K pages are used to cache tables with intermediate record lengths and also for transaction control.  Intervals (128-512) can be specified for Windows Mobile servers, allowing additional pages to be allocated dynamically when needed. The lower limit is the number of static pages. The upper limit restricts the total number of pages.

.topic 70
This sets the number of 64K size pages to allocate to the bufferpool. 64K pages are used to cache tables with long record lengths. Intervals (128-512) can be specified for Windows Mobile servers, allowing additional pages to be allocated dynamically when needed. The lower limit is the number of static pages. The upper limit restricts the total number of pages.

.topic 72
The databanks are the physical files that store the database information. This parameter controls how many databank files may be held open at the same time.

.topic 73
This parameter defines the maximum number of tables that may be open concurrently by the database server.

.topic 71
Each active transaction is tracked by the system. A transaction starts when an application initiates a transaction, and ends when the background threads in the Mimer SQL database server has finished processing the transaction.

.topic 100
Select the database you wish to control. You can only select databases located on the node specified.

.topic 99
Specify the name of the Windows NT/2000/XP node for the local databases you want to control.

.topic 94
This starts the selected database and automatically enables logins.

.topic 95
This allows logins to the selected database.

.topic 96
This blocks additional logins to the selected database.

.topic 97
This shuts down the selected database.

.topic 101
This window displays the current status of the selected database. The information is automatically updated to reflect changes in the status of the selected database server.
The window may show error information in, for example, cases where the node name is invalid, or you may have improper access rights. More error information may be obtained by using the Windows NT Event Viewer.

.topic 98
Click help to display an overview of this dialog box.
For help on an item, select the item and press the F1 key.

.topic 93
Exits the program.

.topic 164
A dialog to select node name of computer on which to control database servers.

.topic 46
This is the name of the Data Source used to access a Mimer SQL database from ODBC.

.topic 55
Enter the user name you wish to use to access the selected database.

.topic 56
Enter the password for the specified user name. Please note that case is significant.

.topic 57
Select the OK button to log into the selected database. If you have not filled in all the required fields the OK button will be disabled.

.topic 58
Select the cancel button to close the dialog without logging into the database.

.topic 54
Select the name of the Mimer SQL database you wish to access. The names in the list are both local and remote Mimer SQL databases.
New databases are defined using the Mimer Administrator.

.topic 87
The CPU Id is used by the Mimer SQL License software to identify this particular workstation or server. The key is unique for each CPU Id. I.e. you need a separate license for each machine you are running a Mimer SQL database server.

.topic 81
This field contains the installation number for the license key. This number is computed from the License key.
This field only contains a valid number when editing an existing key. Invalid keys are given a temporary Installation number in the format: ErrXX where XX is a unique number.

.topic 85
This is a string that provides descriptive information about the license key. This is not a required parameter, so you may leave it blank.

.topic 86
This is the license key string. It gives you access to the database server(s) on this machine. You receive this string from your Mimer distributor.

.topic 82
This field contains the expiration date for the license key.
This field only contains a date value when editing an existing key.

.topic 83
This field contains the maximum number of users supported by the license key. This count includes both local users and users connected over a network. The number of users that can connect to a server is restricted by the number of users allowed per database server.
This field only contains a value when editing an existing key.

.topic 84
This field contains the maximum number client/server users, i.e. the number of users that may connect over a network to one or more database servers on this machine.
This field only contains a value when editing an existing key.

.topic 155
The version this key was issued. The system uses keys from the current version or later. Keys from earlier version are ignored.
This field only contains a value when editing an existing key.

.topic 156
This is a list of all components of the key. Fore each module the number of users allowed is shown. An extra column shows the number of concurrent client/server connections allowed.
Some modules, such as Shadowing, do not have a usecount associated with them, in which case the user fields are empty.
This field only contains a value when editing an existing key.

.topic 78
This is the protocol interface to use when communicating with the remote database. This may be left blank to get the default, or you may select an alternative. You can typically select winsocket as an interface under Windows.
Generally, it is appropriate to accept the default value for this parameter.

.topic 79
This is the service to use when communicating with the remote database. This may be left blank to get the default, or one of the following may be selected 1360 or mimer.
For tcp/ip, the service corresponds to the port number. For NamedPipes, the service is the name that is used for the named pipe.
Generally, it is appropriate to accept the default value for this parameter.

.topic 51
Help is available for each item in this group. Press the ‘?’ at the top of the dialog box and then click the specific item you want information about.

.topic 75
This is a string that provides descriptive information about the remote database. This is not a required parameter, so you may leave it blank.

.topic 74
This is the name of the database you wish to access remotely. The name you specify must match the name specified when the local definition for the database was created. It will not be possible to connect to the database remotely if the two names differ.

.topic 77
This is the communications protocol to use when contacting the network node the remote database resides on. Typical protocols are NamedPipes and tcp.

.topic 76
This is the name of the network node the remote database resides on. This can be a protocol-specific name, e.g. the IP address can be specified for a TCP/IP connection.

.topic 45
This is a string that provides descriptive information about the data source. This is not a required parameter, so you may leave it blank.

.topic 44
Select the name of the Mimer SQL database you wish to access from ODBC. The names in the list are both local and remote Mimer SQL databases.
If you press the right mouse button in this field you can create a new database or modify the parameters for an existing one.

.topic 18
Enter the full path to the directory which will be the default directory for the server for this database. The system databank is stored in this directory.

.topic 21
This setting limits the number of concurrent connections allowed to the database server.

.topic 20
Select "Check all pages" for production systems. Use "Check index pages" only for test, as data pages are not verified for integrity after an uncontrolled shutdown.

.topic 23
Number of database server threads that service requests from applications.

.topic 24
Number of database server background threads. The threads are used for background transaction processing.

.topic 25
This parameter determines the operating system priority level for the database server process.

.topic 26
Determines the relative scheduling priority for the request threads.

.topic 27
Determines the relative scheduling priority for the background threads.

.topic 59
Allows you to enable or disable shared memory communication to the database server.

.topic 60
Allows you to control (or disable) how TCP/IP connections are made to the database server.

.topic 61
Allows you to control (or disable) how Named Pipes connections are made to the database server.

.topic 62
The SQLPool holds information about users logged, compiled SQL statements and so on. You can set both initial and maximum size here.

.topic 29
Determines how the database server is started. The recommended setting is "autostart".

.topic 165
This listbox displays all items for the currently selected type. Double-click an item to view it's properties.
Right-clicking an item will display a popup menu with additional commands for the selected type.

.topic 166
Press this button to create a new item of the selected type.

.topic 167
Press this button to change/view the currently selected item.

.topic 168
Press this button to the remove the currently selected item.