Installation

Title of the Documentation | Contents
Database Software Installation Guide | Standard installation and uninstallation of all the MaxDB software
Web Tools Installation Guide | Installation of the MaxDB Web Tools
Connecting External Backup Tools | Configuring the MaxDB software to use various external backup tools
Installation Manual | Installation, update, and uninstallation of installation profiles and individual software components, updates of database instances, including software


Database Software Installation Guide

Purpose

This documentation describes the installation and uninstallation of all MaxDB software with Version 7.5x; in the following, these processes are called a standard installation and standard uninstallation.

This Database Software Installation Guide is an extract from the Installation Manual , and only describes some of the possible installation procedures. It is only intended for those users who want to perform a complete installation or complete uninstallation of the MaxDB database software outside an SAP system.

You also have the option of installing or uninstalling individual database software components. When you do this you must take into account the dependencies between the components, and how they might affect the way your software installation works.

You also have the option of updating database software installations with or without database instances.

You can also use the Red Hat Package Manager to install the software on Linux.

For more information, see the Installation Manual.

You can download the database software free of charge from http://www.mysql.com/downloads.

See also:

Supported Operating Systems and Platforms

Constraints

This guide does not apply for installing and uninstalling the MaxDB database software in SAP systems.

The installation or uninstallation of the database software required for SAP systems is described in SAP-specific installation guides. SAP customers can find these guides on the SAP Service Marketplace at http://service.sap.com. If you want to upgrade database instances, including database software, in SAP systems, use the Installation Manual.

Implementation Considerations

You use the SDBINST program for installing the SAP DB software and the SDBUNINST program for uninstalling the MaxDB software. These programs are included in the database software package.

For general information on the database system, see the Database Administration documentation.

Standard Installation with SDBINST

Standard Uninstallation with SDBUNINST


Standard Installation with SDBINST (MaxDB: Database Software Installation Guide)

Standard Installation with SDBINST

The program SDBINST for installing the database software is used interactively for the standard installation described in this documentation.

You can also use SDBINST for installations in the background. This procedure is described in the Installation Manual.

Standard Installation on UNIX

Standard Installation on Linux (Intel)

Standard Installation on Microsoft Windows


Standard Installation on UNIX (MaxDB: Database Software Installation Guide)

Standard Installation on UNIX

Use

You want to install the installation profile all of the database software on the UNIX operating system. All necessary information is queried by the program during the installation.

The installation process is logged by the system.

Conventions

Variables

Prerequisites

· You are in a rootshell.

· You have downloaded and unpacked the installation package (Downloading and Unpacking the Database Software on UNIX).

Preparations

If the following conditions apply to your system, you must perform the specified steps before the installation:

· The installation program enters the required services sql6, sql30, and sapdbni72 in the file /etc/services if they do not already exist there. If these services are managed centrally for your system on the network (NIS), you must enter them there as follows:
sql6 7210/tcp
sql30 7200/tcp
sapdbni72 7269/tcp

· During the installation, the database software must be assigned to a special operating system user, <sdb_user>, as the owner of the software, and to the group <sdba_group>.
The group and the owner must have been defined in advance. Only users with the correct authorizations can generate the database instances later (see also Authorization Concept for UNIX Operating Systems for software versions from 7.5.00).
The special operating system user must not log on to the operating system. For this reason, take this authorization away from this user. For information on how to do this, see your operating system documentation (lock account).

If you manage user groups and owners locally on your computer, we recommend that you register the names of the user groups and the owner in the operating system before you start the installation. However, you can also specify this information during the installation process.
If you manage user groups and owners for your system centrally in the network, you must create them here before you start the installation. For more information on creating operating system users and user groups, see your operating system documentation.

The primary group of the owner of the database software is the administrator group.

For consistency, especially if you need the help of the support team, we recommend that you use the names sdb and sdba for the owner and group.

· If the path <independent_program_path>/bin is not yet entered in the environment variable PATH, enter it now. (For information on setting environment variables, see your operating system documentation.)

Procedure

...

1. Go to the directory
maxdb-all-<os>-32|64bit-<arch>-<version>_<build>,
into which you unpacked the installation package.

2. Enter ./SDBINST, to call the installation program.

3. The system displays the possible installation profiles. Enter the ID for the installation profile all and confirm it.

4. The system prompts you to enter the following information:

¡ Special operating system user <sdb_user> (owner of the SAP DB database software)

¡ The group <sdba_group>

If you have already created the groups and the owner, enter the correct values and confirm them. The system compares this information with the values stored locally or elsewhere in the network. If your entries do not match the stored values, the installation crashes.

If the group and the owner have not yet been created, the system asks whether you want to create them. Enter your chosen values or confirm the system default values. This creates the group and the owner locally on your computer.

5. The system now checks whether there are installations of the database system already on your computer.

¡ If installations of the database system already exist on your computer, a list of these installations is displayed. You are requested to specify the ID of the installation that you want to upgrade.
For a new installation of the database software in parallel with an existing installation, enter none. You then have the option of specifying an installation path that is different from the existing installations. Define an installation path in parallel with the existing installation paths.

¡ If there are no installations of the database software on your computer, the software components contained in the installation profile are now installed. The system prompts you to specify the following paths:

· Path for storing the data, configurations, and run directories of the database instances and database applications (the system default value is /var/opt/sdb/data)

· Path for storing the programs and libraries shared by the database instances and database applications (the system default value is /opt/sdb/programs)

· Path for storing the server software that depends on the database version
This path must be unique.Multiple directories with different versions can exist alongside each other (the system default value is /opt/sdb/<version>)

Enter your chosen paths or confirm the system default values.

6. If there were no installations of the database system on your computer until now, add the following entry to the PATH environment variable for all users that want to use the database system: <independent_program_path>/bin.

You see a success message about the installation.

Result

The installation profile all of the database software is now installed and registered on your computer. You can use the log to check the result of the installation (Logging on UNIX).

You can now create new database instances using the Database Manager

(See:

· Creating a Database Instance in the Database Manager CLI documentation

· The Web DBM documentation)


Downloading and Unpacking the Software Under UNIX (MaxDB: Database Software Installation Guide)

Downloading and Unpacking the Software on UNIX

Use

Download the latest version of the database software for your operating system from http://www.sapdb.org.

Take account of the relevant notes about disk capacity and the tested operating system versions.

Procedure

...

1. Choose the database software package that matches your operating system architecture for the installation profile all
maxdb-all-<os>-32|64bit-<arch>-<version>_<build>.<tgz>

2. Download the software package and unpack it to a local directory of your choice with the following command:
tar xvzf maxdb-all-<os>-32|64bit-<arch>-<version>_<build>

In this local directory, the system creates a subdirectory
maxdb-all-<os>-<32|64>bit-<arch>-<version>
and stores the database software there.


Logging on UNIX (MaxDB: Database Software Installation Guide)

Logging on UNIX

The entire installation process is logged. The system stores this log under the following path:

<independent_data_path>/wrk/MAXDBall_install-<date>-<time>.log

If the <independent_data_path> directory is not yet known when the installation process crashes, the log will be created in the current directory.

Standard Installation on UNIX


Standard Installation on Linux (Intel) (MaxDB: Database Software Installation Guide)

Standard Installation on Linux (Intel)

Use

You want to install or update all components of the database software on the Linux operating system.
If you only want to install or update individual components, you must consider the dependencies between software components to ensure that the software installation can function. For more information, see the Installation Manual.

If you already have an installation of the database software on your computer that was installed using the Red Hat Package Manager (installation with an rpm package), you can only perform additional installations using this program. It is no longer possible to perform additional installations using the SDBINST program (installation with a tgz package).

See the Installation Manual, section Installation/Update with the Red Hat Package Manager.

Procedure

Follow the procedure described in the section Standard Installation on UNIX.


Standard Installation on Microsoft Windows (MaxDB: Database Software Installation Guide)

Standard Installation on Microsoft Windows

Use

You want to install the installation profile all of the database software on the operating system Microsoft Windows. All necessary information is queried by the program during the installation.

The installation process is logged by the system.

Conventions

Variables

Prerequisites

· You have administration rights for your computer.

· You have downloaded and unpacked the installation package (see Downloading and Unpacking the Software on Microsoft Windows).

Procedure

...

1. Open the Command Prompt and navigate to the local directory that contains the installation files:
maxdb-all-win-<32|64>bit-<arch>-<version>

2. Enter sdbinst to call the installation program.

3. The system displays the possible installation profiles. Enter the ID for the installation profile all and confirm it.

4. The system now checks whether there are installations of the database system already on your computer.

¡ If installations of the database system already exist on your computer, a list of these installations is displayed.
If you want to install new database software in parallel with the existing installation, enter none. You then have the option of specifying a new installation path. Define an installation path in parallel with the existing installation paths.

¡ If there are no installations of the database system on your computer, the software components contained in the installation profile are now installed. Depending on the installation profile that you have chosen, the system may prompt you to specify the following paths:

§ Path for storing the data, configurations, and run directories of database instances and database applications (the system default value is C:\Program Files\sdb\data)

§ Path for storing the programs and libraries shared by the database instances and database applications (the system default value is C:\Program Files\sdb\programs)

§ Path for storing the server software that depends on the database version
This path must be unique. Multiple directories with different versions can exist alongside each other (the system default value is C:\Program Files\sdb\<version>).

Enter your chosen paths or confirm the system default values.

You see a success message about the installation.

5. If there was no installation of the database system on your computer until now, we recommend that you now shut down and restart your computer to make the <independent_program_path> known to the system.

Result

The installation profile all of the database software is now installed and registered on your computer. You can use the log to check the result of the installation (Logging on Microsoft Windows).

You can now create new database instances using the Database Manager

(See:

· Creating or Initializing a Database Instance in the Database Manager GUI documentation

· Creating a Database Instance in the Database Manager CLI documentation

· The Web DBM documentation)


Downloading and Unpacking the Software Under Microsoft Windows (MaxDB: Database Software Installation Guide)

Downloading and Unpacking the Software on Microsoft Windows

Use

Download the latest database software for your operating system from http://www.sapdb.org.

Take account of the relevant notes about disk capacity and the tested operating system versions.

Procedure

...

1. Choose the database software package that matches your operating system architecture for the installation profile all
maxdb-all-<win>-<32|64>bit-<arch>-<version>_<build>.<zip>

2. Use WinZip to unpack the software package to a local directory of your choice.

3. In this local directory, the system creates a subdirectory
maxdb-all-<win>-<32|64>bit-<arch>-<version>
and stores the database software there.


Logging on Microsoft Windows (MaxDB: Database Software Installation Guide)

Logging on Microsoft Windows

The entire installation process is logged. The system stores this log under the following path:

<independent_data_path>\wrk\MAXDBall_install-<date>-<time>.log

If the <independent_data_path> directory is not yet known when the installation process crashes, the log will be created in the current directory.

Standard Installation on Microsoft Windows


Standard Uninstallation with SDBUNINST (MaxDB: Database Software Installation Guide)

Standard Uninstallation with SDBUNINST

Use

You use the program SDBUNINST. This program is included in the installation of the database software.

During the standard uninstallation with SDBUNINST, you uninstall the entire database software on your computer.

You can also use the SDBUNINST program if you only want to uninstall individual software components. In this case, however, you must consider sequences and dependencies of software components. For information on uninstalling individual software components, see Uninstalling the Database Software in the Installation Manual.

If you work on the Linux operating system and used the Red Hat Package Manager (rpm package) to install the database software on your computer, you can uninstall the software with this program only.

See Installation Manual, section Uninstallations with the Red Hat Package Manager

Prerequisites

· You have administration rights for your computer.

Procedure Under Microsoft Windows, UNIX, and Linux

...

1. On UNIX/Linux, switch to the rootshell.
On Microsoft Windows, open the command prompt on your computer.

2. Stop each database instance on your computer with the following command:
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

3. Delete each database instance on your computer with the following command:
dbmcli –d <database_name> -u <dbm_user>,<password> db_drop

4. Call the uninstall program with the option for uninstalling all database software:
sdbuninst –all
The system displays a list of all existing database software components.

5. Start the uninstallation by entering y.

You see a success message about the uninstallation.

Result

The entire database software is deleted from your computer.


Web Tools Installation Guide

Purpose

This documentation describes how you install the MaxDB Web Tools.

This installation guide is not relevant for a standard installation of an SAP system. The installation of the database software required for SAP systems is described in SAP-specific installation guidelines. SAP customers can find these guidelines in the SAP Service Marketplace, under http://service.sap.com.

Introduction

· Variables Used

· Supported Operating Systems and Browsers

Installation Description

You can install the Web Tools on the following operating systems:

· Installation on Linux

· Installation on UNIX

· Installation on Windows

Additional Information

· Calling the Web Tools

· Using the Web Tools with the Apache Web Server

· Setting Up the WebDAV Service

· Uninstalling the Web Tools

For general information on the MaxDB database system, see the documentation Database Administration.


Variables Used (MaxDB: Web Tools Installation Guide)

Variables Used

The table below contains a list of the special variables used in the installation descriptions.

<independent_program_path>/web | Installation directory of the Web Tools
<log_path> | Directory of the web tools logs
<registry_path> | Registry path (Microsoft Windows)
<web_server> | Name of the host on which the Web Server is installed
<port> | Port address of the Web Server

For explanations of the other variables used, see the documentation Database Administration under Variables.


Supported Operating Systems and Browsers (MaxDB: Web Tools Installation Guide)

Supported Operating Systems and Browsers

This table shows you with which operating systems, platforms, and browsers the current version of the Web Tools has been tested.

<os> | <arch> | Browser
aix | ppc | Mozilla 1.1
linux | i386 | Mozilla 1.1, Konqueror 3.0.3
solaris | sparc | Mozilla 1.1
tru64 | alpha | Mozilla 1.1
hpux | hppa | Mozilla 1.1
win | i386, ia64 | Internet Explorer 6.0, Mozilla 1.1


Installation Steps (MaxDB: Web Tools Installation Guide)

Installation Steps

You can install the Web Tools on the following operating systems:

· Installation on Linux

· Installation on UNIX

· Installation on Windows


Linux: Installation of the Web Tools (MaxDB: Web Tools Installation Guide)

Linux: Installing the Web Tools

Procedure

...

...

1. Installing the Web Tools Software

2. Configuring the MaxDB Web Server

3. Starting the MaxDB Web Server

4. Configuring the Web Browser

Additional Information

· Calling the Web Tools

· Using the Web Tools with the Apache Web Server

· Setting Up the WebDAV Service

· Uninstalling the Web Tools


Linux: Installation of the Web Tools Software (MaxDB: Web Tools Installation Guide)

Linux: Installing the Web Tools Software

Use

When you install the Web Tools software package, you install the Web Tools and the MaxDB Web Server.

See also: Variables Used, Supported Operating Systems and Browsers

Procedure when Using the rpm Package

1. Log onto your computer as the root user.

2. If an older version of the Web Tools is already installed on your server, stop the Web Server.

3. Copy the software package
maxdb-web-<os>-<arch>-<version>.rpm
to a local directory of your choice.

4. Install the Web Tools. To do this, enter the following command:
rpm –U maxdb-web-<os>-<arch>-<version>.rpm

Procedure when Using the tgz Package

...

1. Log onto your computer as the root user.

2. If an older version of the Web Tools is already installed on your server, stop the Web Server.

3. Copy the software package
maxdb-webtools-<os>-<arch>-<version>.tgz
to a local directory of your choice.

4. Install the Web Tools. To do this, enter the following command:
gzip -d maxdb-webtools-<os>-<arch>-<version>.tgz tar xf maxdb-webtools-<os>-<arch>-<version>.tar ./SDBINST

5. Follow the instructions provided by the installation program.

Result

The Web Tools and the Web Server have been installed in the directory <independent_program_path>/web.

Next Installation Step

Configuring the MaxDB Web Server


Linux: Configuring the MaxDB Web Server (MaxDB: Web Tools Installation Guide)

Linux: Configuring the MaxDB Web Server

Use

You can configure the MaxDB Web Server in the configuration file /usr/spool/sql/ini/WebAgent75.ini.

When starting the MaxDB Web Server, you can specify which configuration file the system should use. This means that you can also specify a configuration file other than WebAgent75.ini.

See also: Variables Used, Supported Operating Systems and Browsers

Prerequisites

You are logged on as the root user.

Procedure

Section [HTTP] of the WebAgent75.ini configuration file contains the following entries:

Browsable=0
DefaultDocument=index.html
DocumentRoot=<independent_program_path>/web/Documents
LogDirectory=<independent_program_path>/web/Log
LogRequests=1
MaxThreads=10
MimeTypeFile=<independent_program_path>/web/config/mime.types
Port=9999

Browsable

Set whether the contents of the directories under DocumentRoot should be visible using a browser.

· 0: The contents are not visible

· 1: The contents are visible

DefaultDocument

Change the start page of the Web Server, if desired.

DocumentRoot

Change the path for the root directory of the web pages, if necessary.

LogDirectory

If you set LogRequest so that HTTP accesses are logged, accesses to the MaxDB Web Server are logged in the files httperr.log and httpreq.log.
These log files are written in the directory specified in LogDirectory.

LogRequests

You can determine whether each HTTP access should be logged or not.

· 1: HTTP accesses are logged.

· 0: HTTP accesses are not logged.

MaxThreads

You can determine the maximum number of threads that can be used to process access to the Web Server. When the Web Server is started, the threads are also started as a thread pool.

MimeTypeFile

Specify the MIME type file, if necessary.

Port

Change the port address for the Web Server, if desired.

Next Installation Step

Starting the MaxDB Web Server


Linux: Starting the MaxDB Web Server (MaxDB: Web Tools Installation Guide)

Linux: Starting the MaxDB Web Server

See also: Variables Used, Supported Operating Systems and Browsers

Procedure (rpm Package)

If you have performed an rpm installation of the Web Tools software, start the MaxDB Web Server with the command
/etc/rc.d/sdb-web start

To stop the server, use the command
/etc/rc.d/sdb-web stop

Procedure (tgz Package)

Start the Web Server as follows:

...

1. Set the environment variable LD_LIBRARY_PATH. To do this, enter the following command:
export LD_LIBRARY_PATH=<independent_program_path>/web/lib:
<independent_program_path>/lib:$LD_LIBRARY_PATH

2. Switch to the directory <independent_program_path>/web/pgm.

3. Enter the following command: ./wahttp

Call Options

wahttp [-f <file>] [&] [-h]

· You can use the call parameter -f <file> to specify a configuration file other than the file WebAgent75.ini. For <file>, specify the path and file name of the chosen configuration file.

· You can use the call parameter & to start the Web Server in the background.

· You can use the call parameter -h to display all call options.

To use a configuration file other than the file WebAgent75.ini, you can also change the specification of the configuration file in the file <independent_program_path>/web/pgm/wahttp.conf.

Result

When you start the Web Server, the Web Tools are automatically made available as Web Server Services.

Access to the Web Server is logged if you have enabled logging when Configuring the MaxDB Web Server.

Next Installation Step

Configuring the Web Browser


UNIX: Installation of the Web Tools (MaxDB: Web Tools Installation Guide)

UNIX: Installing the Web Tools

Procedure

...

1. Installing the Web Tools Software

2. Configuring the MaxDB Web Server

3. Starting the MaxDB Web Server

4. Configuring the Web Browser

Additional Information

· Calling the Web Tools

· Using the Web Tools with the Apache Web Server

· Setting Up the WebDAV Service

· Uninstalling the Web Tools


UNIX: Installation of the Web Tools Software (MaxDB: Web Tools Installation Guide)

UNIX: Installing the Web Tools Software

Use

When you install the Web Tools software package, you install the Web Tools and the MaxDB Web Server.

See also: Variables Used, Supported Operating Systems and Browsers

Procedure

...

...

1. Log onto your computer as the root user.

2. If an older version of the Web Tools is already installed on your server, stop the Web Server.

3. Copy the software package
maxdb-webtools-<os>-<arch>-<version>.tgz
to a local directory of your choice.

4. Install the Web Tools. To do this, enter the following command:
gzip -d maxdb-webtools-<os>-<arch>-<version>.tgz tar xf sdb-webtools-<os>-<arch>-<version>.tar ./SDBINST

5. Follow the instructions provided by the installation program.

Result

The Web Tools and the Web Server have been installed in the directory <independent_program_path>/web.

Next Installation Step

Configuring the MaxDB Web Server


UNIX: Configuring the MaxDB Web Server (MaxDB: Web Tools Installation Guide)

UNIX: Configuring the MaxDB Web Server

Use

You can configure the MaxDB Web Server in the configuration file /usr/spool/sql/ini/WebAgent75.ini.

See also: Variables Used, Supported Operating Systems and Browsers

Prerequisites

You are logged on as the root user.

Procedure

Section [HTTP] of the WebAgent75.ini configuration file contains the following entries:

Browsable=0
DefaultDocument=index.html
DocumentRoot=<independent_program_path>/web/Documents
LogDirectory=<independent_program_path>/web/Log
LogRequests=1
MaxThreads=10
MimeTypeFile=<independent_program_path>/web/config/mime.types
Port=9999

Browsable

Set whether the contents of the directories under DocumentRoot should be visible using a browser.

· 0: The contents are not visible

· 1: The contents are visible

DefaultDocument

Change the start page of the Web Server, if desired.

DocumentRoot

Change the path for the root directory of the web pages, if necessary.

LogDirectory

If you set LogRequest so that HTTP accesses are logged, accesses to the MaxDB Web Server are logged in the files httperr.log and httpreq.log.
These log files are written in the directory specified in LogDirectory.

LogRequests

You can determine whether each HTTP access should be logged or not.

· 1: HTTP accesses are logged.

· 0: HTTP accesses are not logged.

MaxThreads

You can determine the maximum number of threads that can be used to process access to the Web Server. When the Web Server is started, the threads are also started as a thread pool.

MimeTypeFile

Specify the MIME type file, if necessary.

Port

Change the port address for the Web Server, if desired.

Next Installation Step

Starting the MaxDB Web Server


UNIX: Starting the MaxDB Web Server (MaxDB: Web Tools Installation Guide)

UNIX: Starting the MaxDB Web Server

See also: Variables Used, Supported Operating Systems and Browsers

Procedure

Start the MaxDB Web Server as follows:

...

...

    1.      Set the environment variable LD_LIBRARY_PATH. To do this, enter the following command:
export LD_LIBRARY_PATH=<independent_program_path>/web/lib:
<independent_program_path>/lib:$LD_LIBRARY_PATH

If you have installed the Web Tools software for hp-ux (32 Bit), enter SHLIB_PATH instead of LD_LIBRARY_PATH.
If you are working with a 64 bit platform (with the exception of tru64 and linux IA64), enter /lib/lib64 instead of /lib.

2. Switch to the directory <independent_program_path>/web/pgm.

3. Enter the following command: ./wahttp

Call Options

wahttp [-f <file>] [&] [-h]

· You can use the call parameter -f <file> to specify a configuration file other than the file WebAgent75.ini. For <file>, specify the path and file name of the chosen configuration file.

· You can use the call parameter & to start the Web Server in the background.

· You can use the call parameter -h to display all call options.

To use a configuration file other than the file WebAgent75.ini, you can also change the specification of the configuration file in the file <independent_program_path>/web/pgm/wahttp.conf.

Result

When you start the MaxDB Web Server, the Web Tools are automatically made available as Web Server Services.

Access to the Web Server is logged if you have enabled logging (see Configuring the MaxDB Web Server).

Next Installation Step

Configuring the Web Browser


Windows: Installation of the Web Tools (MaxDB: Web Tools Installation Guide)

Windows: Installation of the Web Tools

Procedure

...

1. Installing the Web Tools Software

2. Configuring the MaxDB Web Server

3. Starting the MaxDB Web Server

4. Configuring the Web Browser

Additional Information

· Calling the Web Tools

· Using the Web Tools with the Apache Web Server

· Setting Up the WebDAV Service

· Uninstalling the Web Tools


Windows: Installation of the Web Tools Software (MaxDB: Web Tools Installation Guide)

Windows: Installing the Web Tools Software

Use

When you install the Web Tools software package, you install the Web Tools and the MaxDB Web Server.

See also: Variables Used, Supported Operating Systems and Browsers

Prerequisites

You have administrator rights for your host.

Procedure

...

...

1. If an older version of the Web Tools is already installed on your server, stop the Web Server.

2. Copy the software package
maxdb-webtools-<os>-<arch>-<version>.tgz
to a local directory of your choice.

3. Use the WinZip program to unpack the file maxdb-webtools-<os>-<arch>-<version>.tgz to a local directory of your choice.

4. Open a command prompt.

5. Go to the directory to which you unpacked the files.

6. Start the installation procedure. To do this, enter the following command:
SDBINST.exe

7. Follow the instructions provided by the installation program.

Result

The Web Tools and the Web Server have been installed in the directory <independent_program_path>\web.

Next Installation Step

Configuring the MaxDB Web Server


Windows: Configuring the MaxDB Web Server (MaxDB: Web Tools Installation Guide)

Windows: Configuring the MaxDB Web Server

Use

You can configure the MaxDB Web Server in the registry, in the registry path HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAP DBTech\WebAgent75\HTTP.

See also: Variables Used, Supported Operating Systems and Browsers

Prerequisites

You have administrator rights for your host.

Procedure

The registry path HKEY_LOCAL_MACHINE\ SOFTWARE\SAP\SAP DBTech\WebAgent75\HTTP contains the following entries:

Browsable=0
DefaultDocument=index.html
DocumentRoot=<independent_program_path>\web\Documents
LogDirectory=<independent_program_path>\web\Log
LogRequests=1
MaxThreads=10
MimeTypeFile=<independent_program_path>\web\config\mime.types
Port=9999

Browsable

Set whether the contents of the directories under DocumentRoot should be visible using a browser.

· 0: The contents are not visible

· 1: The contents are visible

DefaultDocument

Change the start page of the Web Server, if desired.

DocumentRoot

Change the path for the root directory of the web pages, if necessary.

LogDirectory

If you set LogRequest so that HTTP accesses are logged, accesses to the MaxDB Web Server are logged in the files httperr.log and httpreq.log.
These log files are written in the directory specified in LogDirectory.

LogRequests

You can determine whether each HTTP access should be logged or not.

· 1: HTTP accesses are logged.

· 0: HTTP accesses are not logged.

MaxThreads

You can determine the maximum number of threads that can be used to process access to the Web Server. When the Web Server is started, the threads are also started as a thread pool.

MimeTypeFile

Specify the MIME type file, if necessary.

Port

Change the port address for the Web Server, if desired.

Next Installation Step

Starting the MaxDB Web Server


Windows: Starting the MaxDB Web Server (MaxDB: Web Tools Installation Guide)

Windows: Starting the MaxDB Web Server

Use

During the installation of the Web Tools software, the MaxDB Web Server is automatically entered as the Service SAP DB WWW with manual start (Startup Type manual). You can start and stop the server using Services or at the command prompt.

Procedure

· To start the Web Server at the command prompt, enter the following command: net start sapdbwww

· To stop the Web Server at the command prompt, enter the following command: net stop sapdbwww

To start the Web Server with a configuration other than WebAgent75, change the specification of the registry path in the file <independent_program_path>\web\pgm\wahttp.conf, or call the server directly.

When you start the MaxDB Web Server, the Web Tools are automatically made available as Web Server Services.

Access to the Web Server is logged if you have enabled logging (see Configuring the MaxDB Web Server).

Next Installation Step

Configuring the Web Browser


Calling the MaxDB Web Server Directly (MaxDB: Web Tools Installation Guide)

Calling the MaxDB Web Server Directly

Use

You can call the MaxDB Web Server directly, to, for example, start it with a configuration other than WebAgent75.

Procedure

...

...

1. Switch to the directory <independent_program_path>\web\pgm.

2. To start the Web Server, enter the following command: wahttp.exe  -d

Call Options

wahttp.exe [-i] [-u] [-d] [-f <file>] [-h]

· Use the call parameter -i to register the Web Server as a service.

· Use the call parameter -u to delete the service entry for the Web Server.

· Use the call parameter -d to start the Web Server directly.

· Use the call parameter -f <registry path> to specify the registry path of a configuration other than WebAgent75.

· Use the call parameter -h to display all call parameters.

To start the MaxDB Web Server with a configuration other than WebAgent75, you can also change the specification of the registry path in the file <independent_program_path>\web\pgm\wahttp.conf.


Configuring the Web Browser (MaxDB: Web Tools Installation Guide)

Configuring the Web Browser

Procedure

Ensure that your browser supports JavaScript, Style Sheets, and Cookies. If necessary, change the relevant settings of your browser.

Additional Information

· Calling the Web Tools

· Setting Up the WebDAV Service


Calling the Web Tools (MaxDB: Web Tools Installation Guide)

Calling the Web Tools

After the installation of the Web Tools, the following database tools are available for you to use:

· The Database Manager Web DBM for managing MaxDB database instances

· The query tool Web SQL Studio for easy access to the data of a database instance

· An administration tool for managing Web services and Web tools

Calling the Web DBM

Open the Web browser and enter the following URL:

http://<web_server>:<port>/webdbm

For more information on using this database tool, see the documentation Web DBM.

Calling the Web SQL Studio

Open the Web browser and enter the following URL:

http://<web_server>:<port>/websql

For more information on using this database tool, see the documentation Web SQL Studio.

See also: Notes on Using Web SQL Studio.

Calling the Administration Tool

Open the Web browser and enter the following URL:

http://<web_server>:<port>/waadmin.wa

Specify the user name and the password of the Web tools administrator. The system defaults are as follows:

· User name: admin

· Password: init

You can change the user name and password for the Web tools administrator with the administration tool under Global Settings ® General Settings. The corresponding Registry entries are in the Registry path \HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAP DBTech\WebAgent75\GeneralSettings (Windows) or in the section [BIT32\GeneralSettings] or [BIT64\GeneralSettings] (UNIX).


Notes on Using the Web SQL Studio (MaxDB: Web Tools Installation Guide)

Notes on Using the Web SQL Studio

If your database instance was set up using a software version below 7.2.05, take the following notes into account.

Customizing the Database Instance

So that you can use the full scope of the Web SQL Studio, you must perform the following actions in the database instance that you want to access with the Web SQL Studio:

...

1. Copy the file <independent_program_path>/web/env/QP.ins to the directory <dependent_path>/env.

2. Reload the system tables. Enter the following command:
dbmcli –u <dbm_user>,<password> -d <database_name> load_systab

You only need to perform these steps once.

Access to Stored Statements with Changed User Name

If a user name is changed in the database instance that you access with Web SQL Studio, this user can no longer access his or her Stored Statements in the same way as before.

To enable the user to access his or her Stored Statements again, perform the following steps:

...

...

1. Start the Web SQL Studio as a database administrator (DBA user).

2. Enter the following SQL statements:
UPDATE sysdba.wa_inode SET "VIEWOWNER" = ’<new_user_name>’ WHERE "VIEWOWNER" = ’<old_user_name>’
UPDATE sysdba.wa_container SET "VIEWOWNER" = ’<new_user_name>’  WHERE "VIEWOWNER" = ’<old_user_name>’

Deleting Stored Statements of a Deleted User Name

If a user name is deleted in the database instance that you access with the Web SQL Studio, the Stored Statements of this user are not automatically deleted too.

To delete the Stored Statements in this situation, you have to carry out the following steps:

...

1. Start the Web SQL Studio as a DBA user.

2. Enter the following SQL statements:
DELETE sysdba.wa_inode WHERE "VIEWOWNER" = ’<deleted_user>’
DELETE sysdba.wa_container WHERE "VIEWOWNER" = ’<deleted_user>’


Setting Up the WebDAV Service (MaxDB: Web Tools Installation Guide)

Setting Up the WebDAV Service

Use

When you install the Web Tools, you also install a database-based WebDAV service. A MaxDB database instance is used to store all WebDAV-related data, including the Web resources. Stored XML documents can be indexed; the SAP DB WebDAV GUI provides a range of easy to use functions for handling documents and the indexing service.

Before you can use the WebDAV service, you must set up the connection to the required database instance.

Procedure

...

1. Start the database instance with the Database Manager.

2. Start the Web Server.

3. Call the administration tool for the Web Tools (see Calling the Web Tools).

4. Choose Session Pools ® WebDAV.

5. Specify the following parameters: the name of the database instance, the name of the host on which the database instance is installed, the name of the database system administrator (SYSDBA user) and his or her password.

6. If desired, adjust the size of the Pool Size value. This specifies the maximum number of parallel database sessions that the WebDAV service can use.

7. Choose Services ® WebDAV and then Reload Service. The WebDAV service is restarted.

Result

The WebDAV service is now set up with the database connection. The WebDAV server is automatically started every time the Web Server is started.

If you want to use the options for indexing XML documents, you must now configure the index engine.


Information About WebDAV (MaxDB: Web Tools Installation Guide)

Information About WebDAV

WebDAV is an abbreviation of “Web-based Distributed Authoring and Versioning”. WebDAV is a standard of the Internet Engineering Task Force (IETF), and is an HTTP 1.1 extension.

The WebDAV protocol allows collaborative editing of documents over the Internet. As in familiar file systems, you can create directories, and store, move, rename, and delete objects. The WebDAV service assigns attributes such as creation date or file type to the stored objects ‑ known as Web resources. Among other things, you can use the attributes to control write locks.

The MaxDB WebDAV service fulfills class 2 of the WebDAV specifications, but does not support the WebDAV Access Control Protocol (ACL) and the Versioning Extension (DeltaV).

See also Setting Up the WebDAV Service.

For more information, see www.webdav.org.


Configuring the Index Engine for XML Indexing (MaxDB: Web Tools Installation Guide)

Configuring the Index Engine for XML Indexing

Use

Along with the Web Tools, an index engine for indexing XML documents in the WebDAV store (document store) is also installed. Before you can use the index engine effectively with the WebDAV GUI tool, you need to configure it with information on the database instance you are using.

Procedure

1. Complete the entries for the index engine that the system made in the Registry (Microsoft Windows) or the file sapdbxie.ini (UNIX) during the installation. To edit these entries, proceed as follows:

¡ On Microsoft Windows operating systems, open the registry path
 \HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAP DBTech\XIE\default

¡ On UNIX operating systems, open the file
 /usr/spool/sql/ini/sapdbxie.ini and search for the [SAPDBXIE ] section

You see the following entries:

Description=WebDAV Asynchronous Indexing
EngineNode=<web_server>
IndexingLibraryDescription=WebDAV Asynchronous Indexing Service
IndexingLibraryFile=<independent_program_path>/web/pgm/sapdbxis
IndexingLibraryVersion=<version>
IndexingServiceName=MediaStore
LogFilename=<log_path>/sapdbxie.log
MaxThreads=10
RegistryName=WebDAV
RegistryNode=
RegistryPassword=DBA
RegistryTraceFilename=
RegistryUser=DBA

For information on the meaning of the variables, see Variables Used.

2. Under IndexingServiceName, specify the indexing service definitions that you want the index engine to work with.

3. Under RegistryName, RegistryNode, RegistryPassword and RegistryUser, enter the connection parameters to the database instance that you are using as the WebDAV store. Enter the following information:

RegistryName | Name of the database instance
RegistryNode | Name of the host on which the database instance is installed You do not need to enter anything here if your database instance is installed locally.
RegistryPassword | Password of the database user
RegistryUser | Name of the database user

4. Close the Registry or the registration file.

5. Now register the index engine in the specified database instance by entering the following command in the command line:
sapdbxie –i <registration_name>

Result

You have set up and registered a fully functioning index engine. You can use the WebDAV GUI to monitor the registered index engines, navigate simply through the document store, index XML documents, and search for indexed documents.


Using the Web Tools with the Apache Web Server (MaxDB: Web Tools Installation Guide)

Using the Web Tools with the Apache Web Server

Use

You can also use the Web Tools in combination with the Apache Web Server as a proxy, for example if you do not want to change your existing Apache environment.

Procedure

1. Make the following entries in the file httpd.confof the Apache Web Server :
 LoadModule proxy_module modules/mod_proxy.so
AddModule mod_proxy.c

2. Remove the commenting # for the proxy server directives and add the following statements to the directives:
 ProxyPass /webdbm http://<web_server:port>/webdbm
ProxyPassReverse /webdbm http://<web_server:port>/webdbm

ProxyPass /sapdb http://<web_server:port>
ProxyPassReverse /sapdb http://<web_server:port>

ProxyPass /WARoot http://<web_server:port>/WARoot
ProxyPassReverse /WARoot http://<web_server:port>/WARoot

ProxyPass /websql http://<web_server:port>/websql
ProxyPassReverse /websql http://<web_server:port>/websql


Uninstalling the Web Tools (MaxDB: Web Tools Installation Guide)

Uninstalling the Web Tools

Use

As of Version 7.3.33, you can use the program SDBUNINST to uninstall the Web Tools.

· Uninstallation on UNIX/Linux

· Uninstallation on Windows

If you installed the Web Tools on Linux using the rpm package, perform the uninstallation with rpm.


Uninstallation on UNIX/Linux (MaxDB: Web Tools Installation Guide)

Uninstallation on UNIX/Linux

Prerequisites

You are logged on as user root on your host.

Procedure

...

1. Stop the MaxDB Web Server.

2. Start the uninstallation by entering the command
sdbuninst –package Webtools


Linux: Uninstalling the Web Tools (rpm) (MaxDB: Web Tools Installation Guide)

Linux: Uninstalling the Web Tools (rpm)

Prerequisites

You are logged on as the root user.

Procedure

...

...

1. Go to the directory /usr/sdb-web.

2. Enter the following command: rpm –e maxdb-web


Uninstallation on Windows (MaxDB: Web Tools Installation Guide)

Uninstallation on Windows

Prerequisites

You have administrator rights for your host.

Procedure

...

1. Stop the MaxDB Web Server.

2. Start the uninstallation by executing the SDBUNINST program at the command prompt, using the following command:
sdbuninst.exe -package Webtools


Connecting External Backup Tools

Implementation Considerations

To manage MaxDB database instances and, in particular, to guarantee data security, easy-to-use database tools are provided as part of the software package. You can use these tools together with external backup tools.

To back up and restore MaxDB database instances, use the Database Manager. To load and unload data into or from MaxDB database instances, use the Loader.

For general information on the MaxDB database system, see the documentation Database Administration. The section External Backup Tools contains a list of external backup tools that are supported by MaxDB.

Content of this Document

This document describes the configuration of the MaxDB software for use with various external backup tools. It gives you an overview of which MaxDB database versions can be connected to which external backup tools, and for which database versions you can create parallel backups or restores.

Use

If, for example, you want to back up the data of a database instance, or load data from the database instance, you can save this data directly to files, pipes, or, by using a tape device, to tapes. However, you can also save data on a permanent medium by using an external backup tool. In this case, too, you use the MaxDB database tools to control the necessary actions. The external backup tool provides the tapes on which you can save or load the data. To be able to use the MaxDB database tool together with the external backup tool, you have to configure the MaxDB software accordingly.

You can use external backup tools for the following actions:

· Back up on external backup media

¡ Incremental data backups

¡ Complete data backups

¡ Log backups

¡ Archive version files

· Restore from external backup media

¡ Restore the database instance by using data backups, log backups, and archived log backups

· Unload data to external backup media

¡ Unload the whole database instance

¡ Unload the whole database catalog

· Load data from external backup media

¡ Load the whole database instance

¡ Load the whole database catalog

The procedures for backups and restores after the relevant configuration are contained in the following documents (depending on which tool you use):
Database Manager CLI, sections Using External Backup Tools for Backups and Using External Backup Tools for Restores
Database Manager GUI, sections Using External Backup Tools for Backups und Using External Backup Tools for Restores.

The procedures for loading and unloading data after the relevant configuration are described in the documentation Loader, sections Unloading with External Backup Tools and Loading with External Backup Tools.

After you have completed the configuration, test all planned actions. In this way, you familiarize yourself with the relevant MaxDB database tool, and test the correct configuration of the MaxDB software for your external backup tool. This is the prerequisite for ensuring that all actions that are performed with the external backup tool for backing up, restoring, loading, and unloading data run without errors during production operation.

Switching the Operating System

When you back up or restore, you can switch from Microsoft Windows to Linux and the other way round only. This means that a backup created on the operating system Microsoft Windows can be restored only on the same operating system or on Linux. A backup created on Linux can be restored only on the same operating system or on Microsoft Windows.

If you are planning to migrate data between different operating systems, it is advisable in most cases to use the Loader. When you load or unload data, there are no restrictions for switching the operating system as far as this database tool is concerned. A switch is restricted only by the various backup devices being independent of operating systems only to a limited extent. If, for example, you want to switch from Microsoft Windows to UNIX, a tape device or an external backup tool would have to be compatible with both operating systems. Check this in advance in the documentation on your backup device.


Block Diagram: Backup and Restore (MaxDB: Connecting External Backup Tools)

Block Diagram: Backup and Restore

The following block diagram illustrates the database software components that are involved when you back up and restore data, and shows how they work together with an external backup tool.

Description of the Backup Process

The Database Manager client is used to send the command that saves the data; this calls the DBM Server program. If you are using a UNIX operating system, the DBM Server creates one or more pipes. If you use Microsoft Windows, the pipes are created by the database kernel. The DBM Server sends the information that starts the backup process to the database kernel. As soon as the data is written to the pipes, the DBM Server program calls the external backup tool. The backup tool reads the data from the pipes and saves it on a permanent medium.

Description of the Restore Process

The Database Manager client is used to send the command that restores the data; this calls the DBM Server program. If you are using a UNIX operating system, the DBM Server creates one or more pipes. If you use Microsoft Windows, the pipes are created by the database kernel. The DBM Server sends the information that starts the restore process to the database kernel. The program then calls the external backup tool and transfers the information about which backup has to be restored. The client of the backup tool requests the specified backup medium from the backup server. The server gets the medium, reads the data of the backup, and transfers the data to the client of the backup tool. The client writes the data into the pipes. There the data is read by the database kernel and transferred to the database system.


Block Diagram: Loading and Unloading Data (MaxDB: Connecting External Backup Tools)

Block Diagram: Loading and Unloading Data

The following block diagram illustrates the database software components that are involved when you load and unload data, and shows how they work together with an external backup tool.

Description of the Load Process

The Loader client is used to send the command that loads the data; this calls the Loader Server program. The Loader Server then creates the pipes. At the same time, it calls the external backup tool and tells it from which external backup tool to load the data. The client of the external backup tool requests the specified backup medium from the backup server. The backup server gets the medium, reads the data to be loaded from the backup medium, and transfers the data to the client of the external backup medium. The client writes the data sequentially to the pipes. There the Loader Server reads them and loads them into the database instance.

Description of the Unload Process

The Loader client is used to send the command that unloads the data; this calls the Loader Server program. The Loader Server then creates the pipes. The Loader Server starts to unload the data and write it sequentially to the pipes. At the same time, it calls the external backup tool. The backup tool reads the data sequentially from the pipes and saves it on a permanent medium.


Connecting to a Backint for Oracle Interface (MaxDB: Connecting External Backup Tools)

Connecting to a Backint for Oracle Interface

Many external backup tools have a Backint for Oracle interface. In principle, the program Backint for Oracle can backup any files in the file system, regardless of whether the Oracle database system is installed on the computer or not. The following description of how to connect MaxDB to a Backint for Oracle interface assumes that this feature is guaranteed by the vendor of the external backup tool with the Backint for Oracle interface.

After the MaxDB software has been configured accordingly, the MaxDB database tools for backing up, restoring, unloading and loading data can be connected to the Backint for Oracle interface of an external backup tool of this type.

The connection is made by using an adapter program that, together with the Backint for Oracle of the external backup tool, implements a Backint for MaxDB. This adapter program is part of your MaxDB installation.

After you have triggered the relevant action by using the database tool, the adapter program copies the data in segments into temporary files. The adapter program calls the Backint for Oracle program several times in succession to save these temporary files by using the external backup tool.

See also:

Restrictions for Using Backint for Oracle

How the MaxDB Adapter Program Works

Configuring the Backint for Oracle Connection


Restrictions for Using Backint for Oracle (MaxDB: Connecting External Backup Tools)

Restrictions for Using Backint for Oracle

The following MaxDB versions are valid, from the specified build numbers, for connecting MaxDB to an external backup tool by using a Backint for Oracle interface. The available MaxDB database tools are specified for each version.

The database versions listed are valid for each database instance type.

MaxDB Versions and Tools for Creating Backups and Restoring by Using a Backint for Oracle Interface

Version | Build No. | Available MaxDB Tools
7.4.03 | from 000 | Database Manager CLI, Database Manager GUI
 | from 002 | Also Web DBM
7.4.02 | from 000 | Database Manager CLI, Database Manager GUI
 | from 011 | Also Web DBM
7.4.01 | from 003 | Database Manager CLI, Database Manager GUI
7.3.32 | from 000 | Database Manager CLI, Database Manager GUI
7.3.00 | from 015 | Database Manager CLI, Database Manager GUI
 | from 025 | Also Web DBM
7.2.05 | from 008 | Database Manager CLI, Database Manager GUI (Backups only)*

* You can use this version of the Database Manager GUI only for creating backups and not for restore purposes. However, if you have installed a newer version of the Database Manager GUI that supports the restore function (7.4.03, for example), you can also restore databases that have an older version (7.2.05, for example), since this database tool is downward compatible.


Functions of the MaxDB Adapter Program (MaxDB: Connecting External Backup Tools)

How the MaxDB Adapter Program Works

To enable you to connect Backint for Oracle to MaxDB, an adapter program is delivered with the MaxDB software. This program meets the Backint for MaxDB specification if it is used with a Backint for Oracle program.

How Backups Work

...

The backup data of the database system is received by one or more pipes and saved in temporary files. You can define the number and size of these files in the parameter file of the MaxDB adapter program.

The MaxDB adapter program calls the external backup tool, and saves the temporary files by using the Backint for Oracle program. The temporary files are then deleted. This step is repeated until all data has been saved.

To speed up the backup process, you need to configure the adapter program to enable parallel backups. To do this, you define a group of parallel backup media and a separate staging area for each pipe. In this way, new temporary files are created, and existing temporary files are saved by using Backint for Oracle.

Administrative information is saved in a backup history, a backup of which is created by Backint for Oracle after each backup.

How Recoveries Work

...

The information about the backup history is evaluated by the adapter program.

The adapter program uses the backup history and Backint for Oracle to restore the required temporary files in the correct sequence. The temporary files are transferred by the adapter program to the database system by using one or more pipes.

If an error occurs and the backup history is no longer available, you have to manually restore the last version of the backup history by using Backint for Oracle. Make sure that you are familiar with Backint for Oracle and the handling of your backup tool in case this is necessary.


Configuring the Backint for Oracle Connection (MaxDB: Connecting External Backup Tools)

Configuring the Backint for Oracle Connection

Use

You configure the MaxDB software with the aim of connecting the MaxDB database tools for backing up, restoring, unloading, or loading data to the Backint for Oracle interface of an external backup tool.

Prerequisites

· Your external backup tool has a Backint for Oracle interface.

· The version of your MaxDB database system supports the connection of a Backint for Oracle interface (see: Restrictions for Using Backint for Oracle).

· Your Backint for Oracle program is able to save any files in a file system, even if you do not have an Oracle database system installed on your computer.

Procedure

To connect MaxDB to the Backint for Oracle interface, perform the following steps:

...

1. Configure the Backint for Oracle interface of the external backup tool according to the instructions of the vendor. If you have to create a configuration file for this, you have to specify its name in the parameter file of the adapter program (see step 2).

2. Create the parameter file for the MaxDB adapter program
This file connects MaxDB with the external backup tool. If necessary, also enter the name of the configuration file of the external backup tool in this file (see step 1).

Example

3. Create the configuration file for Backint for MaxDB (case 1)
This file connects the Database Manager with the MaxDB adapter program. Also enter the name of the parameter file of the MaxDB adapter program in this file (see step 1).

Example

4. Export the environment variables of the external backup tool if you are required to do so by the vendor of the external backup tool.

5. Set the environment variable BSI_ENV for the program Database Manager.

6. If necessary, set non-tool-specific environment variables for the Database Manager.


Creating the Parameter File for the MaxDB Adapter Program (MaxDB: Connecting External Backup Tools)

Creating the Parameter File for the MaxDB Adapter Program

Use

If you want to use an external backup tool with a Backint for Oracle interface for a MaxDB database system, you first have to configure the connection between MaxDB and Backint for Oracle (see Configuring the Backint for Oracle Connection). Creating the parameter file for the MaxDB adapter program is one of the required steps for this configuration.

In the parameter file you determine where the adapter program generates the required temporary files, and where the interface program Backint for Oracle is located.

You enter the name of this parameter file in the configuration file of the Backint for MaxDB (keyword PARAMETERFILE) when you configure Backint for MaxDB.

Procedure

On every line in the parameter file you specify a parameter of the MaxDB adapter program. When you do this, at the beginning of each line you have to specify the keyword for the parameter and then the relevant value(s). Lines that do not begin with keywords are ignored by the system.

Syntax

<key_string> <value_string>

<key_string> | Keyword for a parameter; can consist of one or more words
<value_string> | Value(s) of the parameter

You can define the following parameters for the MaxDB adapter program:

Parameter

Syntax

Description

Absolute path and size of a temporary file

STAGING AREA: <absolute_path>/<file_name> <size> [KB|MB|GB]

You can define up to 256 temporary files.
If you do not specify a unit for the size, the size is configured in bytes.
The program uses precisely one temporary file for each pipe.

Maximum number of temporary files that are to be processed by Backint for Oracle concurrently.

FILES PER BACKINT CALL: <number>

Default value: 1
The program can save temporary files and generate other temporary files at the same time, provided that the <number> specified here is smaller than the configured number of temporary files.

Absolute path and name of the Backint for Oracle program

BACKINT: <absolute_path>/<file_name>

Absolute path and name of the configuration file for the Backint for Oracle program

PARAMETERFILE OF BACKINT: <absolute_path>/<file_name>h>

Define this parameter only if you have to create a configuration file for the external backup tool. Otherwise, do not use this keyword.

Absolute path and name of the backup history

HISTORY FILE: <absolute_path>/<file_name>

The backup history contains the information that is required for the restore function.

Absolute path and name of the standard input file

INPUTFILE FOR BACKINT: <absolute_path>/<file_name>

These files must differ from the files that are configured for the Backint for MaxDB connection (see INPUT, OUTPUT, ERROROUTPUT in Creating the Configuration File for Backint for MaxDB).

Absolute path and name of the standard output file

OUTPUT FILE FOR BACKINT: <absolute_path>/<file_name>

Absolute path and name of the standard error output file

ERRORFILE FOR BACKINT: <absolute_path>/<file_name>

Maximum waiting time in seconds between creating a temporary file and starting to save it by using Backint for Oracle

MAXIMAL DELAY OF BACKINT CALL: <number>

Default value: 10
This value is specified to prevent deadlocks in exceptional situations during a parallel backup or a restore.

If the temporary files are created at different speeds and one temporary file is already complete, the adapter program waits a maximum of the time specified here for another temporary file to be completely created. If no other file is created within the specified time, the existing temporary file is saved.

Specify enough time to save the configured number of temporary files (FILES PER BACKINT CALL:). However, you must also make sure that the end of the backup process is not delayed for too long.

Specifies whether or not the adapter program should ignore the closing slash (/ or \) of an absolute directory name for Backint for Oracle.

OMIT LAST DIRECTORY DELIMITER ON RESTORE: <option>

<option> ::= YES | NO

NO: Default value
The slash is not ignored.
YES: The slash is ignored.
Use this option to avoid problems with Backint for Oracle implementations that do not expect a closing slash (/ or \) at the end of a directory name.
This parameter is supported for the following MaxDB versions as of the specified build numbers:
7.4.03 from build 000, 7.4.02 from build 002, 7.3.00 from build 021, 7.2.05 from build 016

Value of the environment variable BI_CALLER

BI_CALLER_VALUE: <value>

Set this parameter only if the backup tool requires you to set this parameter. In accordance with the system default, the variable BI_CALLER is removed from the environment before Backint for Oracle is called. For most Backint for Oracle implementations you do not need to set this value since these implementations allow the environment variables BI_CALLER to be missing. This parameter is supported for the following MaxDB versions as of the specified build numbers:
All versions from 7.4.04 build 000, 7.4.03 from build 006, 7.4.02 from build 016, 7.3.0 from build 029, 7.2.05 from build 025.

See also:

Example of a Parameter File for the MaxDB Adapter Program


Example of a Parameter File for the MaxDB Adapter Program (MaxDB: Connecting External Backup Tools)

Example of a Parameter File for the MaxDB Adapter Program

Use

You can simplify the way you create the parameter file for the MaxDB adapter program if you use the following example and adjust it to suit your needs. If you do not want a certain parameter to be set by the parameter file, you have to invalidate or delete the relevant keyword.

File Content

STAGING AREA: D:\TEMP\STAGE1 1 GB
STAGING AREA: E:\TEMP\STAGE2 1024 MB
STAGING AREA: F:\TEMP\STAGE3 1048576 KB
STAGING AREA: G:\TEMP\STAGE4 1073741824

FILES PER BACKINT CALL: 2

BACKINT: C:\BackupTool\BIN\backint.exe
PARAMETERFILE OF BACKINT: C:\BackupTool\CONF\backintoraconfig.utl

HISTORY FILE: C:\SAPDB\BackintHistory

INPUTFILE FOR BACKINT: C:\TEMP\backint4Oracle.in
OUTPUTFILE FOR BACKINT: C:\TEMP\backint4Oracle.out
ERRORFILE FOR BACKINT: C:\TEMP\backint4Oracle.err

MAXIMAL DELAY OF BACKINT CALL: 30

Explanation

Keyword | Value(s) | Explanation
STAGING AREA: | D:\TEMP\STAGE1 1 GB E:\TEMP\STAGE2 1024 MB F:\TEMP\STAGE3 1048576 KB G:\TEMP\STAGE4 1073741824 | The adapter program (if configured in this way) can backup or restore a maximum of four pipes at the same time. The temporary files created in doing this can reach a size of one gigabyte, as long as the end of the pipe is not reached.
FILES PER BACKINT CALL: | 2 | As soon as two of the four temporary files have been completely created, they are saved by calling the Backint for Oracle program.
BACKINT: | C:\Backuptool\BIN\backint.exe | The absolute path of the Backint for Oracle program is: C:\Backuptool\BIN\backint.exe.
PARAMETERFILE OF BACKINT: | C:\BackupTool\CONF\backint oraconfig.utl | The absolute path of the configuration file of the Backint for Oracle program is: C:\Backuptool\CONF\backintoraconfig.utl.
HISTORY FILE: | C:\SAPDB\BackintHistory | The adapter program stores the backup history at the end of each backup under the path C:\SAPDB\BackintHistory and saves the history by calling the Backint for Oracle program again.
INPUTFILE FOR BACKINT: | C:\TEMP\backint4Oracle.in | Standard input for Backint for Oracle: C:\TEMP\backint4Oracle.in
OUTPUTFILE FOR BACKINT: | C:\TEMP\backint4Oracle.out | Standard output for Backint for Oracle: C:\TEMP\backint4Oracle.out
ERRORFILE FOR BACKINT: | C:\TEMP\backint4Oracle.err | Standard error output for Backint for Oracle: C:\TEMP\backint4Oracle.err
MAXIMAL DELAY OF BACKINT CALL: | 30 | If the temporary files are created at different speeds and one temporary file is already complete, the adapter program waits a maximum of 30 seconds for another of the temporary files to be completely created. If none of the other files is created within 30 seconds, the temporary file that already exists is backed up using Backint for Oracle.


Creating the Configuration File for Backint for MaxDB (MaxDB: Connecting External Backup Tools)

Creating the Configuration File for Backint for MaxDB

Use

You configure the MaxDB software with the aim of connecting the MaxDB database tools for backing up, restoring, unloading, or loading data to an external backup tool.

You use the configuration file for Backint for MaxDB to inform the Database Manager where the Backint for MaxDB program is located, and how to communicate with it.

Case 1: Connecting to Backint for Oracle by Using the MaxDB Adapter Program

If you want to use an external backup tool with a Backint for Oracle interface for a MaxDB database system, you first have to configure the connection between the MaxDB and the Backint for Oracle program (see Configuring the Backint for Oracle Connection). Creating the configuration file for the Backint for MaxDB is one of the required steps for this configuration.

(See also: How the MaxDB Adapter Program Works.)

Case 2: Connecting to the Backint for MaxDB Interface of an External Backup Tool (Third-Party Vendor)

If you want to use an external backup tool with a Backint for MaxDB interface for a MaxDB database system, you have to create a configuration file. For the most part, this corresponds to the configuration file in case 1. The differences are explained in the following description.

It is assumed that the Backint for MaxDB interface of the third-party vendor meets the Backint for MaxDB specification (see also the documentation Backint for MaxDB).

Procedure

On every line in the configuration file you specify a parameter of the Database Manager. When you do this, at the beginning of each line you have to specify the keyword for the parameter and then the relevant value(s). Lines that do not begin with keywords are ignored by the system.

Syntax

<key_string> <value_string>

<key_string> | Keyword for a parameter; can consist of one or more words
<value_string> | Value(s) of the parameter

You can define the following parameters for connecting Backint for MaxDB to the Database Manager:

Parameter

Syntax

Description

Absolute path and name of the Backint program

BACKINT <absolute_path>/<file_name>

Case 1: Connecting to a Backint for Oracle interface by using a MaxDB adapter program
Specify the absolute path and name of the adapter program that was delivered with MaxDB.

Case 2: Connecting to the Backint for MaxDB interface of an external backup tool (third-party vendor)
Specify the absolute path and name of the Backint for MaxDB program.

Absolute path and name of the standard input file

INPUT <absolute_path>/<file_name>

The Database Manager creates these files temporarily and uses them for standard input, output, and error output for Backint for MaxDB.

Absolute path and name of the standard output file

OUTPUT <absolute_path>/<file_name>

Absolute path and name of the standard error output file

ERROROUTPUT <absolute_path>/<file_name>

Absolute path and name of the configuration file of the Backint for MaxDB program

PARAMETERFILE <absolute_path>/<file_name>

Case 1: Connecting to a Backint for Oracle interface by using a MaxDB adapter program
Specify the absolute path and name of the parameter file of the adapter program.

Case 2: Connecting to the Backint for MaxDB interface of an external backup tool (third-party vendor)
Specify the absolute path and name of a configuration file for the Backint for MaxDB program, if it was necessary to create one.

Time in seconds,

Time after which the backup tool exits, after the database kernel has copied all data successfully

TIMEOUT_SUCCESS <number>

Default value: 300

Case 1 - Connecting to a Backint for Oracle interface by using a MaxDB adapter program: Make sure that you allow enough time so that the backup tool can save all copied data to a tape. The number of temporary files and their configured sizes are the most important factors here.

Case 2 - Connecting to the Backint for MaxDB interface of an external backup tool (third-party vendor): Period of time after which the Database Manager terminates the backup tool, if all data has been copied to the pipes.

Note that the backup tool always exits after this defined period, whether all data copied from the database kernel has been backed up by the backup tool or not.

Time in seconds,

Time after which the backup tool exits, if the database kernel has stopped the backup due to an error.

TIMEOUT_FAILURE <number>

Default value: 300

Make sure that you allow enough time so that the backup tool can save all data copied by the database kernel. This is because the backup tool always exits when this timeout is reached, even if not all of the copied data has been saved yet. On the other hand, do not specify too much time. Otherwise, you risk a situation where a backup stopped by the database kernel blocks other backups (such as automatic backups at night) from being started.

Absolute path of the run directory of the source database

ORIGINAL_RUNDIRECTORY <absolute_path>

Default value: Run directory of the current database instance

Specify this parameter only for a migration.
The prerequisite for the migration from one computer to another is that the version of Backint for MaxDB that you are using can make backups from the source computer available on the target computer.

Pay attention to upper- and lowercase spelling when you specify this value.

See also:

Example of a Configuration File for Backint for MaxDB


Example of a Configuration File for Backint for MaxDB (MaxDB: Connecting External Backup Tools)

Example of a Configuration File for Backint for MaxDB

Use

You can simplify the way you create configuration file for Backint for MaxDB if you use the following example and adjust it to suit your needs. If you do not want a certain parameter to be set by the parameter file, you have to invalidate or delete the relevant keyword.

File Content

Case 1: Connecting to a Backint for Oracle Interface by Using the MaxDB Adapter Program

BACKINT C:\SAPDB\TST\db\bin\backint.exe
INPUT C:\TEMP\backint4MAXDB.in
OUTPUT C:\TEMP\backint4MAXDB.out
ERROROUTPUT C:\TEMP\backint4MAXDB.err
PARAMETERFILE C:\SAPDB\WRK\TST\backintmaxdbconfig.par
TIMEOUT_SUCCESS 600
TIMEOUT_FAILURE 300
ORIGINAL_RUNDIRECTORY C:\SAPDB\wrk\CUSTOMERDB

Case 2: - Connecting to the Backint for MaxDB Interface of an External Backup Tool (Third-Party Vendor)

BACKINT C:\Backuptool\backint.exe
INPUT C:\TEMP\backint4MAXDB.in
OUTPUT C:\TEMP\backint4MAXDB.out
ERROROUTPUT C:\TEMP\backint4MAXDB.err
PARAMETERFILE C:\SAPDB\WRK\TST\backintmaxdbconfig.par
TIMEOUT_SUCCESS 600
TIMEOUT_FAILURE 300
ORIGINAL_RUNDIRECTORY C:\SAPDB\wrk\CUSTOMERDB

Explanation

Keyword | Value | Explanation
BACKINT | C:\Backuptool\backint.exe | The absolute path of the Backint for MaxDB program is: C:\Backuptool\backintsapdb.exe.
INPUT | C:\TEMP\backint4MAXDB.in | The absolute path of the standard input is: C:\TEMP\backint4MAXDB.in
OUTPUT | C:\TEMP\backint4MAXDB.out | The absolute path of the standard output is: C:\TEMP\backint4MAXDB.out
ERROROUTPUT | C:\TEMP\backint4MAXDB.err | The absolute path of the standard error output is: C:\TEMP\backint4MAXDB.err
PARAMETERFILE | C:\SAPDB\WRK\TST\adaptprog.par | The absolute path of the parameter file of the adapter program is: C:\SAPDB\WRK\TST\adaptprog.par.
TIMEOUT_SUCCESS | 600 | If successful, the Database Manager waits for a maximum of 10 minutes for Backint for MaxDB to stop.
TIMEOUT_FAILURE | 300 | If errors occur, the Database Manager waits for a maximum of 5 minutes for Backint for MaxDB to stop.
ORIGINAL_RUNDIRECTORY | C:\SAPDB\wrk\ CUSTOMERDB | Run directory of the original database instance: C:\SAPDB\wrk\P1.


Exporting Environment Variables for the External Backup Tool (MaxDB: Connecting External Backup Tools)

Exporting Environment Variables for the External Backup Tool

Use

If the vendor of the external backup tool stipulates the export of environment variables, you can export them into the environment by using the Database Manager CLI before you call the external backup tool.

The export of environment variables is supported for the following database versions as of the specified build numbers:
7.2.05 from build 016, 7.3.00 from build 021, 7.4.02 from build 002, 7.4.03 from build 000

Syntax

dbmcli -d <database_name> -n <database_server> -u <dbm_user>,<password> dbm_configset -raw set_variable_<number> <variable>=<value>

<number> | Your choice of numbering for the variables that have to be set (0<= number <=100)
<variable> | Environment variable
<value> | Value of the environment variable

Even if you define multiple values for one environment variable, only the smallest of these values is exported for this environment variable.
Example:
You have entered the following DBM commands:

dbmcli ... dbm_configset -raw <variable> <value1>
dbmcli ... dbm_configset -raw set_variable_<number> <variable>=<value2>

If number1 < number2, the Database Manager exports only the <value1> for the environment variable <variable>, otherwise only the value <value2>.

If you publish one of the environment variables TEMP, TMP, ADINT, ADA_OPT, NSR_ENV, NSR_POOL, NSR_EXPIRE, or BSI_ENV with
dbmcli ... dbm_configset -raw <variable> <value1>
and export it with
dbmcli ... dbm_configset -raw set_variable_<number> <variable>=<value2>,
the environment variable is exported with the value <value1> before an external backup tool is called.


Setting the Environment Variable BSI_ENV (MaxDB: Connecting External Backup Tools)

Setting the Environment Variable BSI_ENV

Use

So that the Database Manager or Loader on the database computer can access the configuration file for Backint for MaxDB, you have to explicitly define the absolute path of the file in the environment variable BSI_ENV by using the Database Manager CLI.

If you do not do this, instead of the configuration file, the system uses the file specified in the following table:

Operating System | File
UNIX | <run_directory>/bsi.env
Microsoft Windows | <run_directory>\bsi.env

Syntax

dbmcli -d <database_name> -n <database_server> -u <dbm_user>,<password> dbm_configset -raw BSI_ENV <value>

<value>

Value of the environment variable BSI_ENV

See also:

Database Manager CLI, section Changing a Database Manager Configuration Parameter


Setting Non-Tool-Specific Environment Variables for the Database (MaxDB: Connecting External Backup Tools)

Setting Non-Tool-Specific Environment Variables for the Database Manager

Use

To enable the Database Manager to access the variables it needs on the database computer, or to force the Database Manager to export environment variables before it calls an external backup tool, you must use the Database Manager CLI to specify these environment variables explicitly.

You can set these environment variables for each external backup tool. The values you define here override any values defined for these variables in the environment or in the configuration file of the external backup tool.

¡ If you want to override the environment variable TEMP or TMP, proceed as described in Setting TEMP or TMP.

¡ If you want to define timeouts for external backup tools from third-party vendors, proceed as described under Setting DBM_TTO_SUCCESS and DBM_TTO_FAILURE.

In this way, you can define how long the external backup waits until it exits after all data has been sent to the pipe(s), or how long it waits until it terminates the backup if an error occurs.

Use the same procedure for Backint for MaxDB if you want to override the values defined for TIMEOUT_SUCCESS and/or TIMEOUT_FAILURE in the configuration file.


Setting TEMP or TMP (MaxDB: Connecting External Backup Tools)

Setting TEMP or TMP

Use

You use the Database Manager CLI to set the environment variables TEMP or TMP. The values you define override the values specified for TEMP or TMP in the configuration file of the Database Manager or the environment.

Syntax

dbmcli –d <database_name> -n <database_server> -u <dbm_user>, <password> dbm_configset –raw <variable> <value>

<variable> | Name of the environment variable TEMP | TMP
<value> | Absolute path and name of the directory in which the Database Manager generates temporary files


Setting DBM_TTO_SUCCESS and DBM_TTO_FAILURE (MaxDB: Connecting External Backup Tools)

Setting DBM_TTO_SUCCESS and DBM_TTO_FAILURE

Use

You use the Database Manager CLI to define the values for the environment variables DBM_TTO_SUCCESS and DBM_TTO_FAILURE.

You use the variable DBM_TTO_SUCCESS to define the period of time after which the Database Manager exits the external backup tool, if the database kernel has sent all the data to the pipes or files. The external backup tool is also terminated if not all the data has been backed up to pipes or files, to stop the backup if there are any errors in the backup tool.

If you use Backint for MaxDB, you use this method to override the value of the parameter TIMEOUT_SUCCESS in the Backint for MaxDB configuration file.

You use the variable DBM_TTO_FAILURE to define the period of time after which the Database Manager exits the external backup tool, if the database kernel has stopped the backup due to an error. The external backup tool is also exited if the database kernel has not yet copied all data to the pipes or files. This enables extra backups to be started, for example, when making automatic backups at night.

If you use Backint for MaxDB, you use this method to override the value of the parameter TIMEOUT_FAILURE in the Backint for MaxDB configuration file.

Syntax

dbmcli –d <database_name> -n <database_server> -u <dbm_user>, <password> dbm_configset –raw <variable> <value>

<variable> | Name of the environment variable DBM_TTO_SUCCESS | DBM_TTO_FAILURE
<value> | Value of the timeout in seconds


Connecting to a Backint for MaxDB Interface (MaxDB: Connecting External Backup Tools)

Connecting to a Backint for MaxDB Interface

Use

External backup tools that have their own Backint for MaxDB interface are still being developed. The requirements that need to be met by this interface are documented in Backint for MaxDB.

The section Connecting to a Backint for Oracle Interface describes the use of a Backint for MaxDB implementation by using an adapter program. This implementation uses a program that was developed by SAP and is delivered with the MaxDB software package. This program is intended for connecting to Backint for Oracle. The configuration file that has to be created, however, corresponds to the configuration file that would have to be created for an external backup tool with its own Backint for MaxDB interface if the requirements in the documentation Backint for MaxDB are met by the vendor.

Prerequisites

The version of your MaxDB database system supports the connection of a Backint for MaxDB interface (see: Restrictions for Using Backint for MaxDB).

Procedure

To connect to a Backint for MaxDB interface, perform the following steps:

...

1. Create the configuration file for Backint for MaxDB, case 2.

2. Export the environment variables of the external backup tool if this is required by the vendor of the external backup tool.

3. Set the environment variable BSI_ENV for the Database Manager.

4. If necessary, set non-tool-specific environment variables for the Database Manager.


Restrictions for Using Backint for MaxDB (MaxDB: Connecting External Backup Tools)

Restrictions for Using Backint for MaxDB

The following MaxDB versions are valid from the specified build numbers, for connecting MaxDB to an external backup tool by using a Backint for MaxDB interface. The available MaxDB database tools are specified for each version.

The database versions listed are valid for each database instance type.

MaxDB Versions and Tools for Creating Backups and Restoring by Using a Backint for MaxDB Interface

Version | Build No. | Available MaxDB Tools
7.4.03 | from 000 | Database Manager CLI, Database Manager GUI
 | from 002 | Also Web DBM
7.4.02 | from 000 | Database Manager CLI, Database Manager GUI
 | from 011 | Also Web DBM
7.4.01 | from 003 | Database Manager CLI, Database Manager GUI
7.3.32 | from 000 | Database Manager CLI, Database Manager GUI
7.3.00 | from 015 | Database Manager CLI, Database Manager GUI
 | from 025 | Also Web DBM
7.2.05 | from 008 | Database Manager CLI, Database Manager GUI (Backups only)*

* You can use this version of the Database Manager GUI only for creating backups and not for restore purposes. However, if you have installed a newer version of the Database Manager GUI that supports the restore function (7.4.03, for example), you can also restore databases that have an older version (7.2.05, for example), since this database tool is downward compatible.


Connecting to TSM (MaxDB: Connecting External Backup Tools)

Connecting to TSM

MaxDB supports connections to the external backup tool TSM from the company IBM/Tivoli for backing up, restoring, loading, and unloading data after the MaxDB software has been configured accordingly.

Note that there are version-specific restrictions for using TSM or for creating parallel backups or restores.

See also:

Restrictions for Using TSM

Restrictions for Creating Parallel Backups and Restores with TSM

Configuring the TSM Connection


Restrictions for Using TSM (MaxDB: Connecting External Backup Tools)

Restrictions for Using TSM

The following versions are valid, from the specified build numbers, for connecting MaxDB to the external backup tool TSM. The available MaxDB database tools are specified for each version.

The database versions listed are valid for each database instance type.

MaxDB Versions and Tools for Backups and Restores with TSM

Version | Build No. | Available MaxDB Tools
7.4.03 | from 000 | Database Manager CLI, Database Manager GUI
 | from 002 | Also Web DBM
7.4.02 | from 000 | Database Manager CLI, Database Manager GUI
 | from 011 | Also Web DBM
7.3.32 | from 000 | Database Manager CLI, Database Manager GUI (Backups only)*
7.3.00 | from 000 | Database Manager CLI, Database Manager GUI (Backups only)*
 | from 015 | Database Manager CLI, Database Manager GUI
 | from 025 | Also Web DBM
7.2.05 | from 000 | Database Manager CLI, Database Manager GUI (Backups only)*

* You can use this version of the Database Manager GUI only for creating backups and not for restore purposes. However, if you have installed a newer version of the Database Manager GUI that supports the restore function (7.4.03, for example), you can also restore databases that have an older version (7.2.05, for example), since this database tool is downward compatible.


Restrictions for Creating Parallel Backups and Restores with TSM (MaxDB: Connecting External Backup Tools)

Restrictions for Creating Parallel Backups and Restores with TSM

Parallel backups are only an option for data backups.

Parallel backups and restores with TSM can be performed for the following MaxDB versions as of the specified build numbers. The available MaxDB database tools are specified for each version.

MaxDB Versions and Tools for Performing Parallel Backups and Restores with TSM

Version | Build No. | Available MaxDB Tools
7.4.03 | from 000 | Database Manager CLI, Database Manager GUI
 | from 002 | Also Web DBM
7.4.02 | from 003 | Database Manager CLI, Database Manager GUI
 | from 011 | Also Web DBM
7.3.00 | from 021 | Database Manager CLI, Database Manager GUI
 | from 025 | Also Web DBM
7.2.05 | from 017 | Database Manager CLI, Database Manager GUI


Configuring the TSM Connection (MaxDB: Connecting External Backup Tools)

Configuring the TSM Connection

Use

You configure the MaxDB software with the aim of connecting the MaxDB database tools for backing up, restoring, unloading, or loading data to the external backup tool TSM. For this you use the TSM client adint2. If this client is not available on the platform that you use, you can also connect TSM to MaxDB by using Backint for Oracle.

See also:

Connecting to a Backint for Oracle Interface

The adint2 program is not contained in a standard installation of the TSM client. The program is provided separately by IBM. For more information, see the following Internet address: www.ibm.com.

Prerequisites

· The version of your MaxDB database system supports the connection of TSM (see: Restrictions for Using TSM).

· You have the TSM client adint2.

Procedure

...

1. If you want to create a parallel backup or restore, check whether the version of your database system supports this action (see Restrictions for Creating Parallel Backups and Restores with TSM).

2. Set the environment variables ADINT and ADA_OPT.

3. If necessary, set non-tool-specific environment variables for the Database Manager.


Setting the Environment Variables ADINT and ADA_OPT (MaxDB: Connecting External Backup Tools)

Setting the Environment Variables ADINT and ADA_OPT

Use

So that the Database Manager and the Loader on the database computer can access the required environment variables ADINT and ADA_OPT, you have to explicitly define them by using the Database Manager CLI.

Environment Variable | Description
ADINT | Specifies the directory in which the program adint2 (UNIX) or adint2.exe (Microsoft Windows) is stored. Specify this directory as an absolute path – without a closing slash (/) or backslash (\).
ADA_OPT | Absolute name of the adint2 configuration file. An example configuration file initSID.utl is located in the directory of the adint2 program.

Syntax

dbmcli -d <database_name> -n <database_server> -u <dbm_user>,<password> dbm_configset -raw <variable> <value>

<variable> | Environment variable ADINT | ADA_OPT
<value> | Value of the environment variable

See also:

Database Manager CLI, section Changing a Database Manager Configuration Parameter


Connecting to NetWorker (MaxDB: Connecting External Backup Tools)

Connecting to NetWorker

MaxDB supports connections to the external backup tool NetWorker from the company Legato for backing up, restoring, loading, and unloading data after the MaxDB software has been configured accordingly.

Note that there are version-specific restrictions for using NetWorker or for creating parallel backups or restores.

See also:

Restrictions for Using NetWorker

Restrictions for Creating Parallel Backups and Restores with NetWorker

Configuring the NetWorker Connection


Restrictions for Using NetWorker (MaxDB: Connecting External Backup Tools)

Restrictions for Using NetWorker

The following MaxDB versions are valid, from the specified build numbers, for connecting MaxDB to the external backup tool NetWorker from the company Legato. The available MaxDB database tools are specified for each version.

The database versions listed are valid for each database instance type.

MaxDB Versions and Tools for Backups and Restores with NetWorker

Version | Build No. | Available MaxDB Tools
7.4.03 | from 000 | Database Manager CLI, Database Manager GUI
 | from 002 | Also Web DBM
7.4.02 | from 000 | Database Manager CLI, Database Manager GUI
 | from 011 | Also Web DBM
7.3.32 | from 000 | Database Manager CLI, Database Manager GUI
7.3.00 | from 005 | Database Manager CLI, Database Manager GUI (Backups only)*
 | from 015 | Database Manager CLI, Database Manager GUI
 | from 025 | Also Web DBM
7.2.05 | from 001 | Database Manager CLI, Database Manager GUI (Backups only)*

* You can use this version of the Database Manager GUI only for creating backups and not for restore purposes. However, if you have installed a newer version of the Database Manager GUI that supports the restore function (7.4.03, for example), you can also restore databases that have an older version (7.2.05, for example), since this database tool is downward compatible.

The following NetWorker versions are the minimum required:

Operating System | NetWorker Version
UNIX | 5.5
Microsoft Windows | 5.7


Restrictions for Creating Parallel Backups and Restores with Net (MaxDB: Connecting External Backup Tools)

Restrictions for Creating Parallel Backups and Restores with NetWorker

Parallel backups are only an option for data backups.

Parallel backups and restores with NetWorker can be performed for the following MaxDB versions as of the specified build numbers: The available MaxDB database tools are specified for each version.

MaxDB Versions and Tools for Performing Parallel Backups and Restores with NetWorker

Version | Build No. | Available MaxDB Tools
7.4.03 | from 000 | Database Manager CLI, Database Manager GUI
 | from 002 | Also Web DBM
7.4.02 | from 000 | Database Manager CLI, Database Manager GUI
 | from 011 | Also Web DBM
7.3.32 | from 000 | Database Manager CLI, Database Manager GUI
7.3.00 | from 009 | Database Manager CLI, Database Manager GUI (Backups only)*
 | from 015 | Database Manager CLI, Database Manager GUI
 | from 025 | Also Web DBM
7.2.05 | from 004 | Database Manager CLI

* You can use this version of the Database Manager GUI only for creating backups and not for restore purposes. However, if you have installed a newer version of the Database Manager GUI that supports the restore function (7.4.03, for example), you can also restore databases that have an older version (7.2.05, for example), since this database tool is downward compatible.


Configuring the NetWorker Connection (MaxDB: Connecting External Backup Tools)

Configuring the NetWorker Connection

Use

You configure the MaxDB software with the aim of connecting the MaxDB database tools for backing up, restoring, unloading, or loading data to the external backup tool NetWorker.

Prerequisites

The version of your MaxDB database system supports the connection of NetWorker (see: Restrictions for Using NetWorker).

Procedure

...

1. If you want to create a parallel backup or restore, check whether the version of your database system supports this action (see Restrictions for Creating Parallel Backups and Restores with NetWorker).

2. Set the environment variable NSR_ENV.

3. Create the configuration file for NetWorker.

If you perform a parallel backup with a database whose version is lower than 7.4.03, set the NetWorker parameter Target Sessions for each tape drive to 1. (See the vendor’s documentation.)

4. If necessary, set non-tool-specific environment variables for the Database Manager.


Setting the Environment Variable NSR_ENV (MaxDB: Connecting External Backup Tools)

Setting the Environment Variable NSR_ENV

So that the Database Manager or Loader on the database computer can access the configuration file for NetWorker, you have to explicitly define the absolute path of the file in the environment variable NSR_ENV by using the Database Manager CLI.

If you do not do this, instead of the configuration file, the system uses the file specified in the following table:

Operating System | File
UNIX | /nsr/sapdb/env
Microsoft Windows | C:\Program Files\nsr\sapdb\env

Syntax

dbmcli -d <database_name> -n <database_server> -u <dbm_user>,<password> dbm_configset -raw NSR_ENV <value>

<value>

Value of the environment variable NSR_ENV

See also:

Database Manager CLI, section Changing a Database Manager Configuration Parameter


Creating the Configuration File for NetWorker (MaxDB: Connecting External Backup Tools)

Creating the Configuration File for NetWorker

You configure the MaxDB software with the aim of connecting the MaxDB database tools for backing up, restoring, unloading, or loading data to the external backup tool NetWorker.

Procedure

You determine a parameter of the Database Manager in every line in the configuration file. When you do this, at the beginning of each line you have to specify the keyword for the parameter and then the relevant value(s). Lines that do not begin with keywords are ignored by the system.

Syntax

<key_string> <value_string>

<key_string> | Keyword for a parameter; can consist of one or more words
<value_string> | Value(s) of the parameter

You can define the following parameters for connecting NetWorker and the Database Manager:

Parameter

Syntax

Description

Absolute path of the directory where NetWorker is installed

NSR_HOME <absolute_path>

The NetWorker programs SAVE, MMINFO, and RECOVER are in this directory.

Name of the NetWorker server

NSR_HOST <name>

Name of the NetWorker tape pool

NSR_POOL <name>

If you specify a name, it overwrites the default value for the tape pool that was configured in NetWorker.

Expiration date or period of the backup

NSR_EXPIRE <value>

This value is transferred to the NetWorker program SAVE and overrides the default value for the expiry date or expiry period that was configured in NetWorker.

See the NetWorker documentation for the allowed entries.

Specifies which of the NetWorker programs SAVE and RECOVER is started with the -v option

NSR_NOTVERBOSE <option>

<option> ::= NONE | SAVE | RECOVER | "SAVE AND RECOVER"

This value is required in case the NetWorker programs do not support the –v option.

NONE: Default value
SAVE and RECOVER are started with the -v option.

SAVE: SAVE is started without and RECOVER is started with the -v option.

RECOVER: SAVE is started with and RECOVER is started without the -v option.

"SAVE AND RECOVER": SAVE and RECOVER are started without the -v option.

Specifies whether the output of the NetWorker program SAVE is analyzed when backups take place

NSR_USEOUTPUT <option>

<option> ::= SAVE | NONE

SAVE: Default value
The output of SAVE is checked for error messages.

NONE: The output of SAVE is not checked for error messages. Only the return code of SAVE is used. Since SAVE can return the value 0 even if errors occur, do not use NONE.

Error messages of the NetWorker program SAVE that can be ignored

NSR_IGNOREERROR <error_text>

All error messages of the form <pipe_name>:<error_text> are ignored.

Repeat this parameter definition for each error message that can be ignored.

Specifies whether the Database Manager uses (for recoveries) the backup times or the NetWorker save set identifiers

NSR_EBIDTYPE <option>

<option> ::= NSAVETIME | SSID

NSAVETIME: Default value
Backups are identified by their backup time.
This is the recommended value since no particular authorization is required for the operating system user by the NetWorker program RECOVER.

SSID: Backups are identified using the NetWorker Save Set Identifier.

Waiting time (in seconds) between two SAVE calls during parallel backups

NSR_SAVEINTERVAL <time>

Default value: 10

Name under which you want to save the backup in NetWorker

NSR_BACKUPNAME <name>

Default value: Name of the database instance

Any string of characters that can contain the placeholders <database_name> and/or <node>. When backing up or restoring with NetWorker, the placeholders are replaced with the name of the database instance and/or the database computer.

Avoiding a NetWorker software error

NSR_AVOIDPSSIDBUG <option>

<option> ::= YES | NO

A software error in the MMINFO program when using the option -q pssid=0 (PSSID bug) is known as of NetWorker 6.0. You can avoid this error by setting this parameter.
NO: Default value
Calls the NetWorker MMINFO program with the option -q pssid=0
YES: Avoids the software error in the MMINFO program (only NetWorker versions as of 6.0)

Date format that is used for analyzing the output of the NetWorker program MMINFO

NSR_SAVETIMEFORMAT <format>

<format> ::= mm/dd/yy HH:MM:SS <option> | mm/dd/yyyy HH:MM:SS <option>

<option> ::= AM | PM

Required if current default value does not correspond to NetWorker output.

Default values are
mm/dd/yy HH:MM:SS AM: For date output from NetWorker that is more than 8 characters long

mm/dd/yyyy HH:MM:SS AM: For date output from NetWorker that is more than 10 characters long

You can configure only one format. This can be a format that differs from the default values as long as the specified syntax elements are used.

yy|yyyy year, mm month, dd day, HH hour, MM minute, SS second, AM | PM a.m. or p.m.

Specifies how the size specification for backups transferred with the NetWorker SAVE program is to be used.

NSR_SIZEROUNDUP <option>

<option> ::= NOROUNDUP | FIRSTDECIMAL | NORMAL | LASTINTEGER

Required if the size that was transferred by SAVE for the backup is rounded off.

This parameter can be used for the following database versions as of the specified build numbers only: 7.2.05 from build 017, 7.3.00 from build 021, 7.4.03 from build 000.

NOROUNDUP: Default value
 The size specification is used unchanged.

FIRSTDECIMAL: The size specification is increased by 0.1 (For example: Backup size 14 GB is used with 14.1 GB).

NORMAL: The size specification is increased by 0.5.

LASTINTEGER: The size specification is increased by 1.

Character string that is used as the value for the MMINFO option –t

NSR_AVOIDTIMEBUG <value>

Required if MMINFO from NetWorker does not work without option –t

This parameter can be used for the following database versions as of the specified build numbers only: 7.2.05 from build 018, 7.3.00 from build 022, 7.4.02 from build 004, 7.4.03 from build 000.

The character string must match the format expected by MMINFO. If the character string consists of multiple words, you have to set them in quotation marks.
Note that backups that are not within the time span specified by the character string are regarded by MaxDB as no longer available for a restore.

See also:

Example of a Configuration File


Example of a Configuration File for NetWorker (MaxDB: Connecting External Backup Tools)

Example of a Configuration File for NetWorker

Use

You can simplify the way you create the configuration file for NetWorker if you use the following example and adjust it to suit your needs. If you do not want a certain parameter to be set by the parameter file, you have to invalidate or delete the relevant keyword.

File Content

NSR_HOST           p47579
NSR_HOME           "C:\Program Files\nsr\bin"
NSR_POOL           MAXDBPOOL
NSR_EXPIRE         year

NSR_NOTVERBOSE     RECOVER
NSR_EBIDTYPE       NSAVETIME

NSR_USEOUTPUT      SAVE
NSR_IGNOREERROR    " unknown error 109 (0x6d)"
NSR_IGNOREERROR    " using unlocked access"
NSR_IGNOREERROR    " The pipe has been ended.”

NSR_SAVEINTERVAL   60
NSR_BACKUPNAME     MAXDB:<database_name>_on_<node>

NSR_AVOIDPSSIDBUG YES
NSR_SAVETIMEFORMAT "yyyy/mm/dd HH:MM:SS AM"

Explanation

Keyword

Value

Explanation

NSR_HOST

p47579

The NetWorker server is running on computer p47579.

NSR_HOME

"C:\Program Files\nsr\bin"

The NetWorker client is installed on the database server in the directory
C:\Program Files\nsr\bin

NSR_POOL

MAXDBPOOL

Backups are stored in the NetWorker pool MAXDBPOOL.

NSR_EXPIRE

year

The backups have an expiration time of one year.

NSR_NOTVERBOSE

RECOVERY

The NetWorker RECOVER program is run without the -v option.

NSR_EDITTYPE

NSAVETIME

The backup time is used to identify backups.

NSR_USEOUTPUT

SAVE

The output of the NetWorker SAVE program is searched for errors during every backup.

NSR_IGNOREERROR

" unknown error 109 (0x6d)"
 " using unlocked access"
" The pipe has been ended."

The messages
 <pipe_name>: unknown error 109 (0x6d),
<pipe_name>: using unlocked access and
 <pipe_name>: The pipe has been ended are ignored for the pipes that are used.

NSR_SAVEINTERVAL

60

The system waits 60 seconds between two SAVE calls during parallel backups.

NSR_BACKUPNAME

MAXDB:<database_name>_on_<node>

If the name of the database instance is DB73 and the name of the database computer is p47579, the backups are created with the name MAXDB:DB73_on_p47579 in NetWorker.

NSR_AVOIDPSSIDBUG

YES

The PSSID bug in the NetWorker program MMINFO is avoided.

NSR_SAVETIMEFORMAT

"yyyy/mm/dd HH:MM:SS AM"

The NetWorker MMINFO program delivers date specifications in the specified format.
Example: 2001/12/31 11:59:58 AM


Installation Manual

Purpose

This documentation provides you with detailed information on the following topics: installing and uninstalling MaxDB software with Version 7.5, updating the database software, and upgrading database instances to Version 7.5, on the operating system platforms supported by MaxDB.

It is particularly concerned with the following programs:

· SDBINST for the installation/update of installation profiles and individual software components, while taking into account dependencies between the components

· SDBUNINST for uninstalling software components, while taking into account dependencies between the components

· SDBUPD for upgrading database instances and their software

.

For a short description of the standard installation/update, and standard uninstallation, of the entire MaxDB software package outside of SAP systems, see the documentation Database Software Installation Guide.

For general information about the database system, see the documentation Database Administration.

The description of upgrading database instances and their software also applies to database instances in SAP systems.

Constraints

This documentation is not relevant for installing or uninstalling MaxDB software in SAP systems. The installation or uninstallation of the MaxDB software required for SAP systems is described in SAP-specific guides. SAP customers can find these guides in the SAP Service Marketplace, at http://service.sap.com.

Implementation Considerations

The programs SDBINST, SDBUNINST and SDBUPD are part of the database software package.

Open source users can download the entire database software free of charge from http://www.mysql.com/downloads.

SAP customers receive the MaxDB software with the SAP installation CD or in the Service Marketplace at http://service.sap.com.

The following description is based on using the software available online at http://www.mysql.com/downloads and the SAP Service Marketplace.

Installing and Updating the Database Software

Uninstalling the Database Software

Upgrading Database Instances and Their Software


Installing and Updating the Database Software (MaxDB: Installation Manual)

Installing and Updating the Database Software

Implementation Considerations

You can install or update the database software either interactively, or in the background.

You can install complete installation profiles, or just install or update individual software components. The installation program itself decides whether it is dealing with a new installation or an update.

The system logs the installation process.

Before you start the installation or upgrade of the database software:

· Make sure you have taken precautions against the most common errors that can cause an installation or update to crash (see Troubleshooting).

· Inform yourself about the advantages and disadvantages of interactive and background installations.

· Decide whether you need one or more database instances.

If you plan to run multiple database instances, we recommend a separate (parallel) software installation for each database instance. This makes subsequent updates easier, since any errors will only affect one database instance.

· Choose an appropriate installation profile, or decide whether, in special cases, you only need to install or update one or more individual software components. However, you can install individual components in the background only.

We recommend strongly that you always perform your installation or update with installation profiles. This is a simple and secure way of choosing the database software installation that meets your needs.

Conventions

See Variables, Supported Operating Systems and Platforms, Authorization Concept for UNIX Operating Systems

Interactive Installation/Update

In an interactive installation or update, you install complete installation profiles. The installation program SDBINST queries all necessary information, and offers you defaults and options for the installation profiles and installation paths. The program then installs the software package and registers it.

Background Installation/Update

In a background installation or update, you use options to specify the information needed by SDBINST. The actual installation process then runs in the background.

Advantages of Installation in the Background

· Performing an installation or an upgrade in the background takes less time.

· You have the option of installing or updating individual software components (parts of installation profiles).

· You can use an embedding in a call script to generate identical database software installations on different servers.

Disadvantages of Installation in the Background

· You must enter all the required options in the call script correctly and completely.

· The system determines some options from the software packages only at runtime. This means that the system cannot check the completeness of the information at the start of the installation. It starts the installation, and then interrupts it only when any information is missing.

Installation/Update with Installation Profiles

You can choose between various combinations of software components. Each individual combination fulfils a different purpose. You choose the installation profile that is appropriate for your needs, and do not need to worry about the sequence of the installation, or any dependencies between software components, to obtain a fully functioning software installation.

To perform a standard installation or update of the entire database software package, choose the installation profile all.

For a short description of the standard installation or update of the entire database software package, see the documentation Database Software Installation Guide.

Installation/Update of Software Components

You install individual components of the database software to just update parts of your database software installation. We recommend this installation procedure in special cases only.

In this procedure, you must take into account the dependencies between the individual software components. Otherwise, you see an error message that tells you about this, and the system terminates the installation.

Background Installation of the Software Component Precompiler (CPC <version>)

You want to update only the C++ Precompiler in your existing software installation. You start the installation of the software component CPC SDK <version>. The system recognizes that this component requires a new version of the software component CPC Base. You are reminded that the package CPC SDK <version> depends on the package CPC Base, which must be installed first. The installation terminates.

This means that, if there are many dependencies, you will have to restart the installation many times (each time with a different installation package).

You can avoid this problem by using, for example, the installation profile C Precompiler.

Installing/Updating Software on UNIX

Installing/Updating Software on Linux

Installing/Updating Software on Microsoft Windows


Installing/Updating Software on UNIX (MaxDB: Installation Manual)

Installing/Updating Software on UNIX

Use

You install or update a chosen installation profile or database software component. Use the following procedure for updates only if no database instances refer to the installation path of the software that you want to update.

If database instances refer to the installation path of the software, you must upgrade the database instances together with the software (see Upgrading Database Instances and Their Software). Otherwise, you risk making the database instances incompatible with the database software, and you may not be able to restart them.

The system logs the installation process.

Procedure

...

1. First, unpack the database software to a local directory.

Unpacking the Software on UNIX

2. Now decide whether you want to perform an interactive installation (only possible for installation profiles) or a background installation.

¡ Interactive Installations/Updates on UNIX

¡ Background Installations/Updates on UNIX

For the advantages and disadvantages of these installation procedures, see
Installing and Updating the Database Software.


Unpacking the Software on UNIX (MaxDB: Installation Manual)

Unpacking the Software on UNIX

Conventions

Variables

Procedure

...

1. Choose the appropriate software package for your operating system architecture, your database instance type, and the installation profile.

If you want to install or update an individual software component only, then select an installation profile that contains this software component.

Installation from the SAP Service Marketplace (service.sap.com, for SAP customers only)

¡ For the OLTP database instance type, choose
SAP Software ® Download ® SAP Support Packages & Patches ® Max DB ® MaxDB OLTP 64-BIT ® Max DB <version> OLTP ® <os> ®
MAXDB<version>_<build>-<GUID>.SAR

¡ For liveCache database instance type (SAP APO system), choose
SAP Software ® Download ® SAP Support Packages & Patches ® SAP APO ® SAP APO <apo_version> ® Binary Patches ® APO LC<version>/LCAPPS<apo_version> ® <os> ®
LC<version>A<apo_version>_<apo_build>-<GUID>.SAR

Installation from http://www.sapdb.org

¡ For the OLTP database instance type only
Go to Software, choose your operating system, and follow the instructions for downloading the software package
maxdb-<inst_profile>-<os>-64bit-<arch>-<version>_<build>.tgz

2. Copy the software package to a local directory of your choice.

3. Unpack the software with the following command:

For an installation from the SAP Service Marketplace (service.sap.com):

SAPCAR –xvf MAXDB<version>_<build>-<GUID>.SAR

Installation from http://www.sapdb.org

tar xvzf maxdb-<inst_profile>-<os>-64bit-<arch>-<version>_<build>.tgz

Result

The system creates the following subdirectories in the local directory

· for OLTP software, the subdirectory
max db-<inst_profile>-<os>-64bit-<arch>-<version>

· for SAP liveCache, the subdirectory
 apo<apo_version>_livecache-<os>-64bit-<arch>-<version>

and saves the software to them.


Interactive Installations/Updates on UNIX (MaxDB: Installation Manual)

Interactive Installations/Updates on UNIX

Use

You use the program SDBINST to install/update installation profiles of the database software on UNIX. The program queries all necessary information during the installation process.

If you want to update an existing database software installation, the procedure depends on whether your source version is 7.5.00 or higher, or is lower than 7.5.00.

If your source version is lower than 7.5.00, then you must stop the X Server and all database instances before the installation or update. Remember that this interrupts the communication between the clients and all local database instances. If your source version is 7.5.00 or higher, then the X Server software supports an update of the database software while the X Server is running. In this case, you no longer need to stop the X Server and all database instances. However, you do need to stop the database instances that are assigned to the installation directory that is being updated.

Conventions

Variables

Prerequisites

· You are in a root shell.

· You have downloaded the installation package, and unpacked it in a local directory of your choice (Unpacking the Software on UNIX).

Preparations

If the following conditions apply to your system, you must perform the specified steps before a new installation:

· The installation program enters the services sql6, sql30 and sapdbni72 in the file /etc/services, if they do not already exist there. If these services are managed centrally for your system on your network (NIS), you must enter them there as follows:
 sql6 7210/tcp
sql30  7200/tcp
sapdbni72 7269/tcp

· During the installation, the database software must be assigned to a special operating system user, <sdb_user>, as the owner of the software and to the group <sdba_group>.
We recommend that you define the group and the owner in advance. Only users with the correct authorizations can generate the database instances later (see also Authorization Concept for UNIX Operating Systems for software versions from 7.5.00).
The special operating system user must not log on to the operating system. For this reason, take this authorization away from this user. For information on how to do this, see your operating system documentation (lock account).

If you manage user groups and owners locally on your host, we recommend that you register the names of the user groups and the owner in the operating system before you start the installation. However, you can also specify this information during the installation process.
If you manage user groups and owners for your system centrally in the network, you must create them here before you start the installation. For more information on creating operating system users and user groups, see your operating system documentation.

The primary group of the owner of the database software is the administrator group.

For SAP systems, you must use the names sdb and sdba for the owner <sdb_user> and the group <sdba_group>.

For consistency, especially if you need to contact the support team, we recommend that you also use the names sdb and sdba for the owner and group in other systems.

· If the path <independent_program_path>/bin is not yet entered in the environment variable PATH, enter it now. (For information on setting environment variables, see your operating system documentation.)

Procedure

...

1. If you want to update an existing database software installation,

¡ If necessary, stop each database instance assigned to the installation directory that you want to update with the command
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

¡ If necessary, stop the X Server program ( vserver process) with the command
x_server stop

For a new installation, start at step 2.

2. Switch to the directory
maxdb-<inst_profile>-<os>-64bit-<arch>-<version>_<build>,
which contains the installation software for your chosen installation profile.
Enter ./SDBINST to start the installation/update program.

3. The system proposes your chosen installation profile.
If your chosen installation profile (all, for example) contains other installation profiles, you can also select one of these profiles. Specify the appropriate ID. Confirm your selection.

4. If you are installing the software for the first time, or if you are updating the software to Version 7.5.00, then the system prompts you to enter the following details:

¡ the special operating system user <sdb_user> (the owner of the database software)

¡ the group <sdba_group>

If you are installing or updating older software versions, the system prompts you to enter the group <group> and owner <owner> of the database software.

If the group and owner have already been created, enter and confirm the correct values. The system compares this information with the values stored locally or in the network. If your information does not match these values, then the installation terminates.

If the group and owner have not yet been created, the system asks you whether you want to create them. Specify your chosen values, or confirm the defaults. When you specify these values, the group and owner are created locally on your host.

5. The system now checks your server for installations of the database software that can be updated.

It lists any relevant installations.

¡ If you want to update an existing installation, specify its ID.
The system then updates the software in <independent_program_path>. Depending on your chosen profile, the software in <dependent_path> is also updated, if the installation package contains newer versions of the files.

¡ If you want to perform a new installation of the database software in parallel with the existing installation, specify none. You then have the option of specifying a new installation path. Define an installation path in parallel with the existing installation path.

If no installation of the database software exists yet on your server, the software components in the installation profile are now installed, one by one. Depending on your chosen installation profile, the system prompts you for the following paths:

¡ Path for saving data, configurations, and run directories of database instances and database applications (system default is /var/opt/sdb/data)

¡ Path for saving programs and libraries shared by database instances and database applications (system default is /opt/sdb/programs)

¡ Path for saving the server software that is dependent on the database version.
The specified path must be unique. Multiple directories containing different versions can exist simultaneously (system default is /opt/sdb/<version>)

Specify paths, or confirm the defaults.

6. If there has not been an installation of the database software on your server up to now, add the entry <independent_program_path>/bin to the environment variable PATH for each user that wants to use the database system.

You see a message about the successful completion of the installation.

Result

The chosen installation profile of the database software has been installed and registered in the new version on your server. You can check the result of your installation using the log (Logging).

You can now create new database instances with the Database Manager

(See:

· Creating a Database Instance in Database Manager CLI or

· the Web DBM documentation.)


Background Installations/Updates on UNIX (MaxDB: Installation Manual)

Background Installations/Updates on UNIX

Use

You use the program SDBINST to install/update installation profiles or individual components of the database software on UNIX. You specify all required information on the command line, together with the command for starting the installation program.

If you want to update an existing database software installation, the procedure depends on whether your source version is 7.5.00 or higher, or is lower than 7.5.00.

If your source version is lower than 7.5.00, then you must stop the X Server and all database instances before the installation or update. Remember that this interrupts the communication between the clients and all local database instances. If your source version is 7.5.00 or higher, then the X Server software supports an update of the database software while the X Server is running. In this case, you no longer need to stop the X Server and all database instances. However, you do need to stop the database instances that are assigned to the installation directory that is being updated.

Conventions

Variables

Prerequisites

· You are logged on to your server as the root user.

· You have unpacked the required software (Unpacking the Software on UNIX).

Preparations

If the following conditions apply to your system, you must perform the specified steps before a new installation:

· The installation program enters the services sql6, sql30 and sapdbni72 in the file /etc/services, if they do not already exist there. If these services are managed centrally for your system on your network (NIS), you must enter them there as follow:
 sql6      7210/tcp
sql30     7200/tcp
sapdbni72 7269/tcp

· During the installation, the database software must be assigned to a special operating system user ( <sdb_user>), as the owner of the software and to the group ( <sdba_group>). We recommend that you define the group and the owner in advance. Only users with the correct authorizations can generate the database instances later (see also Authorization Concept for UNIX Operating Systems for software versions from 7.5.00).

· If the path <independent_program_path>/bin is not yet entered in the environment variable PATH, enter it now.

Procedure

...

1. If you want to update an existing database software installation,

¡ If necessary, stop each database instance assigned to the installation directory that you want to update with the command
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

¡ If necessary, stop the X Server program ( vserver process) with the command
x_server stop

For a new installation, start at step 2.

2. For the OLTP software, start the installation/update process with the following command:
./SDBINST [-b] -profile <inst_profile> [,<inst_profile2>...]| -package <package_name>[,<package_name2>...] -indep_data <independent_data_path> -indep_prog <independent_program_path> -depend <dependent_path> [-o <sdb_user> -g <sdba_group>]

For the SAP liveCache software, start the installation/update process (in SAP APO systems only) with the following command:

¡ For the installation profile APO liveCache
./SDBINST [-b] -profile "APO LiveCache" -indep_data <independent_data_path> -indep_prog <independent_program_path> -depend <dependent_path> [-o <sdb_user> -g <sdba_group>]

¡ For the software component APO LC APPS
./SDBINST [-b] -package "APO LC APPS" -depend <dependent_path>

You only need to specify the special operating system user <sdb_user> and the group <sdba_group> when you install the software for the first time, or if you are upgrading the software to Version 7.5.00.

For an explanation of the options, see Overview of the Options for the Program SDBINST.

You must place any names of installation profiles and software components that contain blanks in double quotation marks.

For certain installation profiles or software components you do not need to specify the options –indep_prog, -indep_data, and –depend . If you do specify them, the system ignores them. See the overview of the options for more information.

You see a message about the successful completion of the installation.

Result

The software packages are installed and registered. You can check the result of your installation in the log (Logging).

You can now create new database instances with the Database Manager

(See:

· Creating a Database Instance in Database Manager CLI or

· the Web DBM documentation.)


Installing/Updating Software on Linux (MaxDB: Installation Manual)

Installing/Updating Software on Linux

Use

You choose a software component, and install it.

Use the following procedure for updates only if no database instances refer to the installation path of the software that you want to update.

If database instances refer to the installation path of the software, you must upgrade the database instances together with the software (Upgrading Database Instances and Their Software). Otherwise, you risk making the database instances incompatible with the database software, and you will not be able to restart them.

If you have already installed the database software on your server with the Red Hat Package Manager (installation with rpm package), then you can now use this program only for subsequent installations and updates.
You cannot use the SDBINST program for installations and updates (installation with tgz package).

Two programs are available for installations on Linux:

· Installations/Updates with the Red Hat Package Manager

· Installations/Updates with SDBINST


Installations/Updates with SDBINST (MaxDB: Installation Manual)

Installations/Updates with SDBINST

Use

You install or update components of the database software on Linux. You specify all required information on the command line, together with the command for starting the installation program.

You must take into account the dependencies between the software components to guarantee that the software installation can function.

If you have already installed the database system on your server with the Red Hat Package Manager (installation with rpm package), then you can now use this program only for subsequent installations and updates.
You cannot use the SDBINST program for installations and updates (installation with tgz package).

Procedure

Proceed as described under Installing/Updating the Software on UNIX.


Installations/Updates with the Red Hat Package Manager (MaxDB: Installation Manual)

Installations/Updates with the Red Hat Package Manager

Use

You install or update components of the database software on Linux. You specify all required information on the command line, together with the command for starting the installation program.

You must take into account the dependencies between the software components to guarantee that the software installation can function.

Prerequisites

· You are in a root shell.

· You can access the rpm packages that you want to install from your computer.

Procedure

First Installation of the Database Software

...

1. Execute the installation command:
rpm -Uhv maxdb<package_name>.rpm

2. Add the entry /opt/sdb/programs/bin to the environment variable PATH for each user that wants to use the database system.

Updating the Database Software

Stop all existing database software on the server where you want to update the software version.

Stop the X Server program ( vserver process). Remember that this interrupts the communication between the clients and all local database instances.

...

1. Stop all database instances assigned to the installation directory that you want to update with the command
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

2. Execute the installation command:
rpm -Uhv maxdb<package_name>.rpm

Result

The software components in the installation directory have been installed and registered in their new version.

You can now create new database instances with the Database Manager

See:

· Creating a Database Instance in Database Manager CLI or

· the Web DBM documentation


Installing/Updating Software on Microsoft Windows (MaxDB: Installation Manual)

Installing/Updating Software on Microsoft Windows

Use

You install or update a chosen installation profile or database software component. Use the following procedure for updates only if no database instances refer to the installation path of the software that you want to update.

If database instances refer to the installation path of the software, you must upgrade the database instances together with the software (see Upgrading Database Instances and Their Software). Otherwise, you risk making the database instances incompatible with the database software, and you may not be able to restart them.

The system logs the installation process.

Procedure

...

1. First, unpack the database software to a local directory.

Unpacking the Software on Microsoft Windows

2. Now decide whether you want to perform an interactive installation (only possible for installation profiles) or a background installation.

¡ Interactive Installations/Updates on Microsoft Windows

¡ Background Installations/Updates on Microsoft Windows

For the advantages and disadvantages of these installation procedures, see
Installing and Updating the Database Software.


Unpacking the Software on Microsoft Windows (MaxDB: Installation Manual)

Unpacking the Software on Microsoft Windows

Conventions

Variables

Procedure

...

...

1. Select the database software package that is appropriate for your installation profile and operating system architecture.

If you want to install or update an individual software component only, then select an installation profile that contains this software component.

Installation from the SAP Service Marketplace (service.sap.com, for SAP customers only)

¡ For the OLTP database instance type, choose

For the 32 bit version
SAP Software ® Download ® SAP Support Packages & Patches ® Max DB ® Max DB OLTP ® Max DB <version> OLTP ® <os> ®
MAXDB<version>_<build>-<GUID>.SAR

For the 64 bit version
SAP Software ® Download ® SAP Support Packages & Patches ® Max DB ® Max DB OLTP 64-BIT ® Max DB <version> OLTP ® <os> ®
MAXDB <version>_<build>-<GUID>.SAR

¡ For liveCache database instance type (SAP APO system), choose
SAP Software ® Download ® SAP Support Packages & Patches ® SAP APO ® SAP APO <apo_version> ® Binary Patches ® APO LC<version>/LCAPPS<apo_version> ® <os> ®
LC<version>A<apo_version>_<apo_build>-<GUID>.SAR

Installation from http://www.sapdb.org

¡ OLTP instance type only
Go to Software, choose your operating system, and follow the instructions for downloading the software package
 maxdb-<inst_profile>-win-<32|64>bit-<arch>-<version>_<build>.zip

2. Copy the software package to a local directory of your choice.

3. Unpack

¡ a sar package with the program SAPCAR

¡ a zip package with the program Winzip

to a local directory of your choice.

Result

The system creates the following subdirectories in the local directory

· for OLTP software, the subdirectory
 maxdb-<inst_profile>-win-<32|64>bit-<arch>-<version>

· for SAP liveCache software, the subdirectory
apo<apo_version>_livecache-win-<32|64>bit-<arch>-<version>

and saves the software to them.


Interactive Installations/Updates on Microsoft Windows (MaxDB: Installation Manual)

Interactive Installations/Updates on Microsoft Windows

Use

You use the program SDBINST to install/update installation profiles of the database software on Microsoft Windows. The program queries all necessary information during the installation process.

You must stop the program X Server before you update the database software. Remember that this interrupts the communication between the clients and all local database instances.

Conventions

Variables

Prerequisites

· You have administrator rights for your server.

· You have downloaded and unpacked the installation package (Unpacking the Software on Microsoft Windows).

Procedure

...

1. If you want to update an existing installation of the database system,

¡ Stop each database instance of all installed versions of the database system with the command
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

¡ Stop the X Server program ( Xserverservice) with the command
x_server stop

For a new installation, start at step 2.

2. Open a command prompt and navigate to the local directory that contains the installation files:

¡ for OLTP software, the directory
 maxdb-<inst_profile>-win-<32|64>bit-<arch>-<version>

¡ for liveCache software, the directory
 apo<apo_version>_<livecache>-win-<32|64>bit-<arch>-<version>

3. Enter sdbinst to start the installation/update program.

4. The system proposes your chosen installation profile. If your installation profile (all, for example) contains other installation profiles, you can also select one of these profiles. Specify the appropriate ID. Confirm your selection.

5. The system now checks your server for installations of the database system that can be updated.

It lists any relevant installations.

¡ If you want to update an existing installation, specify its ID.
The system then updates the software in <independent_program_path>. Depending on your chosen profile, the software in <dependent_path> is also updated, if the installation package contains newer versions of the files.

¡ If you want to perform a new installation of the database software in parallel with the existing installation, specify none. You then have the option of specifying a new installation path. Define an installation path in parallel with the existing installation path.

If no installation of the database software exists yet on your server, the software components in the installation profile are now installed, one by one. Depending on your chosen installation profile, the system prompts you for the following paths:

¡ Path for saving data, configurations, and run directories of database instances and database applications (system default is C:\Program Files\sdb\data)

¡ Path for saving programs and libraries shared by database instances and database applications (system default is C:\Program Files\sdb\programs)

¡ Path for saving the server software that is dependent on the database version.
The specified path must be unique. Multiple directories containing different versions can exist simultaneously (system default is C:\Program Files\sdb\<version>)

Specify paths, or confirm the defaults.

You see a message about the successful completion of the installation.

6. If no database software has been installed on your server up to now, we recommend that you shut down your server, and restart it, so that the system can recognize the <independent_program_path>.

This is not necessary if you have updated the database software.

Result

The chosen installation profile of the database software has been installed and registered in its new version. You can check the result of your installation using the log (Logging).

You can create new database instances with the Database Manager

(See:

· Creating or Initializing a Database Instance in Database Manager GUI

· Creating a Database Instance in Database Manager CLI

· or the Web DBM documentation.)


Background Installations/Updates on Microsoft Windows (MaxDB: Installation Manual)

Background Installations/Updates on Microsoft Windows

Use

You use the program SDBINST to install/update installation profiles or individual components of the database software on Microsoft Windows. You specify all required information on the command line, together with the command for starting the installation program.

You must stop the program X Server before you update the database software. Remember that this interrupts the communication between the clients and all local database instances.

Conventions

Variables

Prerequisites

· You have administrator rights for your server.

· You have downloaded and unpacked the installation package (Unpacking the Software on Microsoft Windows).

Procedure

1. If you want to update an existing installation of the database system,

¡ Stop each individual database instance with the command
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

¡ Stop the X Server program ( Xserverservice) with the command
x_server stop

For a new installation, start at step 2.

2. Start the installation/update process for the OLTP software with the following command:
sdbinst [-b] -profile <inst_profile> [,<inst_profile2>...]| -package <package_name>[,<package_name2>...] -indep_data <independent_data_path> -indep_prog <independent_program_path> -depend <dependent_path>

Start the installation/update process for the liveCache software (in SAP APO systems only) with the following command:

¡ For the installation profile APO liveCache
sdbinst [-b] -profile "APO LiveCache" -indep_data <independent_data_path> -indep_prog <independent_program_path> -depend <dependent_path>

¡ For the software component APO LC APPS
sdbinst [-b] -package "APO LC APPS" -depend <dependent_path>

For an explanation of the options, see Overview of the Options for the Program SDBINST.

You must place any names of installation profiles and software components that contain blanks in double quotation marks.

For certain installation profiles or software components you do not need to specify the options –indep_prog, -indep_data, and –depend. If you do specify them, the system ignores them. See the overview of the options for more information.

You see a message about the successful completion of the installation.

Result

The software packages are installed and registered. You can check the result of your installation in the log (Logging).

You can create new database instances with the Database Manager

(See:

· Creating or Initializing a Database Instance in Database Manager GUI

· Creating a Database Instance in Database Manager CLI

· or the Web DBM documentation.)


Uninstalling the Database Software (MaxDB: Installation Manual)

Uninstalling the Database Software

Implementation Considerations

Depending on the procedure you used to install the database software, you can now use either the SDBUNINST program or the Red Hat Package Manager to uninstall the software.

In both cases, you can uninstall the entire database software, individual installation profiles, or individual software components.

If you used the Red Hat Package Manager (rpm package) to install the database software on your server, you can uninstall the software with this program only.

Conventions

Variables

Uninstallations with SDBUNINST on UNIX, Linux and Microsoft Windows

Uninstallations with the Red Hat Package Manager


Uninstallations with SDBUNINST on UNIX, Linux and Microsoft Wind (MaxDB: Installation Manual)

Uninstallations with SDBUNINST on UNIX, Linux and Microsoft Windows

Implementation Considerations

You use the uninstall program SDBUNINST to uninstall some or all of the software components, while taking into account the dependencies between them. This program is included in the database software from Version 7.3.00 Build 033.

You can use it to uninstall the software of the database system from Version 7.2.

Overview of Options for the Program SDBUNINST

For a short description of the standard uninstallation of the entire database software package with SDBUNINST, see the documentation Database Software Installation Guide.

Conventions

Variables, Supported Operating Systems and Platforms

Prerequisites

· One or more versions of the database software are installed on your server. These include at least one installation of Version 7.3.00, Build 033 or higher, which includes SDBUNINST.

· You have administrator rights for your server.

Procedure

...

1. On UNIX/Linux: Switch to the rootshell.

On Microsoft Windows: Open the command prompt on your server.

2. Stop the database instances on your server one by one with the command:
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

3. Delete the database instances on your server one by one with the command:
dbmcli –d <database_name> -u <dbm_user>,<password> db_drop

4. Call the uninstall program with your chosen option:

¡ If you want to uninstall all software components, specify the option –all; otherwise, specify your chosen component with the option –package.


Uninstallations with the Red Hat Package Manager (MaxDB: Installation Manual)

Uninstallations with the Red Hat Package Manager

Use

You install or update components of the database software on Linux. You specify all required information on the command line, together with the command for starting the installation program.

Prerequisites

You are in a root shell.

Procedure

1. Stop and delete each database instance one by one by executing the following commands:
dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

dbmcli –d <database_name> -u <dbm_user>,<password> db_drop

2. Execute the uninstall command:
rpm -e maxdb<package_name | *>.rpm

Result

The specified software component(s) are uninstalled.


Upgrading Database Instances and Their Software (MaxDB: Installation Manual)

Upgrading Database Instances and Their Software

Implementation Considerations

You upgrade database instances from one version to another, and update their database software at the same time. The following information refers to this procedure as an upgrade.

The strategy you choose depends on the database instance type and the source and target versions. For help on choosing a suitable upgrade strategy, see the tables under Selection of the Upgrade Strategy.

Each time you upgrade database instances, we recommend that you take precautions to avoid errors. Make sure that you have made complete backups of all data in the relevant database instances, and also have the database software of the source version. Only then can you return to the source version straight away, if necessary, and avoid long periods of system downtime.

Before you start, make sure that you have excluded the most common sources of errors in the upgrade (see Troubleshooting).

Whenever possible, use the SDBUPD program to perform the upgrade. This program gives you comprehensive support for an upgrade without problems. However, you can only use it if you fulfill certain prerequisites. Otherwise, you must use a different upgrade strategy.

Prerequisites for Using SDBUPD

SAP customers can use the program SDBUPD for upgrading database instances in SAP systems. The SDBUPD program makes all required checks during the upgrade process.

You can also use this program to upgrade database instances that are not part of an SAP system. To do this, however, the following prerequisites must be fulfilled:

· The program SDBINST was used to install the existing software.

· Each of the existing database instances refers to a separate software installation.

Conventions

See Variables, Supported Operating Systems and Platforms


Selection of the Upgrade Strategy (MaxDB: Installation Manual)

Selection of the Upgrade Strategy

Procedure

Select an upgrade strategy that is appropriate to the instance type of the database instance, and the source and target versions of the database software. Proceed as described for your chosen upgrade strategy.

If your database instance fulfills the necessary prerequisites, we recommend that you use the program SDBUPD, since an upgrade with this program removes the need for most of the user interaction, and is quicker and safer.

Upgrade Strategies for OLTP Database Instances

 | Target Version 7.5.x
Source Version from 7.3.00 Build 025 | In-Place Migration with SDBUPD or* In-Place Migration with SDBINST
Source Version 7.4.03 | Patch Installation with SDBUPD or* Patch Installation with SDBINST.
Source Version 7.2.00 | Patch Installation with SDBUPD or* Patch Installation with SDBINST

* Use the SDBUPD program if your database instance is part of an SAP system.
In special cases, you can use SDBUPD even if the database instance is not part of an SAP system. See Prerequisites for Using SDBUPD under Upgrading Database Instances and Their Software.

Upgrade Strategies for liveCache Database Instances

 | Target Version 7.5.00/410
Source Version 7.2.05/30A | Upgrade with APO Extract/Load
Source Version 7.4.02/30A | Upgrade with APO Extract/Load
Source Version 7.4.02/310 | Upgrade with APO Extract/Load
Source Version 7.4.03/400 | Upgrade with APO Extract/Load
Source Version 7.5.00/410 | Patch Installation with SDBUPD


Patch Installation with SDBUPD (MaxDB: Installation Manual)

Patch Installation with SDBUPD

Use

You use the program SDBUPD to upgrade the database instance. When you do this, only the database software is replaced.

You can use this procedure for software with Version 7.5x if only the build number of the version has changed between the source and target version, and also for upgrades from 7.4.03 to 7.5x (see also Selection of the Upgrade Strategy).

You use this upgrade strategy if your database instance is part of an SAP system.

You can use this procedure even if the database instance is not combined with an SAP system. To do this, however, the following prerequisites must be fulfilled:

· The program SDBINST was used to install the existing software (that is, with a tgz package or a zip file, and not an rpm package)

· Each database instance refers to a separate software installation.

The procedure depends on whether your source version is lower than 7.5.00 or 7.5.00 or higher, and on which operating system you work.

If you work on UNIX or Linux and your source version is lower than 7.5.00, then you must stop the X Server and all database instances before the upgrade. Remember that this interrupts the communication between the clients and all local database instances. If your source version is 7.5.00 or higher, then the X Server software supports an update of the database software while the X Server is running. You no longer need to stop the X Server. The database instance that you want to upgrade is stopped by SDBUPD during the upgrade.

If you work on Microsoft Windows, you must always stop the X Server and all database instances.

Prerequisites

Before you start upgrading a database instance, make sure that you have up-to-date log backups and/or data backups for recovering this database instance in the event of errors.

The database parameters of the database instance you want to upgrade must not have been changed since the last restart.

· The database instance that you want to upgrade is the only instance that refers to the installation path of the software you want to update.

· The database instances is in one of the three defined operational states, which means that there are no errors.

Procedure

...

1. If necessary, stop each database instance with the following command:

dbmcli –d <database_name> -u <dbm_user>, <password> db_offline

2. If necessary, stop the X Server.

x_server stop

3. Start the program SDBUPD for the database instance by entering the following commands:

UNIX, Linux:

Microsoft Windows:

./SDBUPD –d <database_name> -u <dbm_user>,<password>
[-o <sdb_user>
-g <sdba_group>]

sdbupd –d <database_name> -u <dbm_user>,<password>

You only need to specify the special operating system user <sdb_user> and the group <sdba_group> (according to the Authorization Concept for UNIX Operating Systems) if you are upgrading to software version 7.5.00.

SDBUPD performs the upgrade, and displays a success message if the upgrade is completed successfully. It then flags the installation as complete.

Result

The database instance and its software have been upgraded.

If you have upgraded a liveCache database instance, it is now in the operational state OFFLINE.

If you have upgraded an OLTP database instance, it is now in the operational state ONLINE.


Patch Installation with SDBINST and Follow-Up Actions (MaxDB: Installation Manual)

Patch Installation with SDBINST and Follow-Up Actions

Use

You use the program SDBINST to upgrade database instances. When you do this, only the database software is replaced. You must then perform the necessary follow-up actions in the command line with the Database Manager CLI.

This upgrade strategy is valid for database instances of the type OLTP only (see Selection of the Upgrade Strategy). It is valid for all supported operating system platforms.

The procedure depends on whether your source version is lower than 7.5.00 or 7.5.00 or higher, and on which operating system you work.

If you work on UNIX or Linux and your source version is lower than 7.5.00, then you must stop the X Server and all database instances before the upgrade. Remember that this interrupts the communication between the clients and all local database instances. If your source version is 7.5.00 or higher, then the X Server software supports an update of the database software while the X Server is running. In this case, you no longer need to stop the X Server and all database instances. However, you do need to stop the database instance that is assigned to the installation directory that is being updated.

If you work on Microsoft Windows, you must always stop the X Server and all database instances.

Prerequisites

Before you start the upgrade process, make sure that you have up-to-date log backups and/or data backups for recovering the database instances in the event of errors.

· All database instances that you want to upgrade refer to the same software installation.

Procedure

...

1. If necessary, stop each database instance with the following command:

dbmcli –d <database_name> -u <dbm_user>, <password> db_offline

2. If necessary, stop the X Server.

x_server stop

3. Start the SDBINST program with the options for installing the installation profile Server. Make sure that, for the <dependent_path>, you enter the correct software installation path of the database instance or instances that you want to upgrade.

UNIX/Linux:

Microsoft Windows:

./SDBINST [-b] -profile server -indep_data <independent_data_path> -indep_prog <independent_program_path> -depend <dependent_path>
[-o <sdb_user> -g <sdba_group>]

sdbinst [-b] -profile server -indep_data <independent_data_path> -indep_prog <independent_program_path> -depend <dependent_path>

When you upgrade the software to Version 7.5.00, specify the special operating system user <sdb_user> and the group <sdba_group> according to the authorization concept for UNIX operating systems.

4. Start the X Server with the following command:

x_server start

5. Log on again to each of the database instances in sequence as the DBM operator, and perform the specified actions:

Procedure

Command

...

1.

Log on to the Database Manager CLI with the data of the database instance that you want to upgrade.

dbmcli –d <database_name> -u <dbm_user>, <password>

2.

Update the software version of the database instance.

db_reg

3.

Update the parameters of the database instance.

param_checkall

4.

If you are upgrading to database version 7.5.00 on a UNIX operating system, then perform the following steps:

a. Log off from the Database Manager CLI.

b. Call the program chvolperm. This program changes the owner, group, and access rights to the volumes of the database instance according to the authorization concept for UNIX operating systems.

c. Log on to the Database Manager CLI again.

exit | release | quit | bye

<dependent_path>/bin/chvolperm –d <database_name>

dbmcli –d <database_name> -u <dbm_user>, <password>

5.

Transfer the database instance to the operational state WARM (up to Version 7.3) or ONLINE (from Version 7.4).

db_online | db_warm

6.

Load the system tables.

You see a message about the successful completion of the procedure.

load_systab

7.

Exit the Database Manager CLI.

exit | release | quit | bye

Result

The specified OLTP database instance and its software have been updated.

It is in the operational state ONLINE.


In-Place Migration with SDBUPD (MaxDB: Installation Manual)

In-Place Migration with SDBUPD

Use

You use the program SDBUPD to upgrade the database instance.

Use this procedure if the database instance is part of an SAP system.

This upgrade strategy is valid for the instance type OLTP only. It is valid for all supported operating system platforms.

Prerequisites

· The database instance you want to upgrade is part of an SAP system.

· The database instance is in the operational state ONLINE.

· The database instance is the only instance that refers to the installation path of the software version you want to update.

· The database parameters of the database instance you want to upgrade have not changed since the last restart.

· The source version of the database software is Version 7.3 Build 025 or higher, the target version is 7.5.00 or higher (Selection of the Upgrade Strategy).

Procedure

...

Description

Command

1.

Log on to the Database Manager CLI and stop the database instance that you want to upgrade.

If the existing X Server has a version lower than 7.5, then use this command to stop all database instances one by one.

dbmcli –d <database_name> -u <dbm_user>,<password> db_offline

2.

Transfer the database instance that you want to upgrade to the operational state COLD (up to Version 7.3) or ADMIN (from Version 7.4).

db_cold | db_admin

3.

If you have a newer data backup, make an incremental data backup and a log backup. Otherwise, make a complete data backup (see Backing Up the Database Instance).

backup_start <medium> [<type>] [AUTOIGNORE]

4.

Exit the Database Manager CLI.

exit | release | quit | bye

5.

If the source version is lower than 7.5.00, stop the X Server.

If your source version is 7.5.00 or higher, then the X Server software supports an update of the database software while the database is running. In this case, you no longer need to stop the X Server.

x_server stop

6.

Stop the X Server if it has a source version lower than 7.5.

x_server stop

7.

Start SDBUPD.

SDBUPD performs the upgrade, and displays a success message if completed successfully. It then flags the installation as complete.

The execution of this command can take a long time. Under no circumstances must you terminate it. If you do, you risk losing all your data. Your only option in this event is to use data backups to go back to the state of the database instance that is stored in these backups.

UNIX/Linux:

./SDBUPD –d <database_name> -u <dbm_user>,<password>
[-o <sapdb_user>
-g <sapdb_admin>]

You only need to specify the special operating system user <sdb_user> and the group <sdba_group> (according to the Authorization Concept for UNIX Operating Systems) if you are upgrading to software version 7.5x.

Microsoft Windows:

sdbupd –d <database_name> -u <dbm_user>,<password>

Result

The specified OLTP database instance and its software have been upgraded.

The database instance is in the operational state ONLINE.


In-Place Migration with SDBINST and Follow-Up Actions (MaxDB: Installation Manual)

In-Place Migration with SDBINST and Follow-Up Actions

Use

You use the program SDBINST to upgrade database instances from Version 7.3 to 7.5. First you install the new version of the database software. Then you migrate the database instance(s).

The source version of the database software is Version 7.3.00 Build 025 or higher, the target version is 7.5.00 or higher (see also Selection of the Upgrade Strategy).

Use this procedure for database systems that are not part of an SAP system, particularly if multiple database instances refer to the same installation path.

This upgrade strategy is valid for database instances of the type OLTP only. It is valid for all supported operating system platforms.

Prerequisites

· The database instance you want to upgrade is not part of an SAP system.

· You have a backup medium for a complete data backup.

Procedure

To guarantee the security of your data if any errors occur in the migration, we recommend that you make a complete data backup of the instance in step 6, in the operational state COLD. This causes downtime because the database instance has to be stopped. However, in the event of an error, the resulting data backup can be used to recover the database instance in both Version 7.3 and the target version.

Alternatively, you can make a complete data backup in the operational state WARM before you start the migration. However, in the event of an error, you can use this backup to recover the source version of the database instance only. Therefore, it is not equivalent to a data backup in the operational state COLD during the migration process.

...

1. Install the source version of the software with SDBINST (zip file or tgz package) in the installation path <dependent_path><target_version> in parallel with the installation path of Version 7.3.

or

Install the software of the target version with the Red Hat Package Manager (rpm package).

If you have installed Version 7.3 of the database software on your server with the Red Hat Package Manager, you can now perform subsequent installations with this program only. You can not use the SDBINST program for subsequent installations.

2. Perform the following migration steps for each of your database instances with the source version.

Procedure

Command

...

1.

Call the Database Manager CLI as the DBM operator and connect to the database instance that you want to migrate.

dbmcli –d <database_name> -u <dbm_user>,<password>

2.

Stop the database instance correctly

Use the command db_offline and not db_stop. This is the only way of making sure you can restart the database instance if an error occurs.

db_offline

3.

Transfer the database instance to the operational state COLD.

db_cold

4.

Execute the command that prepares the migration.

util_execute migrate

5.

Open a utility session.

util_connect

6.

Make a complete data backup in the operational state COLD.

backup_start <medium>

7.

Exit the utility session.

util_release

8.

Transfer the database instance to the operational state OFFLINE.

db_offline

9.

UNIX:

Assign the database instance to the new software version <target_version>.

Microsoft Windows:

Delete the registration of the database instance.

UNIX:

db_reg –R <dependent_path><target_version>

Microsoft Windows:

db_drop WITHOUTFILES

10.

Exit the Database Manager CLI.

For Microsoft Windows only:

Register the installation path of the new database software with the Database Manager and create a database instance of this new software version.

exit | release | quit | bye

dbmcli –R <dependent_path><target_version> db_create –d <database_name> -u <dbm_user>,<password>

11.

Log on to the Database Manager CLI again.

dbmcli –d <database_name> -u <dbm_user>,<password>

12.

Start the migration of the database parameters.

param_checkall

13.

If you are upgrading to database version 7.5.00 or higher on a UNIX operating system, then perform the following steps. Otherwise, proceed as described under point 14:

a. Log off from the Database Manager CLI.

b. Call the program chvolperm. This program changes the owner, group, and access rights to the volumes of the database instance according to the authorization concept for UNIX operating systems.

c. Log on to the Database Manager CLI again.

exit | release | quit | bye

<dependent_path>/bin/chvolperm –d <database_name>

dbmcli –d <database_name> -u <dbm_user>, <password>

14.

Transfer the database instance to the operational state ADMIN.

db_admin

15.

Execute the migration command.

The execution of this command may take some time, depending on the size of the database instance. Do not cancel it under any circumstances.

util_execute migrate database

16.

Transfer the database instance to the operational state OFFLINE.

db_offline

17.

Restart the database instance. The database catalog is migrated from 7.3 to the target version.

db_online

18.

Reload the system tables.

You see a message about the successful completion of the procedure.

load_systab

Result

You have migrated your database instance from software version 7.3 to the required target version.

It is in the operational state ONLINE.


Upgrade with APO Extract/Load (MaxDB: Installation Manual)

Upgrade with APO Extract/Load

Use

You use the SDBUPD program for an upgrade with APO Extract/Load. You must first back up the transaction data of the application system from the liveCache database instance to the APO database, and then substitute the software (Selection of the Upgrade Strategy).

This procedure is currently valid only for the instance type liveCache in the SAP APO system. It is valid for all operating system platforms supported by the database system.

The procedure depends on whether your source version is lower than 7.5.00 or 7.5.00 or higher, and on which operating system you work.

If you work on UNIX or Linux and your source version is lower than 7.5.00, then you must stop the X Server and all database instances before the upgrade. Remember that this interrupts the communication between the clients and all local database instances. If your source version is 7.5.00 or higher, then the X Server software supports an update of the database software while the X Server is running. In this case, you no longer need to stop the X Server and the database instances.

If you work on Microsoft Windows, you must always stop the X Server and all database instances.

Prerequisites

· You have backed up the liveCache transactions to the APO database.

SAP customers can find information on this in the Service Marketplace under http://service.sap.com/instguides ® Installation ® Installation & Upgrade Guides ® mySAP SCM ® Using SAP SCM 4.1Server... ® Upgrade Information ® Upgrade for SAP SCM 4.1: SAP liveCache 7.5 ® Upgrade Preparations.

· The database parameters of the database instance you want to upgrade have not changed since the last restart.

· The database instance can be in any operational state.

Procedure

...

1. If necessary, stop each database instance with the following command:

dbmcli –d <database_name> -u <dbm_user>, <password> db_offline

2. If necessary, stop the X Server.

x_server stop

3. Start the SDBUPD program with the following command:

UNIX, Linux:

Microsoft Windows:

./SDBUPD –d <database_name> -u <dbm_user>,<password>
[-o <sapdb_user>
-g <sapdb_admin>]

sdbupd –d <database_name> -u <dbm_user>,<password>

You only need to specify the special operating system user <sdb_user> and the group <sdba_group> (according to the Authorization Concept for UNIX Operating Systems) if you are upgrading to software version 7.5.00.

4. SDBUPD performs the upgrade, and displays a success message if completed successfully. You are prompted to start liveCache.

5. Start liveCache ( [image] Starting liveCache).

6. Recover the data from the APO system to liveCache (see the above link to Upgrade for SAP SCM 4.1: SAP liveCache 7.5.).

Result

The specified liveCache database instance in the SAP APO system and its software have been upgraded.

liveCache is in the operational state ONLINE.


Authorization Concept for UNIX Operating Systems (MaxDB: Installation Manual)

Authorization Concept for UNIX Operating Systems

Use

For the execution of MaxDB programs and access to database files, the database software package contains a preconfigured authorization concept as of Version 7.5.00. This concept applies to both installations within SAP systems, and to open source installations.

This concept includes the special operating system user <sdb_user> and the operating system user group <sdba_group>.

If you manage operating system users and user groups locally on your host, we recommend that you register the names of the special operating system user and the user groups in the operating system before you start the installation. However, you can also do this during the installation process.

If you manage operating system users and user groups for your system centrally in the network, you must create them here before you start the installation.

For more information on creating operating system users and user groups, see your operating system documentation.

Special Operating System User

The special operating system user is the owner of all the database software and database processes, which also makes this user the owner of, for example, the volumes, database trace, and the database logs. This user is created once during the initial installation of a database software package with version 7.5.00 or higher. The system default for the user name is sdb.

The special operating system user is a member of the administrator group, and does not log on to the operating system interactively. The administrator group is the primary group of the user sdb.

This special operating system user cannot have the authorization to log on to the operating system interactively. For this reason, take this authorization away from this user. For information on how to do this, see your operating system documentation (lock account).

Administrator Group

The programs and libraries used by both the database instances and database applications are assigned to the administrator group once when the software is installed. The system default for the name of the administrator group is sdba.

Operating system users who belong to this group have access to the database logs. They can create new database instances and start, stop, and update the X Server.

The users of the administrator group have access to the volumes of the database instances through the file system.


Troubleshooting (MaxDB: Installation Manual)

Troubleshooting

When you install or update your database software, or when you upgrade database instances and their software, you can sometimes experience errors that cause the program to terminate. In the event of these errors, you can use the available programs, your data backups, and the source version software to return temporarily to the original version. This gives you time for troubleshooting, and keeps downtime as short as possible.

Underno circumstances delete installed files from the file system manually. Even if installations crash, use only the program SDBUNINST for uninstalling software. Otherwise, unexpected problems may occur in your next installation or upgrade.

Errors in the Execution of the Program SDBINST

Errors in the Execution of the Program SDBUPD


Errors in the Execution of the Program SDBINST (MaxDB: Installation Manual)

Errors in the Execution of the Program SDBINST

If errors occur when you execute the program SDBINST, the program terminates abnormally with a message about the cause of the error.

Frequent Causes of Errors

...

1. Files of the software you want to update are still being used.

¡ Administration sessions are still running, which means that the Database Manager CLI is still active.

¡ Applications are still running that use the runtime or scripting interfaces of the database system

2. There is not enough disk space for the new software.

3. You have attempted to update a 64 bit database kernel with software for a 32 bit kernel. This is not possible.

4. You are attempting to update the software with SDBINST. However, you have ignored the dependencies between the software components; these dependencies concern the versions of the components or the order in which they need to be installed.

User Action

Remove the cause of the error and execute the program again.


Errors in the Execution of the Program SDBUPD (MaxDB: Installation Manual)

Errors in the Execution of the Program SDBUPD

If errors occur when you execute the program SDBUPD, the program terminates with a message about the cause of the error.

Frequent Causes of Errors

...

1. An unexpected error occurred when you executed SDBUPD.

2. You are attempting to use SDBUPD to switch to a software version that is lower than your current version (in the following called a downgrade). Examples of this situation:

¡ You have selected the wrong software version by mistake.

¡ The upgrade of the database instance terminated with an error. You then tried to use SDBUPD to return to the original software version.

¡ The database instance upgrade was successful, however, you want to return to a lower software version for other reasons.

You cannot use SDBUPD to downgrade software. If you want to use SDBUPD, the new software must have at least a higher build number (Version Notation).

User Action

Proceed as follows in each case.

Case 1:

No database instances exist that refer to a higher software version.

Case 2:

Database instances exist that refer to a higher software version. You want to downgrade the software that is used exclusively by the database instance (Dependent Software).

Case 3:

Database instances exist that refer to a higher software version. You want to downgrade the software that is not used by the database instance, or whose version is not relevant for the database instance (Independent Software).


Case 1: No Database Instances Exist Yet (MaxDB: Installation Manual)

Case 1: No Database Instances Exist Yet

Use

No database instances exist that refer to a higher software version.

Procedure

Either uninstall the entire database software with SDBUNINST

or

uninstall only those software components that you want to install in a lower version. Take into account the dependencies between the components.

Uninstalling the Database Software


Case 2: Downgrade for Dependent Software (MaxDB: Installation Manual)

Case 2: Downgrade for Dependent Software

Use

Database instances exist that refer to a higher software version. You want to downgrade the software that is used exclusively by the database instance (Dependent Software).

Procedure

Delete the existing database instances before a downgrade.

· If you want to perform the downgrade at build level only, there will be no incompatibilities between the database instances of the higher version and the software of the lower version you want to install. Proceed as follows for each database instance:

Procedure

Command

...

1.

Call the Database Manager CLI as the DBM operator and connect to the database instance.

dbmcli –d <database_name> -u <dbm_user>,<password>

2.

Delete the registration of the database instance.

db_drop WITHOUTFILES

3.

Exit the Database Manager CLI.

exit | release | quit | bye

4.

Uninstall at least the database kernel and the chosen software component(s) with the higher version.

sdbuninst –package "Database Kernel" [, <package_name2>…]

5.

Install your chosen installation profile with the lower version (for OLTP database instances at least Server, for liveCache database instances at least APO liveCache).

If you are installing the software in SAP systems, read the important note below.

sdbinst –profile Server | "APO LiveCache" [, <inst_profile2>…]

6.

Register the database instance again. Enter the name and DBM user of the old database instance, and the path of the newly installed lower software version.

Unix/Linux:

<dependent_path>\bin
\dbmcli –s –R <dependent_path> db_create <database_name> <dbm_user>,<password>

Microsoft Windows:

"<dependent_path>\pgm
\dbmcli" –s –R "<dependent_path>" db_create <database_name> <dbm_user>,<password>

· If the downgrade is combined with a change of version (minor or major release, see also: Version Notation) of the database software, proceed as follows:

 | Procedure | Command
 | Call the Database Manager CLI as the DBM operator and connect to the database instance. | dbmcli –d <database_name> -u <dbm_user>,<password>
1. | Delete the database instance | db_drop
2. | Exit the Database Manager CLI. | exit | release | quit | bye
3. | Uninstall at least the database kernel and the chosen software component(s) with the higher version. | sdbuninst –package "Database Kernel" [, <package_name2>…]
4. | Install your chosen installation profile with the lower version (for OLTP database instances at least Server, for liveCache database instances at least APO liveCache). If you are installing the software in SAP systems, read the important note below. | sdbinst –profile Server | "APO LiveCache" [, <inst_profile2>…]
5. | Start the Database Manager GUI. Use the Installation Wizard to create a new database instance by using the parameter file from a backup. | Choose Instance ® Install. Follow the instructions for creating or initializing a database instance. For the new database instance, specify the database administrator that is saved in the backup parameter file.
6. | Exit the Database Manager GUI. | Choose File ® Exit.

If you want to use this procedure in SAP systems, do not accept the system defaults. Specify the following settings instead:

<group> | For target version 7.5.00 or higher: sdba For all previous database versions: sapsys
<owner> | For target version 7.5.00 or higher always: sdb For all previous database versions · For OLTP database instances: sqdsid · For liveCache database instances: sidad m
<independent_data_path> | UNIX/Linux: /sapdb/data Microsoft Windows: <drive>:\sapdb\data
<independent_program_path> | UNIX/Linux: /sapdb/programs Microsoft Windows: <drive>:\sapdb\programs
<dependent_path> | UNIX/Linux: /sapdb/<SID>/db Microsoft Windows: <drive>:\sapdb\<SID>\db


Case 3: Downgrade for Independent Software (MaxDB: Installation Manual)

Case 3: Downgrade for Independent Software

Use

Database instances exist that refer to a higher software version. You want to downgrade the software that is not used by the database instance, or whose version is not relevant for the database instance (Independent Software).

Procedure

 | Action | Command
... 1. | Uninstall at least the database kernel and the chosen software component(s) with the higher version. | sdbuninst –package "Database Kernel" [, <package_name2>…]
2. | Install your chosen installation profile with the lower version (for OLTP database instances at least Server, for liveCache database instances at least APO liveCache). If you are installing the software in SAP systems, read the important note below. | sdbinst –profile Server | "APO LiveCache" [, <inst_profile2>…]

If you want to use this procedure in SAP systems, do not accept the system defaults. Specify the following settings instead:

<group> | For target version 7.5.00 or higher: sdba For all previous database versions: sapsys
<owner> | For target version 7.5.00 or higher always: sdb For all previous database versions · For OLTP database instances: sqdsid · For liveCache database instances: sidadm
<independent_data_path> | UNIX/Linux: /sapdb/data Microsoft Windows: <drive>:\sapdb\data
<independent_program_path> | UNIX/Linux: /sapdb/programs Microsoft Windows: <drive>:\sapdb\programs
<dependent_path> | UNIX/Linux: /sapdb/<SIS>/db Microsoft Windows: <drive>:\sapdb\<SID>\db


Detailed Information (MaxDB: Installation Manual)

Detailed Information

Installation Profiles

Software Components

Logging

Overview of Options for the Program SDBINST

Overview of Options for the Program SDBUNINST

Overview of Options for the Program SDBUPD


Installation Profiles (MaxDB: Installation Manual)

Installation Profiles

Installation profiles are different combinations of individual software components, which meet different requirements. An installation profile provides you with a fully functioning software installation, regardless of which profile you choose.

If you install individual software components (parts of installation profiles), you must take into account the dependencies between the components to guarantee that the software installation can function.

Choose from the following installation profiles:

Name | Included Software Components | Installation/Update of
all | All software components | Complete software package
Server | Base, multiple PCR <version>, server utilities, ODBC, DB Analyzer, database kernel, JDBC, Loader | Server software and client software of the OLTP database system
Web Tools | Base, ODBC, Web Tools, XML Indexing Engine | Web Tools
DB Analyzer | Base, ODBC (for MS Windows only), DB Analyzer | Database Analyzer
Runtime for SAP AS | Base, multiple PCR <version>, JDBC, Loader | Client software for the SAP application server
APO LiveCache | For liveCache in the SAP APO system only Base, multiple PCR <version>, Server Utilities, ODBC (MS Windows only), DB Analyzer, Database Kernel, APO LC APPS or APO COM (up to APO Version 4.0) | Server software and client software of the liveCache database system
C Precompiler | Base, multiple PCR <version>, CPC Base, CPC SDK <version> | Software required for developing precompiler applications
Script Interface | Base, Perl Interface, Python Interface | Runtimes for applications that use programming interfaces
XML Indexing Engine | Base, ODBC, XML Indexing Engine | XML Indexing Engine
Loader | Base, Loader | Loader tool
JDBC | Base, JDBC | MaxDB JDBC Driver

You must place any names of software components that contain blanks in double quotation marks.


Software Components (MaxDB: Installation Manual)

Software Components

Use

You install installation packages that contain only individual components of the database software. You can do this to install missing components without updating components that you do not need.

The installation of software components is more complex than the installation of installation profiles, and demands that the user understands and takes into account the dependencies determined by the content or versions of the software.

Since this installation is not interactive and can run in the background only, you must in advance determine any other components you need to install first, and in which order. The installation program terminates the installation as soon as it recognizes that a dependency has been ignored. For this reason, use this installation type in special cases only.

The database software is split into the following components:

Name | Description
Base | Programs for registering the installation, uninstallation tool, InstallRegistryViewer, and programs that the SAP application server needs to access the database system (including XUSER and SQLCLI)
PCR<version> | Precompiler Runtime Package Contains runtime libraries for applications created with the C/C++ Precompiler for Embedded SQL Can exist in multiple versions in the local installation directory
Server Utilities | Tools for the administration of the database kernel (including Database Manager CLI, XPU and XCONS)
Database Kernel | Database kernel with runtime environment
CPC Base | C++ Precompiler base (call programs for the precompiler)
CPC SDK <version> | C++ Precompiler
ODBC | ODBC driver
DB Analyzer | Database Analyzer: Tool for analyzing database performance
Web Tools | Web Server and Web-based database tools (WebDBM, WebSQL, WebDAV)
Python Interface | Python interface
Perl Interface | Perl interface
XML Indexing Engine | XML Indexing Engine; can be installed on a computer other than the database host to improve performance
Loader | Loader: tool for loading and unloading data
JDBC | MaxDB JDBC driver for accessing the MaxDB database system
APO LC APPS (from APO Version 4.0) or APO COM | For SAP liveCache in the SAP APO system only: Libraries with APO liveCache routines

You must place any names of software components that contain blanks in double quotation marks.

Dependencies

The following dependencies exist between software components:

Base ® PCR <version>
Base ® Server Utilities ®Database Kernel ® APO LC APPS | APO COM
Base [® ODBC]* ® DB Analyzer
Base ® ODBC ® Web Tools
Base ® CPC Base
Base ® CPC Base ®CPC SDK <version>
Base ® Perl
Base ® Python
Base ®ODBC ® XML Indexing Engine
Base ® Loader
Base ® JDBC

* Required for DB Analyzer on Microsoft Windows only

Explanation of Dependencies

· The Base software component is independent of all other packages.

· PCR <version> cannot be installed until Base has been installed.

· Server Utilities cannot be installed until Base has been installed.

¡ Database Kernel cannot be installed until Server Utilities has been installed.

¡ APO LC APPS or APO COM cannot be installed until Database Kernel has been installed

· DB Analyzer cannot be installed until you have installed Base (on UNIX) or Base and ODBC (on Microsoft Windows).

· ODBC cannot be installed until Base has been installed.

¡ Web Tools cannot be installed until ODBC has been installed.

· CPC Bases cannot be installed until Base has been installed.

¡ CPC SDK <version> cannot be installed until CPC Base has been installed.

· Perl cannot be installed until Base has been installed.

· Python cannot be installed until Base has been installed.

· ODBC cannot be installed until Base has been installed.

¡ XML Indexing Engine cannot be installed until ODBC has been installed.

· Loader cannot be installed until Base has been installed.

· JDBC cannot be installed until Base has been installed.


Logging (MaxDB: Installation Manual)

Logging

Use

All installation/update steps and the steps involved in upgrading database instances and their software are saved in log files. The name of the log file contains information on the product name MaxDB or SAP liveCache.

Conventions

Variables

Location of Log Files for Installations/Updates

· UNIX/Linux ( tgz package):
<independent_data_path>/wrk/MAXDB<profile>_install-<date>-<time>.log

or

<independent_data_path>/wrk/SAPliveCache<profile>_install-<date>-<time>.log

· Microsoft Windows:
<independent_data_path>\wrk\MAXDB<profile>_install-<date>-<time>.log

or

<independent_data_path>\wrk\SAPliveCache<profile>_install-<date>-<time>.log

If the <independent_data_path> directory is not yet known when the installation process crashes, the log will be created in the current directory.

If you have installed/updated individual software components, the steps are logged in the file
 MAXDBSoftware_install-<date>-<time>.log

or

SAPliveCacheSoftware_install-<date>-<time>.log

Location of the Log File for Updates of Database Instances and Their Software (Upgrades)

· UNIX/Linux ( tgz package):
<independent_data_path>/wrk/MAXDBUpgrade_install-<date>-<time>.log or

<independent_data_path>/wrk/SAPliveCacheUpgrade_install-<date>-<time>.log

· Microsoft Windows:
<independent_data_path>\wrk\MAXDBUpgrade_install-<date>-<time>.log

or

<independent_data_path>\wrk\SAPliveCacheUpgrade_install-<date>-<time>.log


Overview of Options for the Program SDBINST (MaxDB: Installation Manual)

Overview of Options for the Program SDBINST

You can specify the following options when you use the program SDBINST to install or update database software:

Option

Description

-b | -batch

Use installation program in the background

If you specify this option, the installation program terminates with an error if any information is missing.

If you do not specify this option, the program stops if any information is missing, and prompts you to act.

-profile <inst_profile>

Installation profile

You must place any names that contain blanks in double quotation marks.

-package <package_name>

Logical name of the software component (not file name)

You must place any names that contain blanks in double quotation marks.

-indep_data <independent_data_path>

Can be specified for an initial SAP DB installation only. Otherwise, the system ignores it. You can change this path only after completely uninstalling the database software.

-indep_prog <independent_program_path>

Can be specified for an initial SAP DB installation only. Otherwise, the system ignores it. You can change this path only after completely uninstalling the database software.

-depend <dependent_path>

Needs to be specified for a new installation only, and only for the installation profiles all, Server and APO LiveCache and the software components Database Kernel and APO LC APPS (from APO Version 4) or APO COM. Otherwise, the system ignores it.

-o | -owner <sdb_user>

UNIX only: Software owner

-g | -group <sdb_group>

UNIX only: Group of the software (administrator group)

-h | -help

List of options and descriptions

-v | -version

Version number of the SDBINST installation program

-l | -list

Display all possible installation profiles and software components

See also: Variables


Overview of Options for the Program SDBUNINST (MaxDB: Installation Manual)

Overview of Options for the Program SDBUNINST

You can specify the following options when you use the program SDBUNINST to uninstall database software:

Option | Description
-all | Uninstalls all software registered for MaxDB
-package <package_name> | Logical name of the software component (not file name) that you want to uninstall
-package_dir <package_directory> | Directory of the specified software component Specify this information only if there are multiple software packages with the same name
-autoresolve | As well as the specified software component, the system also uninstalls all dependent components. -package ODBC –autoresolve On Microsoft Windows, the component ODBC and its dependent component Web Tools are uninstalled.
-h | -help | List of options and descriptions
-v | -version | Version number of the uninstallation program SDBUNINST
-l | -list | Display all possible software components


Overview of Options for the Program SDBUPD (MaxDB: Installation Manual)

Overview of Options for the Program SDBUPD

You can specify the following options when you use the program SDBUPD to upgrade database instances from Version 7.3 to Version 7.4:

Option

Description

-b | -batch

Use SDBUPD in the background

If you specify this option, the installation program terminates with an error if any information is missing.

If you do not specify this option, the program stops if any information is missing, and prompts you to act.

-d <database_name>

Name of the database instance

-u <dbm_user>,<password>

Name and password of the DBM operator

-h | -help

List of options and descriptions

-v | -version

Version number of SDBUPD

-l | -list

Display all possible installation profiles and software components

-o <sdb_user>

Owner of the software (UNIX only) when you upgrade the software to Version 7.5.00, according to the authorization concept

-g <sdba_group>

Administrator group (UNIX only) when you upgrade the software to Version 7.5.00


Basic Information

Title of the Documentation | Contents
Database Administration | Introduction to the MaxDB database system: architecture, directory structure, database parameters, database tools, user and security concepts, overview of the documentation, terminology, and so on.
Reference Manual | SQL statements and their syntax, system tables, special features of the SQL mode ORACLE
Messages | List of all messages of the database system: Return codes and error messages from the database kernel, the database tools, and the Precompiler. Includes short explanations of possible causes of the errors, and tips on how to solve them.
Background Knowledge | Background knowledge about the MaxDB database system, such as the log concept, B* trees, standby databases
SAP Security Guide: MySQL MaxDB | Recommended security measures for the database system


Database Administration

This documentation gives you an overview of the database system MySQL MaxDB Version 7.5 (previously SAP DB), its tools, and programming interfaces.

For database administration and your general work with the database system, you can find information on the following topics:

· Configuring and operating database instances, including database parameters and database files

· Terms, such as cache, volume, database session, transaction, and lock

· User concept and security concepts, including backups and recoveries

· Version notation, technical specifications, and supported operating systems and platforms

The overview of the documentation provides you with a list of all available documentation about the database system. The Background Knowledge documentation goes into greater detail about important concepts in the database system.

Open source users can download all the MaxDB software free of charge from http://www.mysql.com/downloads.

SAP customers receive the MaxDB software with the SAP installation CD, or on the Service Marketplace at http://service.sap.com.

You can also obtain support for your database system.


SAP DB and MySQL MaxDB (MaxDB: Database Administration)

SAP DB and MySQL MaxDB

In May 2003, SAP concluded a cooperation agreement with MySQL AB. As part of this agreement, the SAP DB database will be delivered under the name MySQL MaxDB from database version 7.5.

MaxDB 7.5 is the result of the continuing development of the SAP DB source code. As specified in the releases for SAP applications, you can use the MaxDB 7.5 software as a direct update for the previous SAP DB versions from 7.2.04.

This cooperation agreement does not change anything for SAP customers. Open source users can find information about the new licensing conditions at http://www.sapdb.org/7.4/sapdb_mysql.htm#license.


Database System (MaxDB: Database Administration)

Database System

The database system consists of all the software that is used to create and manage MaxDB and liveCache database instances, and which enables users to process the data of these database instances. The central component of the database system is the kernel.

To optimize performance, adjust the directory structure of the database system to your hardware configuration.

See also:

· Database Tools

· Programming Interfaces

· X Server


Kernel (MaxDB: Database Administration)

Kernel

The kernel is the central component of the database system. The kernel program needs to be running for the database to operate. It manages access to data in permanent storage, processes SQL queries, and, for liveCache database instances, it processes the OMS procedures.

The database system is shipped with several different variants of the kernel.

When the database instance is started, the kernel generates threads for all tasks that have to be performed in parallel ("multithreaded program"). These tasks include connecting to the database, processing SQL queries, I/O handling, and monitoring the database instance. When these tasks are executed, the state of the kernel changes, which is reflected in the kernel data and in the data volumes and log volumes.


Kernel Variant (MaxDB: Database Administration)

Kernel Variant

Kernel variants are variants of the kernel of the database system with differing properties. They differ according to the information that is logged and the runtime checks that are made while the database is running normally.

When you perform the following actions, you can specify which kernel variant you want to use explicitly: start the database instance, restart the database instance, transfer the database to the operational state ADMIN, transfer the database to the operational state ONLINE.

You can choose from the following kernel variants:

Kernel Variant | Properties
fast | System default. Fastest kernel variant, with minimum logging and runtime checks.
quick | Variant of the kernel with additional logs and runtime checks
slow | Variant of the kernel with extensive logs and runtime checks

Do not use the kernel variants quick and slow during production operation of the database. The additional logs and runtime checks make these variants much slower than the fast variant. They should be used by support teams only.

See also:

Database Manager CLI, Displaying the Database Kernel Variant


Thread (MaxDB: Database Administration)

Thread

A database instance includes multiple operating system threads. Among other things, they are responsible for performing tasks.

We differentiate between user kernel threads (UKT) and special threads. The number of user kernel threads and special threads depends on the hardware configuration, the number of volumes used, and the database parameters that were set.


User Kernel Thread (MaxDB: Database Administration)

User Kernel Thread

A user kernel thread (UKT) bundles a range of tasks that fulfill various functions. The following task types can run in a user kernel thread:

· Pager

· Log writer

· Server task

· Timer task

· Trace writer task

· User task

· Utility task

Several user kernel threads are generated when a database instance is started. The number of user kernel threads and the number and type of tasks that can run in a user kernel thread are specified in database parameters.


Pager (MaxDB: Database Administration)

Pager

Pagers (data writers) are tasks in the user kernel thread. They are responsible for writing data from the data cache to the data volumes. Pagers become active at every savepoint.

Writing a savepoint can take a long time for a large data cache. In this case, the pagers also become active between the end of a savepoint and the start of the next one, to write the changed data asynchronously.

When the database system is restarted, the pagers import the converter pages from the data volumes into the converter (a component of the I/O buffer cache).

The system calculates the number of pagers required. It depends primarily on the data cache size and the number of data volumes.


Log Writer (MaxDB: Database Administration)

Log Writer

The log writer is a task in the user kernel thread. It writes the log entries from the log queue to the log area, for example, after a COMMIT. When this is done, the same log page is always written to the same physical space in the log area.

For more detailed information, see Background Knowledge under Logging.


Server Task (MaxDB: Database Administration)

Server Task

Server tasks are tasks in the user kernel thread. They are used primarily for running parallel database functions. They are required, for example, for backups, recoveries, and creating indexes.

The number of available server tasks is defined by the special database parameter MAXSERVERTASKS.


Timer Task (MaxDB: Database Administration)

Timer Task

Timer tasks are tasks in the user kernel thread. They handle all types of timeout situations.


Trace Writer Task (MaxDB: Database Administration)

Trace Writer Task

The trace writer task is a task in the user kernel thread. The trace writer task writes the log file when a database trace is used for diagnosis purposes.


User Task (MaxDB: Database Administration)

User Task

The user task is a task in the user kernel thread. It is responsible for processing SQL statements.

When a database session is opened, precisely one user task is given a fixed assignment to each client (in other words, to each user and each application program that is accessing the database instance).

The number of user tasks available is defined by the general database parameter MAXUSERTASKS. The general database parameter MAXCPU specifies the number of user kernel threads across which the user tasks are distributed. The user tasks generate the main load for the processor; other tasks, including the special threads, consume only a very small amount of processor time. You can use the parameter MAXCPU to restrict the number of processors that are used in parallel by the database instance.


Utility Task (MaxDB: Database Administration)

Utility Task

The utility task is a task in the user kernel thread. It is reserved solely for managing the database instance.

There is only one utility task for each database instance, which is why it is not possible to perform management actions in parallel. An exception to this rule is the automatic log backup. This can be performed in parallel with other management actions.


Special Threads (MaxDB: Database Administration)

Special Threads

Special threads are operating system threads. Among other things, they are responsible for accessing external resources. A database instance has the following special threads:

Coordinator

The coordinator monitors all threads of the database instance. It is the first thread to be created when the database instance is started. It coordinates the start processes of the other threads. If operating errors occur, the coordinator can stop other threads.

Requester

The requester accepts user logons to the database instance and assigns them to a user task in a user kernel thread.

Console thread

The console thread processes requests from the XCONS tool (database console).

Clock thread

The clock thread determines internal times, for example, the time it takes to execute an SQL statement. It is only used on Microsoft Windows.

Dev threads

Dev threads are responsible for processing write and read requests to and from the volumes.

The number of dev threads is primarily dependent on the number of volumes in the database instance. Under normal circumstances, two dev threads are activated for every data volume and every log volume. Only one dev thread is activated for writing the database trace, if it is enabled.

The dev threads are numbered sequentially (dev<n>). The dev thread dev0 has the special responsibility of coordinating and monitoring the other dev threads.

Temporary dev threads

To make data backups, temporary dev threads (asdev<i>) are activated for reading and writing data.

Timer

Timers monitor timeouts and are also responsible for other internal time-dependent controls.


Task (MaxDB: Database Administration)

Task

Tasks perform database jobs requested by the users of the database system or the kernel. Tasks run in the user kernel thread.

The task states give you information about the current state of a task.

There are several different types of tasks, each responsible for special jobs. For example, user tasks are responsible for processing SQL queries.


Task States (MaxDB: Database Administration)

Task States

The following table shows the possible states that tasks can have. To display the current task states, you can use, for example, the XCONS tool (database console).

AsynClose | Closing the input/output channels after a backup or restore
AsynCntl | Task is determining parameters or initializing the backup device
AsynOpen | Opening the input/output channels for a backup or restore
AsynWait | Task is waiting for execution of input/output activity when making backup/restore
Command reply | Task is sending the result of a request to the application
Command wait | Task is a database session without a request
Connect wait | Free database session
Diaginit | Initializing the trace volume
DcomObjCalled | Task is executing a database procedure/COM object
Inactive | Task is in an initial state and has no resources (such as stack)
InsertEvent | Task is generating an event
IO wait | Task is waiting for I/O (W: write, R: read)
RescheduleMsec | Short-term wait situation; starts running again automatically after specified period (in microseconds)
Runnable | Task can run now, but has been displaced due to long runtime or priority of another task
Running | Task is running, using CPU
Sus... | Special suspend situations
Terminated | Task is being terminated/database session is being terminated
Vattach | Opening the input/output channels (volumes, normal operation)
Vbegexcl | Task is waiting for protected memory access
Vdetach | Closing the input/output channels (volumes, normal operation)
Vdevsize | Determining the size or formatting of a volume
Vendexcl | Task can run again after protected memory access that caused a lock collision
Vopmsg | Writing a message to the database files knldiag, knldiag.err, and/or opmsg[n]
Vrelease | Ending the database session between the database instance and application
Vshutdown | Operational state of the database instance is changing from ONLINE to ADMIN
Vsleep | Short-term wait situation; starts running again automatically after specified period
Vsuspend | Task is waiting for a B* tree lock (very short) or a log I/O, awoken explicitly
Vwait | Task is waiting for an SQL lock
WaitForEvent | Task is waiting for events to be generated


Directory Structure (MaxDB: Database Administration)

Directory Structure

The security and performance of the database system are influenced strongly by the way in which the database directories are distributed across the hard disks. The optimum directory structure depends on the particular hardware configuration.

You must meet the following requirements:

· There must be enough free space to allow the database to expand.

· The data must be stored securely.

· The hardware must meet the performance requirements.

If you are designing the directory structure for a production system, read the Tips for Setting Up the Database Instance. The database directories are defined when the database software is installed (see the Installation Manual). You can either accept the system default or define a different path.

You do not have a free choice of directories for an RPM-based installation on Linux; instead, the directories are specified by the values /var/opt/sdb/data, /opt/sdb/programs, and /opt/sdb/7500.

If you later want to change a directory path or directory name, check all dependencies on other directories and contact the support team for help, if necessary.

To display the paths of the most important database directories, use the Database Manager CLI.

See also:

Database Manager CLI, section Installation and Registration Management


Example: Directory Structure (MaxDB: Database Administration)

Example: Directory Structure

This example shows a typical structure for the database directories on Microsoft Windows:

C:\Program Files\sdb\

-- 7500

-- bin

-- cluster

-- doc

-- env

-- lib

-- misc

-- pgm

-- sap

-- Support

-- symbols

-- data

-- config

-- install

-- wrk

-- DBInstanz1

-- DBInstanz2

-- programs

-- bin

-- env

-- etc

-- incl

-- install

-- lib

-- misc

-- pgm

-- runtime

-- sdk

-- Support

-- symbols

-- web


Database Directories (MaxDB: Database Administration)

Database Directories

The following table shows you the most important directories of the database system.

You can make your own choice of installation directory for the database tools. You can install the database tools either on the database computer or on another computer.

Directory Name

Description

<independent_data_path>/config

Configuration directory that, among other things, contains configuration files for database parameters, database tools, and files for user authorization

<independent_data_path>/wrk/
<database_name>

Default for the run directory of the database instance <database_name>

<independent_program_path>

Programs that are independent of the database system version These programs are installed once for each computer. In this directory and its subdirectories, you will always find the programs for the most recently installed version of the database software.

Libraries for the client runtime environment These libraries are installed once for each computer, however, you must have the option of storing them in different versions.

<dependent_path>

Location of the software that is dependent on the version of the database system This software is installed once for each database instance.

The specified path must be unique. Many different directories with different versions can exist alongside each other.

Any programs in these version-specific directories are not executed directly by the users; instead, they are called by programs located in <independent_program_path>.

The following additional conventions apply to SAP systems:

/sapdb/<database_name>/data | Directory for data volumes
/sapdb/<database_name>/log | Directory for log volumes and mirrored log volumes
/sapdb/<database_name>/save | Directory for backup files of log backups and data backups

See also:

Example: Directory Structure


Run Directory (MaxDB: Database Administration)

Run Directory

The log files of a database instance are stored in the run directory. The directory is specified with the general database parameter RUNDIRECTORY and created by the database system when installing a new database instance.

The default value for the run directory is <independent_data_path>/wrk/<database_name>

The log files of the database instance in the run directory are overwritten when you restart after a database crash. Older log files are therefore moved to the directory <diag_history_path>. The default value for this directory is <independent_data_path>/wrk/<database_name>/DIAGHISTORY.

See also:

Directory Structure of the Database System


Database Tools (MaxDB: Database Administration)

Database Tools

Several different database tools help you in your work with database instances.

The database tools are included in different software components. You can download the database tools (with the exception of the Solution Life Cycle Management (CCMS)) free of charge from the following address: http://www.mysql.com/downloads

The following table shows you which database tools are used for which tasks:

Tool | Task | Typical User | Downward-compatible
Database Analyzer (CLI) | Analyzes the performance of database instances (replaced the program XWIZARD) | Support Database administrator | Yes
Database Manager: Database Manager GUI Database Manager CLI Web DBM | Creates and manages database instances and DBM operators Does not create and manage database users | Database administrator | Yes, 7.2 and later
Loader (CLI) | Loads and unloads data (import and export) | Database administrator Application developer | Yes, 7.3 and later
SQL Studio: SQL Studio (GUI) SQLCLI Web SQL Studio | Accessing data and the database catalog, SQL queries, creating and managing database objects and database users | Database user | SQL Studio: Yes, 7.4.0 and later SQLCLI: Yes, 7.2 and later
VMAKE (CLI) | Development environment. For creating MaxDB software after modifying the source code. | Open source users who modify the MaxDB source code | No
WebDAV GUI (Web) | Indexing XML documents in the WebDAV Service and optimizing access | WebDAV administrator | Yes, 7.4.3.30 and later
XCONS (CLI) | Database console. Provides highly detailed information about the operating system resources used by the database system. | Support Database administrator | Yes
XPU (CLI) | Updates the optimizer statistics | Support Database administrator | Yes
XUSER (CLI) | Manages user-specific database connection data | Support Database administrator Application developer | Yes

For SAP systems only:

Solution Life Cycle Management:

CCMS OLTP (GUI)

CCMS SAP liveCache (GUI)

Manages MaxDB and liveCache database instances in an SAP system

SAP administrator

Yes

Explanation of the Table

Some of the tools are available in different variants:

· GUI: Graphical user interface; all functions are available, must be installed locally, can be used on Microsoft Windows only

· CLI: Command line; all functions available, can be used as a batch script and can be embedded in scripting languages (such as Python or Perl), can be used on all supported operating systems

· Web: Browser interface; only the most important functions are available, installed centrally, can be used through a Web browser only, platform-independent

See also:

Programming Interfaces


Database Analyzer (MaxDB: Database Administration)

Database Analyzer

The Database Analyzer is a database tool for analyzing the performance of database instances.

See also:

Database Analyzer documentation


Database Manager (MaxDB: Database Administration)

Database Manager

The Database Manager is a database tool for creating and managing database instances and Database Manager operators.

The Database Manager cannot be used for creating and managing database users; to do this, use the SQL Studio, the SQLCLI, or the Web SQL Studio.

The Database Manager is available in several different variants:

· Database Manager GUI

· Database Manager CLI

· Web DBM

See also:

Architecture of the Database Manager

Architecture of the Web Tools


Architecture of the Database Manager (MaxDB: Database Administration)

Architecture of the Database Manager

The Database Manager has a client/server architecture. The DBM Server is responsible for the functions, and the user uses the client to access the tool.

The Database Manager clients can be used for remote connections. This means that the client and the DBM Server can be installed on different computers. However, the DBM Server must always be installed on the same computer as the database instance that you want to access with the Database Manager.

At the request of the client (Database Manager GUI or Database Manager CLI), the X Server starts the DBM server. After a connection has been successfully created, an additional thread or an additional child process is started in the X server process to transport the data packets over the network.

See also:

Architecture of the Web Tools


DBM Server (MaxDB: Database Administration)

DBM Server

The DBM Server is the server part of the Database Manager. It is installed by the server installation on the database server.

The DBM Server creates the connection to the database instance and can access its environment using operating system methods.

Client applications such as the Database Manager GUI or the Database Manager CLI form a link to the DBM server and exchange data with the DBM server using a request-reply mechanism.

See also:

Architecture of the Database Manager


Database Manager Files (MaxDB: Database Administration)

Database Manager Files

For each database instance, the Database Manager creates a series of files in the run directory of the database instance.

The Database Manager uses the following different file types:

· Database Manager Log Files

· Database Manager Configuration Files


Database Manager Log Files (MaxDB: Database Administration)

Database Manager Log Files

When you contact the support team, specify the file ID and/or file class when you pack the diagnosis package (see Database Manager CLI, Packing Database Files).

File Name (File ID) | File Class | File Content
dbm.prt (DBMPRT) | protocol | Log of the DBM Server
dbm.utl (UTLPRT) | protocol | Log of the utility commands
dbm.ins (INSTPRT) | protocol | Log of the load/update of the system tables
dbahist.prt (DBAHIST) | protocol | Log of the database administration activities
dbm.knl (BACKHIST) | backup | History of backups and recoveries (see Backup History)
dbm.mdf (BACKMDF) | backup | History of the backup media used for backups
dbm.ebf (BACKEBF) | backup | History of backups made with external backup tools
dbm.ebp (BACKEBP) | backup | Log of the last backup made with an external backup tool


Database Manager Configuration Files (MaxDB: Database Administration)

Database Manager Configuration Files

The Database Manager creates the following configuration files in the run directory of the database instance.

File Name (File ID) | File Class | File Content
dbm.cfg | config | Configuration file of the Database Manager, created once for each database instance
dbm.mmm (DBMMDF) | config | Backup media of the Database Manager

You can use the Database Manager CLI to display and change the configuration.

· Database Manager CLI, Displaying a Configuration Parameter of the Database Manager

· Database Manager CLI, Changing a Configuration Parameter of the Database Manager


Loader (MaxDB: Database Administration)

Loader

The Loader is a database tool for loading and unloading data (export and import).

Data unloaded with the Loader is not suitable for a recovery of a database instance, since the consistency of the data is not ensured. Unloaded data cannot therefore replace data backups.

See also:

Architecture of the Loader

Loader documentation


Architecture of the Loader (MaxDB: Database Administration)

Architecture of the Loader

The Loader has a client-server architecture, but can also be used as a standalone executable program (client and server in one program).

The client is the user interface of the Loader server and forwards the commands that need to be processed. The Loader server itself is, in turn, a client with regard to a database instance. It processes the commands, transforms the data in the data flows, and communicates with the database kernel.

The Loader can be used with remote connections; that is, the Loader and the database instance can be installed on different computers.

In practice, the following configuration is frequently used:
All Loader components are on one computer, and the database instance is on another computer.

...

1. At the request of the client (for example, Loader CLI), the Loader is started directly, without the X server being called.

2. Communication between the Loader and the database kernel is established via the X server.


Loader Server (MaxDB: Database Administration)

Loader Server

The Loader has its own loader server. This server must be installed on the same computer as the media you are using.

The Loader server creates the connection to the database instance and can access its environment using operating system methods. The Loader server can communicate remotely with the database instance and with the client.

See also Architecture of the Loader


Unloading Data (MaxDB: Database Administration)

Unloading Data

You can unload the database catalog and/or application data of a database instance or parts of the database catalog or application data using the Loader.

The data stream generated by doing this can be directed to various media. You can also use a tape as a medium. This is addressed using an external backup tool (Unloading with External Backup Tools).

Data unloaded with the Loader is not suitable for a restore of a database instance, as the consistency of the data is not ensured. Unloaded data cannot therefore replace data backups.


Loading Data (MaxDB: Database Administration)

Loading Data

You can load the database catalog and/or application data of a database instance or parts of the database catalog or application data using the Loader. You can import the data stream required to do this from various media. You can also use a tape as a medium. This is addressed using an external backup tool (see Loading with External Backup Tools).

Data unloaded with the Loader is not suitable for a restore of a database instance, as the consistency of the data is not ensured. Loading data cannot therefore replace a restore from a data backup.


Query Tools (MaxDB: Database Administration)

Query Tools

Query tools are the database tools that you use to access data and the database catalog, make SQL queries, and create and manage database objects and database users.

· SQL Studio

· SQLCLI

· Web SQL Studio

See also:

Architecture of the Query Tools


SQLCLI (MaxDB: Database Administration)

SQLCLI

The SQLCLI is a database tool that enables database users to perform the following tasks:

· Access data

· Access the database catalog

· Make SQL queries

· Create and manage database objects

· Create and manage database users

Syntax

sqlcli [–n <database_server>] [-d <database_name>] [-u database_user>,<database_user_password>] [sqlcli_command|sql_command]

sqlcli_command | SQLCLI command
sql_command | SQL statement

To get a list of all SQLCLI commands and their options, use the following command:

sqlcli \h

Examples

Querying general information about the database HOTELDB as user MONA with the password RED:

sqlcli –d HOTELDB –u MONA,RED \s

Displaying all data records in the table customer in the database HOTELDB as user MONA with the password RED:

sqlcli -d HOTELDB -u MONA,RED SELECT * FROM customer

See also:

SQL Studio

Web SQL Studio


Architecture of the Query Tools (MaxDB: Database Administration)

Architecture of the Query Tools

The Query Tools communicate with the database instance as follows:

· SQL Studio: At the request of the client, a connection to the database instance is created using the ODBC interface.After this, communication can take place between the client and the database instance.

· Web SQL Studio: Calling the Web SQL Studio in the Web browser sets up a connection to the client (Web SQL service integrated into the Web server). The communication between this client and the database instance takes places through the ODBC interface (see also Architecture of the Web Tools).


WebDAV GUI (MaxDB: Database Administration)

WebDAV GUI

The WebDAV GUI is a database tool for indexing XML documents in the WebDAV Service, and optimizing access to these documents.

See also:

WebDAV GUI documentation


Web Tools (MaxDB: Database Administration)

Web Tools

The Web tools comprise all database tools that have a Web interface and that you can operate through a Web browser.

· Web DBM

· Web SQL Studio

See also:

Architecture of the Web Tools

Web Tools Installation Guide


Architecture of the Web Tools (MaxDB: Database Administration)

Architecture of the Web Tools

The Web tools are implemented as a Web service and can be used with the MaxDB Web Server as well as with the Web server Apache.

The MaxDB Web Server is installed with the Web tools. If you want to use the Apache Web server, then you must configure it separately. The database instance can be on the same computer or on a different computer.

A connection to the client (Web DBM or Web SQL service integrated into the Web server) is created by calling a Web Tool in the Web browser. The communication between the client and the database instance takes place, for the Web DBM tool, through the DBM Server and through the ODBC interface for the Web SQL Studio tool.

See also:

Architecture of the Query Tools

Architecture of the Database Manager


XCONS (Database Console) (MaxDB: Database Administration)

XCONS (Database Console)

XCONS (database console) is a database tool that gives you a quick overview of the operating system resources being used by the database system, the distribution of the database sessions among the threads, and the status of the active database sessions. XCONS is called from the command line.

XCONS is a tool designed for troubleshooting and development tasks. Contact your support team before using XCONS in a production environment.

Syntax

x_cons <database_name> <command> [<interval> [<repeat>]]

interval | Time between repetition of the same command. If you do not specify an interval, the command is executed once.
repeat | Number of times the command is repeated. If you specify an interval but no repeat, the command is repeated an unlimited number of times.

Displaying all tasks of the database instance HOTELDB and repeating this command 10 times at one second intervals:

x_cons HOTELDB show active 1 10

Commands

An overview of all commands and their options:
x_cons <database_name> help

time <enable | disable> | Enables internal time measurement. Note that this can have a negative effect on the performance of your system.
cancel <taskindex> | Cancels the command that has just been executed by the task with the index taskindex
pagecache_release | Releases the page cache
diagnose_pagecache | Analyzes the page cache. The results are written to the log file knldiag.
kill <taskindex> | Ends the session of the task with the index taskindex
affinity <uktindex> | Note that this command was designed for development tasks. Do not use it in a production environment. Use this command only when asked to by the support team. This command enables the user kernel thread with the index uktindex to be bound to a processor.
procmask <procmask> | Note that this command was designed for development tasks. Do not use it in a production environment. Use this command only when asked to by the support team. For Microsoft Windows only: Binds user kernel threads to processors
trace_flush | Flushes the trace file
show io | Displays statistics about access to the volumes
show aio | For backups only: displays statistics about access to the volumes
show storage | Displays memory usage. On Microsoft Windows, the task stack is also displayed.
show tasks | Displays statistics for all tasks
show active [dw | sv | us | gc] | Displays statistics for the active tasks. You also have the option of only displaying the statistics of specific task groups: DW (Data Writer=Pager), SV (Server Task), US (User Task), GC (Garbage Collector).
show runnable [dw | sv | us | gc] | Displays information about runnable tasks; you also have the option of displaying this information for specific task groups.
show moveinfo | For load balancing only; history and current movement of tasks between user kernel threads
show t_cnt [dw | sv | us | gc | <taskindex>] | Displays detailed information about all tasks in a specific task group or about the task with the index taskindex
show t_queue | Displays the task queues
show t_reg | Displays the semaphores (usage of the critical sections by the tasks)
show t_stat | Displays task statistics
show t_move | For load balancing only; shows whether tasks are currently allowed to move from one user kernel thread to another
show versions | Displays the version of the database kernel and the runtime environment
show regions | Displays information about the critical section
show state | Displays the operational state of the database instance
show rte | Displays information about the runtime environment (such as threads)
show queues | Displays the queues
show suspends | Displays the reasons why suspended tasks have been suspended
show sleep | Displays statistics about how long the individual user kernel threads have been suspended
show thrd_times | For Microsoft Windows only: Displays how much processor time the threads have used
show all | Displays all available information and statistics

See also:

· Database Manager CLI, display of information about the database instance

· Calling XCONS in the Database Assistant of an SAP system:
Database Administration in CCMS: MySQL MaxDB, [image] Database Console
Database Administration in CCMS: SAP liveCache, [image] Console


XPU (MaxDB: Database Administration)

XPU

XPU is a database tool that you use to check the consistency of the volumes in a database instance and to update the statistics for the SQL Optimizer.

When the database instance is checked, all B* trees are analyzed. This is a very time-intensive process, since all pages need to be read.

XPU does not reorganize the database instance; it just analyzes its current state.

Prerequisites

· Before the XPU checks are started, the database instance must be in the operational state ONLINE.

· XUSER entries must exist, or the environment variable SQLOPT must be set as follows: SQLOPT="-d <database_name> -u <database_user>,<database_user_password>"

Syntax

xpu -v|-s [-u] count

-v | Check consistency of the volumes
-s | Update statistics for the SQL Optimizer
-u | Only in combination with the option –s; all tables of the database are checked. If this option is not set, then only those tables are analyzed whose size has changed the most since the last check.
count | Maximum number of parallel tasks; 1 < count < 50

Example

Checking a database instance:

xpu –v 10

See also:

Background Knowledge, SQL Optimizer

Database Manager CLI, Updating the Optimizer Statistics with the Program XPU


XUSER (MaxDB: Database Administration)

XUSER

XUSER is a database tool that you use to define XUSER entries for any users. You then save these entries under a key name (user_key). You can define XUSER entries for both database users and DBM operators.

XUSER entries make it faster for database tools, such as the Database Manager CLI and the C/C++ Precompiler, to connect to the database instance. SAP systems also support the use of the XUSER tool.

Other database tools, such as the Loader and the Database Manager GUI, and applications that use the ODBC interface (such as SQL Studio) cannot access XUSER data.

XUSER entries consist of a user name and user password, together with additional options. This information and the options are saved separately for each operating system user. The allocation of rights in the file system guarantees that these entries can only be used and modified by the operating system user who created them.

You can use the XUSER program to store user data for various tasks and use this data for logons. An operating system user can define up to 32 user keys. You can manage individual user data in this way if, for example, more than one database user is using the same computer and each user is working under a different user name.

XUSER is not a tool for managing database users or DBM operators. It only manages the XUSER entries for these users in the XUSER program. You can access the database instance with a database user saved under an XUSER entry only if this user has been created for this database instance with an SQL statement. In the same way, you can manage a database instance with a DBM operator saved under an XUSER entry only if you defined this operator when you created the database instance.

See also:

Creating or Changing XUSER Entries

Connecting with the XUSER Entry

Displaying Data for XUSER Entries

Deleting XUSER Entries


Creating or Changing XUSER Entries (MaxDB: Database Administration)

Creating or Changing XUSER Entries

You do not need to connect to the XUSER program to create new XUSER entries. You can either create new XUSER entries interactively, or you can extract them from an XUSER file.

The predefined key name DEFAULT already exists. This key name cannot be changed. If no data is yet saved under this key name, then the first defined entry is always saved under DEFAULT, regardless of any key name that is specified.

If you do not specify a key name when you create an XUSER entry, then all data is saved under DEFAULT; this means that any existing data is overwritten.

To change XUSER entries, you must use the data of the user in the entry you want to change, or the data in the XUSER key DEFAULT, to connect to the XUSER program.

You change an existing XUSER entry by overwriting its data completely.

Syntax

xuser [<options>] set

You can call the XUSER program with the following options:

-h

Display help texts

-V

Display version of XUSER program

-A ASCII8

XUSER data is interpreted as ASCII8

-b <file_name>

XUSER entries are generated in the background from the data in the file <file_name>.

See: XUSER Files

-U <user_key>

Key name under which the XUSER entry is saved in the XUSER program

Character string with a maximum of 18 characters (9 characters in UNICODE). This character string is case-sensitive.

-u <user_name>,<password>

User name and password

Character strings, each with a maximum of 18 characters (9 characters in UNICODE)

You must place them in quotation marks if they contain lowercase letters or special characters. Otherwise lowercase letters are converted to uppercase letters.

-d <database_name>

The name of the database instance you want to work on. If the database instance has not yet been created, follow the conventions for database names.

If you do not specify a <database_name>, then this name is taken from the environment variable SERVERDB. If this environment variable is not set, then no database instance is assigned to the XUSER entry.

-n <database_server>

The name of the server on which the database you called is running

Character string with a maximum of 64 characters

This character string is case-sensitive.

If you do not specify a <database_server>, then the local server is used.

-S <SQL_mode>

SQL mode

Character string with a maximum of 8 characters

If you do not specify an <SQL_mode>, then the INTERNAL SQL mode is used.

-t <timeout>

Timeout value in seconds

Possible values: -1, <number>, 0

-1: The default value of the database instance is used.
0: No timeout value is used.

If you do not specify a <timeout>, then the value –1 is used.

-I <isolation_level>

Isolation level

(for application programs and precompilers only)

If you do not specify an <isolation_level>, then the value –1 is used. This means that the default value of the database instance is used.


Connecting with the XUSER Entry (MaxDB: Database Administration)

Connecting with the XUSER Entry

To use an XUSER entry to connect to a database instance, specify the option –U <user_key> [<options>] when you connect. <user_key> is the XUSER key.

The user key is case-sensitive.

Also note that the connection can only be made successfully if the user saved in the specified XUSER entry has actually been created.

If you specify additional options, then these options override the corresponding data in the XUSER entry.

Various applications of the database system support the XUSER program, and give you the option of connecting to the program from the application itself and using the XUSER key.

· If you use SQL applications (such as the Precompiler) to connect to XUSER, and you do not specify an XUSER key, then the connection is made with the user data saved under the key name DEFAULT.

· If you use the Database Manager to connect to XUSER, and you do not specify an XUSER key, then the connection is made with the user data saved under the key name DBMUSR.


Displaying Data for XUSER Entries (MaxDB: Database Administration)

Displaying Data for XUSER Entries

You can display the data for the XUSER entries saved in the XUSER program. To do this, use the following command:

xuser [-U <user_key>] list

You can display the data for all existing XUSER entries, or the data for a specific XUSER entry:

· To display the data for all saved XUSER entries, use the command without specifying any options.

· To display the data for a specific XUSER entry, specify the option –U and the key name <user_key> for the XUSER entry that you want to display.

See also:

XUSER


Deleting XUSER Entries (MaxDB: Database Administration)

Deleting XUSER Entries

To delete one or all of the XUSER entries saved in the XUSER program, use the following command:

xuser [-U <user_key>] clear

XUSER is not a tool for managing database users or DBM operators. It only manages the XUSER entries for these users in the XUSER program. When you delete an XUSER entry, you do not delete the corresponding user. Database users can only be deleted with an SQL statement. DBM operators can only be deleted with the Database Manager.

You can delete a specific XUSER entry or all XUSER entries of the connected operating system user:

· To delete the data of a specific XUSER entry, use the above command with the option –U and specify the key name of this XUSER entry as the <user_key>.

· To delete all entries of the operating system user who is currently connected, do not specify any options.

See also:

XUSER


XUSER Files (MaxDB: Database Administration)

XUSER Files

XUSER entries can be extracted from XUSER files. You are free to define your own file name. Each XUSER entry in the file must contain the following data in the specified order, and must have a length of exactly 10 lines.

<user_key>
<user_name>
<password>
<database_name>
<database_server>
<SQL_mode>
  (empty line)
<timeout>
<isolation_level>
  (empty line)

The empty lines in the file must be left empty, since they are meant to contain other XUSER data that is not relevant for the database version 7.5.

You must include an extra empty line for every option that you omit.

The following example shows an XUSER file (key name TESTKEY, user MONA). It does not contain any SQL mode information, which is why it has an extra empty line.

TESTKEY
MONA
RED
HOTELDB
GENUA
(empty line)
(empty line)
90
1
(empty line)


X Server (MaxDB: Database Administration)

X Server

The X Server is the communication server of the database system. It listens at service port sql6/TCP for connection requests from database applications and database tools.

If a database application or a database tool wants to communicate with a database instance on a remote computer, then the connection is made through the X Server that is running on this remote computer.

The X Server is a cross-instance server: even if more than one database instance is running on a computer, only one X Server runs.

On UNIX operating systems, the X Server is also used to allow communication with the DBM Server within a computer.

SQL connections on UNIX systems and all connections within computers on Microsoft Windows use Shared Memory. If you still want to force the use of the X Server, specify the option –n localhost when connecting to the database instance.

Prerequisites for Communication

The following prerequisites must be fulfilled to allow communication through the X Server:

· On Microsoft Windows operating systems, the X Server is registered as the system service XServer. This service must be active. An additional thread within the X Server process is created with every successful connection through the X Server.

· On UNIX operating systems, the X Server must be running in the background as the process vserver. An additional child process is started for every successful connection through the X Server.

Starting and Stopping the X Server

x_server [<option>] start|stop

You can specify the following options when you call the X Server:

Option | Explanation
-Y | Suppresses the communication through the NI server, which is only relevant for SAP Support
-F | Suppresses the determination of DNS entries, which speeds up connections
-S <service|port> | Specifies an alternative service port at which the X Server can listen

See also:

· Architecture of the Database Manager

· Architecture of the Loader


Programming Interfaces (MaxDB: Database Administration)

Programming Interfaces

The MaxDB database system offers you the following interfaces for programming database applications:

Interface | Description
Backint for MaxDB | Database backups using external backup tools (such as TSM or Omniback)
C/C++ Precompiler | The Precompiler prepares C/C++ source code with embedded SQL statements (Embedded SQL) so that it can be translated into executable application programs. When it does this, it checks the syntax and semantics of the embedded statements and converts them to procedure calls in the precompiler runtime environment.
JDBC | The JDBC driver supports the specifications JDBC 2.0 and JDBC 3.0.
ODBC | All standard ODBC applications are supported on Windows operating systems. On UNIX/Linux operating systems, you can either use one of their ODBC driver managers (unixODBC, iODBC), or you can link your application directly to the MaxDB ODBC Library.
Perl | MaxDB supports DBI with DBD::ODBC, also on UNIX/Linux operating systems. Modules are also available that execute DBM commands and Loader commands.
PHP | PHP applications are supported by the PHP ODBC function.
Python | Use the modules sapdb.sql and sapdb.dbapi to execute SQL commands. Modules for DBM commands and Loader commands are also available.
SQLDBC | Applications can use this runtime library to execute SQL statements in the database, access data, and modify data.

You can use other programming languages and applications with MaxDB if they can be connected using ODBC.

See also:

Database Tools


Database Instance (MaxDB: Database Administration)

Database Instance

A database together with all information required to run it is known as a database instance. A database instance consists of a database name, volumes, all files in the run directory, and a collection of metadata (including configuration files, database parameters, and paths to the volumes).

To start a database instance, the kernel of the database system is started by specifying the database name. While the database instance is running, some parts of it are located in the cache.

When you create a new database instance, you can choose between different database instance types, depending on your requirements.

See also:

· Installation Guide and Installation Manual

· Creating and managing the database instance with the Database Manager tool

· Database administration in SAP systems with the DBA functions of the CCMS ( [image] CCMS: MySQL MaxDB)


Database (MaxDB: Database Administration)

Database

A database is a set of data with a regular structure; this data can be queried and updated. A database is created and managed by the database system.

The data in a database is divided between the database catalog and application data. This data is stored permanently in volumes. While the database is running, parts of the data are located in the cache.

See also:

Database instance


Database Catalog (MaxDB: Database Administration)

Database Catalog

The database catalog of a database contains the metadata of all database objects. The database catalog is made up of the following sections:

· Information about the installation of the database system and metadata with the definitions of users and user groups

· Metadata for the objects generated by a user or user group. Among other things, this includes metadata for base tables and view tables.

A user can only access the metadata of another user or another user group if authorized to do so (see User Concept ).


Application Data (MaxDB: Database Administration)

Application Data

The application data of a database comprises all data records of this database, together with their index entries. A data record corresponds to one row in a base table. This means that the application data comprises all rows of all base tables, plus the index entries created for the base tables.

As a minimum, the application data of a table or index can use just one data page . As a maximum, a table can extend across all data volumes of the database instance.A table increases or decreases in size automatically without administrative intervention. As a rule, database-internal striping distributes the data belonging to a table evenly across all the data volumes. This means that you cannot determine how the tables are assigned to the individual data volumes, but this is not significant.

See also:

Data Access in the documentation Background Knowledge


Database Instance Type (MaxDB: Database Administration)

Database Instance Type

The database system supports different application areas. It is shipped in variants that enable you to create, administer, and run different types of database instances.

The following database instance types exist:

· OLTP (MySQL MaxDB)

· liveCache (SAP liveCache)

· Archive


OLTP (MySQL MaxDB) (MaxDB: Database Administration)

OLTP (MySQL MaxDB)

MySQL MaxDB is a relational database system that was developed for OLTP (Online Transaction Processing).

The database instance type OLTP is optimized to process individual transactions fast in environments with a high number of users and large databases.


liveCache (SAP liveCache) (MaxDB: Database Administration)

liveCache (SAP liveCache)

The database instance type liveCache is only used in SAP applications.

SAP liveCache is an enhancement of the relational database system MySQL MaxDB. It provides you with an easier and more effective representation of your data structures and data streams (such as networks and relationships). SAP liveCache is object-oriented and, unlike MaxDB, works with its data only in the main memory of the database system, if the system is configured optimally. Supply Chain Management, for example, makes particular use of this, since its large volumes of data need to be constantly accessible and modifiable.

For more information and notes about monitoring SAP liveCache, see the [image] User Manual: SAP liveCache.


Archive (MaxDB: Database Administration)

Archive

To avoid large amounts of data having a negative effect on performance, you can archive the data at periodic intervals.

The database instance type Archive enables you to retain this data alongside the production database instance in a second database instance, where you can access the data directly. However, the data in the second database instance can be stored more cheaply on mass storage media.

The Archive instance type is an OLTP instance with the added ability to address a hierarchical memory management system as a volume. Since this function can have a significant effect on performance when the database is running normally, a separate instance type is used.

Usually, an Archive database instance is used in parallel with a normal OLTP database instance: frequently used data is stored in the OLTP database instance; more rarely used data is stored in the Archive database instance. The higher-level application (for example, Business Warehouse) is responsible for controlling the distribution of the data.

An Archive database instance always has at least one normal data volume and one archive data volume. Archive data volumes can be configured only once, when the database instance is created. They cannot be added later.

Creating an Archive Database Instance

Database Manager CLI:

· Example: How to Create an Archive Type Database Instance

· Creating a Database Instance

· Changing Volume Parameters

Database Manager GUI:

· Creating/Initializing a Database Instance


Operational State (MaxDB: Database Administration)

Operational State

The following operational states exist for a database instance:

Operational State | Meaning
ONLINE | The database instance has been started, and users can log on.
STANDBY | For standby instances in hot standby systems only. Standby instances cannot accept any connections. They are constantly in a restart state.
ADMIN | The database instance is only available for database administration work.
OFFLINE | The database instance is not running.

Monitoring and Changing the Operational State

To monitor or change the operational state of the database instance, use the Database Manager, or, in SAP systems, the Database Assistant of the CCMS.

· Database Manager GUI, Monitoring the Operational State

· Database Manager CLI, Commands for Database Operations

· Database Administration in CCMS: MySQL MaxDB, DB State

· Database Administration in CCMS: SAP liveCache, liveCache State, and Operating


Database Name (MaxDB: Database Administration)

Database Name

In principle, you can make your own choice of name for a database instance during its installation. However, note the following points:

· The maximum length of a database name is eight characters.

· The database name can contain the characters from the 7-bit ASCII character set.

· The database name cannot begin with an underscore or a period.

· When you create a database instance, the Database Manager automatically converts all lowercase letters into uppercase letters.


UNICODE (MaxDB: Database Administration)

UNICODE

Data types such as CHAR ASCII are mainly suited to English and central European languages. With other character sets, a code attribute is usually used for these data types. This code attribute uses a different presentation code from ASCII, even for internal storage in the database system. This causes problems if you want to access these database systems using a different character set, or if you want to exchange data between database systems with different character sets.

You can avoid these problems by using character coding in accordance with UNICODE. UNICODE is an international standard and is able to express any characters used in an alphabet in a single character set.

For metadata and application data, a UNICODE database implements UNICODE in accordance with ISO 10646. Internally, the data is stored in UTF-16/UCS-2.

The storage of data in the UTF-16/UCS-2 format requires twice as much memory as storage in ASCII. This is because the data is encoded as 16 bit instead of 8 bit.

UNICODE in Database Interfaces

SQL statements can contain both UNICODE literals and UNICODE identifiers. The prerequisite for implementing these SQL statements in a UNICODE-compliant database instance is a UNICODE-compliant client (C/C++ Precompiler, JDBC, ODBC, or the query tools SQL Studio and Web SQL Studio).

The database interfaces JDBC, ODBC, the C/C++ Precompiler, and Python support UNICODE.

Database Interface

Special UNICODE Features

JDBC

Since Java works with UNICODE strings, it can read and write UNICODE columns. If you also want to use UNICODE in SQL statements, set the UNICODE CONNECT property to true. SQL statements are then sent to the database instance in UTF-16/UCS-2 format.

See also Example

ODBC

Microsoft Windows:

From Version 7.4.03.26, the database software includes both a UNICODE-compliant ODBC driver and a driver without UNICODE.

The driver MaxDB (Unicode) (or SAP DB (Unicode)) corresponds to the previous driver SAP DB 7.4. It implements the UNICODE interface from ODBC (such as SQLConnectW) and communicates with a UNICODE-compliant database kernel using UNICODE only. It uses ASCII to communicate with a non-UNICODE-compliant kernel.

The driver MaxDB (or SAP DB) implements the ASCII interface from ODBC (without Wide functions such as SQLConnectW) and uses only ASCII to communicate with the database kernel. This communication is more efficient (produces a smaller network load) and has fewer restrictions, for example, on the maximum length of SQL statements.

UNIX/Linux:

The use of the ODBC driver is currently not possible on platforms for which the standard UNICODE type WCHAR_T with four bytes is defined. The database and ODBC driver process UNICODE internally as values that are two bytes long.

Both the ANSI and UNICODE variants of the ODBC-API are defined in the driver.

Applications that do not require the functions of a driver manager can be linked statically with the ODBC driver.

C/C++ Precompiler

You can work with UNICODE data. When a database session is opened, the C/C++ Precompiler checks whether the database is UNICODE-compliant.

Python

Python 2.x: UNICODE columns can be read and written. UNICODE character strings cannot be used as SQL statements.

Python 1.5.2: UNICODE output values are converted to ASCII. If this conversion fails, an error is reported.


Creating a UNICODE Database (MaxDB: Database Administration)

Creating a UNICODE Database

You can use this database system to create and implement UNICODE databases.

Procedure

To create a UNICODE database, proceed as follows:

...

1. To store the metadata of the database instance in UNICODE, set the special database parameter _UNICODE to YES when you install the database instance with the Database Manager.

The CHARACTER columns of the corresponding system tables then have the code attribute UNICODE. The names of database objects (such as table names or column names) can then be displayed in the required presentation code in the database tools.

Once you have installed the database instance, you can no longer change the database parameter _UNICODE. If you still want to change it, you must reinitialize the database instance.

2. To store application data in a table column in UNICODE, specify the code attribute UNICODE for the data types CHAR[ACTER], VARCHAR, and LONG[VARCHAR] when you define the column. You can use the special database parameter DEFAULT_CODE to specify UNICODE as the default code attribute for all data.


Example: Displaying Column Information (MaxDB: Database Administration)

Example: Displaying Column Information

In a Unicode database, you can specify a default code for CHAR/VARCHAR columns (ASCII or UNICODE). The Java class TableDef in the example can be used to display the results of various column definitions.

TableDef Definition

import java.sql.*;

/**

*

*/

public class TableDef

{

private Connection connection;

/**

* creates a new TableDef

*/

public

TableDef (

String url)

throws SQLException, ClassNotFoundException

{

// load class

Class.forName ("com.sap.dbtech.jdbc.DriverSapDB");

// create connection

this.connection = DriverManager.getConnection(url,

new java.util.Properties ());

this.connection.setAutoCommit (false);

}

/**

*

*/

protected void

createTable (

String tableName,

String createCommand)

throws SQLException

{

String fullCommand = "CREATE TABLE " + tableName + " ("

+ createCommand + " )";

Statement stmt = this.connection.createStatement ();

stmt.execute (fullCommand);

}

/**

*

*/

protected void

showTableDef (

String tableName)

throws SQLException

{

System.out.println ("Table: " + tableName);

DatabaseMetaData metaData = this.connection.getMetaData ();

ResultSet tableColumns = metaData.getColumns(null,

metaData.getUserName (), tableName, null);

while (tableColumns.next ()) {

String columnName = tableColumns.getString ("COLUMN_NAME");

String typeName = tableColumns.getString ("TYPE_NAME");

int colSize = tableColumns.getInt ("COLUMN_SIZE");

System.out.println (" " + columnName

+ ": " + typeName + " (" + colSize + ")");

}

}

/**

*

*/

protected void

close ()

{

try {

this.connection.rollback ();

this.connection.close ();

}

catch (SQLException sqlExc) {

// ignore

}

}

/**

*

*/

static protected String

join (

String [] args,

int startIndex)

{

if (startIndex >= args.length) {

return null;

}

StringBuffer result = new StringBuffer ();

for (int i = startIndex; i < args.length; ++i) {

result.append(args [i]);

result.append (' ');

}

return result.toString();

}

/**

* used when called form the command line

*/

public static void main (String [] args)

throws ClassNotFoundException

{

String url = args [0];

String tableName = args [1];

String createCommand = join (args, 2);

TableDef tableDef = null;

try {

tableDef = new TableDef (url);

if (createCommand != null) {

tableDef.createTable (tableName, createCommand);

}

tableDef.showTableDef (tableName);

}

catch (SQLException sqlExc) {

System.out.println (sqlExc);

}

finally {

if (tableDef != null) {

tableDef.close ();

}

}

}

}

Displaying the Column Definition of a Table

java TableDef <jdbcurl> <table_name>

Creating a Temporary Table Using the Determined Column Definitions, and Displaying these Column Definitions

<command> ::= java TableDef <jdbcurl> <table_name> <column_definition>

<jdbcurl> ::= jdbc:sapdb:<database_name>?user=<user_name>&password=<password>


Language Support (MapChar Sets) (MaxDB: Database Administration)

Language Support (MapChar Sets)

A Mapchar set is used to map language-specific characters to other formats (for example, ü to ue). The underlying code (ASCII, UNICODE) of the characters that need to be replaced and the Mapchar set must match.

· When the database instance is configured, a conversion of these country-specific letters is implicitly allowed and stored under the Mapchar set name DEFAULTMAP (defined as ASCII).

· The DEFAULTMAP Mapchar set can be changed. Additional MapChar sets can also be defined.

· If a Mapchar set is defined as UNICODE, then it can be used for UNICODE values only.

· A Mapchar set that is not defined as UNICODE cannot be used for UNICODE values.

Mapchar sets are only of significance for internal system functions. For example, Mapchar sets are used by the MAPCHAR(x,n,i) SQL function to sort fields containing umlauts.

See also:

Database Manager GUI, Creating Mapchar Sets

Database Manager GUI, Displaying, Changing, and Deleting Mapchar Sets


Multiprocessor Configuration (MaxDB: Database Administration)

Multiprocessor Configuration

To allow multiprocessor configurations to be used to the best advantage, the database system supports a configurable external/internal tasking. The aim here is to allow the maximum possible number of database sessions to be supported by the minimum possible number of operating system threads.

The configuration of the database system controls the degree of external/internal tasking using the two general database parameters MAXUSERTASKS and MAXCPU.

A computer has four processors available for the database instance. You want no more than 800 database sessions to run simultaneously.

You set MAXCPU to four, and MAXUSERTASKS to 800.


Database Parameters (MaxDB: Database Administration)

Database Parameters

You can use database parameters to define various characteristics of a database instance. When you install the database software, a default configuration is stored. This configuration is basically fully functioning. If necessary, you can adjust the database parameters originally set to suit any specific requirements you may have.

Alternatively, you can use the configuration of another database instance already present on the host or the configuration from a complete data backup. Even after this you can still adjust the database parameters to suit your own requirements.

The database parameters are divided into the following groups:

· General database parameters

· Special database parameters

· Support database parameters

Support parameters do not need to be and should not be changed for normal database operation. The setting of these database parameters requires a detailed knowledge of the database system, and should therefore only be carried out by the support team.

There are special [image] liveCache parameters for liveCache instances.

Displaying and Changing Database Parameters

To display or change the database parameters, use the Database Manager or the Database Assistant in SAP systems.

Database Manager GUI, Displaying and Changing Database Parameters

Database Manager CLI, section Database Instance Configuration

Database Administration in CCMS: MySQL MaxDB, [image] Parameters

Database Administration in CCMS: SAP liveCache, [image] Parameters

Changes take effect only after you have restarted the database instance.


General Database Parameters (MaxDB: Database Administration)

General Database Parameters

The following database parameters determine the general properties of the database instance:

CACHE_SIZE

Size of the I/O buffer cache in pages

INSTANCE_TYPE

Database instance type

KERNELVERSION

Version of the database software

LOG_MIRRORED

Specifies whether the log area is mirrored (Log Mode), possible values: YES | NO

This parameter is relevant only when you create a mirror volume with the Database Manager CLI (Changing Volume Parameters). This value is changed implicitly when you create a mirror volume with the Database Manager GUI.

LOG_SEGMENT_SIZE

Size of a log segment in pages

An automatic log backup is started as soon as a log segment is full; this parameter determines the threshold from which a backup is triggered.

MAXBACKUPDEVS

Maximum number of files or tape devices in a group of parallel backup media

The maximum value for MAXBACKUPDEVS is 32.

MAXCPU

Specifies the number of processors across which the user tasks can be distributed

Remember that the operating system resources of your computer must also be free for other processes, not just the database.

For computers with only one processor, set MAXCPU to 1.

MAXDATAVOLUMES

Maximum number of data volumes

MAXLOCKS

Maximum number of entries in the lock list, in which the locks of all users and their lock requests are stored

MAXLOGVOLUMES

Maximum number of log volumes

MAXUSERTASKS

Specifies the maximum possible number of simultaneously active user tasks, which is also the maximum possible number of database sessions

If this number has been reached, then no other user can log on to this database instance. For this reason, you must monitor MAXUSERTASKS as a critical operational parameter,

If you configure this parameter too high, then the space required for addresses rises (particularly the Shared Memory).

RUNDIRECTORY

Run directory of the database instance

You can display more information about the parameters with the Database Manager.


Special Database Parameters (Extended) (MaxDB: Database Administration)

Special Database Parameters (Extended)

The following parameters are database parameters that determine special properties of the database instance:

_EVENT_ALIVE_CYCLE

The time in seconds of an event cycle

_MAX_MESSAGE_FILES

Maximum number of trace files that can be open simultaneously

_MAXEVENTS

Maximum number of events stored by the kernel in the cache for processing by the Database Manager

_UNICODE

Parameter for creating a UNICODE-compliant database

You can no longer change this database parameter after you have created the database instance.

CAT_CACHE_SUPPLY

Size of catalog cache memory for all user tasks in pages

DATE_TIME_FORMAT

System default for the date and time format By entering the appropriate information in the database tool (such as the standard_date_mask in the Loader), or by using SQL statements (such as datetimeformat), each user can change the date and time format for a session.

For information about the possible values and syntax, see Date and Time Format.

DEADLOCK_DETECTION

Maximum search level for deadlock detection.

Any deadlocks that are not detected at this search level are only resolved by the parameter REQUEST_TIMEOUT.

If DEADLOCK_DETECTION = 0, deadlock detection is disabled.

DEFAULT_CODE

System default for the code attribute Applies only to column values of the data type CHAR[ACTER], VARCHAR, and LONG[VARCHAR].

DEVNO_BIT_COUNT

See DEVNO_BIT_COUNT

DIAG_HISTORY_NUM

Number of histories in the <diag_history_path> directory

DIAG_HISTORY_PATH

Directory <diag_history_path> for the histories of log files

The default value is DIAGHISTORY in the run directory of the database instance.

HS_DELAY_TIME_<NNN>

For hot standby systems only; delay in seconds after which the standby component NNN redoes changes that have already been done in the master component

HS_NODE_<NNN>

Computer name/address of the hot standby component NNN.

HSS_NODE_001 is the default for the master component of the standby system.

HS_STORAGE_DLL

For hot standby systems only; name of the library through which the memory management system is addressed

The default is libhsscopy.

HS_SYNC_INTERVAL

For hot standby systems only; minimum period of time (in seconds) between two master component commands for synchronizing the standby components

Any value between 0 and 36000 seconds is allowed. The default is 50.

JOIN_MAXTAB_LEVEL4

Parameter for calculating the join sequence algorithm; see JOIN_SEARCH_LEVEL

JOIN_MAXTAB_LEVEL9

Parameter for calculating the join sequence algorithm; see JOIN_SEARCH_LEVEL

JOIN_SEARCH_LEVEL

Algorithm for the join sequence search; see JOIN_SEARCH_LEVEL

KERNELDIAGSIZE

Size of the log file knldiag in KB

LOAD_BALANCING_CHK

Interval (in seconds) after which the database system checks whether load balancing is needed

0 £ LOAD_BALANCING_CHK < 600

The default is 0 (load balancing deactivated).

LOG_BACKUP_TO_PIPE

Specifies whether log backup in pipes is permitted

LOG_IO_QUEUE

Size of the log queue in pages

LRU_FOR_SCAN

Specifies whether the entire data cache is used for scans

MAXRGN_REQUEST

Maximum number of attempts a task should make to access a region

If this number is exceeded, the task lets another task access the CPU as long as it belongs to the same user kernel thread.

MAXSERVERTASKS

Determines the number of server tasks that are available, for example, for backups and recoveries

MP_RGN_LOOP

Maximum number of times a task may attempt to access a critical section that has been locked by another task

If this number is exceeded, the accessing task changes its status “Waiting”.

OFFICIAL_NODE

For cluster systems only; official name of the database within the cluster system Defined by the system administrator.

OPTIM_INV_ONLY

Determines whether the Index Only strategy is used for joins

OPTIM_MAX_MERGE

Specifies the change of the optimizer algorithm of the strategies for merging index lists

If the number of pages of an index that need to be merged exceeds the value specified in OPTIM_MAX_MERGE, this index will not be used for an index merging strategy.

REQUEST_TIMEOUT

Maximum wait before a lock is released (in seconds)

This parameter limits the amount of time you have to wait until a lock is lifted by other users for all database sessions. If a lock request cannot be satisfied within the time defined here, a message is returned to the waiting database session. Any changes made previously in the transactions are undone.

SEQUENCE_CACHE

The size of the sequence cache in pages

SESSION_TIMEOUT

Timeout value for database sessions in seconds

SET_VOLUME_LOCK

Specifies whether a volume can be added or whether it is locked Possible values are Yes and No; the default is Yes.

Yes: When a volume is added, a lock is set that prevents the same volume from being added again, which would cause errors in the system configuration.

No: No lock is set when a volume is added.

UTILITY_PROT_SIZE

Size of the log file dbm.utl in pages

You can display the full list of special database parameters for your database instance and additional information about these parameters using the Database Manager.


DEVNO_BIT_COUNT (MaxDB: Database Administration)

DEVNO_BIT_COUNT

The special database parameter DEVNO_BIT_COUNT denotes the number of bits in the converter block address that is reserved for the logical device number of a data volume. The higher the setting of the database parameter DEVNO_BIT_COUNT, the more data volumes can be managed. However, a high number of data volumes means the capacity of the individual data volumes is reduced.

The default is eight.

A page has 8 KB. DEVNO_BIT_COUNT is set to eight. This means that the database instance can manage 256 data volumes. Each data volume can have a maximum size of 128 GB.

The value that was set for DEVNO_BIT_COUNT when the database instance was installed should not be subsequently changed. If you change this database parameter during database operation, you must then recover the database instance to update the numbering of the data volumes.


JOIN_SEARCH_LEVEL (MaxDB: Database Administration)

JOIN_SEARCH_LEVEL

The special database parameter JOIN_SEARCH_LEVEL specifies the algorithm for the join sequence search, which itself determines how long the search takes and how many resources it uses.

You can specify the algorithm directly or it can be calculated from the parameters JOIN_MAXTAB_LEVEL4 and JOIN_MAXTAB_LEVEL9, and the number of tables in the join.

To specify the algorithm directly, enter one of the following values for JOIN_SEARCH_LEVEL:

· 9: All possible join sequences are calculated (permutation algorithm).

· 4: Various join sequences are calculated, depending on the query structure (transformer algorithm).

· 1: The simplest algorithm is used for the join sequence search (greedy algorithm).

If you enter 0 as the JOIN_SEARCH_LEVEL, then the algorithm for the join sequence search is specified as follows:

Table Number n of the Join | Algorithm for the Join Sequence Search
n £ JOIN_MAXTAB_LEVEL9 | 9
JOIN_MAXTAB_LEVEL9 <n £ JOIN_MAXTAB_LEVEL4 | 4
JOIN_MAXTAB_LEVEL4 < n | 1

JOIN_SEARCH_LEVEL is set to 0.

JOIN_MAXTAB_LEVEL4 is set to 16.

JOIN_MAXTAB_LEVEL9 is set to 4.

Five tables are used for a join.

Join sequence search level 4 (transformer algorithm) is used for this join because JOIN_MAXTAB_LEVEL9 < 5 = JOIN_MAXTAB_LEVEL4 applies.

For information on the way the Optimizer works, see the documentation SQL Optimizer.


Database Files (MaxDB: Database Administration)

Database Files

For each database instance, the database system creates several files within the directory structure of the database system.

The following files exist:

· Log files

· Configuration files

The database files are also assigned to various file classes.


File Classes (MaxDB: Database Administration)

File Classes

The following classes of database file exist:

backup | Log files for backups and recoveries
config | Configuration files
dump | Memory dumps
lvc | Log files for the database instance type SAP liveCache
protocol | General log files


Log Files (MaxDB: Database Administration)

Log Files

Each database instance saves the log files listed in the following table to its run directory and subdirectories. These files belong to various file classes.

File Name (File ID)

File Class

File Content

knldiag (KNLDIAG)

protocol

Current kernel log

This file is created each time the database instance is started. It is given the size specified in the special database parameter KERNELDIAGSIZE.

All messages from the running database are overwritten cyclically. One exception to this are messages relating to starting the database in the operational state ADMIN.

knldiag.old (KNLDIAGOLD)

protocol

Last kernel log

Each time the database instance is started, the file knldiag is renamed as knldiag.old.

knldiag.err (KNLDIAGERR)

protocol

Kernel error messages

This file is not overwritten. New error messages are added to the end of the file.

knldiag.evt
(KNLEVT)

protocol

Log of database events

knltrace (KNLTRC)

dump

Log file of the database trace

This file can also contain information about the causes of crashes. This file is initialized each time the database instance is started.

<database_name>.prt (KNLTRCPRT)

protocol

Text version of database trace

knldump (KNLDUMP)

dump

Backup of the main memory information after a database crash

rtedump (RTEDUMP)

dump

Memory dump from runtime environment of database instance

<database_name>.pah (DBMPAHI)

protocol

History of the database parameters

These files belong to the SAP liveCache database instance type (only in SAP systems):

lcinit.log | Start or initialization of SAP liveCache with CCMS functions from the SAP system
lcinit.his | History of all liveCache actions Information from the log lcinit.log is attached to this history.
lc<token> | Log of SAP liveCache activities

The log files of the Database Manager are also located in the run directory of the database instance.

Loaders and X Servers save their log files (loader.prt and xserver.prt) to the directory <independent_data_path>/wrk, independently of the instance (see also Loader Log File). The installation and update of the database software is also logged in this directory.

You can specify the directory for the log files of the Database Analyzer when you start the Analyzer.


Database Trace (MaxDB: Database Administration)

Database Trace

You can activate a database trace. When you do this, the trace writer task logs all reactions of the database kernel to database statements in the log file knltrace.

You can use a database trace to detect errors when processing the statements. You can also use the trace to classify inconsistencies caused by hardware errors more exactly.

Only enable the writing of a database trace if you are asked to do so by the support team. We do not recommend that you activate the trace function unless it is really necessary, because it seriously affects the performance of the database instance.

While the database trace is activated, run the database instance with the smallest load possible, and only perform those actions needed to reproduce the error.

Deactivate the database trace as soon as the actions needed for the analysis have been logged.

Activating and Deactivating the Database Trace

Use the Database Manager or the Database Assistant in SAP systems to activate and deactivate the database trace.

· Database Manager GUI, Activating the Database Trace

· Database Manager CLI, section Database Trace Functions

· Database Administration in CCMS: MySQL MaxDB, [image] Database Trace


Configuration Files (MaxDB: Database Administration)

Configuration Files

For each database instance, the system creates the following configuration files in the database directories:

· Configuration file <database_name> with the database parameters in the directory <independent_data_path>\config\<database_name>

The history of the database parameters is part of the log files.

· Configuration files of the Database Manager in the run directory of the database instance


Caches (MaxDB: Database Administration)

Caches

To reduce the number of times that the disk is accessed, read and write operations on the data of a database instance are buffered. The relevant main memory structures are called caches. They can be dimensioned appropriately using the corresponding database parameters.

Among others, the database system uses the following caches:

· Catalog cache

· I/O buffer cache

¡ Data cache

¡ Converter

· Log queue

See also:

Database Manager GUI, Displaying Cache Information

Database Manager CLI, Displaying Information About the Database Instance

In SAP systems, you use the [image] Database Assistant to display database information, or the [image] liveCache Assistant for liveCache instances.


Catalog Cache (MaxDB: Database Administration)

Catalog Cache

The catalog cache of a database instance contains the database catalog objects most recently used by a database session and the internal representation (execution plans) of the most recently executed SQL statements.

One catalog cache exists for each database session. You can configure its size using the special database parameter CAT_CACHE_SUPPLY. The hit rate should be above 85 percent.

Data that is displaced from the catalog cache is moved to the data cache.


I/O Buffer Cache (MaxDB: Database Administration)

I/O Buffer Cache

Any part of the main memory that is available for I/O operations is managed in the I/O buffer cache. When the database instance is started, the I/O buffer cache is created in the main memory in accordance with the size entered in the general database parameter CACHE_SIZE.The size of the main memory is given in pages.

The primary consumers of the main memory managed in the I/O cache are the converter and the data cache. If the converter grows while the database is running, and requires more pages, it is given pages from the I/O buffer cache. If the pages run out here, data is displaced from the data cache and given to the converter.


Converter (MaxDB: Database Administration)

Converter

The converter holds the information about which logical data pages are assigned to which physical data pages.

If any data pages that are not in the data cache need to be accessed, then a search is first made in the converter for their logical position. The corresponding physical position of the data pages in the data volumes is then determined. The converter is used by all simultaneously active users.

Only the converter pages that contain a mapping of permanent data pages are written to the data volumes with each savepoint. In a restart, the pager can use these pages to restore the converter.

Pages are never displaced from the converter. If necessary, additional pages are taken from the I/O buffer cache. This means that the size of the converter can never be specified explicitly.


Data Cache (MaxDB: Database Administration)

Data Cache

The data cache contains the last read- or write-accessed pages of the data volumes. It is shared by all simultaneously active users.

The data cache is dimensioned dynamically, which means that you cannot directly influence its size. The required pages are taken from the I/O buffer cache. If the converter grows, the number of data cache pages is reduced accordingly.

The hit rate, that is the proportion of successful accesses in the total number of accesses to the data cache, is a crucial measure of performance. Successful access means that the required data was already available in the data cache when it was accessed.


Log Queue (MaxDB: Database Administration)

Log Queue

The main memory area required for logging is called the log queue. The size of a log queue is determined by the special database parameter LOG_IO_QUEUE.

For a detailed explanation of logging, and the tasks of the log wait queue, see Background Knowledge.


Volumes (MaxDB: Database Administration)

Volumes

A volume is a logical grouping of physical storage units (disks). A volume can be a part of a physical disk, a complete physical disk, or a completely structured storage system consisting of several storage units. The disks used should have similar performance parameters (specifically, access speeds) to ensure that the volumes are filled evenly.

The database system differentiates between data volumes and log volumes. Every database instance has one or more log volumes and data volumes. If database management tools are used, a volume is addressed through a directory path. You can change the directory paths.

The number of data volumes and log volumes that you can define for a database instance is specified in the general database parameters MAXDATAVOLUMES and MAXLOGVOLUMES. You can configure one or more of these data volumes and log volumes when you install a new database instance. If necessary, you can configure more volumes while the database is running.

Managing Volumes

To manage the volumes, use the Database Manager or the Database Assistant of the CCMS in SAP systems.

· Database Manager GUI, section Managing Database Instances

· Database Manager CLI, commands for configuring database instances

· Database Administration in CCMS: MySQL MaxDB, [image] Volumes

· Database Administration in CCMS: SAP liveCache, [image] Volumes


Data Volumes and Data Area (MaxDB: Database Administration)

Data Volumes and Data Area

The volumes in which the database content is recorded are called data volumes. All data volumes together form the data area. Among other things, the data area contains the database catalog and the application data.

The size of the data area represents the total size of the database instance. It must not fall below 2000 pages. In the data area, there must also always be sufficient space to hold all the data that is created during database operations.

Make regular backups of the data area.

See also:

Database Manager GUI, Displaying Data Area Information

Database Manager CLI, Displaying Information About the Database Instance


Log Volumes and Log Area (MaxDB: Database Administration)

Log Volumes and Log Area

The volumes in which all changes to database content are recorded as log entries are called log volumes. Together, all log volumes form the log area.

Log entries are needed alongside data backups to guarantee that the database instance can be recovered after errors, either to its last consistent state, or to any other state in the past. When you recover the database instance, the log entries that are still in the log area are restored. If the required log entries no longer exist, then the corresponding log backups are restored.

Importance of Log Backups

The log area is overwritten cyclically. However, if you use standard log backups, the existing log entries in the log area can only be overwritten after they have been backed up. If no new log entries can be written, then the database crashes. For this reason, you must back up the log area at regular intervals, for example, with automatic log backups.

You can use the Database Manager GUI to monitor the fill level of the log area (see Displaying Log Area Information). If the log area is full, make a log backup so that the log area can be overwritten again.

For security reasons, we recommend that you mirror the log area. If hardware-based mirroring is not possible, you can use an appropriate log mode setting.

See also:

Log Settings

In log backups, the log area is not saved as a whole. Instead, it is saved in backup units, called log segments. You must match the size of the log segments, the size of the log volume, and the capacity of the backup media to each other.

For more detailed information about logging, see Background Knowledge.


Log Segment (MaxDB: Database Administration)

Log Segment

In log backups, the log area is not saved as a whole. Instead, it is saved in backup units, called log segments.

The size of the log segments is defined by the general database parameter LOG_SEGMENT_SIZE. Their size is independent of the size of the individual log volumes, but must not be bigger than the total size of the log volumes. The size should be selected so that, when a log segment is backed up, enough space remains in the log area to ensure that the changes taking place at the time can be recorded.

User-Defined Value | Log Segment Sizes Used by the System
No definition of log segment size (LOG_SEGMENT_SIZE = 0) | One-third of the total log area
The log segment size in pages is smaller than or the same as 50% of the total log area. | The value defined for LOG_SEGMENT_SIZE
The log segment > 50% of the total log area. | 50% of the log area


Page (MaxDB: Database Administration)

Page

A page is a basic physical unit of disk input and output, that is, a page corresponds to a certain number of blocks. Storage and disk space is often specified in pages.

The page size for this database system is 8 KB.


Database Session (MaxDB: Database Administration)

Database Session

To work with a database instance, send database requests, or manage the database instance, the user must first connect to the database instance with a user name and password and open a new database session.

If the user does not belong to a user group, then the specified user name is known as the current user. If the user does belong to a user group, the current user is the name of the user group.

A database session is either ended explicitly by the user, or implicitly when a timeout value has been exceeded.

Displaying Information About Database Sessions

You can display information on current database sessions with the Database Manager, or you can get this information from the appropriate system tables.

Database Manager GUI, Displaying Database Sessions

In SAP systems, you use the [image] Database Assistant to display database information, or the [image] liveCache Assistant for liveCache instances.


Connecting to a Database Instance (MaxDB: Database Administration)

Connecting to a Database Instance

Users must make the following entries when connection to a database instance:

database_name | The name of the database instance you want to work on
database_server | Name of the computer on which the database instance is installed
user_name | User name
password | Password of the user

Additionally, you can specify other options, depending on the application or database tool. These options can include the SQL mode or the timeout value.

Specifying User Data

When you work with the database tools or other application programs, you have the following options for specifying user data:

· Specify user data on the logon screen of the Database Manager GUI or SQL Studio

Remember the rules for lowercase and uppercase letters when you open a database session in the SQL Studio.

· Specify user data in call options when you call the database tool or application program

· Specify user data with XUSER

Any missing or incorrect user data causes the program to terminate with an appropriate error message.

When you call the C/C++ Precompiler and application programs that were generated using the programming interface of the database, you can also specify user data directly in the program itself. For this reason, the program contains a special modified rule for the specification of user data. For more information, see the C/C++ Precompiler User Manual under Precompiler Options and Connecting to a Database Instance.


Calling the Database Tools (MaxDB: Database Administration)

Calling the Database Tools

User data for logging on to a database instance and, in some cases, other data can be specified as options when calling the database tools, the C/C++ Precompiler, or the application programs. Some call options must be specified to start the tools.

Note that the user concept distinguishes between Database Manager operators and database users, and that you need the appropriate authorizations to work with a specific tool.

Database Manager GUI and SQL Studio

The Database Manager GUI and the SQL Studio also start if no options are specified, or if the options are incorrect or incomplete. In the logon screen, enter the user data required to log on to the database instance.

Database Manager GUI, Calling the Database Manager GUI

SQL Studio, Starting SQL Studio

Database Manager CLI

You need to connect to the database instance to use all the Database Manager CLI functions. To do this, enter the option -d <database_name> , if the database instance is on the local computer, and enter the option -n <database_server> as well if the database instance is on a remote computer. You can specify other information, such as a user name and password, as options (for example, -u).

The Database Manager CLI also supports the usage of XUSER.

If you do not specify the options required to log on to the database instance, or specify only some of them, or the details are incorrect, the Database Manager CLI is still started, and a connection to the DBM server is created, however, you are not logged on to the database instance. In this case, the Database Manager CLI can only be used to call DBM commands that are independent of the database (such as help, dbm_version, and so on).

Database Manager CLI, Opening a DBM Server Session and Logging on to the Database Manager

Loader CLI

To call the Loader CLI, you must specify the name of the database instance –d <database_name>. If you want to work in the background rather than interactively, you must use the option –b <command_file> to specify the command file. Further user data (such as user name and password) can be specified as options (for example -u) or, if required, as commands (for example, USE USER).

If the required options are not specified, or specified incorrectly, then the Loader is not started. Instead, a list of all possible options is displayed.

See also:

Call with the Loader CLI (LOADERCLI)


SQL Mode (MaxDB: Database Administration)

SQL Mode

There are several different SQL language variants. The database system can execute database applications that are written in accordance with one of the following SQL definitions:

· INTERNAL: Internal database system definition

· ANSI: ANSI standard in accordance with ANSI X3.135-1992, Entry SQL

· DB2: DB2 Version 4 definition

· ORACLE: ORACLE7 definition

You can specify your required SQL mode when you open a database session. The default SQL mode is INTERNAL.

There is restricted support for the Data Definition Language (DDL) statements of other SQL modes.

For information on the special features of SQL statements in the SQL mode ORACLE, see the documentation SQL Mode Oracle.


Timeout Value (MaxDB: Database Administration)

Timeout Value

The timeout value defines the maximum period of inactivity during a database session. The inactivity period is the time interval between the completion of an SQL statement and the next SQL statement. If the specified timeout value is exceeded, the database session is ended implicitly with a ROLLBACK (see also the ROLLBACK WORK RELEASE statement).

Timeout values are specified in seconds.

Setting the Timeout Value

The timeout value is set as follows:

· For all users, the timeout value is predefined in the database instance in the special database parameter SESSION_TIMEOUT.

· You can use a CREATE USER statement or an ALTER USER statement to define a user-specific timeout value for an individual user.

You can use a CREATE USERGROUP statement or an ALTER USERGROUP statement to define a user-specific timeout value for a group of users.

· You have the option of specifying a lower timeout value when you connect to a database instance.

The timeout value for the current database session is always the lowest value of any values specified using the procedures above.


Transactions (MaxDB: Database Administration)

Transactions

Among other things, the transaction management functions of a database system make sure that parallel transactions from multiple database sessions are processed correctly, and that they deliver the same results as if the transactions were processed sequentially.

A transaction is a sequence of sql statements that are handled by the database system as a unit, in the sense that any modifications made to the database by the sql statements are either all reflected in the state of the database, or else none of the database modifications are retained.

When you open an SQL session, you also open the first transaction. A transaction is concluded with a COMMIT or a ROLLBACK. This has the following consequences:

· When a transaction is successfully concluded with a commit, all of the changes to the database are retained.

· However, if a transaction is terminated using a rollback statement, or if it is terminated in another way, all of the changes to the database made by the transaction are rolled back.

Both COMMITs and ROLLBACKs open a new transaction implicitly.

Since the database system allows concurrent transactions to access the same database objects, locks are required to isolate individual transactions.

For information on the SQL statements that manage transactions, see the Reference Manual under Transactions.


COMMIT (MaxDB: Database Administration)

COMMIT

In a COMMIT, all the changes made by a transaction or a subtransaction are recorded in the database instance. The locks assigned to the transaction are released, and a new transaction is opened implicitly.

Changes closed with a COMMIT can no longer be reversed with a ROLLBACK.

In normal database operation, the database system performs the required COMMIT actions without user interaction. However, a COMMIT can also be explicitly requested using appropriate SQL statements (see Reference Manual under COMMIT Statement).


ROLLBACK (MaxDB: Database Administration)

ROLLBACK

In a ROLLBACK, all the changes made by a transaction or a subtransaction in the database instance are canceled. Any locks assigned to the transaction are released. All result tables generated within the current transaction are deleted implicitly and a new transaction is opened.

Changes closed with a COMMIT can no longer be reversed with a ROLLBACK.

In normal database operation, the database system performs the required ROLLBACK actions without user interaction. However, a ROLLBACK can also be explicitly requested using appropriate SQL statements (see Reference Manual under ROLLBACK Statement).


Locks (MaxDB: Database Administration)

Locks

The database system allows concurrent transactions to use the same database objects. Locks are required to guarantee that the parallel processes are synchronized and individual transactions isolated.

· Among other things, the lock behavior of the database depends on the type of lock.

· Locks can be placed on rows, tables, or the entire database catalog.

If a transaction requests too many row locks in a table, then the database system attempts to place a table lock. If this causes conflicts with other locks, the database system continues to request row locks. The limit beyond which the database system attempts to transform row locks into table locks depends on the general database parameter MAXLOCKS.

· Locks can be requested or released either implicitly or explicitly.

The more locks that are set, and the longer these stay in place, the lower the degree of parallelism possible in the database. For this reason, make sure that locks are only set if they are absolutely necessary, and that set locks are released as soon as possible.

· You can use the special database parameter REQUEST_TIMEOUT to restrict the amount of time that a user waits for a lock to be released.

Displaying Locks and Lock Requests

You can use, for example, the Database Manager GUI, to display information on current locks and lock requests.

Database Manager GUI, Displaying Database Activities

In SAP systems, you use the [image] Database Assistant to display database information, or the [image] liveCache Assistant for liveCache instances.

The system table LOCKS also contains lock information.


Type of Lock (MaxDB: Database Administration)

Type of Lock

The database system differentiates between the following locks:

· Shared lock

· Exclusive lock

· Optimistic lock

· Special locks for the metadata of the database catalog. These must, however, always be explicitly assigned.

The following table provides an overview of the possible parallel shared locks (S locks) and exclusive locks (E locks).

 | A transaction has the following type of lock
 | on a table |  | on a row |  | on the database catalog
Can another transaction | E lock | S lock | E lock | S lock | E lock | S lock
request an E lock for the table? | No | No | No | No | No | Yes
request an S lock for the table? | No | Yes | No | Yes | No | Yes
request an E lock for any row in the table? | No | No | - | - | No | Yes
request an E lock for the locked row? | - | - | No | No | - | -
request an E lock for another row? | - | - | Yes | Yes | - | -
request an S lock for any row in the table? | No | Yes | - | - | No | Yes
request an S lock for the locked row? | - | - | No | Yes | - | -
request an S lock for another row? | - | - | Yes | Yes | - | -
change the definition of the table in the database catalog? | No | No | No | No | No | No
read the definition of the table in the database catalog? | Yes | Yes | Yes | Yes | No | Yes

A lock collision exists in the cases that are marked with No; that is, after having requested a lock within a transaction, the user must wait for the lock to be released until one of the above situations or one of the situations that are marked with Yes in the matrix occurs.

The following also applies:

· If no lock has been assigned to a transaction for a data object, then a shared or exclusive lock can be requested within any transaction and the lock is immediately assigned to the transaction.

· If a shared lock has been assigned to a transaction T1 for a data object, and if no lock has been assigned to any concurrent transaction for this data object, then the transaction T1 can request an exclusive lock for this data object and the lock is immediately assigned to this transaction.

· If an exclusive lock has been assigned to a transaction for a data object, then a shared can, but need not, be requested for this transaction.


Shared Lock (MaxDB: Database Administration)

Shared Lock

One type of lock is the shared lock.

Shared locks refer to a row or a table.

Once a shared lock is assigned to a transaction for a particular data object, concurrent transactions can access the object but not modify it. Other transactions can set a shared lock, but not an exclusive lock for this object.


Exclusive Lock (MaxDB: Database Administration)

Exclusive Lock

One type of lock is the exclusive lock.

Exclusive locks refer to a row or a table.

Once an exclusive lock is assigned to transaction for a particular database object, other transactions cannot modify this object. Transactions that check for the existence of exclusive locks, or that want to set exclusive or shared locks, conflict with the existing exclusive lock of another transaction. You cannot access the locked object.


Optimistic Lock (MaxDB: Database Administration)

Optimistic Lock

One type of lock is the optimistic lock at row level.

An update operation performed by the current user on a row on which this user has set an optimistic lock is only actually performed if this row has not been changed in the meantime by a concurrent transaction. If a concurrent transaction has changed the row, then the change operations of the current user are rejected. The optimistic lock is released again in both cases.

If the update operation was successful, an exclusive lock is set for this row. If the update operation was not successful, it should be repeated after reading the row again with or without optimistic lock. In isolation level 0, an explicit lock must be specified for the new read operation. In this way, it can be ensured that the update is done to the current state and that no modifications made in the meantime are lost.

It only makes sense to use an optimistic lock if one of the isolation levels 0, 1 or 10, or 15 has been assigned. An optimistic row lock must be explicitly requested by specifying a LOCK statement. A request can conflict with an exclusive lock only. Concurrent transactions do not collide with an optimistic lock.


Requesting Locks (MaxDB: Database Administration)

Requesting Locks

Locks can be requested either implicitly or explicitly.

If you want to set explicit or implicit locks, and you are waiting too long for a lock to be released, then a message is sent to the database system. The user can then respond to this message, for example, by terminating the transaction. In this case, the database system does not execute an implicit ROLLBACK.

Requesting Locks Implicitly

You can choose the lock type by specifying an isolation level when you open the database session. The database system then requests locks implicitly during processing of an SQL statement in accordance with the specified isolation level. All other SQL statements (such as INSERT, UPDATE, DELETE) always request an exclusive lock .

Requesting Locks Explicitly

You can use the LOCK statement to assign locks to a transaction explicitly. You can specify a LOCK option in an SQL statement to lock individual rows in a table. This is possible at every isolation level.

You can use the LOCK option to temporarily change the isolation level for an SQL statement.


Releasing Locks (MaxDB: Database Administration)

Releasing Locks

The locks assigned to a transaction are usually released at the end of the transaction, making the respective database objects accessible again to other transactions.

The following rules apply:

· The locks requested by the LOCK statement are usually released when the transaction ends, provided that the COMMIT statements or the ROLLBACK statements that end a transaction do not also contain a LOCK statement.

· The length of time for which an implicit shared lock is held depends on the isolation level.

· Exclusive locks for rows that have not yet been modified and shared locks on rows can be released by the UNLOCK statement before the end of the transaction.

· Exclusive locks set implicitly cannot be released within a transaction.

· Exclusive locks on updated rows, exclusive locks that were requested by an SQL statement that leads to a change (INSERT, UPDATE, DELETE), and table blocks cannot be released within a transaction, only after the transaction has ended.


Isolation Level (MaxDB: Database Administration)

Isolation Level

The isolation level has an important role to play in the lock activities of the database system. It specifies whether locks are requested or released implicitly, and how.

The isolation level has consequences for whether concurrent transactions can be executed in parallel, and affects the consistency of the data. The lower the chosen value of the isolation level, the higher the degree of concurrency and the lower the guaranteed level of consistency. If transactions are competing for access to the same data, then different isolation levels can cause different inconsistent phenomena.

You can specify the isolation level with the CONNECT statement when, for example, you open a database session.

The following isolation levels exist:

· Isolation level 0 (uncommitted)

· Isolation level 1 or 10 (committed)

· Isolation level 15

· Isolation level 2 or 20 (repeatable)

· Isolation level 3 or 30 (serializable)

1 and 10 are just different ways of writing the same isolation level; there is no difference in meaning. The same applies to 1 and 20 and to 3 and 30.


Isolation Level 0 (MaxDB: Database Administration)

Isolation Level 0

If you specify the isolation level 0 (uncommitted), then rows are read without shared locks being requested implicitly. If a row is then read twice within a transaction, this isolation level does not guarantee that the row has the same state the second time as the first, since it could have been changed by a competing transaction between the two reads.

Furthermore, there is no guarantee that the state of a row that was read has already been recorded in the database using a COMMIT WORK statement.

When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.


Isolation Level 1 or 10 (MaxDB: Database Administration)

Isolation Level 1 or 10

If you specify the isolation level 1 or 10 (committed), then a shared lock is assigned to the transaction for a read row R1 of a table. When the next row R2 in the same table is read, the lock on R1 is released and a shared lock is assigned to the transaction for the row R2.

When you retrieve data with a QUERY statement, the database system ensures that, at the time each row is read, no exclusive lock has been assigned to other transactions for the given row. It is impossible to predict, however, whether a query statement causes a shared lock for a row of the specified table or not and for which row this may occur.

When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.


Isolation Level 15 (MaxDB: Database Administration)

Isolation Level 15

For all SQL statements, the behavior described for isolation level 1 or 10 also applies for isolation level 15. The only difference is that, with isolation level 15, shared locks are requested for all the tables addressed by the SQL statement before processing starts. If the SQL statement generates a result table that is not saved physically, then these locks are released only at the end of the transaction, or when the result table is closed. Otherwise, the locks are released directly after the SQL statement is processed.

When rows are inserted, updated or deleted, exclusive locks are assigned implicitly to the transaction for the rows concerned. These cannot be released until the end of the transaction.


Isolation Level 2 or 20 (MaxDB: Database Administration)

Isolation Level 2 or 20

If you specify the isolation level 2 or 20 (repeatable), then shared locks are requested implicitly for all the tables addressed by an SQL statement data query before processing starts.

If an SQL statement generates a result table that is not saved physically, then these locks are released only at the end of the transaction, or when the result table is closed. Otherwise, the locks are released directly after the SQL statement is processed.

The table shared lock is not assigned to the transaction in the case of SQL statements in which just one table row is processed that is determined by key specifications or by CURRENT OF <result_table_name>.

In addition, an implicit shared lock is assigned to the transaction for each row read while an sql statement is being processed. These locks can only be released with an UNLOCK statement or by ending the transaction.

When rows are inserted, updated or deleted, exclusive locks are assigned implicitly to the transaction for the rows concerned. These cannot be released until the end of the transaction. However, no locks are set for the entire table.


Isolation Level 3 or 30 (MaxDB: Database Administration)

Isolation Level 3 or 30

If you specify the isolation level 3 or 30 (serializable), then a table shared lock is implicitly assigned to the transaction for every table addressed by an SQL statement.

These shared locks cannot be released until the end of the transaction. This table shared lock is not assigned to the transaction in the case of SQL statements in which just one table row is processed that is determined by key specifications or by CURRENT OF <result_table_name>.

When rows are inserted, updated or deleted, exclusive locks are assigned implicitly to the transaction for the rows concerned. These cannot be released until the end of the transaction.


Phenomena (MaxDB: Database Administration)

Phenomena

When concurrent transactions are processed, inconsistent situations can occur. Try and avoid these situations by setting the lock behavior and isolation level of the database system accordingly. The following phenomena can occur if the same data is accessed concurrently:

· Dirty Read

A row is modified by transaction T1, and transaction T2 reads this row before T1 has been completed with the COMMIT statement. T1 then executes the ROLLBACK statement. In this case, T2 has read a row that never existed.

· Non-Repeatable Read

Transaction T1 reads a row. Transaction T2 then modifies or deletes this row, and completes the action with the commit statement. If T1 then reads the row again, it either gets the modified row or a message indicating that the row no longer exists.

· Phantom

Transaction T1 executes an SQL statement S that reads a set of rows (M) that fulfill a search condition. Transaction T2 then inserts or modifies data, and produces another row that fulfills this search condition. If T1 then executes the statement S again, the set of rows that is read differs from the set M.

This table gives you an overview of which phenomena occur in which isolation level.

 | Isolation Level 0 | Isolation Level 1 or 10 | Isolation Level 2 or 20 | Isolation Level 3 or 30
Dirty Read | + | - | - | -
Non-Repeatable Read | + | + | - | -
Phantom | + | + | + | -


User Concept (MaxDB: Database Administration)

User Concept

The database system differentiates between the following user classes:

· Database Manager operator (DBM operator)

DBM operators can work with the Database Manager to administer database instances. However, they cannot log on to the query tools.

· Database user

Database users can work with the query tools, for example, to send SQL statements to the database. However, they cannot log on to the Database Manager. One exception is the database system administrator (SYSDBA user). This user has the authorizations of a Database Manager operator.

See also:

Connecting to a Database Instance

Calling the Database Tools


Database Manager Operator (DBM Operator) (MaxDB: Database Administration)

Database Manager Operator (DBM Operator)

A Database Manager operator (DBM operator) can perform various functions of the Database Manager tool, specified by his or her properties . These functions include the control and monitoring of database instances, making backups, or restoring a database instance. The operator can log on to the Database Manager more than once, which means he or she can, for example, query information about the running database instance while functions that take a long time are still running.

You define the first DBM operator when you install a database instance. This operator can then create more DBM operators, to which he or she can assign some or all of his or her authorizations. When you use the Database Manager CLI to access the database instance, the first DBM operator is the system default. This default is used whenever no operator is specified.

The Database Manager stores the name and password of the DBM operators in uppercase characters. They can have a maximum of 18 characters (nine characters in UNICODE). Special characters are not permitted.

DBM operators are not usually database users. For example, they cannot connect to the query tools or the Loader program, since only database users can work with these programs.

The only exceptions to this rule are as follows:

· The first DBM operator
This operator has various database user rights only when accessing a database instance with the Database Manager CLI. This operator cannot create any further database users.

· The database system administrator (SYSDBA user)
This administrator is the first database user with all rights. This administrator also has the rights of a DBM operator.

Administration of the Database Manager Operators

Use the Database Manager for the administration of the Database Manager operators.

Database Manager GUI, Administration of the Database Manager Operators

Database Manager CLI, Administration of the DBM Operators


Properties of a DBM Operator (MaxDB: Database Administration)

Properties of a DBM Operator

You can change the properties of a DBM operator. A DBM operator can create other DBM operators, depending on his or her server authorizations. The operator can assign authorizations to new DBM operators, and change the authorizations of existing DBM operators.

The first Database Manager operator you create when you create a database instance has all server authorizations.

The user password of this operator cannot be changed.

The following properties can be assigned to a DBM operator:

Property | Description
PASSWORD | Password of the user
COMMENT | More detailed description of the user
DISABLED | The user is locked.
SECONDPASSWORD | A second password used to allow other people to work temporarily with a user account, for example for support purposes, without having to reveal or change the original password.
SERVERRIGHTS | Authorizations for the DBM Server program and therefore for performing actions with the Database Manager, such as administration of the DBM operators (see also Server Authorizations)

Use the Database Manager to assign the required properties and authorizations to a DBM operator.

Database Manager GUI, Changing the User Properties, Changing the Server Authorizations

Database Manager CLI, Changing DBM Operator Data


Server Authorizations (MaxDB: Database Administration)

Server Authorizations

To perform the functions of the Database Manager, the Database Manager operator (DBM operator) needs the appropriate authorizations for accessing the DBM Server and the Database Manager program.

Authorization | Name in the Database Manager GUI | Name in the Database Manager CLI
Accessing database files (read-only) | Database file access (read only) | DBFileRead
Accessing database parameters (checked write) | Parameter access (checked write) | ParamCheckWrite
Accessing database parameters (read and write) | Parameter access (read and write) | ParamFull
Accessing database parameters (read-only) | Parameter access (read only) | ParamRead
Accessing an SQL session | Access to SQL session | AccessSQL
Accessing a utility session | Access to utility session | AccessUtility
Displaying state information | Request status data | DBInfoRead
Executing operating system commands | Execute operating system commands | SystemCmd
Installation management | Installation management | InstallMgm
Loading system tables | Load the system tables | LoadSysTab
Making backups | Saving backups | Backup
Managing the DBM operators | User management | UserMgm
Restoring backups | Restoring backups | Recovery
Running the LOAD program | Execute the LOAD program | ExecLoad
Starting the database instance | Start database instance | DBStart
Stopping the database instance | Stop database instance | DBStop


Database User (MaxDB: Database Administration)

Database User

Database users can connect to a database instance, execute SQL statements, and work with database objects such as tables, views, and indexes.

To manage the database instance (for example, make backups or recoveries), you need a Database Manager operator. The database system administrator is the only database user that can log on to the Database Manager as well.

The database system uses several different database user classes. The database user class that a database user belongs to defines which database operations that user is allowed to execute.

The database user classes are as follows:

· Database system administrator (SYSDBA user)

· Database administrator (DBA user)

· DOMAIN user

· RESOURCE user

· STANDARD user

Database users can be grouped into user groups. The database system supports a role concept.

Administration of Database Users

For the administration of the database users, use the SQL statements for user authorization.


Database System Administrator (SYSDBA User) (MaxDB: Database Administration)

Database System Administrator (SYSDBA User)

The database system administrator (SYSDBA user) is the first database user . You create this user when you create the database instance. The SYSDBA user can then use the query tools to define other database users or user groups with the SQL statements for user authorization . This user can define data and database procedures and grant other database users privileges for these database objects.

The SYSDBA user also has the following properties:

· The SYSDBA user is the owner of some system tables . When system tables are loaded, the load tool logs on to the database instance as the SYSDBA user.

· The SYSDBA user is the only database user who also has DBM operator rights, more specifically all authorizations of the first Database Manager operator .

The data of this user is saved in both the Database Manager and the database.

The Database Manager stores the name and password of the database system administrator in uppercase characters. They can have a maximum of 18 characters (nine characters in UNICODE ). Special characters are not permitted.

Do not enter the character string SYSDBA as a user name, since this is a reserved SQL key word.

After you have started the database instance in the operational state ONLINE, you can change the password of the SYSDBA user with the ALTER PASSWORD statement. You can also use the Database Manager GUI to change the password (Changing a User Password).


Database Administrator (DBA User) (MaxDB: Database Administration)

Database Administrator (DBA User)

A database administrator (DBA user) is a database user. This user must be created by the SYSDBA user, for example, with the CREATE USER statement in a query tool.

DBA users themselves can create database users of the classes RESOURCE and STANDARD. They can define database objects and database procedures and grant other database users all or some DBA user privileges for these database objects.They can also group database users with identical access rights into user groups.


DOMAIN User (MaxDB: Database Administration)

DOMAIN User

The DOMAIN user is a special DBA user. This user is the owner of system tables from the database catalog.

Just like the SYSDBA user, the DOMAIN user is created when a database instance is installed. The system gives this user the user name DOMAIN automatically, with the same user password as the SYSDBA user. You can then change the user password of the DOMAIN user.


RESOURCE Users (MaxDB: Database Administration)

RESOURCE Users

RESOURCE users are database users that can be created by both the SYSDBA user and DBA users.

RESOURCE users can define data and database procedures and grant other database users privileges for these database objects.


STANDARD User (MaxDB: Database Administration)

STANDARD User

STANDARD users are database users that can be created by the SYSDBA user or the DBA user.

STANDARD users only have access to data and database procedures that were defined by other database users and for which they have been given privileges.

STANDARD users themselves can define views, synonyms, and temporary tables.


User Groups (MaxDB: Database Administration)

User Groups

The database system administrator (SYSDBA user) or a database administrator (DBA user) can combine database users in user groups.

A user group can either be assigned to the database user class RESOURCE or to the database user class STANDARD.

All database objects defined by members of a certain user group can be identified by the user group name. The owner of a database object of this type is the user group, and not the individual database user. However, each member of a user group can work with the database objects of his or her user group as if they were his or her own database objects.

Privileges can only be granted or removed from the user group as a whole and not from individual members of the group.

For information on the syntax of the SQL statements for user group management, see the Reference Manual under Authorization.


Security Concepts (MaxDB: Database Administration)

Security Concepts

Pay attention to the following notes on the security of your database system:

· You can achieve high availability of your system by using robust hardware and software, specifying appropriate log settings, and implementing high availability strategies, such as standby databases and hot standby.

· Easy-to-use database tools , such as the Database Manager , enable you to back up and recover your data in accordance with your backup strategy.

· Some inconsistencies are corrected automatically when you restart the database instance.

· You can find any errors in database structures (B* trees) by making regular checks on these structures. If there are serious inconsistencies, the database instance must be recovered in the same way you recover it after a disk failure.

See also:

SAP Security Guide: MaxDB


Availability (MaxDB: Database Administration)

Availability

You can use the appropriate features of your hardware, operating system, or database to optimize the availability of a database instance. Note the following recommendations:

· Locate every volume type on a different disk.

· In a production system, the log area should always be mirrored with hardware-based tools. Use RAID 5 or RAID 1 systems. Make sure that your RAID controller delivers good write performance, and that a cache is backed up to the disk even in a power outage.

· If you cannot use hardware-based mirroring, then you can set the log mode of the database instance so that it uses software-based mirroring.

· Use normal log backups. Do not allow the log area to be overwritten.

To make sure there is always enough space to write the log entries, make regular log backups.

· Always have redo log management activated.

· If you want to ensure a high standard of availability, we recommend using RAID-5 or RAID-1 configurations for the data area. A disk crash and change will then not affect the operation of the database, if the RAID system is able to perform a corresponding recovery procedure.

· In a production system on UNIX, data volumes and log volumes should be located on raw devices. Raw devices achieve better performance, and can be more securely controlled in the event of a system failure.

· When using fault-tolerant hardware, it is best to only use the same type of hardware when you want to extend the capacity. For example, only extend RAID-5 systems with RAID-5 systems and mirror disks with mirror disks.

See also:

High Availability


Log Settings (MaxDB: Database Administration)

Log Settings

The following log settings are possible:

· Log mode: Set the log mode accordingly to use software-based mirroring of the log area.

· Overwrite mode for the log area: You can set the overwrite mode so that the log area is overwritten cyclically, without the log entries being backed up first.

· Activate or deactivate redo log management: In very special situations, you can deactivate redo log management temporarily to prevent any more redo log entries being written. However, deactivating redo log management places the security of your system at serious risk, and should be considered only under exceptional circumstances.

For more information about logging, see the documentation Background Knowledge.


Log Mode (MaxDB: Database Administration)

Log Mode

You can use this log setting to specify whether the log area is mirrored using software-based mirroring. Use this setting to increase the availability of your database instance when no hardware-based mirroring is possible.

Since software-based mirroring has a negative effect on the performance of your database system, we recommend that you use hardware-based mirroring.

Single Log Area

By default, the database instance uses only one log area.

Even if the database instance only uses one log area, you can still guarantee a high level of security for your database system, since RAID-5 or RAID-1 hardware-based mirroring is usually implemented. RAID systems offer a good level of security for production use of the database.

Mirroring the Log Area

If you cannot use hardware-based mirroring, then you can use database methods to mirror the log area.

When you use software-based mirroring, the database instance uses the two log areas as follows:

· Data is written to both log areas in parallel.

· During a restart or log backup, the log entries are only read from one log area, the primary log area.

· When you use standard log backups, neither of the two log areas can be overwritten until the log entries of the primary log area have been backed up.

· If access problems occur in the primary or secondary log area, the log volume in question is marked as BAD and the database instance is switched to the operational state OFFLINE.

· You can restore the defective log volume of a log area in the operational state ADMIN (see Restoring a Mirrored Log Volume). In this process, the complete contents of the relevant log volume are copied from the other log area to the defective log volume. This ensures that the database instance does not have to be restored after a disk error that led to the loss of a log volume, as the content of the log volume was mirrored.

Procedure

Use the Database Manager to configure the additional log volumes that are required, and to set the log mode.

Database Manager GUI, Changing Log Settings

Database Manager CLI, Changing Volume Parameters


Overwrite Mode for the Log Area (MaxDB: Database Administration)

Overwrite Mode for the Log Area

You can use this log setting to control whether the log area is overwritten cyclically without the log entries being backed up.

Normal Log Backups

By default, the log area can be overwritten only if the appropriate log entries have been backed up. For this reason, you must make log backups at regular intervals.

The log entries of the log area and the log backups are then available if you need to restore the database. As long as they are complete, you can use the data backup, log backups and the log entries in the log area to recover the database up to a chosen point in time.

If overwrite mode was activated and you then change back to normal log backups, you must then make a complete data backup.

Overwriting the Log Area Without a Log Backup

The log area is overwritten cyclically, and you do not need to back up the log entries.

This interrupts the log backup history. If you need to recover the database, only the log entries in the log area are available. This usually means that you cannot recover your database instance up to the last COMMIT before the crash, or to any other time; instead, you can restore it only to the state it had at the time of the last data backup.

You can only recover the database to a time of your choice if all the log entries written after the data backup exist in the log area (which means that the log area has not been overwritten since the data backup).

Only activate the overwrite mode if you are happy with only being able to recover your system to the state it had when the last available data backup was made.

Procedure

You can use the Database Manager GUI to set the overwrite mode (see Changing Log Settings).


Activating or Deactivating Redo Log Management (MaxDB: Database Administration)

Activating or Deactivating Redo Log Management

One possible log setting that you can make is activating or deactivating redo log management. Redo log management is activated by default.

Deactivate redo log management only in special cases, and then only for a fixed period of time.

When you deactivate redo log management, the log writer no longer writes any redo log entries to the log areas. This interrupts the log backup history, which means you have no log entries available for this period if you want to recover the database. In rare cases, it may be a good idea to deactivate redo log management, for example, when you initialize a database instance.

Procedure

1. Transfer the database instance to the operational state ADMIN.

2. To activate or deactivate redo log management, you can use, for example, the Database Manager GUI, as described under Changing Log Settings.

3. If you deactivate redo log management, and then reactivate it, you must then make a complete data backup.


Backup (MaxDB: Database Administration)

Backup

Make the following regular backups as specified in your backup strategy:

· Data backups

· Log backups

All backups can be made to an individual backup medium; data backups can also be made to a group of parallel backup media.

Follow the naming conventions for backup media.

Each backup is given a unique backup ID automatically.


Backup Strategy (MaxDB: Database Administration)

Backup Strategy

One key element of the security concept for your database system is the making of regular backups of your data.

Note the following recommendations when designing your backup strategy:

· Perform a complete data backup on each day of production.

· If you cannot or do not want to make a complete data backup every day, you should at least make an incremental data backup on each day of production use of the database.

Note that, if you are restoring data, the more up-to-date the data backup is, the fewer log entries need to be reproduced.

· Activate automatic log backups (autosave log mechanism).

· If you do not use automatic log backups, then make regular checks to see whether there is enough memory in the log area. Also make at least one interactive log backup on each day of production use of the database.

If new log entries cannot be written to the log area because there is not enough space, the database stops.

· Archive the version files written during a log backup to a medium of your choice at regular intervals. Once the files have been archived successfully, you can delete the archived version files, so ensuring that there is enough space available in the directory for version files.

· Tapes containing backups should not be directly overwritten with the next backup. If you retain, say, the last four backup generations, it may be possible to use an older backup if a media failure occurs.


Data Backup (MaxDB: Database Administration)

Data Backup

When you back up data, you back up content from the data volumes , as well as the database parameters required for a recovery to a backup medium of your choice.

The following data backup types exist:

· In a complete data backup, all pages of the data volumes are backed up.

· In an incremental data backup, all pages of the data volumes are backed up that have changed since the last complete data backup.

You can perform complete and incremental data backups in the operational mode ONLINE or ADMIN. You can also back up to a group of parallel backup media . Data backups are always consistent.

If errors occur, you may need log backups in addition to the data backups, to restore the required state of the database instance.

You cannot start an incremental data backup during a complete data backup.

Procedure

Use the Database Manager or, in SAP systems, the DBA Planning Calendar to perform the backups.

Database Manager GUI, section Backup Procedures

Database Manager CLI, section Commands for Backups

Database Administration in CCMS: MySQL MaxDB, [image] DBA Planning Calendar

Database Administration in CCMS: SAP liveCache, [image] Backing Up liveCache


Log Backup (MaxDB: Database Administration)

Log Backup

In a log backup, the contents of the log area are copied to version files or backed up using an external backup tool.

If you use version files, a version file is generated for each log segment of the log area.

The space in the log area that was originally used by the backed up log entries is available to be overwritten again after the log backup.

You can use the following log backup types:

· Automatic log backup

· Interactive log backup


Automatic Log Backup (MaxDB: Database Administration)

Automatic Log Backup

To guarantee the security and availability of the data in your database instance, we recommend that you activate automatic log backups.

If automatic log backup is activated, a log segment of the log area is saved as soon as it has been filled. This log segment is then available again to be overwritten. This mechanism ensures that overflows in the log area are practically impossible.

We particularly recommend activating automatic log backups for all database instances where many changes are made to the data, leading to a high volume of log entries. In this way, constant monitoring of the fill level of the log area is not necessary.

You can only perform automatic log backups in the operational state ONLINE. Only version files are allowed as a backup medium. These files must be archived at regular intervals (see Backup).

As long as automatic log backup is active, you cannot start an interactive log backup. However, you can perform a data backup at the same time.

Procedure

Use the Database Manager or the DBA Planning Calendar in SAP systems to activate and deactivate automatic log backups.

Database Manager GUI, Activating and Deactivating the Automatic Log Backup

Database Manager CLI, Backing Up the Database Instance

Database Administration in CCMS: MySQL MaxDB, [image] Activating Automatic Log Backup

Database Administration in CCMS: SAP liveCache, [image] Backing Up liveCache


Interactive Log Backup (MaxDB: Database Administration)

Interactive Log Backup

You can use interactive log backups to back up all the pages of the log area that have been written since the last log backup.

If you back up the log entries in version files, a version file is also generated for the last log segment, which may not be full.

You can perform interactive log backups in the operational state ONLINE or ADMIN.

You cannot perform any other backup while the interactive log backup is running.

Prerequisites

A full data backup of the current database instance has been created at some point.

Procedure

Use the Database Manager or, in SAP systems, the DBA Planning Calendar to perform interactive log backups.

Database Manager GUI, section Backup Processes

Database Manager CLI, Commands for Backing Up and Archiving

Database Administration in CCMS: MySQL MaxDB, [image] DB Planning Calendar

Database Administration in CCMS: SAP liveCache, [image] Backing Up liveCache


Version Files of the Log Backup (MaxDB: Database Administration)

Version Files of the Log Backup

A log backup copies the contents of the log area to files. One version file is generated for each log segment. The names of the generated version files are made up of the file name specified when the backup medium was defined and a sequential number specified by the database system.

Archive the version files at regular intervals in accordance with the recommended backup strategy. To do this, copy the files to another backup medium, either manually or with external backup tools.

Archiving Version Files

To archive the version files with external backup tools, use the Database Manager CLI.

Database Manager CLI, Archiving the Version Files of the Log Area


Backup History (MaxDB: Database Administration)

Backup History

Information on all actions that have been carried out that relate to backing up and restoring the database instance are registered in chronological order in the backup history.

The system writes the backup history to the log file dbm.knl. This file is in the database instance’s run directory.

Displaying the Backup History

Use the Database Manager or, in SAP systems, the Database Assistant to display the backup history.

Database Manager GUI, Displaying the Backup History

Database Manager CLI, Commands for the Backup History

Database Administration in CCMS, [image] Result of an Action


Backup ID (MaxDB: Database Administration)

Backup ID

The database system automatically gives each backup a backup ID to allow them to be identified. This label uniquely identifies the backups made since the database instance was created or last initialized. If you use external backup tools, then the backup is given an external backup ID.

The backup ID consists of the backup type <save_type> (complete or incremental data backup or log backup) and a sequential number <sequence_no>. Data backups are numbered sequentially, regardless of whether they are complete or incremental. Log backups are numbered in a separate sequence.

After the backup, the backup ID is written to the Database Manager log file dbm.knl. You can display all the contents of this file in the backup history. When you recover data, you can view the backup history with the Database Manager and select the required backup using its backup ID.

If the backup medium is a tape, write the backup ID on the sticker of the tape at the end of the backup.

Formal Description of the Backup IDs

<backup_id> ::=<save_type>_<sequence_no>

<save_type> ::= DAT | PAG | LOG

<sequence_no> ::= <number>


External Backup ID (MaxDB: Database Administration)

External Backup ID

When you use an external backup tool to back up or unload data, then each backup or data stream gets an external backup ID. If a backup was created using a group of parallel backup media, every part of this backup has its own external backup ID.

The Database Manager writes the external backup ID to the log files of the Database Manager, dbm.knl and dbm.ebf. This ID is also displayed in the backup history.

The Loader writes the external backup ID to the Loader log file and to the system tables relevant to the Loader.

The external backup ID is needed when restoring or loading data, to request the required backup or data stream.


Backup Medium (MaxDB: Database Administration)

Backup Medium

For backups and recoveries, you need a backup medium. Data is backed up to this medium, from where it can then be restored again. Backup media include files, tapes, autoloaders, and pipes.

Define separate backup media for each database instance. You can combine multiple backup media in a group of parallel backup media.

Recommended Backup Media

Note the following points:

· The recommended backup media for data backups are tape and autoloader. Data may also be backed up to pipes or files.

· The only valid media type for log backups are files; version files are created automatically.

· Only use pipes if you are working with an external backup tool.

· Follow the naming conventions for backup media.

· For security reasons, archive your files and version files on a separate medium.

Follow the manufacturer's recommendations on how frequently backup media should be used.

Defining Backup Media

Use the Database Manager or, in SAP systems, the Database Assistant to define the backup media.

Database Manager GUI, section Managing the Backup Media

Database Manager CLI, Commands for the Backup Media

Database Administration in CCMS: MySQL MaxDB, [image] Backup Media

Database Administration in CCMS: SAP liveCache, [image] Backup Media


Group of Parallel Backup Media (MaxDB: Database Administration)

Group of Parallel Backup Media

To speed up backups and recoveries, you can make backups to multiple backup media in parallel, and restore data from parallel backup media. For this purpose you define a group of parallel backup media that is identified by a single media name.

The general database parameter MAXBACKUPDEVS specifies the maximum possible number of files or tape devices in a group of parallel backup media.

Defining a Group of Parallel Backup Media

Use the Database Manager or, in SAP systems, the Database Assistant to define a group of parallel backup media.

Database Manager GUI, Creating a Group of Parallel Backup Media

Database Manager CLI, Creating or Changing a Backup Medium

Database Administration in CCMS: MySQL MaxDB, [image] Backup Media

Database Administration in CCMS: SAP liveCache, [image] Backup Media


External Backup Tool (MaxDB: Database Administration)

External Backup Tool

You can back up and restore, and unload and load data with external backup tools and external backup media.

The database system supports the use of the following external backup tools:

· TSM (IBM/Tivoli)

· NetWorker (Legato)

· All backup tools that support Backint for MaxDB

· All backup tools that support Backint for Oracle

These include the following backup tools: ARCserve, Backup Express, dbBRZ for R/3, DBVAULT, DoroStore, EASY_BASE, EMC, EPOCH, FDR/UPSTREAM, HIBACK, HSMS-CL Backint, NetBackup, NetVault, NetWorker, Omniback, Seagate Backup, SESAM, Solstice Backup, Sys-Save, TIME NAVIGATOR for R/3, Tivoli

If you want to use a different backup tool, contact the support team.

Depending on the platform, it may also be possible to address TSM using the Backint for Oracle interface.

For information on the requirements that need to be met by a Backint for MaxDB interface, see the documentation Backint for MaxDB.

Procedure

· Use the Database Manager to back up and restore the database instance. When defining the backup media, follow the naming convention. The backups created receive an external backup ID.

· To load or unload data, use the Loader and follow the procedure described in Unloading or Loading with External Backup Tools.

· For information about setting up the external backup tools, see the documentation Connecting External Backup Tools.


Naming Conventions for Backup Media (MaxDB: Database Administration)

Naming Conventions for Backup Media

Note the following naming conventions when defining backup media:

· If you are using an external backup tool, the media names must begin with defined character strings:

Character String | Backup Tool
ADSM | TSM (IBM/Tivoli)
BACK | Backup tool with the interfaces Backint for Oracle or Backint for MaxDB
NSR | NetWorker (Legato)

· If you are not using an external backup tool, choose a media name that does not begin with any of these character strings.


Restore (MaxDB: Database Administration)

Restore

By importing backups from a backup medium, you can restore a database instance after a crash or an error, or restore it to a previous state.

Usually, a complete data backup is imported first, and then, if necessary, additional incremental data backups and log backups from the backup history. You can import data backups from a group of parallel backup media to reduce the restore time.

When you restore data, any existing log entries may also be read from the log area. In certain circumstances, you may therefore need to initialize the database instance before restoring the data. This then forces the deletion of the log entries in the log area. You can then import the required backups.

Procedure

Use the Database Manager to perform the restore.

Database Manager GUI, Restoring Data

Database Manager CLI, Commands for Restoring

You may also then have to restore indexes.

Database Manager GUI, Restoring the Indexes After a Database Restore

Database Manager CLI, Recreating a Damaged Index


Savepoint (MaxDB: Database Administration)

Savepoint

The system carries out a backup action at regular intervals for the most important database information. This backup action is known as a savepoint.

It writes all changed pages held in the data cache to the data area.

Among other things, the data cache also contains the undo log files. These files are used, for example, to roll back non-committed transactions during a restart.

See also Logging in the documentation Background Knowledge.


Restart (MaxDB: Database Administration)

Restart

When the database instance is restarted, the information from the last savepoint and the log entries are used to roll forward the effects of committed transactions to the data volumes and roll back the effects of open transactions. Any changed database parameters take effect after the restart.

If the database fails (for example, as the result of a power failure), and the volumes of the database instance were fully functioning, the database system performs a restart.

See also the descriptions of how to use log entries for restarts or recoveries in the Background Knowledge documentation.


Checking the Database Structures (MaxDB: Database Administration)

Checking the Database Structures

You have the following options for checking the database structures of your database instance:

· Checking the database structures for all tables and indexes (CHECK DATA)

· Checking the database structures for selected tables (CHECK TABLE)

Checking a database structure takes a long time. You should therefore only schedule the check at times when there is a low database load (on a weekend, for example).

Check the database structure as infrequently as possible, however, at least once during a backup history. Also make sure that you remove a backup from the backup history only if a database structure check was performed after the backup was made.

Checking the Database Structures for All Tables and Indexes (CHECK DATA)

You can perform this database structure check in the operational state ADMIN or ONLINE. The B* trees of the tables and indexes are checked. In the case of the database instance type liveCache, the corresponding liveCache structures are also checked.

If a data page flagged as BAD is found more than once when the database instance is ONLINE, then the corresponding B* tree or liveCache structure is also flagged as BAD. You can clean up this situation by checking the database structure.

If you check the database structure in the operational state ADMIN, any pages that are no longer referenced are taken out of the Converter.

Procedure

Database Manager GUI, section Checking Database Structures

Database Administration in CCMS: MySQL MaxDB, [image] Scheduling a Database Structure Check

Database Administration in CCMS: SAP liveCache, section [image] Checking Database Structures

Checking the Database Structures for Selected Tables (CHECK TABLE)

You can make this database structure check in the operational state ONLINE only. You can check individual tables.

If a data page flagged as BAD is found when the database instance is ONLINE (and hence a B* tree flagged as BAD), then you can clean up this situation by checking the database structure.

Procedure

· Checking a table (OLTP and liveCache instances)
Database Administration in CCMS, section [image] Tables/Views

· Checking all tables (OLTP instances only)
Database Administration in CCMS: MySQL MaxDB, section [image] Scheduling a Database Structure Check


Version Notation (MaxDB: Database Administration)

Version Notation

The versions of the database software are specified according to the version notation
<major>.<minor>.<cl>.<build>.

The specified numbers have the following meanings:

major | Single digit version number
minor | Single digit version number
cl | Two digit correction level
build | Two digit build number

In a technical context, you can also see the following notation:
<major>.<minor>.<cl> Build <build>

In this case, the build number is given with three digits.

7.4.03.30 and 7.4.03 Build 030 mean database version 7.4,
correction level 3, and build number 30.


Technical Specifications (MaxDB: Database Administration)

Technical Specifications

The following table lists the restrictions and maximum values that apply to the database system.

Size of the database instance (total of the data volumes) | 32 TB (with 8 KB page size)
Number of data volumes in each database instance | Depends on the special database parameter DEVNO_BIT_COUNT, default: 256
Size of a data volume | Depends on the number of data volumes, default: 128 GB
Size of the log area | 32 TB
Maximum length of an SQL statement | ³ 16 KB (default 64 KB), defined by a support database parameter
Length of a label | 32 characters
Numeric precision | 38 digits
Number of tables | Unlimited
Number of columns in each table (with KEY) | 1024
Number of columns in each table (without KEY) | 1023
Number of primary key columns in each table | 512
Number of columns in an index | 16
Number of triggers in each basis table | 3
Number of indexes for each table | 255
Number of referential CONSTRAINT definitions (foreign key dependencies) for each table | Unlimited
Number of columns in a referential CONSTRAINT definition (foreign key dependency) | 16
Number of references in each table | Unlimited
Total of internal lengths of all key columns | 1024 bytes
Total of internal lengths of all columns belonging to an index | 1024 bytes
Internal length of a LONG column | 2 GB
Number of rows in each table | Limited by the size of a database
Internal length of a table row | 8088 bytes
Number of columns in a SELECT statement | 1023
Number of columns in an INSERT statement | 1024
Number of columns in a results table | 1023
Number of join tables in a SELECT statement | 64
Number of columns in an ORDER or GROUP clause | 128
Length of the columns in an ORDER or GROUP clause | 1020 bytes
Nested trigger levels | Unlimited
Nested subqueries | 127
Number of join conditions in a WHERE clause of a SELECT statement | 128
Number of correlated columns in an SQL statement | 64
Number of correlated tables in an SQL statement | 16
Number of parameters in an SQL statement | 2000


Supported Operating Systems and Platforms (MaxDB: Database Administration)

Supported Operating Systems and Platforms

The database version 7.5 supports the following operating systems and platforms:

· Compaq Tru64 Unix (Alpha)

· HP-UX (HP-PA)

· IBM AIX (pSeries)

· Linux (i386, ia64)

· SUN Solaris (SPARC)

· Microsoft Windows 2000 (i386)

· Microsoft Windows XP (i386)

· Microsoft Windows Server 2003 (i386, ia64)

The database instance type SAP liveCache does not support Windows XP.


Support (MaxDB: Database Administration)

Support

You can obtain support for your database system in the following ways:

· Online support in the mailing list maxdb@lists.mysql.com is based on mutual support between MaxDB users and is free of charge.

Direct your queries and problems to this mailing list in an e-mail. Both the database development team and members of the Open Source community can then reply to you.

Online support does not guarantee fixed response times. However, the development team continually monitors the correspondence in the mailing list.

· If you use the database system in an SAP application, then your support agreement with SAP provides you with access to the entire SAP AG support infrastructure.

· If you use the database system in other applications (non-SAP applications), then you can conclude a support agreement with MySQL.

· If you use the database in both SAP applications and non-SAP applications, then SAP AG provides you with support for the SAP applications, and MySQL AB provides you with support for the other applications.


Using Web PTS to Search for Known Problems (MaxDB: Database Administration)

Using Web PTS to Search for Known Problems

To search for known errors in MaxDB/SAP DB software, use the Web Based Problem Tracking System (Web PTS).

You can access Web PTS at the address http://www.sapdb.org/webpts.

See also:

Web Based Problem Tracking System


Overview of the Documentation (MaxDB: Database Administration)

Overview of the Documentation

The following tables provide an overview of the available documentation.

Installation

Title | Explanation
Database Software Installation Guide | Standard installation and uninstallation of all the database software
Web Tools Installation Guide | Installation of the MaxDB Web Tools
Connecting External Backup Tools | Configuring the MaxDB software to use various external backup tools
Installation Manual | Installation, update, and uninstallation of installation profiles and individual database software components, updates of database instances, including software
SAP Web Application Server Installation on UNIX: MySQL MaxDB | Installation of an SAP system on UNIX, available only to SAP customers on the SAP Service Marketplace
SAP Web Application Server Installation on Microsoft Windows: MySQL MaxDB | Installation of an SAP system on Microsoft Windows, available only to SAP customers on the SAP Service Marketplace
SAP Web Application Server: Homogeneous and Heterogeneous System Copy | Copy of the SAP system, available only to SAP customers on the SAP Service Marketplace

Basic Information

Title of the Documentation | Explanation
Database Administration | Introduction to the database system: architecture, directory structure, database parameters, database tools, user and security concepts, overview of the documentation, terminology, and so on.
Reference Manual | SQL statements and their syntax, system tables, special features of the SQL mode ORACLE
Messages | List of all messages
Background Knowledge | Background knowledge about the database system, such as the log concept, B* trees, standby databases
SAP Security Guide: MySQL MaxDB | Recommended security measures for the database system
High Availability for the MySQL MaxDB Database | Conditions for guaranteeing the high availability of a MaxDB database instance in an SAP system
User Manual: SAP liveCache | Information on monitoring SAP liveCache

Tools

Title | Explanation
Database Manager Database Manager GUI Web DBM Database Manager CLI | Creating and managing database instances Graphical user interface Web-based user interface Command line-oriented user interface
Database Analyzer | Analysis of the performance of database instances
Loader | Loading and unloading data
Query Tools SQL Studio Web SQL Studio | Data queries and data processing Graphical user interface Web-based user interface
WebDAV GUI | Using a database to store XML documents, accessing XML documents with WebDAV, indexing

Interfaces

Title | Explanation
C/C++ Precompiler Manual | Description of the C/C++ Precompiler
ODBC Manual | Basics and special features of the MaxDB ODBC driver
JDBC Manual | Basics and special features of the MaxDB JDBC driver
Perl Manual | Description of the programming interfaces SQL, Database Manager and Loader for programming database applications with the Perl script language
Python Manual | Description of the programming interfaces SQL, Database Manager and Loader for programming database applications with the Python script language
Backint for MaxDB | Description of the Backint for MaxDB interface for external backup tools

Development

Title | Explanation
Development Environment | Using the development environment for creating MaxDB software
Source Code for Tools | Installing source code and creating software using the examples of the Database Manager GUI and SQL Studio
Web Based Problem Tracking System | Web interface for the Problem Tracking System (PTS) for documenting problems with the database software

Database Administration in CCMS

Title | Explanation
Database Administration in CCMS: MySQL MaxDB | Using the SAP system to analyze and monitor a MaxDB database instance, scheduling actions, alert monitoring
Database Administration in CCMS: SAP liveCache | Using the SAP system to analyze a liveCache database instance, alert monitoring

Accessing the Documentation

You can access the documentation in the following ways:

· Documentation for Open Source users at the address http://www.mysql.com/documentation

· Documentation for SAP systems in the Help Portal at http://help.sap.com

Choose SAP NetWeaver ® Server <release> <language> ® SAP NetWeaver ® Application Platform ® Databases ® MySQL MaxDB.

· liveCache documentation for SAP systems in the Help Portal at http://help.sap.com

Choose SAP NetWeaver ® Server <release> <language> ® SAP NetWeaver ® Application Platform ® Databases ® SAP liveCache.

· High availability documentation for MySQL MaxDB in SAP systems in the Help Portal at http://help.sap.com

Choose SAP NetWeaver ® <release> <language> ® SAP-NetWeaver ® Solution Life Cycle Management ® SAP High Availability ® Database High Availability ® High Availability for the MySQL MaxDB Database.

· Installation guides for SAP solutions on the SAP Service Marketplace (available to SAP customers only)

¡ Guides for the installation of MaxDB instances:

At the address http://service.sap.com/instguides, choose SAP NetWeaver in Detail ® Solution Life-Cycle Management ® Installation ® Installation and Upgrade Guides ® SAP Web Application Server ® <release> ® SAP Web Application Server Installation on <operating_system>: MySQL MaxDB

¡ Guides for the installation and upgrade of SAP liveCache instances:

At the address http://service.sap.com/instguides, choose SAP NetWeaver in Detail ® Solution Life Cycle Management ® Installation ® Installation & Upgrade Guides ® mySAP SCM ® Using SAP SCM 4.1Server... ® Upgrade Information ® Upgrade for SAP SCM 4.1: SAP liveCache 7.5


SAP liveCache and CCMS Documentation

Component documentation SAP liveCache and CCMS Documentation

All documentation on SAP liveCache, and the administration of MaxDB database systems (formerly SAP DB) in the Computing Center Management System CCMS, is relevant for SAP customers only. Therefore, you find these documents exclusively in the SAP Help Portal at http://help.sap.com under the following paths:

-> SAP NetWeaver -> SAP Web Application Server -> Release SAP Web Application Server 6.30/English -> SAP Library -> SAP NetWeaver Components -> SAP liveCache
-> liveCache User Manual
or
-> Database Administration in CCMS: liveCache

-> SAP NetWeaver -> SAP Web Application Server -> Release SAP Web Application Server 6.30/English -> SAP Library -> SAP NetWeaver Components -> SAP DB
-> Database Administration in CCMS OLTP


Variables (MaxDB: Database Administration)

Variables

The table below contains a list of the variables and example data used throughout this documentation.

Variable | Description | Examples Used
<arch> | Name of the operating system architecture in the path specifications |
<backup_medium> | Backup medium | CPLBM (complete data backup) INCBM (incremental data backup) LOGBM (log backup)
<build> | Build number of the database software |
<database_name> | Database name | HOTELDB
<database_server> | Name of the computer on which the database instance is installed | GENUA PARMA
<database_user> | Database user | MONA DAVID BORIS
<database_user_password> | Password of the database user | RED BLUE PINK
<db_instance_type> | Database instance type |
<dbm_user> | Name of a Database Manager operator | OLEG
<dbm_user_password> | Password of the Database Manager operator | MONDAY
<dependent_path> | Location of the server software that is dependent on the database version (see Database Directories) |
<domain_user> | Name of the DOMAIN user | DOMAIN
<domain_user_password> | Password of the DOMAIN user | FIRST
<file_name> | File name |
<first_dbm_user> | Name of the first Database Manager operator | DBM
<first_dbm_user_password> | Password of the first Database Manager operator | DBM
<group> | UNIX/Linux: Name of the group of the database software |
<independent_data_path> | Location of the data, configuration, and run directories of database instances and applications (see Database Directories) |
<independent_program_path> | Location of the programs and libraries shared by the database instances and applications (see Database Directories) |
<inst_path> | Installation path |
<inst_profile> | Name of the installation profile |
<os_user> | Name of the operating system user | ANNA
<os_user_password> | Password of the operating system user | MAY
<os> | Name of the operating system in the paths |
<owner> | UNIX/Linux: Name of the owner of the database software |
<package_directory> | Directory where the software package is located after it has been installed |
<package_name> | Logical name of the software package |
<password> | Password of the user |
<path> | Specified path |
<program_path> | Standard Microsoft Windows directory for the user software (for example, C:\Program Files) |
<server_name> | Name of the computer |
<sysdba_user> | Name of the SYSDBA user | DBA
<sysdba_user_password> | Password of the SYSDBA user | DBA
<user_key> | Key name of the XUSER entry | SAMPLEKEY
<user_name> | Name of the user |
<version> | Version number in accordance with the four-digit version notation |
<web_server> | Name of the computer on which the web server is installed |


Terms (MaxDB: Database Administration)

Terms

After image | Application data | Automatic log backup
Availability |  |
B* tree | Backup history | Backup ID
Backup medium | Backups | Before image
Cache | Catalog | Catalog cache
COMMIT | Complete data backup | Configuration file
Console | Converter |
Data area | Data backup | Database
Database administrator | Database Analyzer | Database catalog
Database consistency | Database console | Database directories
Database files | Database instance | Database instance type
Database kernel | Database Manager | Database Manager CLI
Database Manager GUI | Database name | Database parameters
Database session | Database structure | Database structure check
Database system | Database tools | Database trace
Database user | Data cache | Data page
Data volume | Data writer | DBA user
DBMCLI | DBMGUI | DBM operator
DBM Server | Dev thread | Directory structure
Documentation | DOMAIN |
Exclusive lock | External backup ID | External backup medium
External backup tool |  |
Garbage Collector | Group of parallel backup media |
History file | Homogeneous system copy | Hot standby
Incremental data backup | Instance type | Interactive log backup
Interfaces | I/O buffer cache | Isolation level
Kernel | Kernel variant |
Language support | liveCache | Load balancing
Loader | Loader Server | Loading data
Lock | Log area | Log backup
Log file | Logging | Log mode
Log queue | Log segment | Log settings
Log volume | Log writer |
Mapchar sets | Multiprocessor configuration |
Naming conventions for backup media | Normal log backups |
OLTP | Online logging | Operational state
Optimistic lock |  |
Page | Pager | Parallel backup
Password | Performance | Programming interfaces
Query tools |  |
Redo list | Redo log entry | Redo log file
Redo log management | Redo Log Manager | RESOURCE
Restart | Restore | Role
ROLLBACK | Run directory |
Savepoint | Server authorizations | Server task
Session | Shared lock | Special threads
SQLDBC | SQL lock | SQL mode
SQL Optimizer | SQL Studio | Standby database
Support | SYSDBA | System tables
Task | Task state | Thread
Timeout value | Timer task | Trace writer task
Transaction | Transaction file | Transaction list
Undo log entry | Undo log file | Undo log management
UNICODE | Unloading data | User
User data | User group | User kernel thread
User properties | User task | Utility task
Variables | Version file | Version notation
Volume |  |
WebDAV GUI | Web DBM | Web Server
Web SQL Studio | Web Tools |
XCONS | XPU | XUSER
X Server |  |


Reference Manual

This document outlines the syntax and semantics of the SQL statements of the MySQL MaxDB database system. The syntax notation used in this document is BNF.

An SQL statement performs an operation on the database instance. The parameters used are host variables of a programming language in which the SQL statements are embedded.

Fore general information on the database system, see the database administration documentation.

Basic Elements

SQL Statements: Overview

Data Definition

Authorization

Data Manipulation

Data Query

Transactions

Statistics

Terms and Concepts

Syntax List

System Tables

SQL Mode ORACLE

Other Documentation

Technical Specifications


Basic Elements (MaxDB: Reference Manual)

Basic Elements

Character

Literal

Token

Names

Column spec

Parameter spec

Specifying values

Date and time format

String specification

Key specification

Expression

Predicate

Search condition

Functions: Overview

Function

Set function


Character (MaxDB: Reference Manual)

Character

A character is an element of a character string or keyword .

Syntax

<character> ::= <digit>
             | <letter>
             | <extended_letter>
             | <hex_digit>
             | <language_specific_character>
             | <special_character>

digit , letter , extended_letter , hex_digit , language_specific_character , special_character


Digit (MaxDB: Reference Manual)

Digit

A digit is a character .

Syntax

<digit> ::= 0 | 1 | 2 | | 3 | 4 | 5 | 6 | 7 | 8 | 9


Letter (MaxDB: Reference Manual)

Letter

A letter is a character .

Syntax

<letter> ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
| a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z


Extended letter (MaxDB: Reference Manual)

Extended letter

An extended letter is a character .

Syntax

<extended_letter> ::= # | @ | $


hex_digit (MaxDB: Reference Manual)

hex_digit

A hex_digit is a character .

Syntax

<hex digit> ::=
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
| A | B | C | D | E | F
| a | b | c | d | e | f


language_specific_character (MaxDB: Reference Manual)

language_specific_character

A language-specific character is any letter that occurs in a northern, southern, or central European language and is not contained in the list of letters.

German umlauts: ä, ö, ü

French letters with a “grave” accent.

If you have installed a UNICODE-enabled database, a language-specific character is a character that is not included in the ASCII code list from 0 to 127.


Special character (MaxDB: Reference Manual)

Special character

A special character is any character that is not contained in the following list:

  • digit
  • letter
  • extended_letter
  • hex_digit
  • language_specific_character
  • Characters that indicate the end of a line in a file


Literal (literal) (MaxDB: Reference Manual)

Literal (literal)

A literal is an unknown data object that is defined fully by virtue of its value (specifies a non-NULL value, see data type). Literal values cannot be modified. A distinction is made between string literals and numeric literals.

Syntax

<literal> ::= <string_literal> | <numeric_literal>

string_literal, numeric_literal

String literals
 '69190 Walldorf'
'Anthony Smith'

Numeric literals
+0.58498
1E160
-765E-04


String Literal (string_literal) (MaxDB: Reference Manual)

String Literal (string_literal)

A string literal is a literal consisting of a sequence of characters enclosed in quotation marks. String literals can also be represented in hexadecimal notation by preceding them with x or X.

Syntax

<string_literal> ::= '' | '<character>...' | <hex_literal>

Character, hex_literal

'69190 Walldorf'

'Anthony Smith'

X'12ab'

Explanation

A quotation mark within a character string is represented by two successive quotation marks.

A string literal of the type '<character>...' or '' is only valid for a value referring to an alphanumeric column with the code attribute ASCII. A hex literal is only valid for a value referring to a column with the code attribute BYTE.

A string literal of the type '', x'' and X'', and string literals that only contain blanks are not the same as the NULL value.


hex_literal (MaxDB: Reference Manual)

hex_literal

String literal that contains a value in hexadecimal notation.

Syntax

<hex_literal> ::= x'' | X'' | x'<hex_digit_seq>' | X'<hex_digit_seq>'

hex_digit_seq

x'123F'
X'12ab'


hex_digit_seq (MaxDB: Reference Manual)

hex_digit_seq

Sequence of hexadecimal digits ( hex_digit_seq ).

Syntax

<hex_digit_seq> ::=
<hex_digit><hex_digit> | <hex_digit_seq><hex_digit><hex_digit>

hex_digit


Numeric Literal (numeric_literal) (MaxDB: Reference Manual)

Numeric Literal (numeric_literal)

A numeric literal is a number represented as a fixed or floating point number.

Syntax

<numeric_literal> ::= <fixed_point_literal> | <floating_point_literal>

fixed_point_literal, floating_point_literal


Fixed point literal (MaxDB: Reference Manual)

Fixed point literal

Numeric literal that specifies a number as a fixed point number.

Syntax

<fixed_point_literal> ::=   [<sign>]<digit_sequence>[.<digit_sequence>]
| [sign]<digit_sequence>. | [sign].<digit_sequence>

sign , digit_sequence

+123.12
1234.


Sign (MaxDB: Reference Manual)

Sign

Sign

Syntax

<sign> ::= + | -


Digit sequence (MaxDB: Reference Manual)

Digit sequence

Sequence of digits

Syntax

<digit_sequence> ::= <digit>...

digit


Floating point literal (MaxDB: Reference Manual)

Floating point literal

Numeric literal that specifies a number as a floating point number.

Syntax

<floating_point_literal> ::=  <mantissa>E<exponent> | <mantissa>e<exponent>

mantissa , exponent

1e160
-765E-04


Mantissa (MaxDB: Reference Manual)

Mantissa

Mantissa

Syntax

<mantissa> ::= <fixed_point_literal>

fixed_point_literal


Exponent (MaxDB: Reference Manual)

Exponent

Exponent

Syntax

<exponent> ::= [<sign>][[<digit>]<digit>]<digit>

sign , digit


Unsigned integer (MaxDB: Reference Manual)

Unsigned integer

An unsigned_integer is a special numeric literal.

Syntax

<unsigned_integer> ::= <numeric_literal>

numeric_literal

Explanation

An unsigned integer can be represented in any way but must be a positive integer.


Integer (MaxDB: Reference Manual)

Integer

An integer is a special numeric_literal . This integer can be displayed in any number of ways.

Syntax

<integer> ::= [sign]<unsigned_integer>

sign , unsigned_integer


Token (MaxDB: Reference Manual)

Token

A character set or token comprises a series of characters that are combined to form a lexical unit. A distinction is made between regular and delimiter tokens.

Syntax

<token> ::= <regular token> | <delimiter token>

regular_token, delimiter_token

SELECT * FROM reservation
ALTER TABLE reservation DROP FOREIGN KEY customer_reservation

Explanation

Each token can be followed by any number of blanks. Each regular_token must be followed by a delimiter_token or a blank.

Double quotes within a special identifier are represented by two consecutive quotes.


Regular token (MaxDB: Reference Manual)

regular_token

Normal character set (token) (regular_token)

Syntax

<regular_token> ::= <literal> | <key_word> | <identifier> | <parameter_name>

Literal, key_word, identifier, parameter_name

SELECT

'Tours10'


Keyword (MaxDB: Reference Manual)

Key Word (key_word)

Key word. A distinction is made between “normal“ and reserved key words.

Syntax

<keyword> ::= <not_reserved_key_word> | <reserved_keyword>

not_reserved_keyword, reserved_keyword

Explanation

Key words can be entered in uppercase/lowercase characters.

Reserved key words (reserved_key_word) must not be used in simple identifiers. Reserved key words, however, can be specified in the form of special identifiers.


Not reserved keyword (MaxDB: Reference Manual)

not_reserved_key_word

Key words (not_reserved_key_word). If possible, these key words should not be used to designate objects.

You can find a list of all key words in the syntax directory: not_reserved_key_word


Reserved keyword (MaxDB: Reference Manual)

reserved_key_word

Reserved key words ( reserved_key_word). These key words must not be used to designate objects.

You can find a list of all key words in the syntax directory: reserved_key_word


Identifier (MaxDB: Reference Manual)

Identifier

Identifier (identifier). A distinction is made between simple identifiers (simple_identifier) and special identifiers (special_identifier).

Syntax

<identifier> ::= <simple_identifier> | <double quotes><special_identifier><double_quotes>

simple_identifier, double_quotes, special_identifier

Explanation

Identifiers can be entered in uppercase/lowercase characters. When you specify simple identifiers, upper and lower case are ignored, as the system always converts the identifier to upper case letters.

Reserved key words (reserved_key_word) must not be used in simple identifiers. Reserved keywords, however, can be specified in the form of special identifiers.

Double quotation marks (double_quotes) within a special identifier (special_identifier) are represented by two consecutive quotation marks.

Simple identifier: reservation

Special identifier: "ADD"


Simple Identifier (simple_identifier) (MaxDB: Reference Manual)

Simple Identifier (simple_identifier)

Simple identifier. The first character in a simple identifier must not be a digit or underscore.

Syntax

<simple_identifier> ::= <first_character>[<identifier_tail_character>...]

first_character, identifier_tail_character

Explanation

Simple identifiers are always converted into uppercase characters in the database. For this reason, simple identifiers are not case sensitive.

Reserved keywords must not be used in simple identifiers.

If the name of a database object is to contain lowercase letters, special characters, reserved keywords, or blanks, the identifier must be specified as a special identifier (enclosed in double quotation marks).


First character (MaxDB: Reference Manual)

First character

First character in a simple identifier .

Syntax

<first_character> ::= <letter> | <extended_letter> | <language_specific_character>

letter , extended_letter , language_specific_character


Identifier tail character (MaxDB: Reference Manual)

Identifier tail character

Character allowed after the first character in a simple identifier or password .

Syntax

<identifier_tail_character> ::=
<letter> | <extended_letter> | <language_specific_character>
| <digit> | <underscore>

letter , extended_letter , language_specific_character , digit , underscore


Underscore (MaxDB: Reference Manual)

Underscore

Underscore

Syntax

<underscore> ::= _


Double quotes (MaxDB: Reference Manual)

Double quotes

Quotation marks ( double_quotes )

Syntax

<double_quotes> ::= "


Special Identifier (special_identifier) (MaxDB: Reference Manual)

Special Identifier (special_identifier)

Special identifier ( special_identifier). A special identifier must be entered in double quotation marks if it is to be used as an identifier.

Syntax

<special_identifier> ::= <special_identifier_character>...

<special_identifier_character> ::= any characters, that can be linked in any sequence

Explanation

Special identifiers are always used as specified in the database; that is upper and lower case characters are taken into account. Special identifiers are case-sensitive.

If the name of a database object is to contain lowercase letters, special characters, reserved keywords (reserved_key_word), or blanks, the identifier must be specified as a special identifier (enclosed in double quotation marks).

“ADD”, “Example_1”


Delimiter token (MaxDB: Reference Manual)

Delimiter token

Delimiter token

Syntax

<delimiter_token> ::=
  ( | ) | , | . | + | - | * | / | < | > | <> | != | = | <= | >=
| ¬= | ¬< | ¬>(for machines with ASCII code)


Names (MaxDB: Reference Manual)

Names

Names identify objects. The following list contains names that are frequently used in the syntax description of the SQL statements.

Name |
Alias name | alias_name
Column name | column_name
Constraint name | constraint_name
Name of a Database Function | dbfunction_name
Name of a database procedure | dbproc_name
Domain name | domain_name
Index name | index_name
Indicator name | indicator_name
Mapchar set name | mapchar_set_name
Owner | owner
Parameter name | parameter_name
Password | password
Reference name | reference_name
Name of a referential constraint | referential_constraint_name
Result table name | result_table_name
Role name | role_name
Sequence name | sequence_name
Synonym name | synonym_name
Table name | table_name
Trigger name | trigger_name
User Group Name | usergroup_name
User Name | user_name

Explanation

For all names consisting of several identifiers that are separated by a ".", any number of blanks can be specified before and after the dot.


Alias name (MaxDB: Reference Manual)

Alias name

An alias name is a new column name that specifies the name of a column in the following types of tables:

  • View tables
  • Tables defined with a recursive DECLARE CURSOR statement

Syntax

<alias_name> ::= <identifier>

identifier

Explanation

An error message is output if the name has more than 32 characters.

SQL statement for defining an alias name

CREATE VIEW statement

Recursive DECLARE CURSOR statement


Column name (column_name) (MaxDB: Reference Manual)

Column name (column_name)

A column name identifies a column.

Syntax

<column_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statements

Column Definition, Column Specification

CREATE TABLE Statement

CREATE INDEX Statement

UNIQUE Definition

RENAME COLUMN Statement

COLUMN Change Definition

INSERT Statement

UPDATE Statement

MODIFY Definition

UPDATE Clause

DROP Definition


Constraint Name (constraint_name) (MaxDB: Reference Manual)

Constraint Name (constraint_name)

A constraint name defines an integrity condition (data integrity) that must be satisfied by the rows in a table.

Syntax

<constraint_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statements

CONSTRAINT definition

ALTER definition

CREATE DOMAIN definition

DROP Definition


Name of a Database Function (dbfunction_name) (MaxDB: Reference Manual)

Name of a Database Function (dbfunction_name)

A database function name (dbfunction_name) identifies a database function called by a database function call.

Syntax

<dbfunction_name> ::= [<owner>.]<identifier>

owner, identifier

Explanation

The identifier must not exceed 32 characters in length.

SQL statements for creating and deleting a database function

CREATE FUNCTION Statement

DROP FUNCTION Statement


Name of a database procedure (dbproc_name) (MaxDB: Reference Manual)

Name of a database procedure (dbproc_name)

The name of a database procedure ( dbproc_name ) designates a database procedure .

Syntax

<dbproc_name> ::= [<owner>.]<procedure_name>

<procedure_name> ::= <identifier>

owner , identifier

Explanation

You cannot specify TEMP as the owner in a database procedure.

SQL statements for creating, calling, and dropping a database procedure

CREATE DBPROC statement

CALL statement

DROP DBPROC statement


Domain Name (MaxDB: Reference Manual)

Domain Name

A domain name identifies a domain in a table column.

Syntax

<domain_name> ::= [<owner>.]<identifier>

owner, identifier

Explanation

An error message occurs if the name has more than 32 characters.

You cannot specify TEMP as the owner in a domain name.

SQL statement

CREATE DOMAIN statement

DROP DOMAIN statement


Index Name (index_name) (MaxDB: Reference Manual)

Index Name (index_name)

An index name identifies an index.

Syntax

<index_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statements

CREATE INDEX statement

ALTER INDEX statement

RENAME INDEX statement

DROP INDEX statement


Indicator name (MaxDB: Reference Manual)

Indicator name

An indicator name designates an indicator variable in an application that can be specified together with a parameter name.

Syntax

<indicator_name> ::= <parameter_name>

parameter_name

Explanation

The indicator variable of a parameter provides information on any irregularities (e.g. NULL value, difference value and parameter lengths).


Mapchar Set Name (mapchar_set_name) (MaxDB: Reference Manual)

Mapchar Set Name (mapchar_set_name)

A Mapchar set name (mapchar_set_name) identifies a Mapchar set.

Syntax

<mapchar_set_name> ::= <identifier>

identifier

Functions Using Mapchar Sets

MAPCHAR

See also:

Creating Mapchar Sets

Displaying, Changing, and Deleting Mapchar Sets


Owner (MaxDB: Reference Manual)

Owner

The owner of an object is defined by specifying the name of owner name.

Syntax

<owner> ::= <user_name> | <usergroup_name> | TEMP

user_name , usergroup_name

Explanation

If the owner is not a member of a usergroup, the owner name and usergroup name are identical.

If TEMP is specified as the owner in a table name , the table is a temporary table. The owner of this temporary table is the current owner.

An error message is output if the name of the owner has more than 32 characters.


Password (MaxDB: Reference Manual)

Password

Users require a password to connect to the database instance (start a database session).

Syntax

<password> ::= <identifier> | <first_password_character>[<identifier_tail_character>...]

identifier, identifier_tail_character

<first_password_character> ::= <letter> | <extended_letter> | <language_specific_letter> | <digit>

letter, extended_letter, language_specific_letter, digit

Explanation

Passwords are truncated after 18 characters.

SQL statement for defining a user password

CREATE USER statement

SQL statement for changing a user password

ALTER PASSWORD statement


Parameter name (MaxDB: Reference Manual)

Parameter name

A parameter name identifies a parameter (host variable) in an application containing SQL statements from the database system.

Syntax

<parameter_name> ::= :<identifier> | :<identifier>(<identifier>) | :<identifier>(.<identifier>.)

identifier

Explanation

The conventions of the programming language in which the SQL statements of the database system are embedded determine the number of significant characters in the parameter name.

Identifiers for parameter names may contain the characters "." and "_", but not as the first character.


Privilege type (privilege) (MaxDB: Reference Manual)

Privilege type (privilege)

A privilege type ( privilege ) identifies a certain privilege .

Syntax

<privilege> ::= INSERT | UPDATE [(<column_name>,...)]
| SELECT [(<column_name>,...)] | SELUPD [(<column_name>,...)]
| DELETE | INDEX | ALTER | REFERENCES [(<column_name>,...)]

column_name

Explanation

Privilege | Explanation
INSERT | Allows the identified user to insert rows in the specified table. The current user must be authorized to grant the INSERT privilege.
UPDATE | Allows the identified user to update rows in the specified table. If column names are specified, the rows may only be updated in the columns identified by these names. The current user must be authorized to grant the UPDATE privilege.
SELECT | Allows the identified user to select rows in the specified table. If column names are specified, the rows may only be selected in the columns identified by these names. The current user must be authorized to grant the SELECT privilege.
SELUPD | The SELECT and UPDATE privileges are granted. If column names are specified, the rows may only be selected or updated in the columns identified by these names. The current user must be authorized to grant both the SELECT and the UPDATE privileges.
DELETE | Allows the identified user to delete rows from the specified table. The current user must be authorized to grant the DELETE privilege.
INDEX | Allows the identified user to execute the CREATE INDEX and DROP INDEX statements for the specified tables. The INDEX privilege can only be granted for base tables. The current user must be authorized to grant the INDEX privilege.
ALTER | Allows the identified user to execute the ALTER TABLE statement for the specified tables. The ALTER privilege can only be granted for base tables. The current user must be authorized to grant the ALTER privilege.
REFERENCES | Allows the identified user to specify the table as a referenced table in a column_definition or referential_constraint_definition .

SQL statement for granting or revoking privileges

GRANT statement

REVOKE statement


Reference Name (reference_name) (MaxDB: Reference Manual)

Reference Name (reference_name)

The reference name is an identifier that is declared for a certain validity range and associated with exactly one table. The scope of this declaration is the entire SQL statement.

Syntax

<reference_name> ::= <identifier>

identifier

Explanation

The same reference name specified in various scopes can be associated with different tables or with the same table.

An error message occurs if the name has more than 32 characters.

Use in SQL statements

Column spec

Selected column

FROM TABLE specification

Recursive DECLARE CURSOR statement

UPDATE statement

DELETE statement


Name of a Referential Constraint (referential_constraint_name) (MaxDB: Reference Manual)

Name of a Referential Constraint (referential_constraint_name)

The name of a referential constraint (referential_constraint_name) identifies a referential constraint (referential integrity condition, data integrity). This integrity condition specifies deletion and existence dependencies between two tables.

Syntax

<referential_constraint_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statements

Referential CONSTRAINT definition

ALTER TABLE statement


Result Table Name (result_table_name) (MaxDB: Reference Manual)

Result Table Name (result_table_name)

A result table name identifies a result table.

Syntax

<result_table_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

See also:

Named/Unnamed Result Table

SQL statements

QUERY Statement

UPDATE Clause


Role Name (role_name) (MaxDB: Reference Manual)

Role Name (role_name)

A role name identifies a role.

Syntax

<role_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statement for defining a role

CREATE ROLE statement

SQL statement to assign privileges to a role

GRANT statement

SQL statement for granting a role

GRANT statement

SQL statements for activating a role

ALTER USER statement

ALTER USERGROUP statement

SET statement

SQL statement for dropping a role

DROP ROLE statement

See also:

Role Concept


Sequence Name (sequence_name) (MaxDB: Reference Manual)

Sequence Name (sequence_name)

A sequence name identifies a sequence of values.

Syntax

<sequence_name> ::= <identifier>

identifier

Explanation

A sequence is a series of values that are generated in accordance with certain rules. The step width between these values can be defined, among other things.

Sequences can be used to generate unique values. These are not uninterrupted, because values generated within a transaction that was rolled back cannot be used again.

An error message occurs if the name has more than 32 characters.

SQL statements

CREATE SEQUENCE statement

DROP SEQUENCE statement


Synonym Name (synonym_name) (MaxDB: Reference Manual)

Synonym Name (synonym_name)

A synonym name identifies a synonym for a table name.

Syntax

<synonym_name> ::= <identifier>

identifier

Explanation

If the synonym is not a PUBLIC synonym, it is only known by one user or one user group. A PUBLIC synonym is known by every user and user group.

An error message occurs if the name has more than 32 characters.

SQL statements

CREATE SYNONYM statement

RENAME SYNONYM statement

DROP SYNONYM statement


Table Name (table_name) (MaxDB: Reference Manual)

Table Name (table_name)

A table name identifies a table.

Syntax

<table_name> ::= [<owner>.]<identifier>

owner , identifier

Explanation

The database system uses certain table names for internal purposes. The identifiers of these tables begin with SYS. To avoid naming conflicts, therefore, you should not use table names that start with SYS.

If the name of the owner was not specified in the table name, the catalog parts are searched for the table name in the following order:

1. Catalog part of the current user

2. Set of PUBLIC synonyms

3. Catalog part of the DBA who created the current user

4. Catalog part of the SYSDBA

5. Catalog part of the owner of the system tables

An error message occurs if the name has more than 32 characters.

SQL statements

CREATE TABLE statement

CREATE VIEW statement

CREATE SYNONYM statement

Additional SQL statements for data definition


Trigger Name (trigger_name) (MaxDB: Reference Manual)

Trigger Name (trigger_name)

A trigger name identifies a trigger that is defined for a table.

Syntax

<trigger_name> ::= <identifier>

identifier

Explanation

A trigger name must not exceed 32 characters in length.

SQL statements for creating and dropping a trigger

CREATE TRIGGER statement

DROP TRIGGER statement


Usergroup Name (usergroup_name) (MaxDB: Reference Manual)

Usergroup Name (usergroup_name)

A usergroup name identifies a usergroup.

Syntax

<usergroup_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statements

CREATE USERGROUP statement

ALTER USERGROUP statement

RENAME USERGROUP statement

DROP USERGROUP statement

GRANT USERGROUP statement


User Name (user_name) (MaxDB: Reference Manual)

User Name (user_name)

A user name identifies a user.

Syntax

<user_name> ::= <identifier>

identifier

Explanation

An error message occurs if the name has more than 32 characters.

SQL statements

CREATE USER statement

ALTER USER statement

RENAME USER statement

DROP USER statement

GRANT USER statement


Column specification (column_spec) (MaxDB: Reference Manual)

Column specification (column_spec)

A column specification ( column_spec ) specifies a column in a table.

Syntax

<column_spec> ::= <column_name> | <table_name>.<column_name>
| <reference_name>.<column_name> | <result_table name>.<column_name>

column_name , table_name , reference_name , result_table_name

Explanation

For all names consisting of several identifiers separated by a ".", any number of blanks can be specified before and after the dot.


Parameter specification (parameter spec) (MaxDB: Reference Manual)

Parameter specification (parameter spec)

A parameter specification ( parameter spec) identifies the parameter name and, if necessary, the indicator name needed to specify a parameter.

Syntax

<parameter spec> ::= <parameter name> [<indicator name>]

parameter_name, indicator name

Explanation

The indicator must be declared as a variable in the embedding programming language. It must be possible to assign at least four-digit integers to this variable.

A distinction is made between output parameters and input parameters:

· Output parameters: parameters that are to receive values retrieved from the database system.

- An indicator parameter with the value 0 indicates that the transferred value is not a NULL value and that the parameter value is the transferred value.

- An indicator with the value –1 indicates that the parameter value is the NULL value.

- Alphanumeric output parameters: an indicator with a value greater than 0 indicates that the assigned character string was too long and has been truncated. The indicator specifies the untruncated length of the original output column.

- Numeric output parameters: an indicator with a value greater than 0 indicates that the assigned value has too many significant digits and decimal places have been truncated. The indicator specifies the number of digits in the original value.

- For numeric output parameters, an indicator with the value -2 indicates that the parameter value is the special NULL value.

· Input parameters: parameters containing values that are to be transferred to the database system.

- An indicator with a value greater than or equal to 0 indicates that the specified parameter value is the value that is to be transferred to the database system.

- An indicator with a value less than 0 indicates that the specified parameter value is the NULL value.


Specifying values (extended value spec) (MaxDB: Reference Manual)

Specifying values (extended value spec)

Values can be specified (extended value spec) by specifying values (value spec) or with one of the keywords DEFAULT or STAMP.

Syntax

<extended value spec> ::= <value spec> | DEFAULT | STAMP

value_spec

Explanation

  • DEFAULT keyword
    DEFAULT identifies the default value for the column in a     CREATE TABLE statement or ALTER TABLE statement . DEFAULT cannot be used to specify values if one of these values is not defined.
    The DEFAULT keyword can be used in the following SQL statements:
    INSERT statement
    UPDATE statement
    The DEFAULT keyword can be used in a     DEFAULT predicate .
  • STAMP key word
    The database system is able to generate unique values. This is a serial number that starts with X'000000000001'. The values are assigned in ascending order. It cannot be ensured that a sequence of values is uninterrupted. The STAMP key word supplies the next value generated by the database system.
    The STAMP keyword can be used in the following SQL statements (only on columns of the data type CHAR(n) BYTE with n>=8, see     DEFAULT specification ):
    INSERT statement
    UPDATE statement
    If the user wants to find out the generated value before it is applied to the column, the following SQL statement must be used:
     NEXT STAMP statement


Specifying Values (value_spec) (MaxDB: Reference Manual)

Specifying Values (value_spec)

Values can be specified ( value_spec) by specifying literals, parameter specifications, or a series of keywords.

Syntax

<value_spec> ::= <literal> | <parameter_spec>
| NULL | USER | USERGROUP | SYSDBA | UID
| [<owner>.]<sequence_name>.NEXTVAL | [<owner>.]<sequence_name>.CURRVAL
| <table_name>.CURRVAL
| DATE | TIME | TIMESTAMP | UTCDATE | TIMEZONE | UTCDIFF
| TRUE | FALSE | TRANSACTION

literal | Literal
parameter_spec | Parameter specification
NULL | NULL value
USER | Current user name
USERGROUP | Name of the user group to which the user calling the SQL statement belongs. If the user does not belong to a user group, the user name is displayed.
SYSDBA | Database system administrator (SYSDBA user) of the database instance
UID | Identification of the current user. This is a whole number.
[<owner>.]<sequence_name>.NEXTVAL | Next value generated for the specified sequence name (of the owner in question).
[<owner>.]<sequence_name>.CURRVAL | Value that was generated using [<owner>.]<sequence_name>.NEXTVAL as the final value for the specified sequence name.
<table_name>.CURRVAL | Last assigned value of the serial column in the table_name table in the current database session.
DATE | Current date
TIME | Current time
TIMESTAMP | Current timestamp
UTCDATE | Current UTC time stamp (Greenwich Mean Time)
TIMEZONE | Time difference in hours in the format hhmmss (in data type FIXED(6)) between your local time value and the UTC time value (Greenwich Mean Time)
UTCDIFF | Time difference in hours (in data type FIXED(4,2)) between your local time and the UTC time value.
TRUE | FALSE | Corresponding value of a column of the data type BOOLEAN
TRANSACTION | Identification of the current transaction. This is a value of data type CHAR(10) BYTE.


Date and Time Format (datetimeformat) (MaxDB: Reference Manual)

Date and Time Format (datetimeformat)

The date and time format (datetimeformat) specifies the way in which date values, time values, and timestamp values are represented.

In SQL statements, it determines the format in which the date, time, and timestamp values can be represented in these SQL statements, and the way in which results are displayed.

Syntax

<datetimeformat> ::= EUR | INTERNAL | ISO | JIS | USA

The ISO date and time format is used by ODBC and JDBC applications and cannot be replaced with a different date and time format.

Date Value

'YYYY' | Four-digit year format
'MM' | Two-digit month format (01-12)
'DD' | Two-digit day format (01-31)

Format | General Form | Example
EUR | 'DD.MM.YYYY' | '23.01.1999'
INTERNAL | 'YYYYMMDD' | '19990123'
ISO/JIS | 'YYYY-MM-DD' | '1999-01-23'
USA | 'MM/DD/YYYY' | '01/23/1999'

In all formats, with the exception of INTERNAL, leading zeros may be omitted in the identifiers for the month and day.

Time Value

'HHHH' | Four-digit hour format
'HH' | Two-digit hour format
'MM' | Two-digit minute format (00-59)
'SS' | Two-digit second format (00-59)

Format | General Form | Example
EUR | 'HH.MM.SS' | '14.30.08'
INTERNAL | 'HHHHMMSS' | '00143008'
JIS/ISO | 'HH:MM:SS' | '14:30:08'
USA | 'HH:MM AM (PM)' | '2:30 PM'

In all time formats, the identifier of the hour must consist of at least one digit. In the USA time format, the minute identifier can be omitted completely. In all the other formats, with the exception of INTERNAL, the minute and second identifiers must comprise at least one digit.

In the ISO and USA formats, the hours are displayed modulo 24.
In the EUR and JIS formats, a number of hours greater than 99 causes an error.
In the INTERNAL format, you can use up to 9999 hours.

Timestamp Value

'YYYY' | Four-digit year format
'MM' | Two-digit month format (01-12)
'DD' | Two-digit day format (01-31)
'HH' | Two-digit hour format (0-24)
'MM' | Two-digit minute format (00-59)
'SS' | Two-digit second format (00-59)
'MMMMMM' | Six-digit microsecond format

Format | General Form | Example
EUR/JIS/USA | 'YYYY-MM-DD-HH.MM.SS.MMMMMM' | '1999-01-23-14.30.08.456234'
ISO | 'YYYY-MM-DD HH:MM:SS.MMMMMM' | '1999-01-23 14:30:08.456234'
INTERNAL | 'YYYYMMDDHHMMSSMMMMMM' | '19990123143008456234'

The microsecond identifier can be omitted in all timestamp formats. In all formats, with the exception of INTERNAL, the month and day identifiers must consist of at least one digit.

See also:

Special database parameter DATE_TIME_FORMAT


Specifying a string (string spec) (MaxDB: Reference Manual)

Specifying a string (string spec)

Only expressions that have an alphanumeric value as a result are allowed as a string specification (string_spec).


Specifying a Key (key_spec) (MaxDB: Reference Manual)

Specifying a Key (key_spec)

A key specification (key_spec) allows rows in a table to be located whose key column values match the values in the key specification. A row with the specified key values does not have to exist.

Syntax

<key_spec> ::= <column_name> = <value_spec>

column_name , value_spec

Explanation

The value specification (value_spec) must not be NULL.

The column name must identify a key column in the table.

The key specification must contain all the key columns in a table. The individual key specifications (key_spec) must be separated by commas.

For tables defined without key columns, there is the implicitly generated column SYSKEY CHAR(8) BYTE which contains a key generated by the database system. This column can only be used in a key specification.


Expression (MaxDB: Reference Manual)

Expression

An expression specifies a value that is generated, if required, by applying arithmetic operators to values.

A distinction is made between the following arithmetic operators:

  • Additive operators
    + Addition
    - Subtraction
  • Multiplicative operators
    * Multiplication
    / Division
    DIV integer division
    MOD remainder after integer division

Syntax

<expression> ::= <term> | <expression> + <term> | <expression> - <term>
<expression_list> ::= (<expression>,...)

<term> ::= <factor>
| <term> * <factor> | <term> / <factor>
| <term> DIV <factor>| <term> MOD <factor>

factor

Explanation

The arithmetic operators can only be applied to numeric data types.

 | Result of an expression
expression | Value of any data type
factor supplies a NULL value | NULL value
factor supplies a special NULL value | Special NULL value
expression leads to a division by 0 | Special NULL value
expression leads to an overflow of the internal temporary result | Special NULL value

If no parentheses are used, the operators have the following precedence:

  1. The sign has a higher precedence than the additive and multiplicative operators.
  2. The multiplicative operators have a higher precedence than the additive operators.
  3. The multiplicative operators have different priorities.
  4. The additive operators have different priorities.
  5. Operators with the same precedence are evaluated from left to right.

Operands are fixed point numbers

Operand1 (a) | Operand2 (b) | Result
Fixed point number (p precision s number of decimal places | Fixed point number (p' precision s' number of decimal places) | Fixed point number (p" precision s" number of decimal places) or floating point number

The data type of the result depends on the operation as well as on the precision and number of decimal places of the operands.

Note that the data type of a column determines its name, and not the precision and number of decimal places in the current value.

Operands are fixed point numbers, operands are +, - , * or /

The result of addition, subtraction, and multiplication is generated from a temporary result which can have more than 38 valid digits. If the temporary result has no more than 38 valid digits, the final result is equal to the temporary result. Otherwise, a result is generated as a floating point number with 38 places. Decimal places are truncated if necessary.

Condition

Operator

Result

max(p-s,p'-s')

+, -

Fixed point number
p''=max(p-s,p'-s')+max(s,s')+1
s''=max(s,s')

(p+p')<=38

*

Fixed point number
p''=p+p'
s''=s+s'

(p-s+s')<=38

/

Fixed point number
p''=38
s''=38-(p-s+s')
Special NULL value, if b=0

Operands are integers, operators are DIV, MOD

Condition | Operator | Result
ABS (a)<1E38 and ABS(b)<1E38 and b<>0 | DIV | TRUNC (a/b)
b=0 | DIV | Special NULL value
ABS(a)>=1E38 and b<>0 or ABS(b)>=1E38 | DIV | Error message
ABS(a)<1E38 and ABS(b)<1E38 and b<>0 | MOD | a-b*(a DIV b)
b=0 | MOD | a
ABS(a)>=1E38 and b<>0 or ABS(b)>=1E38 | MOD | Error message

An operand is a floating point number

If an operand is a floating point number , the result of the arithmetic operation is a floating point number.


factor (MaxDB: Reference Manual)

factor

Specifies how the values are determined that are to be linked in an expression by means of arithmetic operators.

Syntax

<factor> ::= [<sign>] <value_spec> | [<sign>] <column_spec>
| [<sign>] <function_spec> | [<sign>] <set_function_spec>
| <scalar_subquery> |<expression>

sign , value_spec , column_spec , function_spec , set_function_spec , scalar_subquery , expression


Predicate (predicate) (MaxDB: Reference Manual)

Predicate (predicate)

A predicate is specified in a WHERE condition in a statement which is "true", "false", or "unknown". The result is generated by applying the predicate to a specific row in a result table (see result table name) or to a group of rows in a table that was formed by the GROUP clause.

Syntax

<predicate> ::=
  <between_predicate> | <bool_predicate> | <comparison_predicate>
| <default_predicate> | <exists_predicate> | <in_predicate>
| <join_predicate> | <like_predicate> | <null_predicate>
| <quantified_predicate> | <rowno_predicate> | <sounds_predicate>

between_predicate, bool_predicate, comparison_predicate, default_predicate, exists_predicate, in_predicate, join_predicate, like_predicate, null_predicate, quantified_predicate, rowno_predicate, sounds_predicate

Explanation

· Columns in a table with the same code attribute can be compared.

· Columns with the different code attributes ASCII and UNICODE can be compared.

· Columns with the code attribute ASCII or UNICODE can be compared with date values, time values, or timestamp values.

· LONG columns can only be used in the NULL predicate.

Example table: customer

Selection without a condition:

SELECT city, name, firstname FROM customer

CITY | NAME | FIRSTNAME
New York | Porter | Jenny
Dallas | DATASOFT | ?
Los Angeles | Porter | Martin
Los Angeles | Peters | Sally
Hollywood | Brown | Peter
New York | Porter | Michael
New York | Howe | George
Los Angeles | Randolph | Frank
Los Angeles | Peters | Joseph
Los Angeles | Brown | Susan
Los Angeles | Jackson | Anthony
Los Angeles | Adams | Thomas
New York | Griffith | Mark
Los Angeles | TOOLware | ?
Hollywood | Brown | Rose

Auswahl mit einschränkender Bedingung:

SELECT city, name, firstname FROM customer
WHERE city = 'Los Angeles'

CITY | NAME | FIRSTNAME
Los Angeles | Porter | Martin
Los Angeles | Peters | Sally
Los Angeles | Randolph | Frank
Los Angeles | Peters | Joseph
Los Angeles | Brown | Susan
Los Angeles | Jackson | Anthony
Los Angeles | Adams | Thomas
Los Angeles | TOOLware | ?


BETWEEN predicate (between_predicate) (MaxDB: Reference Manual)

BETWEEN predicate (between_predicate)

The BETWEEN predicate ( between_predicate) checks whether a value is within a specified range.

Syntax

<between_predicate> ::= <expression> [NOT] BETWEEN <expression> AND <expression>

expression

Explanation

Let x, y, and z be the results of the first, second, and third expression. The values x,y,z must be comparable.

 | Result of the specified predicate
x BETWEEN y AND z | x>=y AND x<=z
x NOT BETWEEN y AND z | NOT(x BETWEEN y AND z)
x, y, or z are NULL values | x [NOT] BETWEEN y AND z is undefined

Example table: customer

Finding customers with a credit balance between –420 and 0:

SELECT title, name, city, account FROM customer
WHERE account BETWEEN -420 AND 0

TITLE | NAME | CITY | ACCOUNT
Mr | Porter | Los Angeles | 0.00
Mrs | Peters | Los Angeles | 0.00
Mr | Brown | Hollywood | 0.00
Mr | Porter | New York | 0.00
Mr | Howe | New York | -315.40
Mr | Randolph | Los Angeles | 0.00
Mr | Jackson | Los Angeles | 0.00
Mr | Adams | Los Angeles | -416.88
Mr | Griffith | New York | 0.00

You want to list the customers who have either a credit balance or a significant debit balance:

SELECT title, name, city, account FROM customer
WHERE account NOT BETWEEN -10 AND 0

TITLE | NAME | CITY | ACCOUNT
Mrs | Porter | New York | 100.00
Comp | DATASOFT | Dallas | 4813.50
Mr | Howe | New York | -315.40
Mr | Peters | Los Angeles | 650.00
Mrs | Brown | Los Angeles | -4167.79
Mr | Adams | Los Angeles | -416.88
Comp | TOOLware | Los Angeles | 3770.50
Mrs | Brown | Hollywood | 440.00


Boolean predicate (bool_predicate) (MaxDB: Reference Manual)

Boolean predicate (bool_predicate)

Boolean values ( BOOLEAN ) are compared in a boolean predicate .

Syntax

<bool_predicate> ::= <column_spec> [ IS [NOT] <TRUE | FALSE>]

column spec

Explanation

If only one column specification ( column_spec ) is specified, the syntax is identical to <column_spec> IS TRUE .

The column_spec must always denote a column with the data type BOOLEAN.

The following rules apply to the result of a boolean predicate:

Column value | IS TRUE | IS NOT TRUE | IS FALSE | IS NOT FALSE
false | false | true | true | false
undefined | undefined | undefined | undefined | undefined
true | true | false | false | true


Comparison Predicate (comparison_predicate) (MaxDB: Reference Manual)

Comparison Predicate (comparison_predicate)

A comparison predicate specifies a comparison between two values or lists of values.

Syntax

<comparison_predicate> ::= <expression> <comp_op> <expression>
| <expression> <comp_op> <subquery>
| <expression_list> <equal_or_not> (<expression_list>)
| <expression_list> <equal_or_not> <subquery>

expression, expression_list, subquery

The following operators are available for comparing two values:
<, >, <>, !=, =, <=, >= (comp_op)

Value lists can only be compared with the = and <> operators (equal_or_not).

Explanation

The subquery (subquery) must supply a result table (see result table name) that contains the same number of columns as the number of values on the left of the operator. The result table may contain no more than one row.

The list of values specified to the right of the equal_or_not operator (expression_list) must contain the same number of values as specified in the value list in front of the equal_or_not operator.

The JOIN predicate is a special case.

Comparing two values

Let x be the result of the first expression and y the result of the second expression or of the subquery.

· The values x and y must be comparable with one another.

· Numbers are compared to one another according to their algebraic values.

· Character strings are compared character by character.
Any blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) at the end of one or both of the character strings are removed.
If the character strings have the different code attributes ASCII and UNICODE, the character string with the code attribute ASCII is implicitly converted into a character string with the code attribute UNICODE.
Two character strings are identical if they have the same characters in all positions.
The relationship between two character strings that are not identical is defined by the first character that differs in a comparison from left to right. This comparison is performed according to the code attribute selected for the column (ASCII, UNICODE, or BYTE). If x or y are NULL values, or if the result of the subquery is empty, then (x <comp_op> y) is undefined.

Comparing two value lists

If a value list (expression_list) is specified on the left of the comparison operator equal_or_not, x is the value list that comprises the results of the values x1, x2, ..., xn in this list. y is the result of the subquery or the result of the second value list. A value list y consists of the results of the values y1, y2, ..., yn.

· A value xm must be comparable with the associated value ym.

· x=y is true if for xm=ym for all m=1, ..., n.

· x<>y is true if at least xm<>ym for at least one m.

· (x <equal_or_not> y) is undefined (not known) if there is no m for which (xm <equal_or_not>ym) is false and if there is at least one m for which (xm <equal_or_not>ym) is undefined.

· If one xm or one ym is a NULL value, or if the result of the subquery is empty, (x <equal_or_not> y) is undefined.

Example table: customer

Which customers are female?

SELECT title, firstname, name FROM customer
WHERE title = 'Mrs'

TITLE | FIRSTNAME | NAME
Mrs | Jenny | Porter
Mrs | Sally | Peters
Mrs | Susan | Brown
Mrs | Rose | Brown


Comparison Operators (comp_op) (MaxDB: Reference Manual)

Comparison Operators (comp_op)

Operators for comparing values (comp_op)

Syntax

<comp_op> ::= < | > | <> | != | = | <= | >=
| ~= | ~< | ~> (for machines with ASCII code)


Comparison Operators (equal_or_not) (MaxDB: Reference Manual)

Comparison Operators (equal_or_not)

Operators for comparing value lists (equal_or_not)

Syntax

<equal_or_not> ::= <> |=
| ~= (for machines with ASCII code)


DEFAULT predicate (MaxDB: Reference Manual)

DEFAULT predicate

By specifying a DEFAULT predicate , you can check whether a column contains the default value defined for this column.

Syntax

<default_predicate> ::= <column_spec> <comp_op> DEFAULT

column_spec , comp_op

Explanation

A DEFAULT specification must be made for the specified column. This can be done in the following SQL statements:

  • CREATE TABLE statement
  • ALTER TABLE statement

If the column contains the NULL value , <column_spec> <comp_op> DEFAULT is undefined.

The rules for comparing values or value lists, as defined under comparison predicate , apply here.


EXISTS Predicate (exists_predicate) (MaxDB: Reference Manual)

EXISTS Predicate (exists_predicate)

The EXISTS predicate ( exists_predicate) checks whether a result table (see result table name) contains at least one row.

Syntax

<exists_predicate> ::= EXISTS <subquery>

subquery

Explanation

The truth content of an EXISTS predicate is either true or false.

The subquery generates a result table. If this result table contains at least one row, EXISTS <subquery> is true.

Example tables: customer, reservation

Only select customers that have one or more reservations:

SELECT * FROM customer WHERE EXISTS
(SELECT * FROM reservation WHERE customer.cno = reservation.cno)

CNO | TITLE | NAME | FIRSTNAME | ZIP | CITY | ACCOUNT
3000 | Mrs | Porter | Jenny | 80335 | New York | 100.00
3100 | Comp | DATASOFT | ? | 50933 | Dallas | 4813.50
3200 | Mr | Porter | Martin | 10969 | Los Angeles | 0.00
3600 | Mr | Howe | George | 81737 | New York | -315.40
3900 | Mrs | Brown | Susan | 13599 | Los Angeles | -4167.79
4100 | Mr | Adams | Thomas | 13355 | Los Angeles | -416.88
4300 | Comp | TOOLware | ? | 13629 | Los Angeles | 3770.50
4400 | Mrs | Brown | Rose | 40233 | Hollywood | 440.00


IN Predicate (in_predicate) (MaxDB: Reference Manual)

IN Predicate (in_predicate)

The IN predicate checks whether a value or a value list is contained in a specified set of values or value lists.

Syntax

<in_predicate> ::=
  <expression> [NOT] IN <subquery>
| <expression> [NOT] IN <expression_list>
| <expression_list> [NOT] IN <subquery>
| <expression_list> [NOT] IN (<expression_list>,...)

expression, expression_list, subquery

Explanation

The subquery must supply a result table (see result table name) that contains the same number of columns as the number of values specified by the expression on the left-hand side of the IN operator.

Each value list specified on the right-hand side of the IN operator must contain the same number of values as specified in the value list on the left-hand side of the IN operator.

· x [NOT] IN S, whereby x <expression>and S <subquery> or <expression_list>
The value x and the values in S must be comparable.

· x [NOT] IN S, whereby x <expression_list> with the values x1, x2, ..., xn and S <subquery>(set of value lists s) or (<expression_list>,...) (Range of values lists s) with the value lists s: s1, s2, ..., sn
A value xm must be comparable with all values sm.
x=s is true if xm=sm, m=1,...,n
x=s is false if there is at least one m for which xm=sm is false
x=s is undefined if there is no m for which xm=sm is false and there is at least one m for which xm=sm is undefined.

The entry '------' in the list below means that no statement can be made if only the result of the comparison with one s is known.

 | Result of the function x IN S
x=s is true for at least one s | true
x=s is true for all s | true
S contains NULL values and x=s is true for the remaining s | true
S is empty | false
x=s is false for at least one s | ------
x=s is false for all s | false
S contains NULL values and x=s is false for the remaining s | undefined
x=s is not true for any s and is undefined for at least one value s | undefined

x NOT IN S has the same result as NOT(x IN S)

Example table: customer

Choosing all customers who are natural persons (not companies):

SELECT title, firstname, name, city FROM customer
WHERE title IN ('Mr','Mrs')

TITLE | FIRSTNAME | NAME | CITY
Mrs | Jenny | Porter | New York
Mr | Martin | Porter | Los Angeles
Mrs | Sally | Peters | Los Angeles
Mr | Peter | Brown | Hollywood
Mr | Michael | Porter | New York
Mr | George | Howe | New York
Mr | Frank | Randolph | Los Angeles
Mr | Joseph | Peters | Los Angeles
Mrs | Susan | Brown | Los Angeles
Mr | Anthony | Jackson | Los Angeles
Mr | Thomas | Adams | Los Angeles
Mr | Mark | Griffith | New York
Mrs | Rose | Brown | Hollywood


JOIN Predicate (join_predicate) (MaxDB: Reference Manual)

JOIN Predicate (join_predicate)

A JOIN predicate specifies a JOIN. A JOIN predicate can be specified with or without one or with two OUTER JOIN indicators.

Syntax

<join_predicate> ::=
<expression> [<outer_join_indicator>] <comp_op> <expression> [<outer_join_indicator>]

<outer_join_indicator> ::= (+)

expression, comp_op

Explanation

Each expression must contain a column specification. A column specification must exist for the first and second expression so that both specifications refer to different table names or reference names.

Let x be the value of the first expression and y the value of the second expression. The values x and y must be comparable with one another.

The rules outlined under comparison predicate apply here.

If at least one OUTER JOIN indicator is specified in a JOIN predicate of a search condition, the corresponding table expression must be based on exactly two tables, or the following has to apply:

· OUTER JOIN indicators are only specified for one of the tables in the FROM clause.

· All of the JOIN predicates in this table to just one other table contain the OUTER JOIN indicator.

· All other JOIN predicates contain no OUTER JOIN indicators.

If a JOIN requires more than two tables for the QUERY specification and if one of the rules above cannot be observed, a QUERY expression can also be used in the FROM clause.

Only those rows from the table that have a counterpart of the comparison operator in the JOIN predicate specified in the table are transferred to the result table.

The OUTER JOIN indicator must be specified on the side of the comparison operator where the other table is specified if each row in a table is to appear at least once in the result table.
If it is not possible to find at least one counterpart for a table row in the other table, this row is used to build a row for the result table. The NULL value is then used for the output columns which are formed from the columns in the other table.
Since the OUTER JOIN indicator can be specified on both sides of the comparison operator if the table expression is based on just two tables, it can be ensured that each line in both tables appears at least once in the result table.

The JOIN predicate is a special case of the comparison predicate. The number of JOIN predicates in a search condition is limited to 128.

JOIN predicate

Example tables: customer, reservation

Is there a reservation for the customer 'Porter'? If so, for what date?

SELECT reservation.rno, customer.name,customer.firstname, reservation.arrival, departure

FROM customer, reservation

WHERE customer.name = 'Porter' AND customer.cno = reservation.cno

RNO | NAME | FIRSTNAME | ARRIVAL | DEPARTURE
100 | Porter | Jenny | 13/11/2001 | 15/11/2001
110 | Porter | Jenny | 24/12/2001 | 06/01/2002
120 | Porter | Martin | 14/11/2001 | 18/11/2002

Specifying an OUTER JOIN indicator

Example tables: hotel, reservation

List all the hotels in Los Angeles for which a reservation exists and those for which a reservation does not exist. Missing reservation numbers are assigned a NULL value.

SELECT hotel.hno, hotel.name, reservation.rno

FROM hotel, reservation

WHERE hotel.city = 'Los Angeles' AND hotel.hno = reservation.hno (+)

HNO | NAME | RNO
80 | Midtown | 100
50 | Lake Michigan | 120
80 | Midtown | 140
120 | Sunshine | 180
40 | Eight Avenue | ?


LIKE Predicate (like_predicate) (MaxDB: Reference Manual)

LIKE Predicate (like_predicate)

A LIKE predicate ( like_predicate) is used to search for character strings that have a certain pattern. This pattern can be a certain character string or any sequence of characters (whose length may or may not be known).

Syntax

<like_predicate> ::= <expression> [NOT] LIKE <like_expression> [ESCAPE <expression>]

<like_expression> ::= <expression> | '<pattern_element>...'

expression, pattern_element

Explanation

The expression in the like_expression must supply an alphanumeric value or a date or time value.

x NOT LIKE y has the same result as NOT(x LIKE y).

Result of x LIKE y

x or y are NULL values

x LIKE y is undefined

x and y are non-NULL values

x LIKE y is either true or false

x can be split into substrings with the result that:

A substring of x is a sequence of 0,1, or more contiguous characters, and each character of x belongs to exactly one substring.

The number of substrings of x and y is identical.

If the nth pattern element of y is a sequence of characters and the nth substring of x is a sequence of 0 or more characters.

x LIKE y is true
ESCAPE

An escape character (ESCAPE <expression>) must be used if you want to search for an <underscore>, '%', or the hexadecimal value X'1E' or X'1F' in the LIKE predicate.

If ESCAPE <expression> is specified, the corresponding expression ( expression) must supply an alphanumeric value that consists of just one character. If this escape character is contained in the LIKE expression ( like_expression), the following character must be one of the special characters <underscore>, %, X’1E’, or X’1F’. This special character is then viewed as standing for itself.

Search for any character string with a minimum length of 1: LIKE '%_'
Search for a character string in which a fixed number of characters is known: LIKE'_c_'
Search for a character string with any number of characters, whereby the character string must contain an <underscore>: LIKE '%:_%'ESCAPE':'

Example table: customer

Customers whose name ends with 'FT':

SELECT name, city FROM customer
WHERE name LIKE '%FT'

NAME | CITY
DATASOFT | Dallas

Finding all customers whose names consist of six letters and begin with 'P':

SELECT name, firstname, city FROM customer
WHERE name LIKE 'P_ _ _ _ _'

NAME | FIRSTNAME | CITY
Porter | Jenny | New York
Porter | Martin | Los Angeles
Peters | Sally | Los Angeles
Porter | Michael | New York
Peters | Joseph | Los Angeles

Customers with a 'p' in their name from the second position:

SELECT name, city FROM customer
WHERE name LIKE '_%p%'

NAME | CITY
Randolph | Los Angeles


Pattern element (MaxDB: Reference Manual)

Pattern element

Element for specifying a comparison pattern (for a LIKE predicate ). A comparison can be carried out with a string of characters or a set of characters.

Syntax

<pattern_element> ::= <match_string> | <match_set>

match_string , match_set


match_string (MaxDB: Reference Manual)

match_string

If a match_string is specified, this position in the search pattern can be replaced by any number of characters.

Syntax

<match_string> ::= % | X'1F'

Explanation

A LIKE predicate is used to search for character strings that have a certain pattern. Match_string can be used to specify the pattern (pattern element).

Example table: customer

Finding all customers whose first names have any lengths and begin with 'M':

SELECT firstname, name FROM customer
WHERE firstname LIKE 'M%'

FIRSTNAME | NAME
Martin | Porter
Michael | Porter
Mark | Griffith


match_set (MaxDB: Reference Manual)

match_set

If a match_set is specified, this position in the search pattern can be replaced by the exact number of characters specified in the match_set.

Syntax

<match_set> ::= <underscore> | X'1E' | <match_char>

<match_char>    ::= Every character other than %, X'1F', underscore, X'1E'

underscore

Explanation

A LIKE predicate is used to search for character strings that have a certain pattern. Match_set can be used to specify the pattern (pattern element).

· <underscore> | X'1E' : this position in the pattern can be replaced by any one character

· match_char : this position in the pattern can be replaced by the specified character itself.

Example table: customer

Finding all customers whose names consist of six letters and begin with 'P':

SELECT name, firstname, city FROM customer
WHERE name LIKE 'P_ _ _ _ _'

NAME | FIRSTNAME | CITY
Porter | Jenny | New York
Porter | Martin | Los Angeles
Peters | Sally | Los Angeles
Porter | Michael | New York
Peters | Joseph | Los Angeles


NULL predicate (MaxDB: Reference Manual)

NULL predicate

By specifying a NULL predicate , you can test whether the value is a NULL value .

Syntax

<null_predicate> ::= <expression> IS [NOT] NULL

expression

Explanation

The truth content of a NULL predicate is either true or false.

 | Result of the function x IS NULL
x is NULL value | true
x is a special NULL value | false

x IS NOT NULL has the same result as NOT(x IS NULL) .


Quantified Predicate (quantified_predicate) (MaxDB: Reference Manual)

Quantified Predicate (quantified_predicate)

By specifying a quantity predicate, you can compare a value or list of values to a set of values or value lists.

Syntax

<quantified_predicate> ::=
  <expression> <comp_op> <quantifier> <expression_list>
| <expression> <comp_op> <quantifier> <subquery>
| <expression_list> <equal_or_not> <quantifier> (<expression_list>,...)
| <expression_list> <equal_or_not> <quantifier> <subquery>

subquery, expression_list

The following operators are available for comparing values:
<, >, <>, !=, =, <=, >= (comp op)

Value lists can only be compared with the = and <> operators (equal_or_not).

The quantified predicate can be qualified with ALL, SOME, or ANY (quantifier).

Explanation

The subquery must supply a result table (see result table name) that contains the same number of columns as the number of values specified by the expression or expression list on the left-hand side of the operator.

Each list of values specified to the right of the equal_or_notoperator ( expression_list) must contain the same number of values as specified in the value list in front of the equal_or_notoperator.

· Let x be the result of the first expression and S the result of the subquery or sequence of values. S is a set of values s. The value x and the values in S must be comparable with each other.

· If a value list ( expression_list) is specified on the left of the comparison operator equal_or_not, then let x be the value list comprising the results of the values x1, x2, ..., xn of this value list. Let S be the result of the subquery consisting of a set of value lists s or a sequence of value lists s. A value list s consists of the results of the values s1, s2, ..., sn. A value xm must be comparable with all values sm.
x=s is true if xm=sm, m=1,...,n
x<>s is true if there is at least one m for which xm<>sm
x <equal or not> s is undefined if there is no m for which xm <equal or not> sm is false and if there is at least one m for which xm <equal_or_not> sm is undefined.
If one xm or one ym is a NULL value, or if the result of the subquery is empty, x <equal_or_not> y is undefined.

The entry '------' in the list below means that no statement can be made if only the result of the comparison with one s is known.

x <compare> <quantifier> S, whereby compare ::= comp_op | equal_or_not

 | quantifier ::= ALL | quantifier ::= ANY | SOME
S is empty | true | false
x <compare> S is true for at least one s from S | ------ | true
x <compare> S is true for all s from S | true | true
x <compare> S is not false for any value from S and is undefined for at least one value s | undefined |
S contains NULL values and x <compare> S is true for all other s | undefined | true
x <compare> S is false for at least one value s from S | false | ------
x <compare> S is false for all s from S | false | false
x <compare> S is not true for any value s from S and is undefined for at least one value s |  | undefined
S contains NULL values and x <compare> S is false for all other s | false | undefined

Example table: hotel

List of hotels that have the same name as other cities in the base table.

SELECT name, city FROM hotel
WHERE name = ANY (SELECT city FROM hotel)

The subquery SELECT city FROM hotel determines the list of city names that are compared with the hotel names.

NAME | CITY
Los Angeles | Cincinatti
Long Beach | Long Beach
Dallas | Dallas


Quantifier (MaxDB: Reference Manual)

Quantifier

The quantified predicate can be qualified with ALL, SOME, or ANY.

Syntax

<quantifier> ::= ALL | SOME | ANY


ROWNO Predicate (rowno_predicate) (MaxDB: Reference Manual)

ROWNO Predicate (rowno_predicate)

The ROWNO predicate restricts the number of lines in a result table).

Syntax

<rowno_predicate> ::= ROWNO < <unsigned_integer>
| ROWNO < <parameter_spec>
| ROWNO <= <unsigned_integer>
| ROWNO <= <parameter_spec>

unsigned_integer, parameter_spec

Explanation

A ROWNO predicate may only be used in a WHERE clause that belongs to a QUERY statement. The ROWNO predicate can be used like any other predicate in the WHERE clause if the following restrictions are observed:

· The ROWNO predicate must be linked to the other predicates by a logic AND

· The ROWNO predicate must not be negated

· The ROWNO predicate may not be used more than once in the WHERE clause

You can specify the maximum number of lines in the result table using an unsigned integer or a parameter specification. If more lines are found, they are simply ignored and do not lead to an error message. Specifying a ROWNO predicate of the type ROWNO <= 0 results in an empty results table.

If a ROWNO predicate and an ORDER clause are specified, only the first n result lines are searched and sorted. The result usually differs from that which would have been obtained if a ROWNO predicate had not been used and if the first n result rows had been considered.

If a ROWNO predicate and a set function are specified, the set function is only applied to the number of lines restricted by the ROWNO predicate.


SOUNDS Predicate (sounds_predicate) (MaxDB: Reference Manual)

SOUNDS Predicate (sounds_predicate)

A SOUNDS predicate is used to perform a phonetic comparison.

Syntax

<sound_predicate> ::= <expression> [NOT] SOUNDS [LIKE] <expression>

expression

Explanation

Specifying LIKE in the SOUNDS predicate has no effect.

The values in the expressions must be alphanumeric (code attribute ASCII).

A phonetic comparison between values is carried out according to the SOUNDEX algorithm. First, all vowels and some consonants are eliminated, then all consonants which are similar in sound are mapped to each other.

x [NOT] SOUNDS [LIKE] y

 | Result of the predicate
x or y is the NULL value | x SOUNDS y is undefined
x and y are non-NULL values | x SOUNDS y is true or false
x and y are phonetically identical | x SOUNDS y is true

x NOT SOUNDS y has the same result as NOT (x SOUNDS y).

See also:

String function SOUNDEX(x)


Search Condition (search_condition) (MaxDB: Reference Manual)

Search Condition (search_condition)

A search_condition links statements that can be true, false, or undefined. Rows in a table may be found that fulfill several conditions that are linked with AND or OR.

Syntax

<search_condition> ::= <boolean_term> | <search_condition> OR <boolean_term>

<boolean_term> ::= <boolean_factor> | <boolean_term> AND <boolean_factor>

boolean factor: determine the boolean values (BOOLEAN) to be linked or their negation ( NOT).

Explanation

Predicates in a WHERE clause are applied to the specified row or a group of rows in a table formed with the GROUP clause. The results are linked using the specified Boolean operators (AND, OR, NOT).

If no parentheses are used, the precedence of the operators is as follows: NOT has a higher precedence than AND and OR, AND has a higher precedence than OR. Operators with the same precedence are evaluated from left to right.

NOT

x | NOT(x)
true | false
false | true
undefined | undefined

x AND y

x y | false | undefined | true
false | false | false | false
undefined | false | undefined | undefined
true | false | undefined | true

x OR y

x y | false | undefined | true
false | false | undefined | true
undefined | undefined | undefined | true
true | true | true | true

Example table: customer

Customers who live in New York or have a credit balance:

SELECT firstname, name, city, account FROM customer
WHERE city = 'New York' OR account > 0

FIRSTNAME | NAME | CITY | ACCOUNT
Jenny | Porter | New York | 100.00
? | DATASOFT | Dallas | 4813.50
Michael | Porter | New York | 0.00
George | Howe | New York | -315.40
Joseph | Peters | Los Angeles | 650.00
Mark | Griffith | New York | 0.00
? | TOOLware | Los Angeles | 3770.50
Rose | Brown | Hollywood | 440.00

Customers who live in Hollywood and have a credit balance:

SELECT firstname, name, city, account FROM customer
WHERE city = 'Hollywood' AND account > 0

FIRSTNAME | NAME | CITY | ACCOUNT
Rose | Brown | Hollywood | 440.00


Boolean factor (MaxDB: Reference Manual)

Boolean factor

Specifies how the Boolean values are determined that are to be linked in a search condition by AND or OR.

Syntax

<boolean_factor> ::= [NOT] <predicate> | [NOT] (<search_condition>)

predicate , search_condition


Functions: Overview (MaxDB: Reference Manual)

Functions: Overview

List of all function names

ABS | ACOS | ADDDATE
ADDTIME | ALPHA | ASCII
ASIN | ATAN | ATAN2
AVG |  |
CASE | CEIL | CHAR
CHR | COS | COSH
COT | COUNT |
DATE | DATEDIFF | DAY
DAYNAME | DAYOFMONTH | DAYOFWEEK
DAYOFYEAR | DECODE | DEGREES
EXP | EXPAND |
FIXED | FLOAT | FLOOR
GET_OBJECTNAME | GET_OWNER | GREATEST
HEX | HEXTORAW | HOUR
INDEX | INITCAP |
LEAST | LENGTH | LFILL
LN | LOG | LOWER
LPAD | LTRIM |
MAKEDATE | MAKETIME | MAX
MAPCHAR | MICROSECOND | MIN
MINUTE | MONTH | MONTHNAME
NOROUND | NUM |
PI | POWER |
RADIANS | REPLACE | RFILL
ROUND | RPAD | RTRIM
SECOND | SIGN | SIN
SINH | SOUNDEX |
SQRT | SUBDATE | SUBSTR
SUBTIME | STDDEV | SUM
TAN | TANH | TIME
TIMEDIFF | TIMESTAMP | TRANSLATE
TRIM | TRUNC |
UPPER |  |
VALUE | VARIANCE |
WEEKOFYEAR |  |
YEAR |  |
|| | & |


Function (function spec) (MaxDB: Reference Manual)

Function (function spec)

There is a series of functions that can be applied to a value (row) as an argument ( function spec) and supply a result.

Syntax

<function_spec> ::= <arithmetic_function> | <trigonometric_function>
| <string_function> | <date_function> | <time_function>
| <extraction_function> | <special_function> | <conversion_function>
| <dbfunction_call>

arithmetic_function, trigonometric_function, string_function, date_function, time_function, extraction_function, special_function, conversion_function, dbfunction_call

Explanation

The arguments and results of the functions are numeric, alphanumeric or Boolean values that are subject to certain restrictions. LONG columns are not allowed as arguments.


Arithmetic function (MaxDB: Reference Manual)

Arithmetic function

An arithmetic function is a function that supplies a numeric value as a result.

Syntax

<arithmetic_function> ::=
  TRUNC   ( <expression>[, <expression>] )
| ROUND   ( <expression>[, <expression>] )
| NOROUND ( <expression> )
| FIXED   ( <expression>[, <unsigned_integer> [, <unsigned_integer] ] )
| FLOAT   ( <expression>[, <unsigned_integer> ] )
| CEIL    ( <expression> )
| FLOOR   ( <expression> )
| SIGN    ( <expression> )
| ABS     ( <expression> )
| POWER   ( <expression>, <expression> )
| EXP     ( <expression> )
| SQRT    ( <expression> )
| LN      ( <expression> )
| LOG     ( <expression>, <expression> )
| PI
| LENGTH  ( <expression> )
| INDEX   ( <string_spec>, <string_spec> [,<expression>[, <expression>] ] )

expression , unsigned_integer , string_spec

TRUNC(a,n) , ROUND(a,n) , NOROUND(a) , FIXED(a,p,s) , FLOAT(a,s) , CEIL(a) , FLOOR(a) , SIGN(a) , ABS(a) , POWER(a,n) , EXP(a) , SQRT(a) , LN(a) , LOG(a,b) , PI , LENGTH(a) , INDEX(a,b,p,s)


ABS(a) (MaxDB: Reference Manual)

ABS(a)

ABS(a) is an arithmetic_function that determines the unsigned value (absolute value) of the number a.

 | Result of the ABS(a) function
a is NULL value | NULL value
a is special NULL value | Special NULL value


CEIL(a) (MaxDB: Reference Manual)

CEIL(a)

CEIL(a) is an arithmetic function that calculates the smallest integer value that is greater than or equal to the number a.

The result is a fixed point number with 0 decimal places.

An error message is output if it is not possible to represent the result of CEIL(a) as a fixed point number.

 | Result of CEIL(a) function
a is the NULL value | NULL value
a is special NULL value | Special NULL value


EXP(a) (MaxDB: Reference Manual)

EXP(a)

EXP(a) is an arithmetic function that calculates the power from base e (2.71828183) and the exponent a ("e to the power of a").

 | Result of EXP(a) function
a is NULL value | NULL value
a is special NULL value | Special NULL value


FIXED(a,p,s) (MaxDB: Reference Manual)

FIXED(a,p,s)

FIXED(a,p,s) is an arithmetic function that is used to output the number a in a format of the data type FIXED (p,s).

Digits after the decimal point are rounded to s decimal places, if necessary.

 | Result of the FIXED(a,p,s) function
s not specified | Result as for s=0
p not specified | Result as for p=38
ABS(a)>10exp(p-s) | Special NULL value
a is the NULL value | NULL value
a is special NULL value | Special NULL value


FLOAT(a,s) (MaxDB: Reference Manual)

FLOAT(a,s)

FLOAT(a,s) is an arithmetic function that outputs the figure a in a format of the data type FLOAT (s). It is rounded to s places if necessary.

 | Result of the FLOAT(a,s) function
a is NULL value | NULL value
a is special NULL value | Special NULL value


FLOOR(a) (MaxDB: Reference Manual)

FLOOR(a)

FLOOR(a) is an arithmetic function that calculates the largest integer value that is less than or equal to the number a.

The result is a fixed point number with 0 decimal places.

An error message is output if it is not possible to represent the result of FLOOR(a) as a fixed point number.

 | Result of the FLOOR(a) function
a is the NULL value | NULL value
a is special NULL value | Special NULL value


INDEX(a,b,p,s) (MaxDB: Reference Manual)

INDEX(a,b,p,s)

INDEX(a,b,p,s) is an arithmetic function that determines the position of the substring specified in b within the character string a.

The parameter p is optional. If p is specified (p>=1), it defines the start position for the search for the substring b. If p is not specified, the search is started at position 1.

The parameter s is optional. If s is specified, it determines the number of searches for the substring b. If s is not specified, the search is carried out for the first occurrence.

 | Result of the INDEX(a,b,p,s) function
a, b character strings and b not less than s times substring of a | 0
a character string and b empty character string | p
a,b,p or s is NULL value | NULL value
p or s is special NULL value | Error Message

Example table: customer

The position of the character string ‘er’ is to be determined in all customer surnames.

SELECT name, INDEX(name,'er') position_er FROM customer

NAME | POSITION_ER
Porter | 5
DATASOFT | 0
Porter | 5
Peters | 4
Brown | 0
Porter | 5
Howe | 0
Randolph | 0
Peters | 4
Brown | 0
Jackson | 0
Adams | 0
Griffith | 0
TOOLware | 0
Brown | 0


LENGTH(a) (MaxDB: Reference Manual)

LENGTH(a)

LENGTH(a) is an arithmetic function that specifies the number of characters or bytes that are required to represent the value a internally. The function can be used for all data types except LONG.

 | Result of the LENGTH(a) function
a is a value of data type CHAR|VARCHAR <ASCII|UNICODE> with n characters | Number of characters n
a is a value of another data type (other than LONG) of length n | Length n in bytes
a is a NULL value | NULL value
a is special NULL value | Special NULL value

The length of the number of characters or the length in bytes is determined without taking into account any trailing blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE).

Example table: customer

The customer table is sorted according to the length of the surnames, with names with the same length sorted in alphabetical order.

SELECT name, LENGTH(name) mylength
FROM customer ORDER BY mylength, name

NAME | MYLENGTH
Howe | 4
Adams | 5
Brown | 5
Brown | 5
Brown | 5
Peters | 6
Peters | 6
Porter | 6
Porter | 6
Porter | 6
Jackson | 7
DATASOFT | 8
Griffith | 8
Randolph | 8
TOOLware | 8


LN(a) (MaxDB: Reference Manual)

LN(a)

LN(a) is an arithmetic function that calculates the natural logarithm of the number a.

 | Result of the LN(a) function
a is NULL value | NULL value
a is special NULL value | Special NULL value


LOG(a,b) (MaxDB: Reference Manual)

LOG(a,b)

LOG(a,b) is an arithmetic function that calculates the logarithm of the number b to base a.

 | Result of the LOG(a,b) function
a or b is the NULL value | NULL value
b is special NULL value | Special NULL value


NOROUND(a) (MaxDB: Reference Manual)

NOROUND(a)

NOROUND(a) is an arithmetic function that prevents the result of an UPDATE or INSERT statement from being rounded so that it matches the data type of the target column.

If the non-rounded number does not correspond to the data type of the target column, an error message is output.

 | Result of the NOROUND(a) function
a is the NULL value | NULL value
a is special NULL value | Special NULL value


PI (MaxDB: Reference Manual)

PI

PI is an arithmetic function that outputs the value p.


POWER(a,n) (MaxDB: Reference Manual)

POWER(a,n)

POWER(a,n) is an arithmetic function that calculates the nth power of the number a.

An error message is output if n is not an integer.

 | Result of the POWER(a,n) function
a or n is the NULL value | NULL value
a is special NULL value | Special NULL value


ROUND(a,n) (MaxDB: Reference Manual)

ROUND(a,n)

ROUND(a,n) is an arithmetic function with the following result (for the values a and n):

ROUND(a) – round decimal places up and down
ROUND(a,n) – round up and down to the nth place on the right of the decimal point
ROUND(a,-n) – round up and down to the nth place on the left of the decimal point

 | Result of the ROUND(a,n) function
a>=0 | TRUNC (a+0.5*10E-n,n)
a<0 | TRUNC(a-0.5*10E-n,n)
n not specified | Result as for n=0
n is not an integer | The integer component of n is used and the result is as with a>=0 or a<0
a is floating point number | Floating point number
a is fixed point number | Fixed point number
a is the NULL value | NULL value
a is special NULL value | Special NULL value


SIGN(a) (MaxDB: Reference Manual)

SIGN(a)

SIGN(a) is an arithmetic function that indicates the sign of the number a.

 | Result of the SIGN(a) function
a<0 | -1
a=0 | 0
a>0 | 1
a is the NULL value | NULL value
a is special NULL value | Special NULL value


SQRT(a) (MaxDB: Reference Manual)

SQRT(a)

SQRT(a) is an arithmetic function that calculates the square root of the number a.

 | Result of the SQRT(a) function
a>0 | Square root of a
a=0 | 0
a<0 or a is NULL value | NULL value
a is special NULL value | Special NULL value


TRUNC(a,n) (MaxDB: Reference Manual)

TRUNC(a,n)

TRUNC(a,n) is an arithmetic function with the following result (for the values a and n):

TRUNC(a) – truncate the decimal places of a
TRUNC(a,n) – truncate the number a after n decimal places
TRUNC(a,-n) – set n places in the number a before the decimal point to 0

 | Result of the TRUNC(a,n) function
n>0 | Number a that is truncated n places after the decimal point
n=0 | Integer component of a
n<0 | Number a that is truncated s places in front of the decimal point
n not specified | As with n=0
n is not an integer | The integer component of n is used and the result is as with n>0, n=0, or n<0
a is floating point number | Floating point number
a is fixed point number | Fixed point number
a is the NULL value | NULL value
a is special NULL value | Special NULL value


Trigonometric function (MaxDB: Reference Manual)

Trigonometric function

A trigonometric function is a function that supplies a numeric value as a result.

Syntax

<trigonometric_function> ::=
  COS     ( <expression> )
| SIN     ( <expression> )
| TAN     ( <expression> )
| COT     ( <expression> )
| COSH    ( <expression> )
| SINH    ( <expression> )
| TANH    ( <expression> )
| ACOS    ( <expression> )
| ASIN    ( <expression> )
| ATAN    ( <expression> )
| ATAN2   ( <expression>, <expression> )
| RADIANS ( <expression> )
| DEGREES ( <expression> )

expression

All of the values (expression) in every trigonometric function identify an angle in radians. The only exception to this is the RADIANS function.

 | Result of the trigonometric function
<expression> is NULL value | NULL value
<expression> is special NULL value | Special NULL value
COS(a) | Cosine of number a
SIN(a) | Sine of number a
TAN(a) | Tangent of number a
COT(a) | Cotangent of number a
COSH(a) | Hyperbolic cosine of number a
SINH(a) | Hyperbolic sine of number a
TANH(a) | Hyperbolic tangent of number a
ACOS(a) | Arc cosine of number a
ASIN(a) | Arc sine of number a
ATAN(a) | Arc tangent of number a
ATAN2(a,b) | Arc tangent of the value a/b, where -p <=a<=+p and -p <=b<=+p
ASIN(a) | Arc sine of number a
RADIANS(a) | Angle in radians of the number a
DEGREES(a) | Value in degrees of the number a


String Function (string_function) (MaxDB: Reference Manual)

String Function (string_function)

A string function is a function that supplies an alphanumeric value as a result.

Syntax

<string_function> ::=
  <string_spec> || <string_spec>
| <string_spec> & <string_spec>
| SUBSTR    (<string_spec>,<expression>[,<expression>])
| LFILL     (<string_spec>,<string_literal>[,<unsigned_integer>])
| RFILL     (<string_spec>,<string_literal>[,<unsigned_integer>])
| LPAD      (<string_spec>,<expression>,<string_literal>[,<unsigned_integer>])
| RPAD      (<string_spec>,<expression>,<string_literal>[,<unsigned_integer>])
| TRIM      (<string_spec>[,<string_spec>])
| LTRIM     (<string_spec>[,<string_spec>])
| RTRIM     (<string_spec>[,<string_spec>])
| EXPAND    (<string_spec>,<unsigned_integer>)
| UPPER     (<string_spec>)
| LOWER     (<string_spec>)
| INITCAP   (<string_spec>)
| REPLACE   (<string_spec>,<string_spec>[,<string_spec>])
| TRANSLATE (<string_spec>,<string_spec>,<string_spec>)
| MAPCHAR   (<string_spec>[,<unsigned_integer>][,<mapchar_set_name>])
| ALPHA     (<string_spec>[,<unsigned_integer>])
| ASCII     (<string_spec>)
| SOUNDEX   (<string_spec>)
| GET_OBJECTNAME (<string_literal>)
| GET_OWNER      (<string_literal>)

string_spec, expression, string_literal, unsigned_integer, mapchar_set_name

Concatenation
(x||y bzw x&y), SUBSTR(x,a,b), LFILL(x,a,n),

RFILL(x,a,n), LPAD(x,a,y,n), RPAD(x,a,y,n), TRIM(x,y), LTRIM(x,y),

RTRIM(x,y), EXPAND(x,n),

UPPER(x)/LOWER(x),

INITCAP(x), REPLACE(x,y,z), TRANSLATE(x,y,z),

MAPCHAR(x,n,i), ALPHA(x,n),

ASCII(x),

SOUNDEX(x), GET_OBJECTNAME(x,o),

GET_OWNER(x,o)


ALPHA(x,n) (MaxDB: Reference Manual)

ALPHA(x,n)

ALPHA(x,n) is a string function that enables a character x in ASCII to be converted to a different one or two-character representation defined in the DEFAULTMAP (mapchar_set_name). ALPHA(x,n) is used to define the sort sequence.

The function ALPHA(x,n) uses the MAPCHAR(x,n,i) function internally (where i is the DEFAULTMAP) and also performs a conversion to uppercase letters (UPPER(x)).

The parameter n is optional, n specifies the maximum length of the result.

 | Result of the ALPHA(x,n) function
ALPHA(x,n) | UPPER(MAPCHAR(x,n,DEFAULTMAP))

The ALPHA function enables data to be sorted practically, for example, if "ü" is to be treated as "UE" for sorting purposes. The MAPCHAR SET with the name DEFAULTMAP is used.

SELECT...,ALPHA(<column name>) sort,...FROM...ORDER BY sort


ASCII(x) (MaxDB: Reference Manual)

ASCII(x)

ASCII(x) is a string function that converts a character string x with the code attribute ASCII or UNICODE (if this is ASCII data) to ASCII data.

 | Result of the Function ASCII(x)
Code attribute for x is ASCII or UNICODE | ASCII(x) is a character string in ASCII notation
x is a NULL value | NULL value

The ASCII functions are useful when ASCII code is to be used for sorting or comparison purposes.

Output of a sorted result table in ASCII order:

SELECT ASCII(name) FROM...WHERE...ORDER BY 1


EXPAND(x,n) (MaxDB: Reference Manual)

EXPAND(x,n)

EXPAND(x,n) is a string function that inserts x times as many blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) to the end of a character string as are needed to give the string the length specified by n.

 | Result of the EXPAND(x,n) function
x is a NULL value | NULL value

See also:

LFILL(x,a,n)

RFILL(x,a,n)


GET_OBJECTNAME(x,o) (MaxDB: Reference Manual)

GET_OBJECTNAME(x,o)

The string function GET_OBJECTNAME(x,o) returns the name of the database object.

x: Identifier of the object
The argument x is a string literal in the format[<owner>.]<identifier> or a character parameter of this type.
<owner> and <identifier> can be special identifiers .

o: Object type
You can use one of the following key words:
DBPROC[EDURE]: database procedure
DOMAIN: domain
SEQUENCE: sequence
SYNONYM: synonym
VIEW: view table
TABLE: table

 | Result of the Function GET_OBJECTNAME(x,o)
x identifies an object that is not of object type o | NULL value
Object x does not exist | NULL value
Object x exists, however the current user does not have any privileges for this object | NULL value
Object x exists for the owner specified under <owner> and the current user has a privilege for this object | <identifier>
Object x exists, and the current user has a privilege for this object | First object name found in the search hierarchy

For some object types, there is no search hierarchy. In this case, the function only searches for the object in the schema of the current user.


GET_OWNER(x,o) (MaxDB: Reference Manual)

GET_OWNER(x,o)

The string function GET_OWNER(x,o) returns the name of the owner of the specified database object.

x: Identifier of the object
The argument x is a string literal in the format[<owner>.]<identifier> or a character parameter of this type.
<owner> and <identifier> can be special identifiers .

o: Object type
You can use one of the following key words:
DBPROC[EDURE]: database procedure
DOMAIN: domain
SEQUENCE: sequence
SYNONYM: synonym
VIEW: view table
TABLE: table

 | Result of the Function GET_OWNER(x,o)
x identifies an object that is not of object type o | NULL value
Object x does not exist | NULL value
Object x exists, however the current user does not have any privileges for this object | NULL value
Object x exists for the owner specified under <owner> and the current user has a privilege for this object | <owner>
Object x exists, and the current user has a privilege for this object | First owner of this object found in the search hierarchy

For some object types, there is no search hierarchy. In this case, the function only searches for the object in the schema of the current user.


INITCAP(x) (MaxDB: Reference Manual)

INITCAP(x)

INITCAP(x) is a string function that changes a character string so that the first character of a word is an uppercase letter and the rest of the word consists of lowercase characters. When this happens, different words are split by one or more characters from the 7-bit ASCII character set that are not letters or digits (commas, blanks, or colons, for example).

 | Result of the Function INITCAP(x)
x is a NULL value | NULL value

Example table: customer

Standardizing the notation for names

SELECT name, INITCAP(name) new_name
FROM customer WHERE firstname IS NULL

NAME | NEW_NAME
DATASOFT | Datasoft
TOOLware | TOOLware


LFILL(x,a,n) (MaxDB: Reference Manual)

LFILL(x,a,n)

LFILL(x,a,n) is a string function that inserts the character string a at the start of the character string x as often as required until the character string has reached the length n. If the character string a cannot be completely inserted without exceeding the specified total length, only the part that is needed to reach the total length is inserted.

 | Result of the LFILL(x,a,n) function
LFILL(x,a) x must identify a CHAR or VARCHAR column. | The column x is filled with the characters of a until its maximum length is reached.
x is NULL value | NULL value
a or n is the NULL value | Error Message

Example table: customer

SELECT LFILL (firstname,' ',8) firstname, name, city
FROM customer
WHERE firstname IS NOT NULL AND city = 'Los Angeles'

FIRSTNAME | NAME | CITY
Martin | Porter | Los Angeles
Sally | Peters | Los Angeles
Frank | Randolph | Los Angeles
Joseph | Peters | Los Angeles
Susan | Brown | Los Angeles
Anthony | Jackson | Los Angeles
Thomas | Adams | Los Angeles

RFILL(x,a,n)

EXPAND(x,n)


LPAD(x,a,y,n) (MaxDB: Reference Manual)

LPAD(x,a,y,n)

LPAD(x,a,y,n) is a string function that inserts the character string y at the start of the character string x as often as specified by the parameter a. Leading and subsequent blanks in the character string x are truncated. The optional parameter n defines the maximum total length of the character string created.

The result of the parameter a must be a positive integer.

The optional parameter n must be greater than or equal to the total LENGTH(x)+a*LENGTH(y).

 | Result of the LPAD(x,a,y,n) function
LPAD(x,a,y) x must identify a CHAR or VARCHAR column. | The maximum length of the character string is the length of the character string x.
x or a is the NULL value | NULL value
a is the special NULL value | Error Message

Example table: customer

Creating bar charts: LPAD inserts asterisks in front of the first parameter (in this case, a blank). This is done according to the number equal to account divided by 100.

SELECT name, account, LPAD(' ',TRUNC(account/100),'*',50) graph
FROM customer WHERE account > 0 ORDER BY account DESC

NAME | ACCOUNT | GRAPH
DATASOFT | 4813.50 | ************************************************
TOOLware | 3770.50 | *************************************
Peters | 650.00 | ******
Brown | 440.00 | ****
Porter | 100.00 | *

See also:

RPAD(x,a,y,n)


LTRIM(x,y) (MaxDB: Reference Manual)

LTRIM(x,y)

LTRIM(x,y) is a string function that removes all of the characters specified in the character string y from the start of the character string x. The result of LTRIM(x,y), therefore, starts with the first character that was not specified in y.

 | Result of the LTRIM(x,y) function
LTRIM(x) | Only blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) are removed from x.
x is a NULL value | NULL value

See also:

TRIM(x,y)

RTRIM(x,y)


MAPCHAR(x,n,i) (MaxDB: Reference Manual)

MAPCHAR(x,n,i)

MAPCHAR(x,n,i) is a string function that converts country-specific letters to a different format (for example, German umlauts, French letters with a grave accent).

MAPCHAR(x,n,i) uses the MapChar set with the name i (mapchar set name) to convert the character string x. If you do not specify a MapChar set name, the MapChar set with the name DEFAULTMAP (defined for the ASCII code) is used.

The code on which the character string x is based and the code on which the implemented Mapchar set is based must match.

The parameter n is optional, n specifies the maximum length of the result.

 | Result of the MAPCHAR(x,n,i) Function
MAPCHAR(x,i) | MAPCHAR(x,n,i), where n is the length of the character string x
MAPCHAR(x,i) x is CHAR or VARCHAR column | MAPCHAR(x,n,i), where n is the length of the column x
MAPCHAR(x) | MAPCHAR(x,DEFAULTMAP)
x is a NULL value | NULL value

The function MAPCHAR enables data to be sorted correctly, for example, if "ü" is to be treated as "UE" for sorting purposes. The MAPCHAR SET with the name DEFAULTMAP is used.

SELECT...,MAPCHAR(<column_name>) sort,...FROM...ORDER BY sort


REPLACE(x,y,z) (MaxDB: Reference Manual)

REPLACE(x,y,z)

REPLACE(x,y,z) is a string function that replaces the character string y in the character string x with the character string z.

 | Result of the REPLACE(x,y,z) function
REPLACE(x,y) | The character string y in x is deleted
x is a NULL value | NULL value
y is NULL value | x remains unchanged
z is NULL value | The character string y in x is deleted

Example table: hotel

The abbreviated notation for Street (St.) is to be written out in full (Street) for the sake of uniformity.

SELECT hno, zip, city, REPLACE (address,' t.' ,' treet' ) address

FROM hotel where address like '%tr%'

HNO | ZIP | CITY | ADDRESS
10 | 89477 | Detroit | 155 Beechwood Street
20 | 86159 | Cincinnati | 1499 Grove Street
80 | 20251 | Los Angeles | 12 Barnard Street
100 | 50668 | Dallas | 1980 34th Street
110 | 81245 | New York | 111 78th Street

See also:

TRANSLATE(x,y,z)


RFILL(x,a,n) (MaxDB: Reference Manual)

RFILL(x,a,n)

RFILL(x,a,n) is a string function that inserts the character string a at the end of the character string x as often as required until the character string has reached the length n. If the character string a cannot be completely inserted without exceeding the specified total length, only the part that is needed to reach the total length is inserted.

 | Result of the RFILL(x,a,n) function
RFILL(x,a) x must identify a CHAR or VARCHAR column. | The column x is filled with the characters of a until its maximum length is reached.
x is NULL value | NULL value
a or n is the NULL value | Error message

See also:

LFILL(x,a,n)

EXPAND(x,n)


RPAD(x,a,y,n) (MaxDB: Reference Manual)

RPAD(x,a,y,n)

RPAD(x,a,y,n) is a string function that inserts the character string y at the end of the character string x as often as specified by the parameter a. Leading and subsequent blanks in the character string x are truncated. The optional parameter n defines the maximum total length of the character string created.

The result of the parameter a must be a positive integer.

The optional parameter n must be greater than or equal to the total LENGTH (x)+a*LENGTH(y).

 | Result of the RPAD(x,a,y,n) function
RPAD(x,a,y) x must identify a CHAR or VARCHAR column. | The maximum length of the character string is the length of the character string x.
x or a is the NULL value | NULL value
a is the special NULL value | Error message

See also:

LPAD(x,a,y,n)


RTRIM(x,y) (MaxDB: Reference Manual)

RTRIM(x,y)

RTRIM(x,y) is a string function that removes the blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) from the end of the character string x and then all of the characters specified in the character string y. The result of RTRIM(x,y), therefore, ends with the last character that was not specified in y.

 | Result of the RTRIM(x,y) function
RTRIM(x) | Only blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) are removed from x.
x is a NULL value | NULL value

See also:

TRIM(x,y)

LTRIM(x,y)


SOUNDEX(x) (MaxDB: Reference Manual)

SOUNDEX(x)

SOUNDEX(x) is a string function that converts a character string x to a format that is generated by the SOUNDEX algorithm.

This representation can be used if the user does not know the exact spelling of the search term.

 | Result of the SOUNDEX(x) function
SOUNDEX(x) | The SOUNDEX algorithm is used. The result is a value with the data type CHAR(4).
x is NULL value | NULL value

The SOUNDS predicate is often applied to a column x.

Since inversions cannot be used here, it is advisable for performance reasons to define an additional table column x1 with the data type CHAR(4), in which the result of SOUNDEX(x) is then inserted.

The requests should then refer to x1:
Instead of x SOUNDS LIKE <string literal> ,
use x1= SOUNDEX(<string literal>)


SUBSTR(x,a,b) (MaxDB: Reference Manual)

SUBSTR(x,a,b)

SUBSTR(x,a,b) is a string function that outputs part of x (character string with length n).

 | Result of the SUBSTR(x,a,b) function
SUBSTR(x,a,b) | Part of the character string x that starts at the ath character and is b characters long.
SUBSTR(x,a) | SUBSTR(x,a,n-a+1) supplies all of the characters in the character string x from the ath character to the last (nth) character.
b is an unsigned integer | SUBSTR(x,a,b) b can also have a value that is greater than (n-a+1).
b is not an unsigned integer | SUBSTR(x,a,b) b must not be greater than (n-a+1).
b>(n-a+1) | SUBSTR(x,a) As many blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) are appended to the end of this result as are needed to give the result the length b.
x, a or b is the NULL value | NULL value

Example table: customer

The SUBSTR function is used to reduce the firstname to one letter, add a period and a blank, and then concatenate it with the name.

SELECT SUBSTR (firstname,1,1)&'. '&name name, city
FROM customer WHERE firstname IS NOT NULL

NAME | CITY
J. Porter | New York
M. Porter | Los Angeles
S. Peters | Los Angeles
P. Brown | Hollywood
M. Porter | New York
G. Howe | New York
F. Randolph | Los Angeles
J. Peters | Los Angeles
S. Brown | Los Angeles
A. Jackson | Los Angeles
T. Adams | Los Angeles
M. Griffith | New York
I. Braun | Los Angeles


TRANSLATE(x,y,z) (MaxDB: Reference Manual)

TRANSLATE(x,y,z)

TRANSLATE(x,y,z) is a string function that replaces the ith character of the character string y with the ith character of the character string z in the character string x. The character strings y and z must have the same length.

 | Result of the TRANSLATE(x,y,z) function
x is a NULL value | NULL value
y is NULL value | x remains unchanged

Example table: customer

Each occurrence of the ith letter in the first character string is replaced by the ith letter in the second one.

SELECT name, TRANSLATE (name,'or','es') new_name
FROM customer WHERE firstname IS NOT NULL AND city = 'Los Angeles'

NAME | NEW_NAME
Porter | Pestes
Peters | Petess
Randolph | Sandelph
Peters | Petess
Brown | Bsewn
Jackson | Jacksen
Adams | Adams

See also:

REPLACE(x,y,z)


TRIM(x,y) (MaxDB: Reference Manual)

TRIM(x,y)

TRIM(x,y) is a string function that removes all of the characters specified in the character string y from the start of the character string x. The result of TRIM(x,y), therefore, starts with the first character that was not specified in y.

TRIM(x,y) also removes the blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) from the end of the character string and then all of the characters specified in the character string y. The result of TRIM(x,y), therefore, ends with the last character that was not specified in y.

 | Result of the TRIM(x,y) function
TRIM(x) | Only blanks (code attribute ASCII, UNICODE) or binary zeros (code attribute BYTE) are removed from x.
x is a NULL value | NULL value

Example table: customer

SELECT name, TRIM(CHR(account)) & ' EURO' account
FROM customer WHERE account > 0.00

NAME | ACCOUNT
Porter | 100.00 EURO
DATASOFT | 4813.50 EURO
Peters | 650.00 EURO
TOOLware | 3770.50 EURO
Brown | 440.00 EURO

See also:

LTRIM(x,y)

RTRIM(x,y)


UPPER/LOWER(x) (MaxDB: Reference Manual)

UPPER/LOWER(x)

UPPER(x) and LOWER(x) are string functions that convert a character string to uppercase/lowercase letters.

 | Result of the Function UPPER(x) or LOWER(x)
x is a NULL value | NULL value

Example table: hotel

Refining searches by specifying uppercase/lowercase letters

SELECT * FROM hotel WHERE UPPER(name) = 'REGENCY'

HNO | NAME | ZIP | CITY | ADDRESS
30 | Regency | 48153 | Portland | 477 17th Avenue


Concatenation (concatenation) (MaxDB: Reference Manual)

Concatenation (concatenation)

A concatenation (concatenation) x||y or x&y is a string function that supplies the following results for x (character string with the length n) and y (character string with the length m):

 | Result of the Concatenation
x||y or x&y | x and y are concatenated to a character string with the length n+m. If a character string originates from a column, its length is determined without taking trailing blanks into account (code attribute. ASCII, UNICODE) or binary zeros (code attribute BYTE).
x or y is the NULL value | NULL value

Columns with the same code attribute can be concatenated.

Columns with different code attributes (ASCII and UNICODE) can be concatenated together as well as with date values, time values, and timestamp values.

Example table: customer

SELECT name, zip & ' – ' & city address FROM customer
WHERE city = 'New York'

NAME | ADDRESS
Porter | 80335 – New York
Porter | 70596 – New York
Howe | 81737 – New York
Griffith | 81739 – New York


Date function (MaxDB: Reference Manual)

Date function

A date function is a function that is applied to date or timestamp values or supplies a date or timestamp value as a result.

Syntax

<date_function> ::=
  ADDDATE    ( <date_or_timestamp_expression>, <expression> )
| SUBDATE    ( <date_or_timestamp_expression>, <expression> )
| DATEDIFF   ( <date_or_timestamp_expression>, <date_or_timestamp_expression> )
| DAYOFWEEK  ( <date_or_timestamp_expression> )
| WEEKOFYEAR ( <date_or_timestamp_expression> )
| DAYOFMONTH ( <date_or_timestamp_expression> )
| DAYOFYEAR  ( <date_or_timestamp_expression> )
| MAKEDATE   ( <expression>, <expression> )
| DAYNAME    ( <date_or_timestamp_expression> )
| MONTHNAME  ( <date_or_timestamp_expression> )

date_or_timestamp_expression , expression

ADDDATE(t,a)/SUBDATE(t,a) , DATEDIFF(t,s) , DAYOFWEEK(t), WEEKOFYEAR(t), DAYOFMONTH(t), DAYOFYEAR(t) , MAKEDATE(a,b) , DAYNAME(t), MONTHNAME(t)

Explanation

Although the Gregorian calendar was not introduced until 1582, it can also be applied to date functions that use dates prior to that year. This means that every year is assumed to have either 365 or 366 days.

A variety of date and time formats (ISO, USA, EUR, JIS, INTERNAL) are available for processing date and time values.


ADDDATE/SUBDATE(t,a) (MaxDB: Reference Manual)

ADDDATE/SUBDATE(t,a)

ADDDATE(t,a) and SUBDATE(t,a) are date functions that calculate a date in the future or past.

t: date_or_timestamp_expression

a: numeric value that represents the number of days. Any decimal places in a are truncated if necessary.

 | Result of the ADDDATE(t,a)/SUBDATE(t,a) function
Addition of a to t/ subtraction of a from t | Date value or Time stamp value
t or a is NULL value | NULL value
a is special NULL value | Error Message

Example table: reservation

Increasing a reservation date by two days

SELECT arrival, ADDDATE(arrival,2) arrival2, rno
FROM reservation WHERE rno = 130

ARRIVAL | ARRIVAL2 | RNO
01/02/2002 | 03/02/2002 | 130


DATEDIFF(t,s) (MaxDB: Reference Manual)

DATEDIFF(t,s)

DATEDIFF(t,s) is a date function that calculates the number of days between a start and end date.

t and s: date_or_timestamp_expression

 | Result of DATEDIFF(t,s) function
Positive difference between t and s | Numeric value (number of days)
t or s are timestamp values | Only the dates in the timestamp value are used to calculate DATEDIFF(t,s).
t or s is NULL value | NULL value

Example table: reservation

SELECT arrival, departure, DATEDIFF(departure,arrival) difference, rno
FROM reservation WHERE rno = 130

ARRIVAL | DEPARTURE | DIFFERENCE | RNO
01/02/2002 | 03/02/2002 | 2 | 130


DAYNAME/MONTHNAME(t) (MaxDB: Reference Manual)

DAYNAME/MONTHNAME(t)

DAYNAME(t) and MONTHNAME(t) are date functions that supply the weekday or month of the specified day.

t: date_or_timestamp_expression

 | Result of the function
DAYNAME(t) or MONTHNAME(t) | Character string that supplies the name of a weekday (Sunday to Saturday) or month (January to December).
t is NULL value | NULL value


DAYOFWEEK/WEEKOFYEAR/DAYOFMONTH/DAYOFYEAR(t) (MaxDB: Reference Manual)

DAYOFWEEK/WEEKOFYEAR/DAYOFMONTH/DAYOFYEAR(t)

DAYOFWEEK(t)/WEEKOFYEAR(t)/DAYOFMONTH(t)/DAYOFYEAR(t) are date functions that calculate the following:

t: date_or_timestamp_expression

 | Result of the function
DAYOFWEEK(t) | Numeric value between 1 and 7 (weekday) The first day is Monday, the second Tuesday, etc.
WEEKOFYEAR(t) | Numeric value between 1 and 53 (calendar week of the specified day)
DAYOFMONTH(t) | Numeric value between 1 and 31 (day of the month of the specified day)
DAYOFYEAR(t) | Numeric value between 1 and 366 (day of the year of the specified day)
t is NULL value | NULL value


MAKEDATE(a,b) (MaxDB: Reference Manual)

MAKEDATE(a,b)

MAKEDATE(a,b) is a date function that supplies a date value from a year and day value.

The values a and b ( expression ) in MAKEDATE must supply numeric values.
The following restrictions also apply: a>=0 (a represents a year value)
b>0 (b represents a day value)
Decimal places in a and b are truncated if necessary.

 | Result of the MAKEDATE(a,b) function
a or b is the NULL value | NULL value
a or b is the special NULL value | Error message

MAKEDATE(1999,49) in the INTERNAL date format outputs '19990218'


date_or_timestamp_expression (MaxDB: Reference Manual)

date_or_timestamp_expression

When used in a function, the date_or_timestamp_expression argument must supply a date value , a timestamp value , or an alphanumeric value that matches the current date or timestamp format .


Time Function (time_function) (MaxDB: Reference Manual)

Time Function (time_function)

A time function ( time_function) is a function that is applied to time or timestamp values, or that supplies a time or timestamp value as a result.

Syntax

<time_function> ::=
  ADDTIME    ( <time_or_timestamp_expression>, <time_expression> )
| SUBTIME    ( <time_or_timestamp_expression>, <time_expression> )
| TIMEDIFF   ( <time_or_timestamp_expression>, <time_or_timestamp_expression> )
| MAKETIME   ( <hours>, <minutes>, <seconds> )

time_or_timestamp_expression, time_expression, hours, minutes, seconds

ADDTIME/SUBTIME(t,a), TIMEDIFF(t,s), MAKETIME(h,m,s)

A variety of date and time formats (ISO, USA, EUR, JIS, INTERNAL) are available for processing date and time values.

In the ISO and USA formats, the hours are displayed modulo 24.
In the EUR and JIS formats, a number of hours greater than 99 causes an error.
In the INTERNAL format, you can use up to 9999 hours.


ADDTIME/SUBTIME(t,a) (MaxDB: Reference Manual)

ADDTIME/SUBTIME(t,a)

ADDTIME(t,a) and SUBTIME(t,a) are time functions that calculate a time/timestamp value in the past or future.

t: time_or_timestamp_expression
a: time_expression

 | Result of the ADDTIME(t,a)/SUBTIME(t,a) function
Addition of a to t/ subtraction of a from t | Time value or time stamp value
SUBTIME(t,a) and t and a are time values | a must be less than t, otherwise an error is output
t or a is NULL value | NULL value


MAKETIME(h,m,s) (MaxDB: Reference Manual)

MAKETIME(h,m,s)

MAKETIME(h,m,s) is a time function that calculates a time value from the total number of hours, minutes, and seconds .

 | Result of the MAKETIME(h,m,s) function
h,m,s is NULL value | NULL value
h,m,s is special NULL value | Error message


TIMEDIFF(t,s) (MaxDB: Reference Manual)

TIMEDIFF(t,s)

TIMEDIFF(t,s) is a time function that calculates the time value between a start and end time.

t and s: time_or_timestamp_expression
Both arguments must have the same data type, i.e. they must be either a time value or a timestamp value .

 | Result of the TIMEDIFF(t,s) function
Positive difference between t and s | Time value
t or s are timestamp values for alphanumeric values that match the current timestamp format. | The dates contained in the timestamp value are used to calculate TIMEDIFF(t,s).
Difference of more than 9999 hours | Number of hours modulo 10000
t or s is NULL value | NULL value


hours/minutes/seconds (MaxDB: Reference Manual)

hours/minutes/seconds

When used in a function, each of these arguments ( hours , minutes or seconds ) must be an integer greater than or equal to 0.

Decimal places are truncated.


Time expression (MaxDB: Reference Manual)

Time expression

When used in a function, the argument time_expression must supply a time value or an alphanumeric value that is in the current time format .


Time or timestamp expression (MaxDB: Reference Manual)

Time or timestamp expression

When used in a function, the argument time_or_timestamp_expression must supply a time value , timestamp value , or an alphanumeric value that matches the current time or timestamp format .


Extraction function (MaxDB: Reference Manual)

Extraction function

An extraction function is a function that extracts parts of a date value , time value , or timestamp value or that calculates a date, time, or timestamp value.

Syntax

<extraction_function> ::=
  YEAR        ( <date_or_timestamp_expression> )
| MONTH       ( <date_or_timestamp_expression> )
| DAY         ( <date_or_timestamp_expression> )
| HOUR        ( <time_or_timestamp_expression> )
| MINUTE      ( <time_or_timestamp_expression> )
| SECOND      ( <time_or_timestamp_expression> )
| MICROSECOND ( <expression> )
| TIMESTAMP   ( <expression>[, <expression> ] )
| DATE        ( <expression> )
| TIME        ( <expression> )

date_or_timestamp_expression , time_or_timestamp_expression , expression

YEAR(t), MONTH(t), DAY(t) , HOUR(t), MINUTE(t), SECOND(t) , MICROSECOND(a) , TIMESTAMP(a,b) , DATE(a) , TIME(a)

A variety of date and time formats (ISO, USA, EUR, JIS, INTERNAL) are available for processing date and time values.


DATE(a) (MaxDB: Reference Manual)

DATE(a)

DATE(a) is a function ( extraction ) that calculates a date value .

 | Result of DATE(a) function
a is a date value or an alphanumeric value that matches the current date format | This date value
a is an alphanumeric value that does not match the current date format | Error message
a is a timestamp value or an alphanumeric value that matches the current timestamp format | The date value that is part of the timestamp
a is a fixed point or floating point number | Date value that is equal to the xth day after December 31, 0000 (x= TRUNC(a) )
a is NULL value | NULL value
a is special NULL value | Error message


HOUR/MINUTE/SECOND(t) (MaxDB: Reference Manual)

HOUR/MINUTE/SECOND(t)

HOUR(t), MINUTE(t), and SECOND(t) are functions ( extraction ) that extract the hours, minutes, or seconds from the specified time or timestamp value.

t: time_or_timestamp_expression

 | Result of the function
HOUR(t), MINUTE(t), or SECOND(t) | Numeric value (hours, minutes, and seconds)
t is NULL value | NULL value


MICROSECOND(a) (MaxDB: Reference Manual)

MICROSECOND(a)

MICROSECOND(a) is a function ( extraction ) that extracts the microseconds from a.

The value a must be a timestamp value or supply an alphanumeric value that matches the current timestamp format.

 | Result of MICROSECOND(a) function
MICROSECOND(a) | Numeric value (microseconds)
a is NULL value | NULL value


TIME(a) (MaxDB: Reference Manual)

TIME(a)

TIME(a) is a function ( extraction ) that calculates a time value .

 | Result of TIME(a) function
a is a time value or an alphanumeric value that matches the current time format | This time value
a is an alphanumeric value that does not match the current time format | Error message
a is a timestamp value or an alphanumeric value that matches the current timestamp format | The time value that is part of the timestamp
a is NULL value | NULL value


TIMESTAMP(a,b) (MaxDB: Reference Manual)

TIMESTAMP(a,b)

TIMESTAMP(a,b) is a function ( extraction ) that calculates a timestamp value comprising a date value , time value , and 0 microseconds.

 | Result of TIMESTAMP(a,b) function
TIMESTAMP(a) | a must be a timestamp value or an alphanumeric value that matches the current timestamp format The result is this timestamp value.
TIMESTAMP(a,b) | a must be a date value and b a time value (or alphanumeric value that matches the current format for date and time values). The result is a timestamp value calculated from a date value, time value, and 0 microseconds.
a or b is the NULL value | NULL value


YEAR/MONTH/DAY(t) (MaxDB: Reference Manual)

YEAR/MONTH/DAY(t)

YEAR(t), MONTH(t), and DAY(t) are functions ( extraction ) that extract the year, month, and day from the specified date or timestamp value.

t: date_or_timestamp_expression

 | Result of the function
YEAR(t), MONTH(t), or DAY(t) | Numeric value (year, month, day)
t is NULL value | NULL value


Special Function (special_function) (MaxDB: Reference Manual)

Special Function (special_function)

There are certain special functions (special_function) that are not restricted to specific data types.

Syntax

<special_function> ::=
  VALUE    (<expression>,<expression>,...)
| GREATEST (<expression>,<expression>,...)
| LEAST    (<expression>,<expression>,...)
| DECODE   (<check_expression>,<search_and_result_spec>,...[,<default_expression>])
| <case_function>

<check_expression> ::= <expression>
<search_and_result_spec> ::= <search_expression>,<result_expression>
<default_expression> ::= <expression>
<result_expression> ::= <expression>
<case_function> ::= <simple_case_function>|<searched_case_function>

expression

VALUE(x,y,...) , GREATEST(x,y,...), LEAST(x,y,...) , DECODE(x,y,...,z) , simple_case_function , searched_case_function


DECODE(x,y(i),...,z) (MaxDB: Reference Manual)

DECODE(x,y(i),...,z)

DECODE(x,y(i),...,z) is a special function that decodes expressions in accordance with their values.

x | check_expression | Expression ( expression) for which a comparison is to be carried out with the values in y(i)
y(i) | search_and_result_spec | <search_and_result_spec> ::= <search_expression>, <result_expression> (y(i)=u(i),v(i), i=1,...) Combination of the comparison value u(i) and the value v(i) that is to replace this comparison value
z | default_expression | Optional default value
u(i) | search_expression | Comparison value that is to be replaced by v(i) if it matches x
v(i) | result_expression | Value that is to be replace u(i)

The data types of x and u(i) must be comparable. The data types of v(i) and z must be comparable. The data types of u(i) and v(i) do not have to be comparable.

DECODE compares the values of x with the values u(i) consecutively. If a match is found, the result of DECODE is the value v(i) in the combination y(i)=u(i),v(i).

A match is present if x and u(i) are NULL values. The comparison of the special NULL value with any other value never results in a match.

If a match is not found, DECODE supplies the result of z. If z is not specified, the NULL value is the result of DECODE.

Example table: room

The room type identifiers are to be replaced in the output by an identifier declared in the DECODE function.

SELECT hno, price, DECODE (roomtype,
'SINGLE', 1, 'DOUBLE', 2, 'SUITE', 3) room_code
FROM room


GREATEST/LEAST(x,y,...) (MaxDB: Reference Manual)

GREATEST/LEAST(x,y,...)

GREATEST(x,y,...) or LEAST(x,y) is a special function that calculates the maximum or minimum value of all arguments.

The functions can be applied to any data type. The data types of the individual arguments must be comparable.

 | Result of the function
At least one argument is the NULL value | NULL value
At least one argument is the special NULL value | Special NULL value


VALUE(x,y,...) (MaxDB: Reference Manual)

VALUE(x,y,...)

VALUE(x,y,...) is a special function that can be used to replace NULL values with a non-NULL value.

The arguments of the VALUE function must be comparable. The arguments are evaluated one after the other in the specified order.

 | Result of the VALUE(x,y) function
One of the arguments is a non-NULL value | The first non-NULL value that occurs
Each argument is a special NULL value | Special NULL value
Each argument is a NULL value | NULL value

Example table: customer

The title does not occur in the output list. The word company is to be output for companies in the firstname column instead of a NULL value.

SELECT VALUE(firstname, 'company') firstname, name FROM customer

FIRSTNAME | NAME
Jenny | Porter
Company | DATASOFT
Martin | Porter
Sally | Peters
Peter | Brown
Michael | Porter
George | Howe
Frank | Randolph
Joseph | Peters
Susan | Brown
Anthony | Jackson
Thomas | Adams
Mark | Griffith
Company | TOOLware
Rose | Brown


General CASE Function (searched_case_function) (MaxDB: Reference Manual)

General CASE Function (searched_case_function)

The general CASE function (searched_case_function) is a special function that analyzes a quantity of search conditions to determine a result expression.

Syntax

<searched_case_function> ::=
CASE
  WHEN <search_condition> THEN <result_expression>
    [...]
  [ELSE <default_expression>])
END

<result_expression> ::= <expression>
<default_expression> ::= <expression>

search_condition, expression

Explanation

CASE checks the search conditions (search_condition) in succession. As soon as a search condition that is true is found, the result of the general CASE function is the value of the expression result_expression that belongs to the search condition.

If no true search expression is found, then CASE gets the result of the expression default_expression. If default_expression is not specified, then the result of CASE is NULL.

All search conditions without ROWNO Predicate are permissible. The data types of the expressions result_expression and default_expression must be comparable.

CASE
  WHEN price IS NULL THEN 'Not yet priced'
  WHEN price < 10 THEN 'Very Reasonable Title'
  WHEN price >= 10 and price < 20 THEN 'Coffee Table Title'
  ELSE 'Expensive book!'
END

See also:

Simple CASE function (simple_case_function)


Simple CASE Function (simple_case_function) (MaxDB: Reference Manual)

Simple CASE Function (simple_case_function)

The simple CASE function (simple_case_function) is a special function that analyzes a quantity of simple expressions to determine a result expression.

Syntax

<simple_case_function> ::=
CASE <check_expression>
        WHEN <search_expression> THEN <result_expression>
            [...]
        [ELSE <default_expression>])
END

<check_expression> | <search_expression> | <result_expression> | <default_expression> ::= <expression>

expression

Explanation

CASE compares the value of the comparison expression check_expression with the values of the expressions search_expression, one after the other. If values match, the result of the simple CASE function is the value of the expression result_expression that belongs to the expression search_expression.

If no values match, DECODE gets the result of the expression default_expression. If default_expression is not specified, then the result of CASE is NULL.

The data types of check_expressionand search_expressionmust be comparable. The data types of result_expression and default_expression must be comparable. The data types of search_expressionand result_expressiondo not need to be comparable.

If the values of the expressions check_expression and search_expression are NULL values, then a match exists. The comparison of the special NULL value with any other value never results in a match.

See also:

General CASE Function (searched_case_function)


Conversion Function (conversion_function) (MaxDB: Reference Manual)

Conversion Function (conversion_function)

A conversion function is a function that converts a value from one data type to another.

Syntax

<conversion_function> ::=
  NUM   ( <expression> )
| CHR   ( <expression>[, <unsigned_integer> ] )
| HEX   ( <expression> )
| HEXTORAW ( <expression> )
| CHAR  ( <expression>[, <datetimeformat> ] )

expression , unsigned_integer , datetimeformat

NUM(a) , CHR(a,n) , HEX(a) , HEXTORAW(a) , CHAR(a,t)


CHAR(a,t) (MaxDB: Reference Manual)

CHAR(a,t)

CHAR(a,t) is a function ( conversion function ) that converts the date values , time values , or timestamp values to a character string with the format for date values, time values, or timestamp values specified in t.

 | Result of the CHAR(a,t) function
CHAR(a) | The current date and time format is used for the value a.
a is the NULL value | NULL value


CHR(a,n) (MaxDB: Reference Manual)

CHR(a,n)

CHR(a,n) is a function (conversion function) that converts numbers into character strings.

The CHR function can only be applied to numeric values, character strings, and Boolean values.

 | Result of the Function CHR(a,n)
a is a numeric value | Character string that matches the CHAR representation of the numeric value a. The code attribute of the character string corresponds to the code type of the computer.
a is a character string | Unchanged character string
a is a Boolean value | T, if a=TRUE F, if a=FALSE
a is not a numeric value, a character string, or a Boolean value | Error message
CHR(a,n), n>=1 | Output with the length attribute n
CHR(a) | The length attribute n is calculated as a function of the data type and the length of a.
CHR(a) and a has data type FLOAT(p) | If p=1, then n=6 If p>1, then n=p+6
CHR(a) and a has data type FIXED(p,s) | If p=s, then n=p+s If s=0, then n=p+1
a is the NULL value | NULL value
a is the special NULL value | Error message


HEX(a) (MaxDB: Reference Manual)

HEX(a)

HEX(a) is a function ( conversion function ) that converts the argument a to hexadecimal notation. The function can be applied to any data type.

 | Result of the HEX(a) function
a is the NULL value | NULL value
a is the special NULL value | Error message


HEXTORAW(a) (MaxDB: Reference Manual)

HEXTORAW(a)

HEXTORAW(a) is a function ( conversion function ). Arguments of the function must be hexadecimal characters ( hex_digit ). The argument a is converted to a character string with the code attribute BYTE that contains the corresponding characters. During this conversion, two hexadecimal characters are converted to one character.

 | Result of the HEXTORAW(a) Function
a is the NULL value | NULL value
a is the special NULL value | Error message


NUM(a) (MaxDB: Reference Manual)

NUM(a)

NUM(a) is a function (conversion function) that converts the argument a to a numeric value.

NUM can be applied to character strings with the code attribute, date values, time values, timestamp values, and to numeric and Boolean values (BOOLEAN).

 | Result of the Function NUM(a)
a is a character string and can be interpreted as a numeric value | Corresponding numeric value
a is a numeric value | Identical numeric value (unchanged)
a is a Boolean value | 1, if a=TRUE 0, if a=FALSE
a is a character string that cannot be interpreted as a numeric value; a is a character string that does not have the code attribute ASCII, a is neither a numeric nor a Boolean value. | Error message
a is a character string that can be interpreted as a numeric value outside the range –9.9999999999999999999999999999999999999E+62, 9.9999999999999999999999999999999999999E+62 | Special NULL value
a is the NULL value | NULL value
a is the special NULL value | Special NULL value


Database Function Call (dbfunction_call) (MaxDB: Reference Manual)

Database Function Call (dbfunction_call)

A database function is called (dbfunction_call) in the same way as a function. The database function is created by executing a CREATE FUNCTION statement.

Syntax

<dbfunction_call> ::= <dbfunction_name> ( [<expression>,...] )

dbfunction_name, expression

Explanation

The current user must have the authorization to execute the function (EXECUTE privilege).


Set Function (set_function_spec) (MaxDB: Reference Manual)

Set Function (set_function_spec)

There is a series of functions that can be applied to a set of values (rows) as an argument and supply a result. These functions are referred to as set functions ( set function spec).

Syntax

<set_function_spec> ::= COUNT (*) | <distinct_function> | <all_function>

COUNT (*), distinct_function, all_function

Explanation

Set functions operate across groups of values but only return one value. The result comprises one row. If a set function is used in a statement, a similar function must also be applied to each of the other columns in the request. This, however, does not apply to columns that were grouped using GROUP BY. In this case, the value of the set function can be defined for each group.

The argument of a DISTINCT function or an ALL function is a result table or a group (the result table can be grouped using a GROUP condition).

With the exception of the COUNT(*) function, no NULL values are included in the calculation.

No locks are set for certain set functions, irrespective of the isolation level specified when the user connected to the database.

Example table: customer

SELECT SUM(account) sum_account, MIN(account) min_account,
FIXED (AVG(account),7,2) avg_account,
MAX(account) max_account, COUNT(*) number
FROM customer WHERE city = 'Los Angeles'

SUM_ACCOUNT | MIN_ACCOUNT | AVG_ACCOUNT | MAX_ACCOUNT | NUMBER
-164.17 | -4167.79 | -20.52 | 3770.50 | 8


DISTINCT Function (distinct_function) (MaxDB: Reference Manual)

DISTINCT Function (distinct_function)

The DISTINCT function ( distinct_function) is a set function that removes duplicated values and all NULLvalues.

Syntax

<distinct function>::= <set function name> ( DISTINCT <expression> )

set_function_name, expression

Explanation

The argument of a DISTINCT function is a set of values that is calculated as follows:

...

1. A result table or group (the result table can be grouped with a GROUP condition) is formed.

2. The expression is applied to each row in this result table or group.
The expression must not contain a set function.

3. All of the NULL values and duplicated values are removed (DISTINCT). Special NULL values are not removed and two special NULL values are considered identical.

The DISTINCT function is executed taking into account the relevant set function name for this set of values.

 | Result of the DISTINCT function
Set of values is empty and the DISTINCT function is applied to the entire result table | The set functions AVG, MAX, MIN, STDDEV, SUM, VARIANCE supply the NULL value as their result. The set function COUNT supplies the value 0.
There is no group to which the DISTINCT function can be applied. | The result is an empty table.
The set of values contains at least one special NULL value. | Special NULL value

Example table: customer

In how many cities do the customers live?

SELECT COUNT(DISTINCT city) number_cities FROM customer

number_cities

4


ALL function (MaxDB: Reference Manual)

ALL function

The ALL function is a set function that removes the NULL value s.

Syntax

<all_function>::= <set_function_name> ( [ALL] <expression> )

set_function_name , expression

Explanation

The argument of an ALL function is a set of values that is calculated as follows:

  1. A result table or group (the result table can be grouped with a GROUP condition) is formed.
  2. The expression is applied to each row in this result table or group.
    The expression must not contain a set function.
  3. All NULL values are removed. Special NULL value s are not removed and two special NULL values are considered identical.

The ALL function is executed taking into account the relevant set function name for the set of values.

The result of an ALL function is independent of whether the keyword ALL is specified or not.

 | Result of the ALL function
The set of values is empty and the ALL function is applied to the entire result table | The set functions AVG, MAX, MIN, STDDEV, SUM, VARIANCE supply the NULL value as their result. The set function COUNT supplies the value 0.
There is no group to which the ALL function can be applied. | The result is an empty table.
The set of values contains at least one special NULL value. | Special NULL value


Set function name (MaxDB: Reference Manual)

Set function name

Set function name is the name of a function that can be specified in a DISTINCT function and an ALL function .

Syntax

<set_function_name> ::= COUNT | MAX | MIN | SUM | AVG | STDDEV | VARIANCE

COUNT , MAX, MIN , SUM , AVG , STDDEV , VARIANCE


AVG (MaxDB: Reference Manual)

AVG

AVG is a set function.

The result of AVG is the arithmetical mean of the values of the argument.

AVG can only be applied to numeric values. The result has the data type FLOAT(38).

Example table: customer

How many corporate customers are taken into account? What is the average value of their account balance?

SELECT COUNT(*) number, FIXED (AVG(account),7,2) avg_account
FROM customer WHERE firstname IS NULL

NUMBER | AVG_ACCOUNT
2 | 4292.00


COUNT (MaxDB: Reference Manual)

COUNT

COUNT is a set function.

· COUNT(*) supplies the total number of values (rows in a result table or group).

· COUNT(DISTINCT <expression>)supplies the total number of different values (number of values in the argument of the DISTINCT function).

· COUNT(ALL <expression>)supplies the number of values that differ from the NULL value (number of values in the argument of the ALL function)

The result has the data type FIXED(10).

Example table: customer

How many customers are there?

SELECT COUNT (*) number FROM customer

number

15


MAX/MIN (MaxDB: Reference Manual)

MAX/MIN

MAX/MIN is a set function .

The result of MAX is the largest value of the argument.

The result of MIN is the smallest value of the argument.


STDDEV (MaxDB: Reference Manual)

STDDEV

STDDEV is a set function.

The result of STDDEV is the standard deviation of the values of the argument.

STDDEV can only be applied to numeric values. The result has the data type FLOAT(38).


SUM (MaxDB: Reference Manual)

SUM

SUM is a set function.

The result of SUM is the sum of the values of the argument.

SUM can only be applied to numeric values. The result has the data type FLOAT(38).


VARIANCE (MaxDB: Reference Manual)

VARIANCE

VARIANCE is a set function.

The result of VARIANCE is the variance of the values of the argument.

VARIANCE can only be applied to numeric values. The result has the data type FLOAT(38).


SQL Statements: Overview (MaxDB: Reference Manual)

SQL Statements: Overview

All SQL statements ( sql_statement) can be embedded in programming languages. For more information, see the precompiler documentation. All SQL statements, with the exception of NEXT STAMP, can be specified interactively.

Comments can be specified for every SQL statement. Example statements have been formulated, using the example tables, for many SQL statements.

SQL statements for data definition

CREATE TABLE statement | DROP TABLE statement | ALTER TABLE statement RENAME TABLE statement RENAME COLUMN statement EXISTS TABLE statement
CREATE DOMAIN statement | DROP DOMAIN statement |
CREATE SEQUENCE statement | DROP SEQUENCE statement |
CREATE SYNONYM statement | DROP SYNONYM statement | RENAME SYNONYM statement
CREATE VIEW statement | DROP VIEW statement | RENAME VIEW statement
CREATE INDEX statement | DROP INDEX statement | ALTER INDEX statement RENAME INDEX statement
COMMENT ON statement |  |
CREATE TRIGGER statement | DROP TRIGGER statement |
CREATE DBPROC statement | DROP DBPROC statement |
CREATE FUNCTION statement | DROP FUNCTION statement |

SQL statements for authorization

CREATE USER statement | DROP USER statement | ALTER USER statement RENAME USER statement GRANT USER statement
CREATE USERGROUP statement | DROP USERGROUP statement | ALTER USERGROUP statement RENAME USERGROUP statement GRANT USERGROUP statement
CREATE ROLE statement | DROP ROLE statement |
ALTER PASSWORD statement | GRANT statement | REVOKE statement

SQL statements for data manipulation

INSERT statement | UPDATE statement | DELETE statement
NEXT STAMP statement | CALL statement |

SQL statements for data query

QUERY statement | SINGLE SELECT statement | EXPLAIN statement
OPEN CURSOR statement | FETCH statement | CLOSE statement

SQL statements for transaction management

CONNECT statement | SET statement |
COMMIT statement | ROLLBACK statement | SUBTRANS statement
LOCK statement | UNLOCK statement | RELEASE statement

SQL statements for statistics management

UPDATE STATISTICS statement

MONITOR statement


Comment (sql_comment) (MaxDB: Reference Manual)

Comment (sql_comment)

A comment (sql_comment) can be included for every SQL statement.

Syntax

<sql_comment> ::= /*<comment text>*/ | --<comment text>

Explanation

You can enter any comment text.

If you use the syntax rule --<comment text> in a line, all characters entered in this line after -- are regarded as comments.

CREATE TABLE person (cno FIXED(4), first name CHAR(7), last name CHAR(7), account FIXED(7,2)) /*create table person*/


Example Tables (MaxDB: Reference Manual)

Example Tables

customer

hotel

room

reservation


customer (MaxDB: Reference Manual)

customer

Create the table customer and fill it with the values listed below.

Table Structure

CREATE TABLE customer
(cno        FIXED(4) PRIMARY KEY CONSTRAINT cno BETWEEN 1 AND 9999,
 title      CHAR(5) CONSTRAINT title IN ('Mr','Mrs','Comp'),
 name       CHAR(10) NOT NULL,
 firstname  CHAR(7),
 zip        CHAR(5) CONSTRAINT zip like '(0-9)(0-9)(0-9)(0-9)(0-9)',
 city       CHAR(12) NOT NULL,
 account    FIXED(7,2) CONSTRAINT account BETWEEN –10000 AND 10000)

Content

CNO | TITLE | NAME | FIRSTNAME | ZIP | CITY | ACCOUNT
3000 | Mrs | Porter | Jenny | 80335 | New York | 100.00
3100 | Comp | DATASOFT | ? | 50933 | Dallas | 4813.50
3200 | Mr | Porter | Martin | 10969 | Los Angeles | 0.00
3300 | Mrs | Peters | Sally | 14165 | Los Angeles | 0.00
3400 | Mr | Brown | Peter | 40233 | Hollywood | 0.00
3500 | Mr | Porter | Michael | 70596 | New York | 0.00
3600 | Mr | Howe | George | 81737 | New York | -315.40
3700 | Mr | Randolph | Frank | 22525 | Los Angeles | 0.00
3800 | Mr | Peters | Joseph | 10787 | Los Angeles | 650.00
3900 | Mrs | Brown | Susan | 13599 | Los Angeles | -4167.79
4000 | Mr | Jackson | Anthony | 10785 | Los Angeles | 0.00
4100 | Mr | Adams | Thomas | 13355 | Los Angeles | -416.88
4200 | Mr | Griffith | Mark | 81739 | New York | 0.00
4300 | Comp | TOOLware | ? | 13629 | Los Angeles | 3770.50
4400 | Mrs | Brown | Rose | 40233 | Hollywood | 440.00

Other example tables


hotel (MaxDB: Reference Manual)

hotel

Create the table hotel and fill it with the values listed below.

Table Structure

CREATE TABLE hotel
(hno     FIXED(4) PRIMARY KEY CONSTRAINT hno BETWEEN 1 AND 9999,
 name    CHAR(20) NOT NULL,
 zip     CHAR(5) CONSTRAINT zip like '(0-9)(0-9)(0-9)(0-9)(0-9)',
 city    CHAR(12) NOT NULL,
 address CHAR(25) NOT NULL)

Content

HNO | NAME | ZIP | CITY | ADDRESS
10 | Congress | 89477 | Detroit | 155 Beechwood St.
20 | Los Angeles | 86159 | Cincinatti | 1499 Grove Street
30 | Regency | 48153 | Portland | 477 17th Avenue
40 | Eight Avenue | 21109 | Los Angeles | 112 8th Avenue
50 | Lake Michigan | 20097 | Los Angeles | 354 OAK Terrace 43
60 | Airport | 60313 | New Orleans | 650 C Parkway
70 | Empire State | 80805 | New York | 65 Yellostone Dr.
80 | Midtown | 20251 | Los Angeles | 12 Barnard Street
90 | Long Beach | 45193 | Long Beach | 200 Yellostone Dr.
100 | Dallas | 50668 | Dallas | 1980 34th St.
110 | Atlantic | 81245 | New York | 111 78th Street
120 | Sunshine | 12249 | Los Angeles | 35 Broadway 77
130 | Star | 40223 | Hollywood | 13 Beechwood Place 2
140 | River Boat | 70469 | New York | 788 MAIN STREET 14
150 | Indian Horse | 69117 | Santa Clara | 16 MAIN STREET

Other example tables


room (MaxDB: Reference Manual)

room

Create the table room and fill it with the values listed below.

Table Structure

CREATE TABLE room
(hno      FIXED(4),
 roomtype  CHAR(6) CONSTRAINT roomtype IN ('SINGLE', 'DOUBLE', 'SUITE'),
 max_free FIXED(3) CONSTRAINT max_free>=0,
 price    FIXED(6,2) CONSTRAINT price BETWEEN 0.00 AND 1000.00,

 PRIMARY KEY(hno,roomtype))

The room table is linked to the hotel table via the hotel number.

Content

HNO | ROOMTYPE | MAX_FREE | PRICE
10 | DOUBLE | 45 | 200.00
10 | SINGLE | 20 | 135.00
20 | DOUBLE | 13 | 100.00
20 | SINGLE | 10 | 70.00
30 | DOUBLE | 15 | 80.00
30 | SINGLE | 12 | 45.00
40 | DOUBLE | 35 | 140.00
40 | SINGLE | 20 | 85.00
50 | DOUBLE | 230 | 180.00
50 | SINGLE | 50 | 105.00
50 | SUITE | 12 | 500.00
60 | DOUBLE | 39 | 200.00
60 | SINGLE | 10 | 120.00
60 | SUITE | 20 | 500.00
70 | DOUBLE | 11 | 180.00
70 | SINGLE | 4 | 115.00
80 | DOUBLE | 19 | 150.00
80 | SINGLE | 15 | 90.00
80 | SUITE | 5 | 400.00
90 | DOUBLE | 145 | 150.00
90 | SINGLE | 45 | 90.00
90 | SUITE | 60 | 300.00
100 | DOUBLE | 24 | 100.00
100 | SINGLE | 11 | 60.00
110 | DOUBLE | 10 | 130.00
110 | SINGLE | 2 | 70.00
120 | DOUBLE | 78 | 140.00
120 | SINGLE | 34 | 80.00
120 | SUITE | 55 | 350.00
130 | DOUBLE | 300 | 270.00
130 | SINGLE | 89 | 160.00
130 | SUITE | 100 | 700.00
140 | DOUBLE | 9 | 200.00
140 | SINGLE | 10 | 125.00
140 | SUITE | 78 | 600.00
150 | DOUBLE | 115 | 190.00
150 | SINGLE | 44 | 100.00
150 | SUITE | 6 | 450.00

Other example tables


reservation (MaxDB: Reference Manual)

reservation

Create the table reservation and fill it with the values listed below.

Table Structure

CREATE TABLE reservation
(rno       FIXED(4) PRIMARY KEY CONSTRAINT rno BETWEEN 1 AND 9999,
 cno       FIXED(4) CONSTRAINT cno BETWEEN 1 AND 9999,
 hno       FIXED(4) CONSTRAINT hno BETWEEN 1 AND 9999,
 roomtype  CHAR(6) CONSTRAINT roomtype IN ('SINGLE','DOUBLE','SUITE'),
 arrival   DATE NOT NULL,
 departure DATE CONSTRAINT departure > arrival)

A logical link between the customer, hotel, and room tables is established through the reservation table.

Content

RNO | CNO | HNO | ROOMTYPE | ARRIVAL | DEPARTURE
100 | 3000 | 80 | SINGLE | 13/11/2001 | 15/11/2001
110 | 3000 | 100 | DOUBLE | 24/12/2001 | 06/01/2002
120 | 3200 | 50 | SUITE | 14/11/2001 | 18/11/2001
130 | 3900 | 110 | SINGLE | 01/02/2002 | 03/02/2002
140 | 4300 | 80 | DOUBLE | 12/04/2001 | 30/04/2001
150 | 3600 | 70 | DOUBLE | 14/03/2002 | 24/03/2002
160 | 4100 | 70 | SINGLE | 12/04/2001 | 15/04/2001
170 | 4400 | 150 | SUITE | 01/09/2001 | 03/09/2001
180 | 3100 | 120 | DOUBLE | 23/12/2001 | 08/01/2002
190 | 4300 | 140 | DOUBLE | 14/11/2001 | 17/11/2001

Other example tables


Data Definition (MaxDB: Reference Manual)

Data Definition

The following sections contain an introduction to the data definition language (DDL) used by the database system.

SQL statements for data definition

CREATE TABLE statement | DROP TABLE statement | ALTER TABLE statement RENAME TABLE statement RENAME COLUMN statement EXISTS TABLE statement
CREATE DOMAIN statement | DROP DOMAIN statement |
CREATE SEQUENCE statement | DROP SEQUENCE statement |
CREATE SYNONYM statement | DROP SYNONYM statement | RENAME SYNONYM statement
CREATE VIEW statement | DROP VIEW statement | RENAME VIEW statement
CREATE INDEX Statement | DROP INDEX statement | ALTER INDEX statement RENAME INDEX statement
COMMENT ON statement |  |
CREATE TRIGGER statement | DROP TRIGGER statement |
CREATE DBPROC statement | DROP DBPROC statement |
CREATE FUNCTION statement | DROP FUNCTION statement |


CREATE TABLE Statement (create_table_statement) (MaxDB: Reference Manual)

CREATE TABLE Statement (create_table_statement)

A CREATE TABLE statement (create_table_statement) defines a base table.

Syntax

<create_table_statement> ::=
CREATE TABLE <table_name> (<column_definition>[,<table_description_element>,...])
[IGNORE ROLLBACK] [NO FIXED LENGTH COLUMN] [<sample_definition>]
| CREATE TABLE <table_name> [(<table_description_element>,...)]
[IGNORE ROLLBACK] [NO FIXED LENGTH COLUMN] [<sample_definition>] AS <query_expression> [<duplicates_clause> ]
| CREATE TABLE <table_name> LIKE <table_name> [IGNORE ROLLBACK]

<table_description_element> ::= <column_definition> | <constraint_definition> | <referential_constraint_definition> | <key_definition> | <unique_definition>

table_name , sample_definition , query_expression , duplicates_clause , column_definition , constraint_definition , referential_constraint_definition , key_definition , unique_definition

SQL statement for creating a table called person:

CREATE TABLE person (cno FIXED(4), firstname CHAR(7), name CHAR(7), account FIXED(7,2))

This CREATE TABLE statement comprises the keywords CREATE TABLE followed by the table name and (in parentheses) a list of column names, separated by commas. You can also define other criteria, such as a primary key, or referential integrity conditions.

Other examples: customer, hotel, reservation, room

Explanation

Executing a CREATE TABLE statement causes data that describes the table (or base table) to be stored in the database catalog. This data is called metadata.

A CREATE TABLE statement cannot contain more than one key definition (key_definition).

The table name (table_name) must not be identical with the name of an existing table of the current user.

The current user becomes the owner of the new table. In other words, he or she obtains the INSERT, UPDATE, DELETE, and SELECT privileges for this table. If the table is not a temporary table, the owner is also granted the INDEX, REFERENCES, and ALTER privileges.

See also:

Technical Specifications

Owner of a table

· The owner of a table is specified before the table name: Temporary tables are identified by the owner TEMP before their name.
If a table name has an owner other than TEMP, the owner must be identical to the name of the current user and the user must have the status database administrator (DBA user) or RESOURCE user.

· The owner of the table is not specified: the result is the same as if the current user were the owner.

CREATE TABLE … AS <query_expression> …

· If no QUERY expression (query_expression) is specified, the CREATE TABLE statement must contain at least one column definition (column_definition).

· If a query expression is specified, a base table is defined with the same structure as the result table defined by the QUERY expression.
If column definitions are specified, the column definition may only consist of a column name and the number of column definitions must be equal to the number of columns in the result table generated by the QUERY expression.
The data_type of the ith column in the base table is identical to that of the ith column in the result table generated by the QUERY expression.
The result table may also contain LONG columns.
If no column definitions are specified, the column names of the result table are used.
The rows of the result table are implicitly inserted in the generated base table. The DUPLICATES clause can be used to determine how key collisions are handled.
The QUERY expression is subject to certain restrictions that also apply to the INSERT statement.

LIKE <table_name>

If LIKE <table_name>is specified, an empty base table is created which, from the point of view of the current user, has the same structure as the source table, that is, it has all the columns with the same column names and definitions as the source table. This view does not necessarily have to be identical to the actual structure of the source table, since the user may not know all the columns because of privilege limitations.

The specified table must be either a base table, a view table, or a synonym. The user must have at least one privilege for this table.

The current user is the owner of the base table.

If all the key columns of the table specified after LIKE are contained in the base table, they form the key columns in this table. Otherwise, the database system implicitly inserts a key column SYSKEY CHAR(8) BYTE which then represents the key for the base table.

DEFAULT specifications or CONSTRAINT definitions for columns that are copied to the base table also apply to the new base table.

IGNORE ROLLBACK

IGNORE ROLLBACK is optional and can only be specified for temporary tables. Temporary tables with this characteristic are not affected by the transaction mechanism; i.e., changes affecting these tables are not reversed by rolling back a transaction.

NO FIXED LENGTH COLUMN

NO FIXED LENGTH COLUMN is optional. If you specify NO FIXED LENGTH COLUMN, all character columns and numeric columns are stored with variable lengths. The only columns excluded from this rule are the first n-1 primary key columns and any columns whose length does not exceed 2.

For character columns, this is the same as specifying VARCHAR.

SQL Statements for Changing Table Properties

Adding and Deleting Columns; Changing Data Types; Changing the CONSTRAINT Definition

ALTER TABLE statement

Renaming Columns

RENAME COLUMN statement

Renaming Tables

RENAME TABLE statement


SAMPLE definition (MaxDB: Reference Manual)

SAMPLE definition

A SAMPLE definition defines the number of rows in a table that are to be used when statistics are updated.

Syntax

<sample_definition> ::= SAMPLE <unsigned_integer> ROWS
| SAMPLE <unsigned_integer> PERCENT

unsigned_integer

Explanation

The database system manages statistics for each base table. These statistics are used to determine the best strategy for executing an SQL statement. The statistics are stored in the catalog by the UPDATE STATISTICS statement .

If a SAMPLE definition is specified in an UPDATE STATISTICS statement, it specifies the number of rows in the table that are to be used to calculate the statistics.

If a SAMPLE definition is not specified in an UPDATE STATISTICS statement and if it is not mandatory that all of the rows in the table be used to calculate the statistics, the database system uses the appropriate SAMPLE definition of the CREATE TABLE or ALTER TABLE statement.

The number of rows for which the UPDATE STATISTICS statement is to be executed can be defined by specifying a numeric or percentage value.

  • If a SAMPLE definition is specified as a PERCENT, the unsigned integer must be between 1 and 100.
  • If a SAMPLE definition is not defined, the database system uses the value 20000 ROWS.

SQL statements in which the SAMPLE definition can be used

CREATE TABLE statement

ALTER TABLE statement

UPDATE STATISTICS statement


Column Definition (column_definition) (MaxDB: Reference Manual)

Column Definition (column_definition)

A column definition defines a column in a table. The name and data type of each column are defined by the column name and data type. The column names must be unique within a base table.

Syntax

<column_definition> ::= <column_name> <data_type> [<column_attributes>]
| <column_name> <domain_name> [<column_attributes>]

column_name, data_type, column_attributes, domain_name

Explanation

If the [PRIMARY] KEY column attribute is specified, the CREATE TABLE statement must not contain a key definition.

A column definition may only consist of a column name if a QUERY expression is used in the CREATE TABLE statement.

If a column name and domain name (the name of a value range) are specified, the domain name must identify an existing domain. The data type and the length of the domain are assigned to the specified column. If the domain has a constraint_definition, the effect is the same as if the corresponding CONSTRAINT definition were specified in the column attribute of the column definition.

Columns, which are part of the key, or for which NOT NULL was defined, are called NOT NULL columns. A NULL value cannot be inserted in these columns.

· Mandatory columns: NOT NULL columns for which a DEFAULT specification has not been declared as a column attribute are called mandatory columns. Whenever rows are inserted, values must be specified for these columns.

· Optional columns: columns that are not mandatory are referred to as optional columns. A value does not have to be specified when a row is inserted in these columns. If a DEFAULT specification exists for the column, the default value is entered in the column. If there is no DEFAULT specification, a NULL value is entered in the column.

Memory requirements of a column value as a function of the data type

See also:

Technical Specifications


Data Type (data_type) (MaxDB: Reference Manual)

Data Type (data_type)

As well as specifying the column name when you define columns, you can also specify data types.

Syntax

<data_typ> ::=
  CHAR[ACTER] [(<unsigned_integer>)] [ASCII | BYTE | UNICODE]
| VARCHAR [(<unsigned_integer>)] [ASCII | BYTE | UNICODE]
| LONG [VARCHAR] [ASCII | BYTE | UNICODE]
| BOOLEAN
| FIXED (<unsigned_integer> [,<unsigned_integer>])
| FLOAT (<unsigned_integer>)
| INT[EGER] | SMALLINT
| DATE | TIME | TIMESTAMP

unsigned_integer

CHAR[ACTER] , VARCHAR , LONG[VARCHAR] , BOOLEAN , FIXED , FLOAT , INT[EGER] , SMALLINT , DATE , TIME , TIMESTAMP

Explanation

For the following character strings, a code attribute can be entered as part of a column_definition, if required: CHAR[ACTER], VARCHAR, LONG[VARCHAR]

In addition to the data types defined above, the following data types are permitted in a column definition and are mapped as follows to the data types below:

Data Type | Is Mapped To
BINARY(p) | FIXED(p)
DEC[IMAL](p,s) | FIXED(p,s)
DEC[IMAL](p) | FIXED(p)
DEC[IMAL] | FIXED (5)
DOUBLE PRECISION | FLOAT(38)
FLOAT | FLOAT(16)
FLOAT(39..64) | FLOAT(38)
LONG VARCHAR | LONG
NUMERIC(p,s) | FIXED(p,s)
NUMERIC(p) | FIXED(p)
NUMERIC | FIXED (5)
REAL(p) | FLOAT(p)
REAL | FLOAT(16)
SERIAL | FIXED(10) DEFAULT SERIAL
SERIAL(p) | FIXED(10) DEFAULT SERIAL(p)

See also:

Data Type

Memory requirements of a column value as a function of the data type


CHAR[ACTER] (MaxDB: Reference Manual)

CHAR[ACTER]

Definition

An alphanumerical column is defined. Specification of length attribute n is optional. If no other length attribute is specified, then n=1.

CHAR[ACTER] [(n)]: 0<n<=8000
CHAR[ACTER] [(n)] UNICODE: 0<n<=4000

The database system determines, in accordance with n, whether the values in the column are stored with a fixed or variable length. If you want to store the values in a variable length regardless of the value of n, you must use VARCHAR.

Use

Specification of data type CHAR[ACTER] in column definition, with a code attribute, if required.

Integration

Data type (data_type)


VARCHAR (MaxDB: Reference Manual)

VARCHAR

Definition

An alphanumerical column is defined. Specification of length attribute n is optional. If no other length attribute is specified, then n=1.

VARCHAR [(n)]: 0<n<=8000
VARCHAR [(n)] UNICODE: 0<n<=4000

Use VARCHAR (n) if the values in the column are to be stored with a variable length, irrespective of n.

Use

Specification of data type VARCHAR in column definition , with a code attribute , if required.

Integration

Data type (data_type)


LONG[VARCHAR] (MaxDB: Reference Manual)

LONG[VARCHAR]

Definition

An alphanumeric column is defined with any length (not for temporary tables).

LONG[VARCHAR]: A maximum of 2 GB of characters can be written in a LONG column.
LONG[VARCHAR] UNICODE: A maximum of 2 GB bytes can be written in a LONG column.

You can only give LONG columns NOT NULL or a DEFAULT specification as a column attribute .

Use

Specification of data type LONG in column definition , with a code attribute , if required.

LONG columns can be used in the following SQL statements:
INSERT statement , UPDATE statement , NULL predicate , and in selected columns .

Integration

Data type (data_type)


BOOLEAN (MaxDB: Reference Manual)

BOOLEAN

Definition

BOOLEAN: The column is given the data type BOOLEAN .

Use

Specifying the data type BOOLEAN when defining columns

Integration

Data type (data_type)


FIXED (MaxDB: Reference Manual)

FIXED

Definition

FIXED (p,s): A column with a fixed point number with precision p and with s number of decimal places (0<p<=38, s<=p). If no s is specified, it is assumed that the decimal places are 0.

Use

Specifying the data type FIXED when defining columns

Integration

Data type (data_type)


FLOAT (MaxDB: Reference Manual)

FLOAT

Definition

FLOAT (p): A column with a floating point number with precision p (0<p<=38).

Use

Specifying the data type FLOAT when defining columns

Integration

Data type (data_type)


INT[EGER] (MaxDB: Reference Manual)

INT[EGER]

Definition

INT[EGER]: This data type is the same as FIXED (10.0). Its permitted values are between -2147483648 and 2147483647.

Use

Specifying the data type INT[EGER] when defining columns

Integration

Data type (data_type)


SMALLINT (MaxDB: Reference Manual)

SMALLINT

Definition

SMALLINT: This data type is the same as FIXED (5.0). Its permitted values are between -32768 and 32767.

Use

Specifying the data type SMALLINT when defining columns

Integration

Data type (data_type)


DATE (MaxDB: Reference Manual)

DATE

Definition

DATE: An alphanumeric column in which you can store date values .

Use

Specifying the data type DATE when defining columns

Integration

Data type (data_type)


TIME (MaxDB: Reference Manual)

TIME

Definition

TIME: An alphanumeric column in which you can store time values .

Use

Specifying the data type TIME when defining columns

Integration

Data type (data_type)


TIMESTAMP (MaxDB: Reference Manual)

TIMESTAMP

Definition

TIMESTAMP: An alphanumeric column in which you can store time stamp values .

Use

Specifying the data type TIMESTAMP when defining columns

Integration

Data type (data_type)


Memory Requirements of a Column Value per Data Types (MaxDB: Reference Manual)

Memory Requirements of a Column Value per Data Types

In the column definition (column_definition), the memory requirement of a column value depends on the data type (data_type).

Data Type | Memory Requirements of a Column Value in Bytes for This Data Type
FIXED(p,s) | (p+1) DIV 2 + 2
FLOAT(p) | (p+1) DIV 2 + 2
BOOLEAN | 2
DATE | 9
TIME | 9
TIMESTAMP | 21
LONG | 9
CHAR(n); n<=30 | n+1
CHAR(n); 30<n<=1023; key column | n+1
CHAR(n); 30<n<=254; no key column | n+2
CHAR(n); 254<n; no key column | n+3
CHAR(n) UNICODE; n<=15 | 2*n+1
CHAR(n) UNICODE; 15<n<=511; key column | 2*n+1
CHAR(n) UNICODE; 15<n<=127; no key column | 2*n+2
CHAR(n) UNICODE; 127<n; no key column | 2*n+3
VARCHAR(n); n<=1023; key column | n+1
VARCHAR(n); n<=254; no key column | n+2
VARCHAR(n); 254<n; no key column | n+3
VARCHAR(n) UNICODE; n<=511; key column | 2*n+1
VARCHAR(n) UNICODE; n<=127; no key column | 2*n+2
VARCHAR(n) UNICODE; 127<n; no key column | 2*n+3


Column Attributes (column_attributes) (MaxDB: Reference Manual)

Column Attributes (column_attributes)

A column_definition can contain the column name and column attributes.

Syntax

<column_attributes>

::= [<key_or_not_null_spec>] [<default_spec>] [UNIQUE]

[<constraint_definition>]
[REFERENCES <referenced_table> [(<referenced_column>)]

[<delete_rule>]]

<key_or_not_null_spec> ::= [PRIMARY] KEY | NOT NULL [WITH DEFAULT]

default_spec, constraint_definition, delete_rule

· A CONSTRAINT definition defines a condition that must be fulfilled by all the column values in the columns defined by the column definition.

· [REFERENCES <referenced_table> [(<referenced_column>)] [<delete_rule>]
has the same effect as specifying the referential CONSTRAINT definition
FOREIGN KEY [<referential_constraint_name>] (<referencing_column>)
REFERENCES <referenced_table> [(<referenced_column>,...)] [<delete_rule>]

referenced_table
referenced_column

referenced table
referenced column

Explanation

The [PRIMARY] KEY and UNIQUE column attributes must not be used together in a column definition.

If the [PRIMARY] KEY column attribute is specified, the CREATE TABLE statement must not contain a key definition.

LONG data type: you may only specify NOT NULL or a DEFAULT specification as a column attribute for LONG columns.

UNIQUE

The UNIQUE column attribute determines the uniqueness of column values (see also CREATE INDEX statement).

KEY

If the KEY column attribute is specified, this column is part of the key of a table and is called the key column. The database system ensures that the key values in a table are unique. To improve performance, the key should start with key columns which can assume many different values and which are to be used frequently in conditions with the "=" operator.

See also:

Technical Specifications

If a table is defined without a key column, the database system implicitly creates a key column SYSKEY CHAR(8) BYTE. This column is not visible with a SELECT *. However, it can be specified explicitly and has then the same function as a key column. The SYSKEY column can be used to obtain unique keys generated by the database system. The keys are in ascending order, thus reflecting the order of insertion in the table. The key values in the SYSKEY column are only unique within a table; that is, the SYSKEY column in two different tables may contain the same values. If a unique key is required across the entire database system, a key column of the data type CHAR(8) BYTE with the DEFAULT specification STAMP can be defined.

NOT NULL

NOT NULL must not be used together with the DEFAULT specification DEFAULT NULL.

NOT NULL WITH DEFAULT defines a default value that is dependent on the data type of the column. NOT NULL WITH DEFAULT must not be used with any of the DEFAULT specifications.

Column Data Type | DEFAULT Value
CHAR (n); VARCHAR (n) | ' '
CHAR(n) BYTE; VARCHAR(n) BYTE | X'00'
FIXED (p,s), INT, SMALLINT, FLOAT (p) | 0
DATE | DATE
TIME | TIME
TIMESTAMP | TIMESTAMP
BOOLEAN | FALSE


DEFAULT Specification (default_spec) (MaxDB: Reference Manual)

DEFAULT Specification (default_spec)

A DEFAULT specification is formed by specifying the keyword DEFAULT and a DEFAULT value The maximum length of a default value is 254 characters.

Syntax

<default_spec> ::= DEFAULT <literal> | DEFAULT NULL
| DEFAULT USER | DEFAULT USERGROUP | DEFAULT SYSDBA
| DEFAULT DATE | DEFAULT TIME | DEFAULT TIMESTAMP
| DEFAULT UTCDATE | DEFAULT UTCDIFF | DEFAULT TIMEZONE
| DEFAULT TRUE | DEFAULT FALSE
| DEFAULT TRANSACTION | DEFAULT STAMP
| DEFAULT SERIAL[(<unsigned_integer>)]

literal, unsigned integer

Explanation

If a DEFAULT specification has been made for a column, the default value (<literal>, NULL, USER,...) must be a value that can be inserted in the column.

DEFAULT Specification

Explanation

DEFAULT <literal>

The literal must be comparable with the data type of the column.

DEFAULT USER

Gets the user name of the current user and can only be specified for columns that have the data type [VAR]CHAR(n) or CHAR(n) (n >= 32)

DEFAULT USERGROUP

Gets the user group name for members of a user group, or the user name for users who do not belong to a user group. This DEFAULT specification can only be specified for columns that have the data type [VAR]CHAR(n) (n >= 32).

DEFAULT SYSDBA

Gets the name of the SYSDBA user and can only be specified for columns that have the data type [VAR]CHAR(n) (n >= 32) (from version 7.4.04.02)

DEFAULT DATE

Gets the current date and can only be specified for columns that have the data type DATE

DEFAULT TIME

Gets the current time and can only be specified for columns that have the data type TIME

DEFAULT TIMESTAMP

Gets the current timestamp and can only be specified for columns that have the data type TIMESTAMP

DEFAULT UTCDATE

Gets the current UTC timestamp (Greenwich Mean Time) and can only be specified for columns that have the data type TIMESTAMP (from Version 7.4.04.02)

DEFAULT UTCDIFF

Gets the time difference (in hours) between your local time and UTC time and can only be specified for columns that have the data type FLOAT(p) (p >= 4) or FIXED(p,s) (s >= 2, p >= s+2) (from Version 7.4.04.02).

DEFAULT TIMEZONE

Gets the time difference (in hours) between your local time and UTC time and can only be specified for columns that have the data type FLOAT(p) (p >= 6) or FIXED(p,s) (s >= 0, p >= s+6). (ab Version 7.4.04.02)

DEFAULT TRUE/DEFAULT FALSE

Can only be specified for columns that have the data type BOOLEAN

DEFAULT TRANSACTION

Gets the ID of the current transaction and can only be specified for columns that have the data type CHAR(n) BYTE (n>=8)

DEFAULT STAMP

Gets an eight-character value that is unique within the database system. Can only be specified for columns that have the data type CHAR(n) BYTE (n>=8).

If a table is defined without a key column, the database system implicitly creates a key column SYSKEY CHAR(8) BYTE. The key values in the SYSKEY column are only unique within a table; that is, the SYSKEY column in two different tables may contain the same values. If you want a unique key across the entire database system, you can define a key column with the DEFAULT specification STAMP.

DEFAULT SERIAL [(<unsigned_integer)]

Gets a number generator for positive integers and can only be specified for columns that have the data type INTEGER, SMALLINT, and FIXED without decimal places (SERIAL).

The first value generated by the generator can be defined by specifying an unsigned integer (must be greater than 0). If this definition is missing, 1 is defined as the first value.

If an INSERT statement inserts the value in this column, you get the current number generator value and not the value 0.

Each table must not contain more than one column with the DEFAULT specification DEFAULT SERIAL.


CONSTRAINT definition (constraint_definition) (MaxDB: Reference Manual)

CONSTRAINT definition (constraint_definition)

A CONSTRAINT definition defines an integrity condition (restrictions for column values, see data integrity ) that must be fulfilled by all the rows in one table.

Syntax

<constraint_definition> ::= CHECK <search_condition>
| CONSTRAINT <search_condition>
| CONSTRAINT <constraint_name> CHECK <search_condition>

search condition , constraint name

Simple constraint (for one column), example table customer

title CHAR(7) CONSTRAINT title IN ('Mr','Mrs','Comp')

Complex constraint (for several columns), example table reservation

arrival DATE NOT NULL
departure DATE CONSTRAINT departure > arrival

The system checks whether the arrival is before the departure.

Explanation

A CONSTRAINT definition defines an integrity condition that must be fulfilled by all the column values in the columns defined by the column definition with CONSTRAINT definition.

The CONSTRAINT definition in a column is checked when a row is inserted and a column changed that occurs in the CONSTRAINT definition. If the CONSTRAINT definition is violated, the INSERT or UPDATE statement fails.

When you define a constraint, you specify implicitly that the NULL value is not permitted as an input.

The search condition ( search_condition) of the CONSTRAINT definition must not contain a subquery .

The search condition of the CONSTRAINT definition must only contain column names in the form <column name>.

Constraint name

· No constraint name:
The database system assigns a constraint name that is unique for the table in question.

· Constraint name is specified:
The constraint name must be different to all other constraint names for this table.

Number of columns in a search condition

· Contains only one column name in the table:
When the table is created (CREATE TABLE statement), you can check whether an additional DEFAULT value (default_spec) specified as a column attribute fulfills the search condition. If it is not true, the CREATE TABLE statement fails.

· Contains more than one column name in the table:
When the table is created (CREATE TABLE statement), it is not possible to decide whether DEFAULT values of the table columns fulfill the search condition. In this case, an attempt to insert DEFAULT values in the table when an INSERT or UPDATE statement is executed may fail.


Referential CONSTRAINT Definition (referential_constraint_defini (MaxDB: Reference Manual)

Referential CONSTRAINT Definition (referential_constraint_definition)

A referential CONSTRAINT definition defines an integrity condition (restrictions for columns values, see data integrity) that must be satisfied by all the rows in two tables. The resultant dependency between two tables affects changes to the rows contained in them.

Syntax

<referential_constraint_definition> ::=
FOREIGN KEY [<referential_constraint_name>] (<referencing_column>,...)
REFERENCES <referenced_table> [(<referenced_column>,...)] [<delete_rule>]

referential_constraint_name, delete_rule

referenced_table referenced_column | Referenced table, referenced column (table/column that is to be addressed)
referencing_column | Referencing column (column that establishes the link to the column that is to be addressed)

Dependency between the model tables customer and reservation. The referential CONSTRAINT definition is specified when the reservation table is defined. The reservation table is assigned a foreign key that corresponds to the key in the customer table.

CREATE TABLE reservation (rno FIXED(4) PRIMARY KEY, cno FIXED(4), hno FIXED(4), roomtype CHAR(6), arrival DATE, departure DATE,

FOREIGN KEY customer_reservation (cno) REFERENCES customer ON DELETE CASCADE)

The defined relationship is called customer_reservation. The DELETE rule ON DELETE CASCADE specifies that deleting rows in the customer table causes the associated rows in the reservation table to be deleted automatically.

Explanation

A referential CONSTRAINT definition can be used in a CREATE TABLE statement or ALTER TABLE statement (ADD definition). The table specified in the corresponding statement (table_name) is referred to in the following sections as the referencing table.

The referencing columns are specified in the referential CONSTRAINT definition. The referencing columns must denote columns in the referencing table and must all be different. They are also called foreign key columns.

Referenced columns (referenced_column)

· If no referencing columns are specified, the result is the same as if the key columns in the referenced table were specified in the defined sequence.

· If referenced columns are specified that are not the key in the referencing table, the referenced table must have a UNIQUE definition whose column names and sequence match those of the referenced columns.

Relationship between referenced and referencing columns:

· The number of referenced columns is equal to the number of referencing columns.

· The nth referencing column corresponds to the nth referenced column.

· The data type and the length of each referencing column must match the data type and length of the corresponding referenced column.

The referencing table and the referenced table must be base tables, but not temporary base tables.

The current user must have the ALTER privilege for the referencing table and the REFERENCE privilege for the referenced table.

Name of a referential constraint (referential_constraint_name)

The name of a referential constraint can be specified after the keywords FOREIGN KEY.

· If the name of a referential constraint is specified, it must be different from all other names of referential constraints for the referencing table.

· If no referential constraint name is specified, the database system assigns a unique name (based on the referencing table).

Inserting and modifying rows in the referenced table

The following restrictions apply when rows in the referencing table are added or modified:

Let Z be an inserted or modified row. Rows can only be inserted or modified if one of the following conditions is fulfilled for the associated referenced table:

· Z is a matching row

· Z contains a NULL value in one of the referencing columns.

· The referential CONSTRAINT definition defines the DELETE rule ON DEFAULT SET DEFAULT, and Z contains the DEFAULT value in each referencing column.

Further terms

· DELETE rule

· CASCADE dependency

· Reference cycle

· A referential CONSTRAINT definition is self-referencing if the referenced and referencing tables are identical.
With self-referencing referential CONSTRAINT definitions, the order in which a DELETE statement is processed can be important.
Specifying CASCADE: all of the rows affected by the DELETE statement are first deleted irrespective of the referential CONSTRAINT conditions. All matching rows in the rows that have just been deleted are then also deleted. As a result, all of the matching rows in the previous deletion operation are deleted, etc.
Specifying SET NULL or SET DEFAULT: all of the rows affected by the DELETE statement are first deleted irrespective of the referential CONSTRAINT conditions. Following this, SET NULL or SET DEFAULT is applied to the matching row.

· When rows are deleted from a referenced table, the number of rows deleted is entered in the third SQLERRD entry in the SQLCA database.

· When an INSERT or UPDATE statement is applied to a referencing table, the database system uses a blocking behavior for the referenced table that corresponds to isolation level 1, irrespective of the isolation level defined for the current session.
When a DELETE statement is applied to a referenced table, the database system uses a locking behavior that corresponds to isolation level 3.


DELETE rule (MaxDB: Reference Manual)

DELETE rule

The DELETE rule defines the effects that deleting a row in the referenced table has on the referencing table (see referential_constraint_definition ). The DELETE rule is also used when column attributes are defined.

Syntax

<delete_rule> ::= ON DELETE CASCADE | ON DELETE RESTRICT
| ON DELETE SET DEFAULT | ON DELETE SET NULL

Explanation

  • No DELETE rule: deleting a row in the referenced table will fail if matching rows exist.
  • ON DELETE CASCADE: if a row in the referenced table is deleted, all of the matching rows are deleted.
  • ON DELETE RESTRICT: deleting a row in the referenced table will fails if matching rows exist.
  • ON DELETE SET DEFAULT: if a row in the referenced table is deleted, the associated DEFAULT value is assigned to each referencing column for each matching row.
    A     DEFAULT specification must exist for each referencing column.
  • ON DELETE SET NULL: if a row in the referenced table is deleted, a NULL value is assigned to each referencing column of every matching row.
    None of these referencing tables may be a NOT NULL column.


CASCADE dependency (MaxDB: Reference Manual)

CASCADE dependency

A table T* is CASCADE dependent on table T if a series of referential CONSTRAINT definitions R1, R2, ..., Rn (n>=1) exist where:

  • T* is the referencing table of R1
  • T is the referenced table of Rn
  • All of the referential CONSTRAINT definitions use CASCADE from the DELETE rule or from the CASCADE option .
  • For i=1,...,n-1, n>1 is the referenced table of Ri is equal to the referencing table of Ri+1

Let R1 and R2 be two different referential CONSTRAINT definitions with the same referencing table S. T1 denotes the referenced table of R1, T2 denotes the referenced table of R2.

If T1 and T2 are identical, or if a table T exists so that T1 and T2 are CASCADE dependent on T, then R1 and R2 must both specify either CASCADE or RESTRICT.

There are different sequences of referential CONSTRAINT definitions that link the tables S and T. A DELETE statement on table T results in an action in table S. In order to ensure that the result of the DELETE statement does not depend on which of the two sequences of referential CONSTRAINT definitions is processed, the above restriction was selected for R1 and R2.

See also:

CASCADE option


Reference cycle (MaxDB: Reference Manual)

Reference cycle

A reference cycle is a sequence of referential CONSTRAINT definitions R1, R2,...,Rn where n>1, so that the following applies:

  • i=1,...,n-1 the referenced table of Ri is equal to the referencing table of Ri+1
  • the reference table of Rn is the referencing table of R1

A reference cycle in which all of the referential CONSTRAINT definitions specify CASCADE ( CASCADE dependency ) is not allowed.

A reference cycle in which one referential CONSTRAINT definition does not specify CASCADE and all other referential CONSTRAINT definitions specify CASCADE is not allowed.


Matching row (MaxDB: Reference Manual)

Matching row

A row in the referencing table is called a matching row of a row in the referenced table if the values of the corresponding referencing and referenced columns are identical.

A referential CONSTRAINT definition defines a 1:n relationship between two tables. This means that more than one matching row can exist for each row in the referenced table.

A row in the referenced table in a referenced column cannot be changed if at least one matching row exists.


Key Definition (key_definition) (MaxDB: Reference Manual)

Key Definition (key_definition)

A key definition in a CREATE TABLE statement or an ALTER TABLE statement defines the key of a base table. The key definition is introduced by the keywords PRIMARY KEY.

Syntax

<key_definition> :: PRIMARY KEY (<column_name>,...)

column_name

SQL statement for creating a person table with a one-column primary key for the column cno:

CREATE TABLE person (cno FIXED(4), firstname CHAR(7), name CHAR(7), account FIXED(7,2), PRIMARY KEY (cno))

Rows are inserted in the same way as in a base table without a key definition. Double entries for the customer number, however, are rejected.

Explanation

The column name must identify a column in the base table. The specified column names are key columns in the table.

A key column must not identify a column of the data type LONG and is always a NOT NULL column. The database system ensures that no key column has a NULL value and that no two rows of the table have the same values in all key columns.

See also:

Technical Specifications


UNIQUE Definition (unique_definition) (MaxDB: Reference Manual)

UNIQUE Definition (unique_definition)

A UNIQUE definition in the CREATE TABLE statement defines the uniqueness of column value combinations.

Syntax

<unique_definition> ::= [CONSTRAINT <index_name>] UNIQUE (<column_name>,...)

index_name, column_name

Explanation

Specifying a UNIQUE definition in a CREATE TABLE statement has the same effect as specifying the CREATE TABLE statement without a UNIQUE definition, but with a CREATE INDEX statement with UNIQUE.

· Index name specified: the generated index is stored under this name in the database catalog.

· No index name: The database system assigns a unique index name to the index.


DROP TABLE Statement (drop_table_statement) (MaxDB: Reference Manual)

DROP TABLE Statement (drop_table_statement)

A DROP TABLE statement (drop_table_statement) deletes a base table.

Syntax

<drop table statement> ::= DROP TABLE <table name> [<cascade option>]

table name, cascade option

Explanation

The table name must be the name of an existing base table. The current user must be the owner of the base table.

All of the metadata and rows in the base table are deleted, along with the view tables, indexes, privileges, synonyms, and referential CONSTRAINT definitions derived from them.

CASCADE option RESTRICT: the DROP TABLE statement will fail if view tables or synonyms are based on the specified table.

CASCADE option (cascade_option) CASCADE: The DROP TABLE statement is executed independently of the dependencies.

No CASCADE option specified: the CASCADE value is accepted.

If all of the data that is linked to this base table by means of a referential constraint definition with a DELETE rule, is processed according to the specified DELETE rule, a DELETE statement must first be executed for this base table and then the DROP TABLE statement.


CASCADE Option (cascade_option) (MaxDB: Reference Manual)

CASCADE Option (cascade_option)

A CASCADE option determines the deletion behavior for objects (e.g. tables, users), that is, it defines whether certain dependencies are to be taken into account when objects are deleted.

Syntax

<cascade_option> ::= CASCADE | RESTRICT

Explanation

CASCADE: Dependencies are not taken into account

RESTRICT: Dependencies are to be taken into account

DROP TABLE statement

DROP USER statement

DROP USERGROUP statement

DROP VIEW statement

DROP definition

REVOKE statement

See also:

CASCADE dependency


ALTER TABLE statement (alter_table_statement) (MaxDB: Reference Manual)

ALTER TABLE statement (alter_table_statement)

An ALTER TABLE statement changes the properties of a base table (see Table).

Syntax

<alter_table_statement> ::=
  ALTER TABLE <table_name> <add_definition>
| ALTER TABLE <table_name> <drop_definition>
| ALTER TABLE <table_name> <alter_definition>
| ALTER TABLE <table_name> <column_change_definition>
| ALTER TABLE <table_name> <modify_definition>
| ALTER TABLE <table_name> <referential_constraint_definition>
| ALTER TABLE <table_name> DROP FOREIGN KEY <referential_constraint_name>
| ALTER TABLE <table_name> <sample_definition>

table_name, add_definition, drop_definition, alter_definition, column_change_definition, modify_definition, referential_constraint_definition, referential_constraint_name, sample_definition

Explanation

The table name must be the name of an existing base table. The table must not be a temporary base table. The current user must have the ALTER privilege for the specified table.

· If a referential CONSTRAINT definition was specified, a new referential constraint is defined for the base table. The rules described in the referential CONSTRAINT definition apply.

· If DROP FOREIGN KEY was specified, the referential CONSTRAINT definition identified by the name of the referential constraint is dropped.

· If a SAMPLE definition is specified, a new number of rows is defined and is taken into account by the database system when the table statistics are calculated.


ADD Definition (add_definition) (MaxDB: Reference Manual)

ADD Definition (add_definition)

You can define additional table properties by specifying an ADD definition in the ALTER TABLE statement.

Syntax

<add_definition> ::= ADD <column_definition>,...
| ADD (<column_definition>,...)
| ADD <constraint_definition>
| ADD <referential_constraint_definition>
| ADD <key_definition>

column_definition, constraint_definition, key_definition, referential_constraint_definition

The following statement adds two columns to the customer table. The columns initially contain the NULL value in all rows.

ALTER TABLE customer ADD (phone_number FIXED (8), street CHAR (15))

The new columns can be used immediately.

Explanation

Adding a Column Definition: ADD <column_definition>

You can specify column definitions to add these columns to the table specified in the ALTER TABLE statement. These specifications must not exceed the maximum number of columns allowed and the maximum length of a row.

The memory requirements for each column are increased by one character (for normal memory requirements, see Memory requirements of a column value as a function of the data type), if the length described is less than 31 characters and the column does not have the data type VARCHAR.

The newly defined columns contain the NULL value in all rows, if no default value has been specified for these columns using a DEFAULT specification. If the NULL value violates a CONSTRAINT definition of the table, the ALTER TABLE statement will fail.

When you add LONG columns, you cannot make a DEFAULT specification. If you want to define a default value for a LONG column, you can define the LONG column using the ADD definition and then use MODIFY Definition to define a default value for the definition.

In every other respect, specifying a column definition has the same effect as specifying a column definition in a CREATE TABLE statement.

· If view tables are defined for the specified table, and if alias names are defined for one of these view tables, and if the view tables reference the columns in the table with *, the ALTER TABLE statement will fail.

· If view tables are defined for the specified table, and if no alias names are defined, and if the view tables reference the columns in the table with *, this view table contains the columns added to the base table by the ADD definition.

Adding a CONSTANT Definition: ADD <constant definition>

All of the rows in the table must satisfy the condition defined by the search condition of the CONSTRAINT definition.

Adding a Referential CONSTRAINT Definition: ADD <referential_constraint_definition>

An integrity condition is defined for the table specified in the ALTER TABLE statement. The columns specified in the referential CONSTRAINT definition must be columns in the table.All of the rows in the table must satisfy the integrity condition defined by the referential CONSTRAINT definition.

Adding a Key Definition: ADD <key definition>

A key is defined for the table specified in the ALTER TABLE statement. At execution time, the table must only contain the key column SYSKEY generated by the database system. The columns specified in the key definition must be columns in the table and must satisfy the key properties (none of the columns may contain NULL value, and no two rows in the table may have the same values in all columns of the key definition). The new key is stored in the metadata of the table. The key column SYSKEY is omitted. This is an extremely lengthy procedure for tables with a large number of rows, since extensive copy operations are carried out.

If a primary key is defined for the table specified in the ALTER TABLE statement, and the structure of this primary key matches the structure of an existing index exactly, then this index is deleted.


ALTER definition (MaxDB: Reference Manual)

ALTER definition

By specifying an ALTER definition in the ALTER TABLE statement , you can change a CONSTRAINT definition or a key definition .

Syntax

<alter_definition> ::=
  ALTER CONSTRAINT <constraint_name> CHECK <search_condition>
| ALTER <key_definition>

constraint_name , search_condition , key_definition

Explanation

CONSTRAINT <constraint_name>

The constraint name must identify a CONSTRAINT definition in the table. If the specified search condition is not violated by any row in the table, it replaces the existing search condition of the CONSTRAINT definition. Otherwise, the ALTER TABLE statement fails.

<key_definition>

The key specified by the key definition replaces the current key in the table. The columns specified in the key definition must identify columns in the table and must have the key property ( key definition ).

If a column of the key to be replaced is a referenced column of a referential CONSTRAINT definition, the ALTER TABLE statement will fail.

With large tables, in particular, this may take more time, since extensive copy operations have to be carried out.


COLUMN Change Definition (column_change_definition) (MaxDB: Reference Manual)

COLUMN Change Definition (column_change_definition)

You can modify the properties of a column by specifying a COLUMN change definition in the ALTER TABLE statement.

Syntax

<column_change_definition> ::= COLUMN <column_name> NOT NULL
| COLUMN <column_name> DEFAULT NULL
| COLUMN <column_name> ADD <default_spec>
| COLUMN <column_name> ALTER <default_spec>
| COLUMN <column_name> DROP DEFAULT

column_name, default_spec

Explanation

NOT NULL

NOT NULL can only be specified if the column contains no NULL values. You cannot add a NULL value to the column once the ALTER TABLE statement has been successfully executed.

DEFAULT NULL

DEFAULT NULL allows a NULL value for the column. The system does not check whether a NULL value violates existing CONSTRAINT definitions in the table. For this reason, inserting the NULL value can fail when an INSERT or UPDATE statement is executed.

ADD <default_spec>

The column must not contain a DEFAULT specification before the ALTER TABLE statement is executed with ADD <default_spec>. ADD <default spec> assigns a DEFAULT value to the column.

ALTER <default spec>

ALTER <default spec> changes the DEFAULT value assigned to the column. All of the rows that contain the old default value in the column remain unaltered.

DROP DEFAULT

DROP DEFAULT drops the DEFAULT specification of the column. If the column is the foreign key column of a referential CONSTRAINT definition with the DELETE RULE ON DELETE SET DEFAULT, the ALTER TABLE statement will fail.


DROP Definition (drop_definition) (MaxDB: Reference Manual)

DROP Definition (drop_definition)

You can delete table properties by specifying a DROP definition in the ALTER TABLE statement.

Syntax

<drop_definition> ::= DROP <column_name>,... [<cascade_option>] [RELEASE SPACE]
| DROP (<column_name>,...) [<cascade_option>] [RELEASE SPACE]
| DROP CONSTRAINT <constraint_name> | DROP PRIMARY KEY

column_name, cascade_option, constraint_name

Explanation

Dropping a column: DROP <column_name>

Each column name must be a column of the table identified by the ALTER TABLE statement. The column must be neither a key column nor a foreign key column of a referential CONSTRAINT definition of the table.

The columns are marked as dropped in the metadata of the table. A DROP definition does not automatically reduce the memory requirements of the underlying table. RELEASE SPACE forces the column values of the dropped columns to be dropped in every row in the table. With large tables, in particular, this may take more time, since extensive copy operations have to be carried out.

Any privileges and comments for the columns to be dropped are also dropped.

If one of the columns to be dropped occurs as a selected column in a view definition, the specified column in the view table is dropped.
If this view table is used in the FROM clause of another view table, the described procedure is applied recursively to this view table.

· If one of the columns to be dropped occurs in the QUERY specification of a view definition and if no CASCADE condition is specified or if the CASCADE condition CASCADE is specified in the DROP definition, the view definition is dropped with all the view tables, privileges, and synonyms that depend on it.

· If one of the columns to be dropped occurs in the QUERY specification of a view definition, and if the CASCADE condition RESTRICT is specified in the DROP definition, the ALTER TABLE statement fails.

Existing indexes referring to columns to be dropped are also dropped. The storage space for the dropped indexes is released.

All CONSTRAINT definitions that contain one of the dropped columns are dropped.

Dropping a constraint: DROP CONSTRAINT <constraint_name>

The constraint name must identify a CONSTRAINT definition in the table. This definition is then deleted from the metadata of the table.

Dropping a key: DROP PRIMARY KEY

· The table must have a key defined by the user.

· The table must not contain more than 1023 columns (technical specifications).

· The maximum permissible length of a row must not exceed 8088 bytes.

· The key columns must not be a referenced column of a referential CONSTRAINT definition.

The key is replaced by the key column SYSKEY generated by the database system. With large tables, in particular, this may take more time, since extensive copy operations have to be carried out.


MODIFY definition (MaxDB: Reference Manual)

MODIFY definition

You can modify data types and properties of table columns by specifying a MODIFY definition in the ALTER TABLE statement.

Syntax

<modify_definition> ::= MODIFY (<column_name> [<data_type>] [<column_attributes>]...)

column_name, data_type, column_attributes

The parentheses are not necessary if the MODIFY definition only contains one column name.

Explanation

Each column name must be a column of the base table specified in the ALTER TABLE statement.

Column Attributes (column_attributes)

Only the following column attributes are allowed:

· NULL
NULL value

· NOT NULL
If NOT NULL is specified, the table must not have any rows that contain a NULL value in the corresponding column. A NULL value can no longer be inserted into the column after being modified.

· DEFAULT specification
The DEFAULT specification DEFAULT SERIAL is not permitted.
If a DEFAULT specification is specified, it replaces an existing DEFAULT specification in the corresponding column. The new DEFAULT specification only affects subsequent INSERT statements and not affect rows that already exist in the table.

Data types

If a DEFAULT specification is not specified and if a DEFAULT specification is defined for the corresponding column, it must be compatible with the data type.

· Code attribute ASCII: the corresponding column must have the data type DATE, TIME, or TIMESTAMP or the code attribute ASCII or UNICODE before it is modified.

· Code attribute UNICODE: A transformation from UNICODE to ASCII must be possible for the relevant column.

· Code attribute BYTE: the corresponding column must have the data type DATE, TIME, or TIMESTAMP or the code attribute ASCII or BYTE before it is modified.

Data type CHAR(n), VARCHAR(n): the corresponding column must have the data type CHAR (n), VARCHAR (n), DATE, TIME, or TIMESTAMP. In this case, the table must not contain a row in which the column has a value with a length greater than n.
If a column had the code attribute UNICODE before the ALTER TABLE statement was executed, and the new code attribute is not UNICODE, transformation to the new code attribute must be possible.

Data type DATE: the corresponding column must have the data type CHAR(n), VARCHAR(n), or DATE . This column must contain a date value in any of the date formats supported by the database system in all rows of the table.

Data type FIXED(n,m): the corresponding column must have the data type FIXED (n,m), FLOAT, INT, or SMALLINT. In this case, the table must not contain a row in which the column has a value with more than (n - m) integral or m fractional digits.

Data type FLOAT(n): the corresponding column must have the data type FIXED(n,m), FLOAT(n), INT, or SMALLINT.

Data type INT: the corresponding column must have the data type FIXED(n,m), FLOAT(n), INT, or SMALLINT. In this case, the table must only contain rows in which this column has integral values in the range between -2147483648 and 2147483647.

Data type SMALLINT: the corresponding column must have the data type FIXED(n,m), FLOAT(n), INT, or SMALLINT. In this case, the table must only contain rows in which this column has integral values in the range between -32768 and 32767.

Data type TIME: the corresponding column must have the data type CHAR(n), VARCHAR(n), or TIME . This column must contain a time value in any of the time formats supported by the database system in all rows of the table.

Data type TIMESTAMP: the corresponding column must have the data type CHAR(n), VARCHAR(n), or TIMESTAMP . This column must contain a timestamp value in any of the timestamp formats supported by the database system in all rows of the table.

Column attribute NULL: a NULL value can be entered in the corresponding column with a subsequent INSERT or UPDATE statement.

If one of the columns identified by column name is contained in a search condition for the table, this column must also define a legal search condition after the data type has been modified.

Others

Depending on the type of modification, the MODIFY definition may result in the table having to be recopied and/or indexes rebuilt. If this happens, the runtime will be correspondingly long.

If a table is recopied and the table contains columns marked as deleted, then these columns are removed from the database catalog and from the table rows, thus reducing the space requirements of the table.


RENAME TABLE statement (MaxDB: Reference Manual)

RENAME TABLE statement

A RENAME TABLE statement changes the name of a base table (see Table ).

Syntax

<rename_table_statement> ::=
RENAME TABLE <old_table_name> TO <new_table_name>

<old_table_name> ::= <table_name>
<new_table_name> ::= <identifier>

table_name , identifier

Explanation

The old table name must identify a base table that is not a temporary table. The current user must be the owner of the table.

The new table name must not already be assigned to a base or view table or a private synonym of the current user.

The old table is assigned the name specified in the new_table_name. All of the properties of the table (e.g. privileges, indexes) remain unchanged. The definitions of view tables based on the old table name are adapted to the new name.


RENAME COLUMN statement (MaxDB: Reference Manual)

RENAME COLUMN statement

A RENAME COLUMN statement ( rename_column_statement ) changes the name of a table column.

Syntax

<rename_column_statement> ::=
RENAME COLUMN <table_name>.<column_name> TO <column_name>

table_name , column_name

Explanation

The specified table must be a base or view table. The current user must be the owner of the table.

The specified table column is given a new name. If the column name of a view table (that was defined with this table) was derived from the column name of the base table, the old column name in the view table is replaced by the new name. If the new column name is identical with an existing column name of the view table, the RENAME COLUMN statement fails.


EXISTS TABLE statement (MaxDB: Reference Manual)

EXISTS TABLE statement

An EXISTS TABLE statement indicates whether a table exists or not.

Syntax

<exists_table_statement> ::= EXISTS TABLE <table_name>

table_name

Explanation

The specified table must be a base table, view table, or a synonym .

The existence or non-existence of the specified table is indicated by the return code 0 or by the error message -4004 UNKNOWN TABLE NAME .

A table only exists for a user if the user has a privilege on this table.


CREATE DOMAIN statement (MaxDB: Reference Manual)

CREATE DOMAIN statement

A CREATE DOMAIN statement defines a value range (domain) .

Syntax

<create_domain_statement> ::= CREATE DOMAIN <domain_name> <data_type> [<default_spec>] [<constraint_definition>]

domain_name , data_type , default_spec , constraint_definition

Explanation

The CONSTRAINT definition must not contain a constraint name .

The CREATE DOMAIN statement can be executed by all users with DBA status.

If the domain name is specified without an owner, the current user is assumed to be the owner. If you specify the domain name with an owner, this owner must be identical to the current user. In this case, the current user becomes the owner of the domain.

The name of the domain must differ from all other domain names of the current user.

If a domain is generated with a CONSTRAINT definition, the domain name is included in the search condition as a column name.


DROP DOMAIN statement (MaxDB: Reference Manual)

DROP DOMAIN statement

A DROP DOMAIN statement drops the definition of a domain .

Syntax

<drop_domain_statement> ::= DROP DOMAIN <domain_name>

domain_name

Explanation

The domain name must identify an existing domain. The current user must be owner of the domain.

The metadata of the domain is dropped from the catalog. Dropping a domain has no effect on tables in which this domain was used to define columns.


CREATE SEQUENCE Statement (create_sequence_statement) (MaxDB: Reference Manual)

CREATE SEQUENCE Statement (create_sequence_statement)

The CREATE SEQUENCE statement defines a database object that supplies integer values (number generator). In the following description, this object is referred to as a sequence.

Syntax

<create_sequence_statement> ::= CREATE SEQUENCE [<owner>.]<sequence_name>
[INCREMENT BY <integer>] [START WITH <integer>]
[MAXVALUE <integer> | NOMAXVALUE] [MINVALUE <integer> | NOMINVALUE]
[CYCLE | NOCYCLE]
[CACHE <unsigned_integer> | NOCACHE]
[ORDER | NOORDER]

owner, sequence_name, integer, unsigned_integer

Explanation

The optional specifications after the sequence name can be specified in any order.

The current user must be a RESOURCE user or database administrator (DBA user). If an owner is specified, this must identify the current user. The current user becomes the owner of the sequence.

The integer values generated by the sequence can be used to assign key values.

INCREMENT BY

Defines the difference between the next sequence value and the last value assigned. A negative value for INCREMENT BY generates a descending sequence. The value 1 is used if no value is assigned.

START WITH

Defines the first sequence value. If no value is specified, the value specified for MAXVALUE or –1 is used for descending sequences and the value specified for MINVALUE or 1 for ascending sequences.

MINVALUE

Defines the smallest value generated by the sequence. If no value is defined for MINVALUE, the smallest integer value that can be represented with 38 digits is used.

MAXVALUE

Defines the largest value generated by the sequence. If no value is defined for MAXVALUE, the largest integer value that can be represented with 38 digits is used.

CYCLE/NOCYCLE

CYCLE: MINVALUE is produced for ascending sequences after MAXVALUE has been assigned. MAXVALUE is produced for ascending sequences after MINVALUE has been assigned.

NOCYCLE: a request for a sequence value fails if the end of the sequence has already been reached, i.e. if MAXVALUE has been assigned for ascending sequences or MINVALUE for descending sequences.

If neither CYCLE nor NOCYCLE is specified, NOCYCLE is assumed.

CACHE/NOCACHE

CACHE: access to the sequence can be accelerated because the defined number of sequence values is held in the memory.

NOCACHE: no sequence values are defined beforehand.

If neither CACHE nor NOCACHE is specified, CACHE 20 is assumed.

ORDER/NOORDER

Specifying ORDER or NOORDER has no effect.

Sequence values can be specified using CURRVAL and NEXTVAL (see value_spec). In this way, you can interrogate or increase the current counter value.


DROP SEQUENCE statement (MaxDB: Reference Manual)

DROP SEQUENCE statement

A DROP SEQUENCE statement drops a number generator (sequence).

Syntax

<drop_sequence_statement> ::= DROP SEQUENCE [<owner>.]<sequence_name>

owner , sequence_name

Explanation

The current user must be the owner. The sequence name must identify a sequence of the current user.

The metadata of the sequence is removed from the catalog.


CREATE SYNONYM statement (MaxDB: Reference Manual)

CREATE SYNONYM statement

The CREATE SYNONYM statement defines a synonym (alternative name) of a table name .

Syntax

<create_synonym_statement> ::= CREATE [PUBLIC] SYNONYM [<owner>.]<synonym_name> FOR <table_name>

owner , synonym_name , table_name

Explanation

The table name must not denote a temporary base table (see Table ). The user must have a privilege for the specified table. The current user must be the owner.

The synonym name can be specified anywhere instead of the table name. This has the same effect as specifying the table name for which the synonym was defined.

PUBLIC

If PUBLIC is specified, the synonym name must not be identical to the name of a synonym defined with PUBLIC. A synonym is generated that can be accessed by all users.

If PUBLIC is not specified, a private synonym is generated that is only known by the current user. In this case, the synonym name must not be identical to the name of an existing base table, view table, or a private synonym of the current user. If a synonym with the same name and the PUBLIC attribute exists, it cannot be accessed by the current user until the private synonym has been dropped.


DROP SYNONYM statement (MaxDB: Reference Manual)

DROP SYNONYM statement

The DROP SYNONYM statement drops a synonym (alternative name) of a table name .

Syntax

<drop_synonym_statement> ::= DROP [PUBLIC] SYNONYM [<owner>.]<synonym_name>

owner , synonym_name

Explanation

The specified synonym name must identify an existing synonym of the current user.

If PUBLIC is specified, the synonym identified by the synonym name must be defined as PUBLIC.

The synonym definition is removed from the set of table name synonyms available to the user.


RENAME SYNONYM statement (MaxDB: Reference Manual)

RENAME SYNONYM statement

The RENAME SYNONYM statement changes the name of a synonym .

Syntax

<rename_synonym_statement> ::= RENAME [PUBLIC] SYNONYM <old_synonym_name> TO <new_synonym_name>

old/new_ synonym_name

Explanation

The old synonym name must have been generated by the current user.

If PUBLIC is specified, the old must be defined as PUBLIC.

A table of the current user with the new synonym name must not exist already.


CREATE VIEW Statement (create_view_statement) (MaxDB: Reference Manual)

CREATE VIEW Statement (create_view_statement)

The CREATE VIEW statement defines a view table (see Table). A view table never actually exists physically. Instead, it is formed from the rows of the underlying base table(s) when this view table is specified in an SQL statement.

Syntax

<create_view_statement> ::= CREATE [OR REPLACE] VIEW <table_name> [(<alias_name>,...)] AS <query_expression> [WITH CHECK OPTION]

table_name, alias_name, query_expression

Explanation

When the CREATE VIEW statement is executed, metadata that describes the view table is stored in the catalog.

The view table is always identical to the table that would be obtained as the result of the QUERY expression. The QUERY expression must not contain a parameter specification. The QUERY expression must not reference a temporary table or a result table name.

The table expressions of the QUERY specification in the QUERY statement of the CREATE VIEW statement must not contain a QUERY expression.

If a column selected by the QUERY statement is of the data type LONG, the FROM clause must contain exactly one table name that is based on exactly one base table.

The user must have the SELECT privilege for all columns occurring in the view definition. The user is the owner of the view table and has at least the SELECT privilege for it. The user may grant the SELECT privilege for any columns in the view table derived from columns for which the user is authorized to grant the SELECT privilege to others. The user has the INSERT, UPDATE, or DELETE privilege when he has the corresponding privileges for the tables on which the view table is based, and when the view table is updateable. The user may only grant these privileges to others if he or she is authorized to grant the corresponding privilege for all tables on which the view table is based.

OR REPLACE

If OR REPLACE is not specified, the table name must not be identical to the name of an existing view table.

If OR REPLACE is specified, the table name may be identical to the name of an existing view table. In this case, the definition of the existing view table is replaced by the new definition. The database system then attempts to adapt privileges granted for the existing view table to the new view definition, with the result that the privileges for the view table usually remain unchanged. Privileges are only removed implicitly if conflicts occur that cannot be resolved by the database system. If there are major discrepancies between the two view definitions, the CREATE VIEW statement may fail in the following case: the CREATE VIEW statement of a view table based on the existing view table cannot be executed correctly for the new view definition.

Alias names (alias_name)

The column names of the view table must be unique. Otherwise, alias names must be specified for the result table generated by the QUERY expression. The number of alias names must be equal to the number of columns in the result table generated by the QUERY expression. If no alias names are specified, the column names of the result table generated by the QUERY expression are applied to the view table. The column descriptions for the view table are taken from the corresponding columns in the query expression. The FROM clause of the QUERY expression can contain one or more tables.

WITH CHECK OPTION

If the create view statement contains a WITH CHECK OPTION, the owner of the view table must have the INSERT, UPDATE, or DELETE privilege for the view table.

Specifying WITH CHECK OPTION has the effect that the insert statement or update statement issued on the view table does not create any rows that could not be selected subsequently via the view table; i.e. the search condition of the view table must be true for any resulting rows.

The CHECK OPTION is inherited; i.e. if a view table V was defined WITH CHECK OPTION and V occurs in the from clause of an updateable view table V1, only those rows that can be selected using V can be inserted or altered using V1.

Further terms and information

· Complex View Table

· Updateable View Table

· INSERT Privilege for Owners of the View Table

· UPDATE Privilege for Owner of the View Table

· DELETE Privilege for Owner of the View Table

· Updateable Join View Table


Complex view table (MaxDB: Reference Manual)

Complex view table

A view table (see CREATE VIEW statement ) is a complex view table if it satisfies one of the following conditions:

  • The definition of the view table contains DISTINCT or GROUP BY or HAVING.
  • The CREATE VIEW statement contains EXCEPT, INTERSECT, or UNION.
  • The search condition in the QUERY expression of the CREATE VIEW statement contains a subquery .
  • The CREATE VIEW statement contains an outer join, that is an OUTER JOIN indicator in a JOIN predicate of the search condition.


Updateable View Table (MaxDB: Reference Manual)

Updateable View Table

A view table (see CREATE VIEW statement ) is called updateable if it is not a complex view table , and if it is not based on a complex view table.

For join view tables, that is, view tables whose FROM clause contains more than one table or join table, the following additional conditions must be satisfied:

  • Each base table on which the view table is based has a key defined by the user.
  • Referential CONSTRAINT definitions must exist between the base tables on which the view table is based.
  • One of the base tables, on which the view table is based, is not a referenced table of a referential CONSTRAINT definition for a different base table of the view table. This table is the key table of the view table.
  • For each base table on which the view table is based, there is a sequence of referential CONSTRAINT definitions so that the respective base table can be accessed from the key table.
  • The referential CONSTRAINT definitions must be reflected as a JOIN predicate in the search condition of the CREATE VIEW statement, that is, the condition "key column = foreign key column" must exist for every column in each referential CONSTRAINT definition.
  • The CREATE VIEW statement must contain either the primary key or foreign key column from each referential CONSTRAINT definition as the selected column , but not both.
  • The view table must be defined with WITH CHECK OPTION.


INSERT Privilege for the Owner of the View Table (MaxDB: Reference Manual)

INSERT Privilege for the Owner of the View Table

The owner of the view table (see CREATE VIEW statement) has the INSERT privilege. This means that he or she can specify the view table as the insert table in the INSERT statement, if the following conditions are satisfied:

· The view table can be updated (updateable view table).

· The owner of the view table has the INSERT privilege for all tables in the FROM clause of the CREATE VIEW statement.

· The selected columns of the CREATE VIEW statement consist of table columns or column names, but they do not consist of expressions with more than one column name.

· The CREATE VIEW statement contains every mandatory column from all tables of the FROM clause as the selected column.


UPDATE privilege for the owner of the view table (MaxDB: Reference Manual)

UPDATE privilege for the owner of the view table

The owner of the view table (see CREATE VIEW statement ) has the UPDATE privilege for a column in the view table, i.e. he or she can specify the column as a the column to be updated in an UPDATE statement if the following conditions are satisfied:

  • The view table is updateable ( updateable view table ).
  • The owner of the view table has the UPDATE privilege for the table columns or the column name that defines the column.
  • The column is defined by specifying table columns or by means of a column name, but not by an expression with more than one column name.


DELETE privilege for the owner of the view table (MaxDB: Reference Manual)

DELETE privilege for the owner of the view table

The owner of the view table (see CREATE VIEW statement ) has the DELETE privilege for the view table, i.e. he or she can specify the view table as a table in which entries are to be deleted in the DELETE statement if the following conditions are satisfied:

  • The view table is updateable ( updateable view table ).
  • The owner of the view table has the DELETE privilege for all tables in the FROM clause of the CREATE VIEW statement.


Updateable join view table (MaxDB: Reference Manual)

Updateable join view table

It is assumed that the definition of the join table V (see CREATE VIEW statement ) in the FROM clause contains the base tables T1,...,Tn (n>1).

  • Let Ti and Tj be two base tables selected by V. Let Rij be a referential CONSTRAINT definition of Ti and Tj in which Ti is the referencing table and Tj the referenced table.
    Let PKj1,...,PKjm be the key columns of Tj.
    Let Fki1,...,Fkim be the corresponding foreign key columns of Ti.
    The referential CONSTRAINT definition is relevant for V if the     JOIN predicate (PKj1=Fki1 AND ... AND PKjm=FKjm) is part of the search condition of V.
  • Let Ti and Tj be two base tables selected by V and Rij a referential CONSTRAINT definition of Ti and Tj that is relevant for V.
    Ti is the predecessor of Tj (Ti<Tj) if Rij is the only referential CONSTRAINT definition of Ti and Tj that is relevant for V.
  • Let Rij be a referential CONSTRAINT definition that is relevant for V.
    Rij defines a 1 : 1 relationship between Ti and Tj if the foreign key columns of Rij make up the key columns of Tj.
  • Let Rij be a referential CONSTRAINT definition that is relevant to V and s a key column of Tj or a foreign key column of this referential CONSTRAINT definition of Ti. The column s can be derived from V if exactly one of the following conditions is satisfied:
    - s is a     selected column of V.
    – a key column or a foreign key column s' of a referential CONSTRAINT definition that is relevant to V exists that can be derived from V and the JOIN predicate s=s' is part of the search condition of V.
  • A column v of V corresponds to a column s of a base table T if one of the following conditions is satisfied
    - v is the ith column of V and s is the ith selected column of V
    - v corresponds to a key column PK of Tj of a referential CONSTRAINT definition Rij that is relevant to V and s is the foreign key column of Ti that is assigned to PK
    - v corresponds to a foreign key column FK of Ti of a referential CONSTRAINT definition Rij that is relevant to V and s is the key column of Tj that is assigned to FK.

A join view table V is updateable if the following conditions are satisfied:

  • Each base table Ti (1 <= i <= n) has a key defined by the user.
  • The database system must be able to determine a processing sequence for the underlying base tables; i.e. an order Ti1,…,Tin of the tables T1,…,Tn must exist so that j < k can be deduced from Tij<Tik. The columns of V from which the key columns of Ti1 can be derived make up the key of V. Ti1 is called the key table of V. The order of the tables does not have to be unique.
  • Starting with a row in the key table of V, it must be possible to assign each underlying base table exactly one row; that is, there is a sequence of tables Ti1,...,Tij for each table Tij (1 <= j <= n) such that Ti1 < .. < Tij
    This sequence is unique for each base table referred to by V.
  • It must be possible to derive the key columns and foreign key columns of all referential CONSTRAINT definitions relevant to V from the columns of V.
  • The join predicates needed to recognize the relevance of a referential CONSTRAINT definition must be specified in parts of the search condition defined with the WITH CHECK OPTION. If the view definition only contains base tables, this means that the view table must be defined WITH CHECK OPTION. If a view table V is derived from a view table V' and if V' was defined WITH CHECK OPTION, then V inherits the CHECK OPTION for the part of the qualification passed on by V'.


DROP VIEW Statement (drop_view_statement) (MaxDB: Reference Manual)

DROP VIEW Statement (drop_view_statement)

The DROP VIEW statement drops a view table.

Syntax

<drop_view_statement> ::= DROP VIEW <table_name> [<cascade_option>]

table name, cascade option

Explanation

The table name must identify an existing view table.

The user must be the owner of the specified view table.

The metadata of the view table and all dependent synonyms, view tables, and privileges are dropped. The underlying tables of the view table remain unaffected.

· If the CASCADE option RESTRICT is specified and other view tables or synonyms based on this view table exist, the drop view statement will fail.

· If the CASCADE option CASCADE, or no CASCADE option is specified, the view table is dropped together with all the view tables, privileges, and synonyms that are dependent on it.


RENAME VIEW statement (MaxDB: Reference Manual)

RENAME VIEW statement

A RENAME VIEW statement changes the name of a view table (see Table ).

Syntax

<rename_view_statement> ::= RENAME VIEW <old_table_name> TO <new_table_name>

<old_table_name> ::= <table_name>
<new_table_name> ::= <table_name>
 table_name

Explanation

The old_table_name must be a view table. The current user must be the owner of the view table.

The new_table_name must not yet be used for a table of the current user.

The CREATE VIEW statement of the old_table_name view table is adapted to the new name. The result of this adaptation can be retrieved from the table DOMAIN.VIEWDEFS.

The definitions of view tables based on the old_table_name are adapted to the new name.


CREATE INDEX Statement (create_index_statement) (MaxDB: Reference Manual)

CREATE INDEX Statement (create_index_statement)

The CREATE INDEX statement creates an index of a base table.

Syntax

<create_index_statement> ::=
CREATE [UNIQUE] INDEX <index_name> ON <table_name> (<index_spec>)

<index_spec> ::= <column_name> [ASC|DESC]
| <dbfunction_name> (<column_name>,...) [ASC|DESC]

index_name, table_name, column_name, dbfunction_name

Explanation

Indexes provide access to the table data using non-key columns. Maintaining these indexes, however, can be quite complex in the case of an INSERT, UPDATE, or DELETE statement.

Specifying a database function name defines a function index. These indexes can accelerate queries that contain the database function in their search condition, or that sort by database function.

If no database function name is entered, the index is generated using the specified columns of the table. In this case, the secondary key consists of the specified columns of the table, in the specified order.

· The specified table must be an existing base table, and not a temporary table. The index name must not be identical with an existing index name of the table.

· The column defined by the column name must be a column in the specified table. This column must not be a LONG column. All of the column name pairs must be different.

· The current user must have the INDEX privilege type for the columns.

· The database function identified by the database function name must fulfill the following conditions:
The current user must have the EXECUTE privilege for the database function.
The database function must not contain any SQL statements.
The type of the specified column names must be compatible with the type of the function parameters.
The result of the database function must be deterministic, that is, repeated execution of the function with the same parameters always produces the same result.

· Technical Specifications

UNIQUE

If UNIQUE is specified, the database system ensures that no two rows of the specified table have the same values in the indexed columns. In this way, if two rows both contain the NULL value for all columns of an index, the two index values are not considered to be identical. If at least one column does not contain the NULL value, two rows that have the same value in all non-NULL columns are considered to be identical.

ASC | DESC

The index values are stored in ascending or descending order. If the specification of ASC or DESC is omitted, ASC is implicitly assumed.


DROP INDEX Statement (drop_index_statement) (MaxDB: Reference Manual)

DROP INDEX Statement (drop_index_statement)

The DROP INDEX statement drops an index for a base table (see table ). The metadata of the index is dropped from the database catalog. The storage space occupied by the index is released.

Syntax

<drop_index_statement> ::= DROP INDEX <index_name> [ON <table_name>]

index_name , table_name

Explanation

The specified index must exist and the specified table name must be the name of an existing base table.

ON <table name> is not necessary if the index name identifies an index unambiguously.

The current user must be the owner of the specified table or have the INDEX privilege for it.


ALTER INDEX Statement (alter_index_statement) (MaxDB: Reference Manual)

ALTER INDEX Statement (alter_index_statement)

The ALTER INDEX (alter_index_statement) statement determines how an index is used in data queries.

Syntax

<alter_index_statement> ::= ALTER INDEX <index_name> [ON <table_name>] ENABLE
| ALTER INDEX <index_name> [ON <table_name>] DISABLE
| ALTER INDEX <index_name> [ON <table_name>] INIT USAGE

index_name, table_name

Explanation

When a CREATE INDEX statement is executed, an index is generated across the specified columns. This index is modified accordingly for all of the following SQL statements for data manipulation (INSERT statement, UPDATE statement, DELETE statement). With all other SQL statements in which individual rows in a table are specified, the database system can use this index to speed up the search for these rows.

ALTER INDEX … DISABLE

The index can no longer be used for this search, however it continues to be changed by the use of the SQL statements INSERT, UPDATE, or DELETE.

ALTER INDEX … ENABLE

The index can be used for the search again.

ALTER INDEX … INIT USAGE

The column INDEX_USED in the system table DOMAIN.INDEXES is initialized with 0; that is, the count of how often an index is used is restarted.


RENAME INDEX statement (MaxDB: Reference Manual)

RENAME INDEX statement

The RENAME INDEX statement changes the name of an index .

Syntax

<rename_index_statement> ::= RENAME INDEX <old_index_name> [ON <table_name>] TO <new_index_name>

<old_index_name> ::= <index_name>
<new_index_name> ::= <index_name>

table_name , index_name

Explanation

The specified table name must be the name of an existing base table (see table ).

The index identified by the old_index_name must exist. ON <table_name> is not necessary if this index is unique.

The current user must be the owner of the specified table or have the INDEX privilege for it.

The new index name must not be identical to an existing index name for the table.


COMMENT ON Statement (comment_on_statement) (MaxDB: Reference Manual)

COMMENT ON Statement (comment_on_statement)

The COMMENT ON statement (comment_on_statement) creates, alters, or drops a comment for a database object stored in the database catalog.

Syntax

<comment_on_statement> ::= COMMENT ON <object_spec> IS <comment>

<object_spec> ::= see explanation
<comment> ::= <string_literal> | <parameter_name>

string_literal, parameter_name

Explanation

Comments can be specified for the following database objects:

<object_spec> ::= | Explanation
COLUMN <table_name>.<column_name> table_name, column_name | The column must exist in the specified table. The current user must be the owner of the table. The comment for this column can be interrogated by selecting the system table DOMAIN. COLUMNS.
DBPROC[EDURE] <dbproc_name> dbproc_name | dbproc_name must identify an existing database procedure whose owner is the current user. A comment is stored for this database procedure. The comment can be queried by selecting the system table DOMAIN. DBPROCEDURES.
DOMAIN <domain_name> domain_name | domain_name must specify a domain of the current user. The comment for this domain can be interrogated by selecting the system table DOMAIN. DOMAINS.
FOREIGN KEY <table_name>.<referential_constraint_name> referential constraint name | referential_constraint_name must specify a referential CONSTRAINT definition for the specified table of the current owner. The comment for this referential CONSTRAINT definition can be interrogated by selecting the system table DOMAIN. FOREIGNKEYS.
INDEX <index_name> ON <table_name> index_name | index_name must specify an index of the specified table. The current user must be the owner of the table. The comment for this index can be interrogated by selecting the system table DOMAIN. INDEXES.
SEQUENCE <sequence_name> sequence_name | An existing sequence must be specified using sequence_name. The current user must be the owner of the sequence. The comment for this sequence can be interrogated by selecting the system table DOMAIN. SEQUENCES.
[PUBLIC] SYNONYM <synonym_name> synonym_name | synonym_name must specify a synonym of the current user. If PUBLIC is specified, the synonym must have the PUBLIC attribute. The comment for this synonym can be interrogated by selecting the system table DOMAIN. SYNONYMS.
TABLE <table_name> table_name | The specified table must identify a base or view table of the current user that is not a temporary table. The comment for this table can be interrogated by selecting the system table DOMAIN.TABLES.
TRIGGER <trigger_name>.<table_name> trigger_name | The specified trigger name must identify a trigger of the specified table. The current user must be the owner of the table. A comment is stored for the trigger. The comment can be interrogated by selecting the system table DOMAIN. TRIGGERS.
USER <user_name> user_name | The specified user must identify an existing user whose owner is the current user. The comment for this user can be interrogated by selecting the system table DOMAIN.USERS.
USERGROUP <usergroup_name> usergroup_name | The specified user group must identify an existing user group whose owner is the current user. The comment for this user group can be interrogated by selecting the system table DOMAIN. USERS.
<parameter_name> parameter_name | The corresponding variable must contain one of the values listed in the table. The values must be encapsulated in quotation marks. Example of specifying the corresponding variables: 'COLUMN <table_name>.<column_name>'


CREATE DBPROC Statement (create_dbproc_statement) (MaxDB: Reference Manual)

CREATE DBPROC Statement (create_dbproc_statement)

The CREATE DBPROC statement (create_dbproc_statement) defines a database procedure.

Syntax

<create_dbproc_statement> ::= CREATE DBPROC <procedure_name> [(<formal_parameter>,..)] [RETURNS CURSOR] AS <routine>

<formal_parameter> ::=
  IN <argument> <data_type>
| OUT <argument> <data_type>
| INOUT <argument> <data_type>

<argument> ::= <identifier>

procedure_name, data_type, identifier, routine

The database procedure determines the average price for single rooms in hotels that are located within the specified zip code range.

CREATE DBPROC avg_price (IN zip CHAR(5), OUT avg_price FIXED(6,2)) AS
VAR sum FIXED(10,2); price FIXED(6,2); hotels

INTEGER;
TRY
SET sum = 0; SET hotels = 0;
SELECT price FROM travel.room,travel.hotel WHERE zip = :zip

AND
room.hno = hotel.hno AND roomtype = 'SINGLE';
WHILE $rc = 0 DO BEGIN
FETCH INTO :price;
SET sum = sum + price;
SET hotels = hotels + 1;
END;
CATCH
IF $rc <> 100 THEN STOP ($rc, 'unexpected error');
IF hotels > 0 THEN SET avg_price = sum / hotels
ELSE STOP (100, 'no hotel found');

Explanation

The current user is the owner of a database procedure. He or she has the EXECUTE privilege to execute the procedure.

Parameter

When an application invokes the database procedure with the CALL statement, it exchanges data via parameters that are defined by means of the formal parameters. A formal parameter of the database procedure usually corresponds to a variable in the application.

IN | OUT | INOUT

The parameter mode (IN | OUT | INOUT) specifies the direction in which the data is transferred when the procedure is invoked.

IN: defines an input parameter, i.e. the value of the variable is transferred to the database procedure when the procedure is invoked.

OUT: defines an output parameter, i.e. the value of the formal parameter is transferred from the database procedure to the variable after the procedure has terminated.

INOUT: defines an input/output parameter that combines the IN and OUT functions.

Argument

By specifying an argument, you assign a name to a formal parameter of the database procedure. This parameter name can then be used as a variable in expressions and assignments in the database procedure.

Data Type

Only BOOLEAN, CHAR[ACTER], DATE, FIXED, FLOAT, INT[EGER], NUMBER, REAL, SMALLINT, TIME, TIMESTAMP, and VARCHAR can be used as the data type of a formal parameter of a database procedure.

RETURNS CURSOR

If RETURNS CURSOR is specified, a database procedure is defined that returns a results table when called.

The name of this table is defined using the system variable $CURSOR. There must therefore be a statement in the database procedure that generates a results table with the result set name $CURSOR.

The value of $CURSOR is already assigned by most programming language embeddings, but can also be explicitly assigned in the database procedure.

CREATE DBPROC hotels_of_town (IN zip CHAR(5))
RETURNS CURSOR AS
$CURSOR = 'HOTEL_CURSOR';
DECLARE :$CURSOR CURSOR FOR
SELECT * FROM travel.hotel WHERE zip = :zip;


Routine (MaxDB: Reference Manual)

Routine

The part of the CREATE DBPROC statement, CREATE TRIGGER statement, or CREATE FUNCTION statement described as the routineis the implementation of the database procedure, the trigger, or the database function. The routine comprises optional variable declarations and statements.

Syntax

<routine> ::= [<local_variables>] <statement_list>;

<local_variables> ::=VAR <local_variable_list>;
<local_variable_list> ::= <local_variable> | <local_variable_list>; <local_variable>
<local_variable> ::= <variable_name> <data_type>
<variable_name> ::= <identifier>

<statement_list> ::= <statement> | <statement_list> ; <statement>

identifier, data_type, statement

Explanation

The statements below referring to database procedures are also true for triggers and database functions.

Variables

The local variables of the database procedure must be declared explicitly by specifying a data type before they are used. Only BOOLEAN, CHAR[ACTER], DATE, FIXED, FLOAT, INT[EGER], NUMBER, REAL, SMALLINT, TIME, TIMESTAMP, and VARCHAR are permitted as data types data types. Once they have been declared, the variables can be used in any SQL and other statements.

Every database procedure has the variables $RC, $ERRMSG, and $COUNT implicitly.

The $RC variable returns a numeric error code after an SQL statement has been executed. The value 0 means that the SQL statement was successfully executed.
In parallel with $RC, the $ERRMSG variable returns an explanation of the error containing a maximum of 80 characters.
The number of lines processed in an SQL statement is indicated by the $COUNT variable.

Variables can be assigned a value with the assignment_statement (see statement).

Restrictions

The statement list must not contain more than 255 SQL statements.


statement (MaxDB: Reference Manual)

statement

statement is a syntax element that is used in a routine. The statements specified in the statement syntax description can be used to define a database procedure (see CREATE DBPROC statement), ar trigger (see CREATE TRIGGER statement), or a database function (siehe CREATE FUNCTION statement).

Syntax

<statement> ::= BEGIN <statement_list> END | BREAK | CONTINUE | CONTINUE EXECUTE
| <if_statement> | <while_statement> | <assignment_statement> | <case_statement>
| RETURN [<expression>]
| STOP (<expression> [,<expression>] )
| TRY <statement_list>; CATCH <statement>
| <routine_sql_statement>

<statement_list> ::= <statement> | <statement_list> ; <statement>

<if_statement> ::= IF <search_condition> THEN <statement> [ELSE <statement>]
<while_statement> ::= WHILE <search_condition> DO <statement>
<assignment_statement> ::= [SET] <variable_name> = <expression>
<case_statement> ::= <simple_case_statement> | <searched_case_statement>

<routine_sql_statement> ::=
<call_statement> | <close_statement> | <create_table_temp> | <drop_table_temp>
| <declare_cursor_statement> | <delete_statement> | <fetch_statement>
| <insert_statement> | <lock_statement>
| <select_statement> | <named_select_statement> | <single_select_statement>
| <subtrans_statement> | <update_statement>

<variable_name> ::= <identifier>

<create_table_temp> :: = <create_table_statement> for creating temporary tables, that is, the table_name in the CREATE TABLE statement must have the format TEMP.<identifier>.

<drop_table_temp> ::= DROP TABLE TEMP.<identifier>

expression, search_condition, simple_case_statement, searched_case_statement, call_statement, close_statement, create_table_statement, declare_cursor_statement; delete_statement, fetch_statement, insert_statement, lock_statement, select_statement, named_select_statement, single_select_statement, subtrans_statement, update_statement, identifier

Explanation

Variables specified in a routine can be assigned a value with the assignment statement.

Control Structures

The IF statement (if_statement) first evaluates the search condition. If this is fulfilled, the statement specified in the THEN branch is executed. Otherwise, the statement in the ELSE branch (if defined) is executed.

The WHILE statement (while_statement) enables statements to be repeated in response to certain conditions. The statement is executed as long as the specified search condition is true. The condition is checked, in particular, before the statement is executed for the first time. This means that the statement may not be executed at all. By specifying BREAK, you can exit the loop straight away, without checking the condition. If CONTINUE is specified in the loop, the condition is re-evaluated immediately and the loop is processed again or exited, depending on the result.

The CASE statement (case_statement) allows the conditional execution of a statement, dependent on search conditions or the equality of operators. There are simple and general CASE statements.

RETURN

CREATE DBPROC and CREATE TRIGGER statement: Specifying RETURN enables you to exit the surrounding database procedure immediately without causing errors.

CREATE FUNCTION statement: Specifying RETURN <expression> enables you to exit the database function while specifying the function value <expression> at the same time.

Troubleshooting

If an SQL error occurs in the statement list between TRY and CATCH, the system branches directly to the statement that follows CATCH. The actual troubleshooting routine can be programmed in this statement. If CONTINUE EXECUTE is executed here, the system jumps directly to the point after the statement that triggered the error.

The database procedure is interrupted immediately when the STOP function is invoked. The value of the first parameter of the STOP function is the return or error message that the application receives as the result of the database procedure call. An error text can also be returned.

SQL Statements (routine_sql_statement)

The tables in the SQL statements (routine_sql_statement) of the database procedure must always be complete, that is, with the owner specified. In the case of SELECT statements, a full statement of the table name in the FROM clause is sufficient.

Restrictions

The statement list (statement_list) must not contain more than 255 SQL statements.

The length of an SQL statement (routine_sql_statement) must not exceed approximately 8 KB.


General CASE Statement (searched_case_statement) (MaxDB: Reference Manual)

General CASE Statement (searched_case_statement)

The general CASE statement (searched_case_statement) is a syntax element that is used in a statement. You can use the general CASE statement to define a database procedure (see CREATE DBPROC statement) or a trigger (see CREATE TRIGGER statement).

Syntax

<searched_case_statement> ::= CASE
<searched_case_when_clause>...
[<case_else_clause>]
END [CASE]

<searched_case_when_clause> ::= WHEN <search_condition> THEN <statement>
<case_else_clause> ::= ELSE <statement>

search_condition, statement

Explanation

Variables specified in a routine can be assigned a value with a statement.

Control Structures

A CASE statement (case_statement) allows the conditional execution of a statement, dependent on search conditions or the equality of operators.

In the case of a general CASE statement (searched_case_statement), the first fulfilled search condition is determined, the associated statement executed, and the CASE statement ends.

CASE
WHEN digit = 0 THEN toCHAR = 'zero';
WHEN digit = 1 THEN toCHAR = 'one';
WHEN digit = 2 THEN toCHAR = 'two';
WHEN digit = 3 THEN toCHAR = 'three';
WHEN digit = 4 THEN toCHAR = 'four';
WHEN digit = 5 THEN toCHAR = 'five';
WHEN digit = 6 THEN toCHAR = 'six';
WHEN digit = 7 THEN toCHAR = 'seven';
WHEN digit = 8 THEN toCHAR = 'eight';
WHEN digit = 9 THEN toCHAR = 'nine';
ELSE STOP(-29000, 'no digit');
END CASE

In a CASE statement, if no matching literal or fulfilled search condition exists, the statement in the ELSE branch is executed.

If there is no ELSE branch, runtime error -28901 is returned.

See also:

Simple CASE statement (simple_case_statement)


Simple CASE Statement (simple_case_statement) (MaxDB: Reference Manual)

Simple CASE Statement (simple_case_statement)

The simple CASE statement (simple_case_statement) is a syntax element that is used in a statement . You can use the simple CASE statement to define a database procedure (see CREATE DBPROC statement ) or a trigger (see CREATE TRIGGER statement ).

Syntax

<simple_case_statement> ::= CASE <expression>
<simple_case_when_clause>...
[<case_else_clause>]
END [CASE]

<simple_case_when_clause> ::= WHEN <literal>[ ...] THEN <statement>
<case_else_clause> ::= ELSE <statement>

expression , literal , statement

Explanation

Variables specified in a routine can be assigned a value with a statement.

Control Structures

A CASE statement (case_statement) allows the conditional execution of a statement, dependent on search conditions or the equality of operators.

In the case of a simple CASE statement (simple_case_statement), the expression is compared with the literals. If the expression matches a literal, the associated statement is executed and the CASE statement ends.

CASE digit
WHEN 0 THEN toCHAR = 'zero';
WHEN 1 THEN toCHAR = 'one';
WHEN 2 THEN toCHAR = 'two';
WHEN 3 THEN toCHAR = 'three';
WHEN 4 THEN toCHAR = 'four';
WHEN 5 THEN toCHAR = 'five';
WHEN 6 THEN toCHAR = 'six';
WHEN 7 THEN toCHAR = 'seven';
WHEN 8 THEN toCHAR = 'eight';
WHEN 9 THEN toCHAR = 'nine';
ELSE STOP(-29000, 'no digit');
END CASE

In a CASE statement, if no matching literal or fulfilled search condition exists, the statement in the ELSE branch is executed.

If there is no ELSE branch, runtime error -28901 is returned.

See also:

General CASE Statement (searched_case_statement)


DROP DBPROC statement (MaxDB: Reference Manual)

DROP DBPROC statement

The DROP DBPROC statement drops a database procedure .

Syntax

<drop_dbproc_statement> ::= DROP DBPROC <dbproc_name>

dbproc_name

Explanation

The specified database procedure name must identify an existing database procedure of the current user.

The metadata of the database procedure is dropped.


CREATE TRIGGER Statement (create_trigger_statement) (MaxDB: Reference Manual)

CREATE TRIGGER Statement (create_trigger_statement)

The CREATE TRIGGER statement defines a trigger for a base table (see Table).

Syntax

<create_trigger_statement> ::= CREATE TRIGGER <trigger_name> FOR <table_name>
AFTER <trigger_event,..> EXECUTE (<routine>) [WHENEVER <search_condition> ]

<trigger_event> :: INSERT | UPDATE [(<column_list>)] | DELETE
<column_list> ::= <column_name> | <column_list>,<column_name>

trigger_name, table_name, search_condition, routine, column_name

The trigger ensures that the hotel number in the roomtable is also changed when a hotel number is changed in the hotel table.

CREATE TRIGGER hotel_update FOR hotel AFTER UPDATE EXECUTE (
TRY
  IF NEW.hno <> OLD.hno
  THEN UPDATE travel.room SET hno = :NEW.hno WHERE hno = :OLD.hno;
CATCH
  IF $rc <> 100
  THEN STOP ($rc, 'unexpected error');
)

Explanation

A trigger is a special type of database procedure that is assigned to a base table. This database procedure cannot be executed explicitly with the CALL statement, but rather automatically by SAP DB when defined events (trigger events) for the table occur.

SAP DB provides a language (special SQL syntax that has been extended to include variables, control structures, and troubleshooting measures) that can be used to define database procedures and triggers.

The specified synonym name must identify an existing base table of the current user.

Trigger Event

The trigger event defines what triggers the trigger. The trigger is always invoked if the triggering event has been processed correctly.

INSERT: the INSERT trigger event causes the trigger to be executed for each row inserted in the table.

UPDATE: the UPDATE event causes the trigger to be executed for each modification made to a row in the table. If a column list is specified, the trigger is only called if one of the columns in the column list was modified.

DELETE: the DELETE trigger event causes the trigger to be executed for every row deleted from the table.

A maximum of one trigger can be defined for each trigger event in each table.

Trigger Routine

Each INSERT trigger implicitly has a corresponding variable NEW.<column_name> for each column in the table. When the trigger is executed, this variable has the value of the corresponding column in the inserted row. It is only permissible to specify NEW for SQL statements specified in routine_sql_statements. Specifying NEW for the other statements leads to an error.

Each UPDATE trigger implicitly has a corresponding variable NEW.<column name> and OLD.<column name> for each column in the table. When the trigger is executed, the OLD.<column_name> variable has the value of the corresponding column in front of and NEW.<column_name> after the change in the row. Specifying NEW and OLD is optional.

Each DELETE trigger implicitly has a corresponding variable OLD.<column_name> for each column in the table. When the trigger is executed, this variable has the value of the corresponding column in the deleted row. It is only permissible to specify OLD for SQL statements specified in routine_sql_statements. Specifying OLD for the other statements leads to an error.

:NEW and :OLD must always be used with a colon in SQL statements that are used in triggers and that belong to the routine_sql_statements
(For example: UPDATE travel.room SET hno = :NEW.hno WHERE hno = :OLD.hno).

NEW and OLD must always be used without a colon in SQL statements that are used in triggers and that do not belong to the routine_sql_statements
(For example: IF NEW.hno <> OLD.hno).

See also:

routine

If the trigger is terminated by STOP with an error number not equal to zero, the entire SQL statement that triggered the trigger fails.

The SUBTRANS statement is not allowed in a trigger.

If a WHENEVER statement is specified, the trigger is only executed if the search condition is fulfilled. The condition must not contain a subquery nor any set functions.


DROP TRIGGER statement (MaxDB: Reference Manual)

DROP TRIGGER statement

A DROP TABLE statement deletes a trigger for a table.

Syntax

<drop_trigger_statement> ::= DROP TRIGGER <trigger_name> OF <table_name>

trigger_name , table_name

Explanation

The specified table name must identify an existing table of the current user.

The specified trigger name must identify an existing trigger of the table.

The metadata of the trigger is dropped.


CREATE FUNCTION Statement (create_function_statement) (MaxDB: Reference Manual)

CREATE FUNCTION Statement (create_function_statement)

The CREATE FUNCTION statement (create_function_statement) defines a database function.

Syntax

<create_function_statement> ::= CREATE FUNCTION <dbfunction_name> [(<formal_parameter1>,..)] RETURNS <data_type> AS <routine>

<formal_parameter1> ::= <argument1> <data_type>
<argument1> ::= <identifier>

dbfunction_name, data_type, routine, identifier

This database function determines the average price for single rooms in hotels that are located within the specified zip code range.

CREATE FUNCTION avg_price (zip CHAR(5))

RETURNS FIXED(6,2) AS
VAR sum FIXED(10,2); price FIXED(6,2);
hotels INTEGER; avg_price FIXED(6,2);
TRY
SET sum = 0; SET hotels = 0;
SELECT price FROM travel.room,travel.hotel WHERE zip = :zip

AND
room.hno = hotel.hno AND roomtype = 'SINGLE';
WHILE $rc = 0 DO BEGIN
FETCH INTO :price;
SET sum = sum + price;
SET hotels = hotels + 1;
END;
CATCH
IF $rc <> 100 THEN STOP ($rc, 'unexpected error');
IF hotels > 0 THEN RETURN sum/hotels
ELSE RETURN NULL;

Explanation

The current user is the owner of a database function. This user has the authorization to execute the database function and assign this authorization to other users.

Argument

By specifying an argument (argument1), you assign a name to a formal parameter of the database function. This parameter name can then be used as a variable in expressions and assignments in the database function.

Data Type

Only BOOLEAN, CHAR[ACTER], DATE, FIXED, FLOAT, INT[EGER], NUMBER, REAL, SMALLINT, TIME, TIMESTAMP, and VARCHAR can be used as the data type (data_type) of a formal parameter of a database function.

RETURNS

Only BOOLEAN, CHAR[ACTER], DATE, DEC[IMAL], DOUBLE, FLOAT, INT[EGER], NUMBER, NUMERIC, REAL, SMALLINT,TIME, TIMESTAMP, and VARCHAR can be used as the data type of the return code.

Data Types

Data types are normally defined with both length and precision. However, if you specify VARCHAR or NUMBER without length or precision, the database system derives these properties automatically, depending on the context of the function call.


DROP FUNCTION Statement (drop_function_statement) (MaxDB: Reference Manual)

DROP FUNCTION Statement (drop_function_statement)

The DROP FUNCTION statement (create_function_statement) deletes a database function.

Syntax

<drop_function_statement> ::= DROP FUNCTION <dbfunction_name>

dbfunction_name

Explanation

The specified database function name must identify an existing database function of the current user.

The metadata of the database function is deleted.


Authorization (MaxDB: Reference Manual)

Authorization

SQL statements for authorization

CREATE USER statement | DROP USER statement | ALTER USER statement RENAME USER statement GRANT USER statement
CREATE USERGROUP statement | DROP USERGROUP statement | ALTER USERGROUP statement RENAME USERGROUP statement GRANT USERGROUP statement
CREATE ROLE statement | DROP ROLE statement |
ALTER PASSWORD statement | GRANT statement | REVOKE statement


CREATE USER Statement (create_user_statement) (MaxDB: Reference Manual)

CREATE USER Statement (create_user_statement)

The CREATE USER statement (create_user_statement) defines a user. The existence and the properties of the user are recorded in the database catalog in the form of metadata.

Syntax

<create_user_statement> ::= CREATE USER <user_name> PASSWORD <password>
[<user_mode>]
[TIMEOUT <unsigned_integer>] [COSTWARNING <unsigned_integer>] [COSTLIMIT <unsigned_integer>] [[NOT] EXCLUSIVE] [DEFAULTCODE <ASCII | UNICODE>]
| CREATE USER <user_name> PASSWORD <password> LIKE <source_user>
| CREATE USER <user_name> PASSWORD <password> USERGROUP <usergroup_name>

user_name, user_mode, unsigned_integer, usergroup_name

Explanation

The current user must be a database administrator (DBA user). The user is the owner of the created user.

The specified user name must not be identical to the name of an existing user, a user group, or a role.

The password (password) must be specified when an database session is started. It ensures that only authorized users can access the database system.

Unsigned integers (unsigned_integer) must always be greater than 0.

Unlimited disk space is available to the user for the storage of his or her private and temporary tables (in the context of the sizes specified for the data volumes during the installation).

TIMEOUT

The timeout value is specified in seconds and must be between 30 and 32400.

Only the database system administrator (SYSDBA user) can define users with the timeout value 0.

COSTWARNING/COSTLIMIT

COSTWARNING and COSTLIMIT limit costs by preventing users from executing query statements or insert statements in the form of INSERT...SELECT... beyond a specified degree of complexity.

Before these SQL statements are executed, the costs expected to result from this statement are estimated. This SELECT costs estimate can be output with the EXPLAIN statement. In interactive mode, the estimated SELECT cost value is compared with the COSTWARNING and COSTLIMIT values specified for the user.

The COSTWARNING and COSTLIMIT values are ignored with query statements or insert statements in the form INSERT...SELECT... which are embedded in a programming language.

COSTWARNING: specifies the estimated SELECT cost value beyond which the user receives a warning. In this case, the user is asked whether he or she really wants to execute the SQL statement.

COSTLIMIT: specifies the estimated SELECT cost value beyond which the SQL statement is not executed.

The COSTLIMIT value must be greater than the COSTWARNING value.

EXCLUSIVE

EXCLUSIVE: prevents the user from opening two different database sessions simultaneously.

NOT EXCLUSIVE: allows the user to open several database sessions simultaneously.

If the EXCLUSIVE condition is not specified, EXCLUSIVE is assumed implicitly (without NOT).

DEFAULTCODE <ASCII | UNICODE>

The value of the special database parameter DEFAULT_CODE is overridden with the code attribute specified in DEFAULTCODE for the objects of the specified user.

LIKE

The current user must have owner authorization over the source user (source_user).

If the source user is not a member of a user group, the new user receives the same user class and values for PERMLIMIT, TEMPLIMIT, TIMEOUT, COSTWARNING, COSTLIMIT, and EXCLUSIVE as the source user. The new user receives all the privileges that the source user was granted by other users.

If the source user is a member of a user group, a new member is created in this user group with the new user name.

USERGROUP

The user issuing the SQL statement must be the owner of the specified user group. The new user then becomes a member of this user group.


user_mode (MaxDB: Reference Manual)

user_mode

user_modeis used when creating a user (see CREATE USER statement) to determine the database user class of the defined user. The user class specifies the operations that the defined user can execute.

Syntax

<user mode> ::= DBA | RESOURCE | STANDARD

DBA, RESOURCE, STANDARD

Explanation

If no user class is specified, the STANDARD class is assumed implicitly.

Dependencies

The user classes are hierarchically ordered as follows:

· The user class RESOURCE encompasses all the rights of STANDARD users.

· The user class DBA encompasses all the rights of RESOURCES users.

· The SYSDBA user can create DBA users. He or she has owner rights over all users. Otherwise, the SYSDBA has the same function and the same rights as a DBA user, i.e. whenever a DBA user is allowed to execute an SQL statement, this also applies to a SYSDBA user.

See also:

usergroup_mode


CREATE USERGROUP Statement (create_usergroup_statement) (MaxDB: Reference Manual)

CREATE USERGROUP Statement (create_usergroup_statement)

The CREATE USERGROUP statement (create_usergroup_statement) defines a user group.

Syntax

<create_usergroup_statement> ::= CREATE USERGROUP <usergroup_name>
[<usergroup_mode>]
[TIMEOUT <unsigned_integer>] [COSTWARNING <unsigned_integer>] [COSTLIMIT <unsigned_integer>] [[NOT] EXCLUSIVE] [DEFAULTCODE <ASCII | UNICODE>]

usergroup_name, usergroup_mode, unsigned_integer

Explanation

The current user must be a database administrator (DBA user).

The specified user group name must not be identical to the name of an existing user, user group, or role.

You can use the CREATE USER statement to define multiple users who belong to this user group. All private objects created by members of the user group are identified by the user group name. The owner of a private object is the group, not the user who created the object. Each user can work with any private object of the group, as if this user were the owner of the object. Privileges can only be granted or revoked from the group. A privilege cannot be granted or revoked from a single member of the group.

Unsigned integers (unsigned_integer) must always be greater than 0.

Unlimited disk space is available to the user for the storage of his or her private and temporary tables (in the context of the sizes specified for the data volumes during the installation).

TIMEOUT

The timeout value is specified in seconds and must be between 30 and 32400.

Only the database system administrator (SYSDBA user) can define users with the timeout value 0.

COSTWARNING/COSTLIMIT

COSTWARNING and COSTLIMIT limit costs by preventing users in this user group from executing query statements or insert statements in the form of INSERT...SELECT... beyond a specified degree of complexity and that are therefore cost-intensive.

Before these SQL statements are executed, the costs expected to result from this statement are estimated. This SELECT costs estimate can be output with the EXPLAIN statement. In interactive mode, the estimated SELECT cost value is compared with the COSTWARNING and COSTLIMIT values specified for the user.

The COSTWARNING and COSTLIMIT values are ignored with query statements or insert statements in the form INSERT...SELECT... which are embedded in a programming language.

COSTWARNING: specifies the estimated SELECT cost value beyond which the user receives a warning. In this case, the user is asked whether he or she really wants to execute the SQL statement.

COSTLIMIT: specifies the estimated SELECT cost value beyond which the SQL statement is not executed.

The COSTLIMIT value must be greater than the COSTWARNING value.

EXCLUSIVE

EXCLUSIVE: prevents users in this user group from opening two different database sessions simultaneously.

NOT EXCLUSIVE: allows the user to open several database sessions simultaneously.

If the EXCLUSIVE condition is not specified, EXCLUSIVE is assumed implicitly (without NOT).

DEFAULTCODE <ASCII | UNICODE>

The value of the special database parameter DEFAULT_CODE is overridden with the code attribute specified in DEFAULTCODE for the objects of the specified user.


usergroup_mode (MaxDB: Reference Manual)

usergroup_mode

usergroup_mode is used when creating a user group (see CREATE USERGROUP statement), to determine the database user class of the defined user group.

Syntax

<usergroup mode> ::= RESOURCE | STANDARD

RESOURCE, STANDARD

Explanation

If no user class is specified, the STANDARD class is assumed implicitly.

The user class RESOURCE encompasses all the rights of STANDARD users.

See also:

user_mode


DROP USER Statement (drop_user_statement) (MaxDB: Reference Manual)

DROP USER Statement (drop_user_statement)

A DROP USER statement deletes the definition of a database user. The metadata of the user to be dropped is dropped from the database catalog.

Syntax

<drop_user_statement> ::= DROP USER <user_name> [<cascade_option>]

user_name, cascade_option

Explanation

The current user must have owner authorization over the user to be dropped.

The specified user must not be logged onto the database system when the DROP USER statement is executed.

· If the user to be dropped does not belong to a usergroup and is the owner of synonyms or tables, and if the CASCADE option RESTRICT was specified, the DROP USER statement fails.

· If no cascade option or the cascade option CASCADE is specified, all the synonyms and tables of the user to be dropped, as well as all indexes, privileges, view tables, etc. based on these objects, are dropped together with the database user.

Dropping a user with the database user class DBA does not affect any users that were created by this user. The SYSDBA user becomes the new owner of these users.


DROP USERGROUP Statement (drop_usergroup_statement) (MaxDB: Reference Manual)

DROP USERGROUP Statement (drop_usergroup_statement)

The DROP USERGROUP statement drops the definition of usergroup. The metadata of the user group to be dropped is dropped from the catalog.

Syntax

<drop_usergroup_statement> ::= DROP USERGROUP <usergroup_name> [<cascade_option>]

usergroup_name, cascade_option

Explanation

The current user must have owner authorization over the usergroup to be dropped.

The users in this usergroup must not be logged onto the database system when the DROP USERGROUP statement is executed.

· If the usergroup to be dropped is the owner of synonyms or tables and if the CASCADE option RESTRICT was specified, the DROP USERGROUP statement fails.

· If no cascade option or the cascade option CASCADE is specified, all the synonyms and tables of the user group to be dropped, as well as all indexes, privileges, view tables, etc. based on these objects, are dropped together with the usergroup.


ALTER USER Statement (alter_user_statement) (MaxDB: Reference Manual)

ALTER USER Statement (alter_user_statement)

The ALTER USER statement alters the properties assigned to a user.

Syntax

<alter_user_statement> ::= ALTER USER <user_name> [<user_mode>]
[TIMEOUT <unsigned_integer> | TIMEOUT NULL]
[COSTWARNING <unsigned_integer> | COSTWARNING NULL]
[COSTLIMIT <unsigned_integer> | COSTLIMIT NULL]
[DEFAULT ROLE ALL [EXCEPT <role_name>] | DEFAULT ROLE NONE
| DEFAULT ROLE <role_name> [IDENTIFIED BY <password>]]
[[NOT] EXCLUSIVE] [DEFAULTCODE <ASCII | UNICODE>]

user_name, user_mode, unsigned_integer, role_name, password

Explanation

At least one of the optional clauses must be specified.

The specified user name must identify a defined user, who is not a member of a user group.

The current user must have owner authorization over the user whose properties are to be altered.

The specified user must not be logged onto the database system when the ALTER USER statement is executed.

Database user class (user_mode)

· DBA: specifies that the user is to be assigned the user class DBA. This user class can only be granted by the SYSDBA.

· RESOURCE: specifies that the user is to be assigned the user class RESOURCE. If the user was previously assigned to the user class DBA, owner authorization for all users he or she created is revoked. The SYSDBA user then becomes the new owner.

· STANDARD: specifies that the user is removed from the current user class and loses the right to create base tables. All the base tables created by the user are dropped.

· No user class: if no user class is specified, the user class remains unchanged.

NULL

If the NULL value is specified, the value defined previously is cancelled.

DEFAULT ROLE

DEFAULT ROLE defines which of the roles assigned to the user is activated automatically when a database session is opened.

· ALL: all the roles assigned to the user are activated when a session is opened. EXCEPT can be used to exclude specified roles from activation.

· NONE: none of the roles is activated when a user database session is opened.

· Role name specified: the roles specified here must exist and be assigned to the user. They are automatically activated when a user database session is opened.

See also:

Role concept

For a description of TIMEOUT, COSTWARNING, COSTLIMIT, [NOT] EXCLUSIVE, and DEFAULTCODE, see CREATE USER statement.


ALTER USERGROUP Statement (alter_usergroup_statement) (MaxDB: Reference Manual)

ALTER USERGROUP Statement (alter_usergroup_statement)

The ALTER USERGROUP statement (alter_usergroup_statement) alters the properties assigned to a user group.

Syntax

<alter_usergroup_statement> ::= ALTER USERGROUP <usergroup_name> [<usergroup_mode>]
[TIMEOUT <unsigned_integer> | TIMEOUT NULL]
[COSTWARNING <unsigned_integer> | COSTWARNING NULL] [COSTLIMIT <unsigned_integer> | COSTLIMIT NULL]
[DEFAULT ROLE ALL [EXCEPT <role_name>] | DEFAULT ROLE NONE
| DEFAULT ROLE <role_name> [IDENTIFIED BY <password>]]
[[NOT] EXCLUSIVE] [DEFAULTCODE <ASCII | UNICODE>]

usergroup_name , usergroup_mode , unsigned_integer , role_name , password

Explanation

At least one of the optional clauses must be specified.

The specified user group must identify a defined user group.

The current user must have owner authorization over the user group whose properties are to be altered.

The members of the specified user group must not be logged onto the database system when the ALTER USERGROUP statement is executed.

Database user class of the user group (usergroup mode)

· RESOURCE: specifies that the user group is to be assigned to the database user class RESOURCE.

· STANDARD: specifies that the user group is removed from the current user class and loses the right to create base tables. All the base tables created by the user group are dropped.

· No user class: if no user class is specified, the user class remains unchanged.

NULL

If the NULL value is specified, the value defined previously is cancelled.

DEFAULT ROLE

DEFAULT ROLE defines which of the roles assigned to the user group is activated automatically when a session is opened by a group member.

· ALL: all the roles assigned to the user group are activated when a session is opened. EXCEPT can be used to exclude specified roles from activation.

· NONE: none of the roles is activated when a session is opened by a member of the user group.

· Role name specified: the roles specified here must exist and be assigned to the user group. They are automatically activated when a session of a group member is opened.

See also:

Role concept

For a description of TIMEOUT, COSTWARNING, COSTLIMIT, [NOT] EXCLUSIVE, and DEFAULTCODE, see CREATE USERGROUP statement.


RENAME USER Statement (rename_user_statement) (MaxDB: Reference Manual)

RENAME USER Statement (rename_user_statement)

The RENAME USER statement changes the name of a user.

Syntax

<rename_user_statement> ::= RENAME USER <user_name> TO <new_user_name>

user_name

Explanation

The user that you want to modify must exist. The user name must identify a user whose owner is the current user.

The new user name (new_user_name) must not be identical to the name of an existing user, user group, or role.

The user whom you want to modify must not be logged on to the database system when the RENAME USER statement is executed.

The database system automatically adapts the objects that are dependent on the modified user to the new user name.


RENAME USERGROUP Statement (rename_usergroup_statement) (MaxDB: Reference Manual)

RENAME USERGROUP Statement (rename_usergroup_statement)

The RENAME USERGROUP statement changes the name of a usergroup.

Syntax

<rename_usergroup_statement> ::= RENAME USERGROUP <usergroup_name> TO <new_usergroup_name>

usergroup_name

Explanation

The user group to be modified must exist. The name of the usergroup must identify a usergroup for which the current user has the owner privilege.

The new usergroup name must not be identical to that of an existing user, usergroup, or role.

The members of this usergroup must not be logged onto the database system when the RENAME USERGROUP statement is executed.

The database system automatically adapts the objects that are dependent on the modified usergroup to the new usergroup name.


GRANT USER Statement (grant_user_statement) (MaxDB: Reference Manual)

GRANT USER Statement (grant_user_statement)

The GRANT USER statement grants another user the owner privilege that the database system administrator (SYSDBA user) or a database administrator (DBA user) has over a user.

Syntax

<grant_user_statement> ::= GRANT USER <granted_users> [FROM <user_name>] TO <user_name>

<granted_users> ::= <user_name>,...| *
user name

Explanation

The current user must be a DBA user.

The user names specified after the FROM and TO keywords must be different and must identify DBA users. If FROM <user name> is not specified, the current user is assumed implicitly.

The users specified after the GRANT USER keywords must exist and must not be a member of a user group . They must have the user class RESOURCE user or STANDARD user. The FROM user must have the owner privilege for these users. If * is specified, the GRANT USER statement affects all users for which the FROM user has the owner privilege.

The FROM user grants the TO user the owner privileges which the FROM user has over the specified users. These rights are revoked from the FROM user. In particular, the TO user is granted the right to drop any specified user and to alter the user class and other properties of this user.


GRANT USERGROUP Statement (grant_usergroup_statement) (MaxDB: Reference Manual)

GRANT USERGROUP Statement (grant_usergroup_statement)

The GRANT USER statement grants another user the owner privilege that the database system administrator (SYSDBA user) or a database administrator (DBA user) has over a user group.

Syntax

<grant_usergroup_statement> ::= GRANT USERGROUP <granted_usergroups> [FROM <user_name>] TO <user_name>

<granted_usergroups> ::= <usergroup_name>,...| *
user name, usergroup name

Explanation

The current user must be a DBA user.

The user names specified after the FROM and TO keywords must be different and must identify DBA users. If FROM <user name> is not specified, the current user is assumed implicitly.

The usergroup name must identify a user groups for which the FROM user has the owner privilege. An asterisk * stands for all user groups for which the FROM user has the owner privilege.

The FROM user grants the TO user the owner authorization which the FROM user has over the specified user groups. These rights are revoked from the FROM user. In particular, the TO user is granted the right to drop any usergroup, to alter the user class and properties of this usergroup, and to drop or create group members.


ALTER PASSWORD statement (alter_password_statement) (MaxDB: Reference Manual)

ALTER PASSWORD statement
(alter_password_statement)

The ALTER PASSWORD statement (alter_password_statement) is required to change the password for a user.

Syntax

<alter_password_statement> ::= ALTER PASSWORD <old_password> TO <new_password>
| ALTER PASSWORD <user_name> <new_password>

<old_password> ::= <password>

<new_password> ::= <password>

user name, password

Explanation

The old password must match the password stored in the database catalog for the current user.

When the user name is specified, the current user must be the SYSDBA.

The next time the user starts a Database session, the new password must be specified in the CONNECT statement.


CREATE ROLE Statement (create_role_statement) (MaxDB: Reference Manual)

CREATE ROLE Statement (create_role_statement)

The CREATE ROLE statement defines a role.

Syntax

<create_role_statement> ::= CREATE ROLE <role_name> [IDENTIFIED BY <password>]

role name, password

Explanation

The current user must be a database administrator (DBA user).

The role name must not be the same as the name of an existing role, user, or user group.

See also:

Role concept


DROP ROLE Statement (drop_role_statement) (MaxDB: Reference Manual)

DROP ROLE Statement (drop_role_statement)

The DROP ROLE statement deletes a role.

Syntax

<drop_role_statement> ::= DROP ROLE <role_name>

role_name

Explanation

The current user must be the owner of the role.

The metadata of the role to be dropped is dropped from the database catalog.


GRANT Statement (grant_statement) (MaxDB: Reference Manual)

GRANT Statement (grant_statement)

The GRANT statement (grant_statement) assigns privileges for tables, individual columns and roles, the SELECT privilege for a sequence, and the execution privilege for a database procedure.

Syntax

<grant_statement> ::= GRANT <priv_spec>,... TO <grantee>,... [WITH GRANT OPTION]
| GRANT EXECUTE ON <dbproc_name> TO <grantee>,...
| GRANT SELECT ON <sequence_name> TO <grantee>,... [WITH GRANT OPTION]

priv_spec, grantee, dbproc_name, sequence_name

Explanation

The privileges in the privilege specification are assigned to the users , user groups , and roles (see also: Role Concept ) specified in the grantee list.

WITH GRANT OPTION

Users or user groups identified as grantees are allowed to pass on their privileges to other users. The current user must have the authorization to pass on these privileges.

The WITH GRANT OPTION cannot be specified if grantee identifies a role.

GRANT EXECUTE ON

GRANT EXECUTE ON allow the user identified by grantee to execute the specified database procedure. The current user must be the owner of the database procedure.

GRANT SELECT ON

GRANT SELECT ON allows the user identified by grantee to use the specified sequence.


Privilege Specification (priv_spec) (MaxDB: Reference Manual)

Privilege Specification (priv_spec)

A privilege specification (priv_spec) defines a role or a set of privileges for specific tables.

Syntax

<priv_spec> ::= ALL [PRIV[ILEGES]] ON [TABLE] <table_name>,...
| <privilege>,... ON [TABLE] <table_name>,... | <role_name>

table name, privilege, role name

Explanation

These tables must not be temporary base tables.

The user must have the authorization to grant (GRANT statement) and revoke (REVOKE statement) privileges for the specified tables. For base tables, the owner of the table has this authorization.

In the case of view tables, the owner may not always be authorized to assign or revoke all privileges. The database determines the privileges that a user can assign or revoke for a view table when the table is created. The result depends on the type of table and on the user's privileges for the tables selected in the view table. The owner of a table can interrogate the privileges that he or she is allowed to grant or revoke by selecting the system table DOMAIN.PRIVILEGES.

A list of all the privileges that can be granted is provided in the privilege type.

If a role is defined as a privilege specification, it must exist and the current user must be the owner of the role.

ALL [PRIV[ILEGES]]

All of the privileges that the user can grant for tables are granted (GRANT statement) or revoked (REVOKE statement) for the specified users, user groups, and roles.

If a user who is not the owner of the table specifies ALL in a REVOKE statement, all of the privileges he or she has granted to the specified user for this table are revoked.


Grantee (MaxDB: Reference Manual)

Grantee

The user (or several users) or role is specified for which privileges are to be granted with the GRANT statement or revoked with the REVOKE statement.

Syntax

<grantee> ::= PUBLIC | <user_name> | <usergroup_name> | <role_name>

user_name, usergroup_name, role_name

Explanation

A user in the grantee list must not be identical to the user name of the current user or the name of the owner of the table. A user in the grantee list must not denote a member of a usergroup.

Roles

If a role is assigned to a user or usergroup, it extends the set of roles which can be activated for this user or usergroup. The user activates the role either with the SET statement or by including the role in the set of roles automatically activated when a session was opened with the ALTER USER statement or ALTER USERGROUP statement.

A cycle may not be created when a role is assigned to a role, that is

· a role cannot be assigned to itself.

· if a role R1 is assigned to a role R2, R2 may not be assigned to R1.

· if a role R1 is assigned to a role R2 and R2 is assigned to a role R3, R3 may not be assigned to either R2 or R1.

· etc.

PUBLIC

The listed privileges are granted to all users, both to current ones and to any created later.

A role cannot be assigned to PUBLIC.


REVOKE Statement (revoke_statement) (MaxDB: Reference Manual)

REVOKE Statement (revoke_statement)

The REVOKE statement revokes privileges.

Syntax

<revoke_statement> ::= REVOKE <priv_spec>,... FROM <grantee>,... [<cascade_option>]
| REVOKE EXECUTE ON <dbproc_name> FROM <grantee>,...
| REVOKE SELECT ON <sequence_name> FROM <grantee>,... [<cascade_option>]

priv_spec, grantee, cascade_option, dbproc_name, sequence_name

Explanation

The owner of a table can revoke the privileges granted for this table from any user.

If a user is not the owner of the table, he may only revoke the privileges he has granted.

If the SELECT privilege was granted for a table without specifying any column names, REVOKE SELECT (<column name>,...) can be used to revoke the SELECT privilege (see privilege type) for the specified columns. The SELECT privilege for table columns that have not been specified remains unchanged. The same is true for the UPDATE, REFERENCES, and SELUPD privileges.

The REVOKE statement can cascade; that is, revoking a privilege from one user can result in this privilege being revoked from other users who have received the privilege from the user in question.

Let U1, U2, and U3 be users.
U1 grants U2 the privilege set P WITH GRANT OPTION.
U1 grants U3 the privilege set P' (P'<=P).

If U1 revokes the privilege set P'' (P''<=P) from user U2, the privilege set (P'*P'') is revoked implicitly from user U3.

· Whenever the SELECT privilege is revoked from the owner of a view table for a selected that does not occur in the table_expression of the view definition (CREATE VIEW statement), the column defined by select_column is dropped from the view table.
If this view table is used in the FROM clause of another view table, the described procedure is applied recursively to this view table.

· If the SELECT privilege is revoked from the owner of a view table for a column or table occurring in the table_expression of the view definition, the view table is dropped, along with all view tables, privileges, and synonyms that are dependent on this view table, if no CASCADE option or the cascade option CASCADE is specified. The REVOKE statement will fail if the CASCADE option RESTRICT is specified.

REVOKE EXECUTE

If REVOKE EXECUTE is specified, the authorization to execute the database procedure is revoked from the user identified by grantee. The authorization for execution can only be revoked by the owner of the database procedure.


Data Manipulation (MaxDB: Reference Manual)

Data Manipulation

The following sections provide an introduction to the Data Manipulation Language (DML) used by the database system.

Every SQL statement that manipulates data implicitly sets an exclusive lock for each inserted, updated, or deleted row (for more information, see Locks).

SQL statements for data manipulation

INSERT Statement | UPDATE Statement | DELETE statement
NEXT STAMP statement | CALL statement |


INSERT Statement (insert_statement) (MaxDB: Reference Manual)

INSERT Statement (insert_statement)

The INSERT statement creates new rows in a table.

Syntax

<insert_statement> ::=
  INSERT [INTO] <table_name> [(<column_name>,...)] VALUES (<insert_expression>,...) [<duplicates_clause>]
| INSERT [INTO] <table_name> [(<column_name>,...)] <query_expression> [<duplicates_clause>]
| INSERT [INTO] <table_name> SET <set_insert_clause>,... [<duplicates_clause>]

<insert_expression> ::= <extended_expression> | <subquery>

table_name, column_name, extended_expression, duplicates_clause, subquery, query_expression, set_insert_clause

Explanation

The table name must denote an existing base table, view table (see Table), or a synonym.

If column names or a SET INSERT clause are specified, all of the specified column names must be columns in the table. If the table was defined without a key (that is, if the SYSKEY column is created internally by the database), the SYSKEY column must not occur in the sequence of column names or in a SET INSERT clause. A column must not occur more than once in a sequence of column names or in more than one SET INSERT clause.

The user must have the INSERT privilege for the table identified by the table name. If the table name identifies a view table, even the owner of the view table may not have the INSERT privilege because the view table cannot be changed.

A specified column (identified by column name or the column name in the set_insert_clause) is a target column. Target columns can be specified in any order.

· If a column name and SET INSERT clause are not specified, the result is the same as if a sequence of columns were specified that contains all of the columns in the table in the order specified in the CREATE TABLE statement or CREATE VIEW statement. In this case, every table column defined by the user is a target column.

· The number of expressions ( insert_expression) must be equal to the number of target columns.The ith expression is assigned to the ith column name.

· Expressions ( extended_expression) and subqueries (subquery) can be specified simultaneously.

· You can specify one or more subqueries.

· The specified subqueries must only return a single result line.

· The number of selected columns specified in the QUERY expression must be identical to the number of target columns.

· All mandatory columns of the table identified by table name must be target columns.

· If the table name identifies a view table, rows are inserted the base table(s) on which the view table is based. In this case, the target columns of the specified table name correspond to columns of the base tables, on which the view table is based. In the following, the term target column always refers to the corresponding column in the base table.

Further Information

· Data type of the target column and data type of the value to be inserted

· Join view table in INSERT statement

· QUERY expression in INSERT statement

· DUPLICATES clause

· Constraint definition in INSERT statement

· Trigger in INSERT statement

In the case of the INSERT statement, the third entry of SQLERRD in the SQLCA is set to the number of inserted rows.

If errors occur when rows are inserted, the INSERT statement fails, and the table remains unmodified.


Data Type of the Target Column and Inserted Value (MaxDB: Reference Manual)

Data Type of the Target Column and Inserted Value

Let C be a target column and v a value that is not equal to the NULL value.

v is to be inserted in C by means of an INSERT statement.
v is to be used to modify C with an UPDATE statement.

Target column C

Required value for v

Numeric column

Number within the permissible range of C.

INSERT statement: if v is the result of a QUERY expression, decimal places are rounded off if necessary.

UPDATE statement: if v is the result of an expression that does not comprise one single numeric literal, decimal places are rounded off if necessary.

Alphanumeric column with the code attribute ASCII, UNICODE

Character string whose length is not greater than the length attribute of C. Subsequent blanks are ignored when the length of v is calculated. If the length of v is shorter than the length attribute of C, then v is lengthened by the corresponding number of blanks.

Alphanumeric column with the code attribute BYTE

Hexadecimal character string whose length is not greater than the length attribute of C. Subsequent binary zeros are ignored when the length of v is calculated. If the length of v is shorter than the length attribute of C, then v is lengthened by the corresponding number of binary zeros.

Data type DATE

Date value in the current date format.

Data type TIME

Time value in the current time format.

Data type TIMESTAMP

Timestamp value in the current timestamp format.

Data type BOOLEAN

One of the values TRUE or FALSE (BOOLEAN)


Join View Table in INSERT Statement (MaxDB: Reference Manual)

Join View Table in INSERT Statement

If the table name does not identify a join view table in an INSERT statement (see CREATE VIEW statement ), and a row containing the key of the row to be inserted already exists, the result will depend on the DUPLICATES clause . The INSERT statement will fail if no DUPLICATES clause is specified.

If the table name identifies a join view table, a row is inserted into each base table on which the view table is based. If the key table of the view table already contains a row with the key of the row to be inserted, the INSERT statement will fail. If any row in a base table, which is not the key table of the view table, already contains the key of the row to be inserted, the INSERT statement will fail if the row to be inserted does not match the existing row.


QUERY Expression in INSERT Statement (MaxDB: Reference Manual)

QUERY Expression in INSERT Statement

If a QUERY expression is specified in the INSERT statement , the specified table must not be a join view table.

The QUERY expression defines a result table (see result table name ) whose ith column is assigned to the ith target column. A row is formed from each row in the result table and inserted in the base table. Each of these rows has the following contents:

  • Each base table column that is a target column of the INSERT statement contains the value of the corresponding column in the current result table row.

If a QUERY expression is not specified in the INSERT statement, exactly one row is inserted in the specified table. The inserted row has the following contents:

  • Each base table column that is a target column of the INSERT statement contains the value assigned to the respective target column.

The following still applies to the inserted row(s):

  • All columns of the base table that are not target columns of the INSERT statement and for which a DEFAULT specification exists contain the DEFAULT value.
  • All columns of the base table that are not target columns of the INSERT statement and for which no DEFAULT specification exists contain the NULL value .


DUPLICATES clause (MaxDB: Reference Manual)

DUPLICATES clause

The DUPLICATES clause can be used to determine how key collisions are handled.

Syntax

<duplicates_clause> ::= REJECT DUPLICATES | IGNORE DUPLICATES | UPDATE DUPLICATES

Explanation

SQL statements in which the DUPLICATES clause is used

CREATE TABLE statement

REJECT DUPLICATES or no DUPLICATES clause | The CREATE TABLE statement fails if key collisions occur.
IGNORE DUPLICATES | Any rows that key collisions on insertion are ignored.
UPDATE DUPLICATES | Any rows that key collisions on insertion overwrite the rows with which they collide.

INSERT statement

If there is already a row in the base table with the key of the row to be inserted, the following cases must be distinguished:

REJECT DUPLICATES or no DUPLICATES clause | The INSERT statement fails.
IGNORE DUPLICATES | The new row is not inserted and processing of the INSERT statement is continued.
UPDATE DUPLICATES | The existing row is overwritten by the new row and processing of the INSERT statement is continued.

If there is more than one key collision for the same key for an INSERT statement with UPDATE DUPLICATES and QUERY expression specification, it is impossible to predict the content of the respective base table row once the INSERT statement has been completed.

If, for an INSERT statement with IGNORE DUPLICATES and a QUERY expression, more than one row in the result table produces the same base table key, and if this key did not exist before in the base table, it is impossible to predict the row that will be inserted in the table.

If the table name specified in the INSERT statement identifies a table without a user-defined key, the DUPLICATES clause has no effect.


Constraint Definition in INSERT Statement (MaxDB: Reference Manual)

Constraint Definition in INSERT Statement

If CONSTRAINT definitions exist for base tables in which rows are to be inserted with the INSERT statement , each row that is to be inserted is checked against the CONSTRAINT definition. The INSERT statement fails if this is not the case for at least one row.

If at least one of the base tables in which rows are to be inserted with the INSERT statement is the referencing table of a referential CONSTRAINT definition , the database system checks each row to be inserted to determine whether the foreign key resulting from the row exists as a key or as a value of an index defined with UNIQUE (see CREATE INDEX statement ) in the corresponding referenced table. The INSERT statement fails if this is not the case for at least one row.


Trigger in INSERT Statement (MaxDB: Reference Manual)

Trigger in INSERT Statement

If triggers that are to be executed after an INSERT statement were defined for base tables in which rows are to be inserted with the INSERT statement, they are executed accordingly. The INSERT statement will fail if one of these triggers fails.


Extended expression (MaxDB: Reference Manual)

Extended expression

An extended expression can be specified by means of an expression or one of the keywords DEFAULT or STAMP.

Syntax

<extended_expression> ::= <expression> | DEFAULT | STAMP

expression

Explanation

  • Expression
     INSERT statement : an expression in an INSERT statement must not contain a column specification .
    The value specified by a     parameter specification in an expression is the value of the parameter identified by the specification. If an indicator parameter is specified with a negative value, the value defined by the parameter specification is a NULL value.
  • Keyword DEFAULT
    DEFAULT denotes the value used as the DEFAULT for the column.
  • STAMP key word
    The database system is able to generate unique values. This is a serial number that starts with X'000000000001'. The values are assigned in ascending order. It cannot be ensured that a sequence of values is uninterrupted. The STAMP key word supplies the next value generated by the database system.
    The STAMP keyword can be used in the     INSERT statement or in the UPDATE statement , but only for columns of the data type CHAR(n) BYTE with n>=8 ( default specification ).
    If the user wants to find out the generated value before it is applied to a column, he or she must use the following SQL statement:
     NEXT STAMP statement

See also:

SET INSERT condition

SET UPDATE condition


SET INSERT clause (MaxDB: Reference Manual)

SET INSERT clause

SET INSERT clause

Syntax

<set_insert_clause> ::= <column_name> = <extended_value_spec>

column_name , extended_value_spec

Explanation

SQL statements in which the SET INSERT clause is used

INSERT statement


UPDATE Statement (MaxDB: Reference Manual)

UPDATE Statement

The UPDATE statement changes column values in table rows.

Syntax

<update_statement> ::=
  UPDATE [OF] <table_name> [<reference_name>] SET <set_update_clause>,... [KEY <key_spec>,...] [WHERE <search_condition>]
| UPDATE [OF] <table_name> [<reference_name>] (<column_name>,...) VALUES (<extended_value_spec>,...) [KEY <key_spec>,...] [WHERE <search_condition>]
| UPDATE [OF] <table_name> [<reference_name>] SET <set_update_clause>,... WHERE CURRENT OF <result_table_name>
| UPDATE [OF] <table_name> [<reference_name>] (<column_name>,...) VALUES (<extended_value_spec>,...) WHERE CURRENT OF <result_table_name>

table name , reference name , set update clause , key spec , search condition , column name , extended value spec , result table name

Explanation

The table name must denote an existing base table, view table (see Table ), or a synonym .

Columns whose values are to be updated are called target columns. One or more target columns and new values for these columns are specified after the table name and reference name (if necessary).

  • All target columns must identify columns in the specified table, and each target column may only be listed once.
  • The number of specified values ( extended_value_spec ) must be identical to the number of target columns. The ith value specification is assigned to the ith target column.
  • The current user must have the UPDATE privilege for each target column in the specified table.
    If the table name identifies a view table, even the owner of the view table may not be able to update column values because the view table is not updateable.
  • If the specified table is a view table, column values are only updated in rows in the base tables on which the view table is based. In this case, the target columns of the specified table correspond to columns in the base tables on which the view table is based. In the following paragraphs, the term target column always refers to the corresponding column in the base table.

Data type of the target column and data type of the value to be inserted

The following specifications determine the rows in the table that are updated:

  • Optional sequence of key specifications and optional search condition
    Key specification and no search condition: a row with the specified key values already exists. The corresponding values are assigned to the target columns in this row. No rows are updated if a row with the specified key values does not exist.
    Key specification and a search condition: a row containing the specified key values exists. The search condition is applied to this row. If the search condition is satisfied, the corresponding values are assigned to the target columns of this row. No rows are updated if a row with the specified key values does not exist or if a search condition applied to a row is not fulfilled.
    No key specification and a search condition: the search condition is applied to each row in the specified table. The corresponding values are assigned to the target columns of all rows that satisfy the search condition.
  • If CURRENT OF is used, i.e. if the cursor position in the result table (result_table_name) is specified: no rows are updated if the cursor is not positioned on a row in the result table.
  • If none of the above specifications were made, all of the rows in the specified table are updated.
  • If no row is found that satisfies the conditions defined by the optional clauses, the following message appears: 100 row not found.

Even values in key columns that were defined by a user in a CREATE TABLE statement or ALTER TABLE statement can be updated. The implicit key column SYSKEY, if created, cannot be updated.

If the table name specifies a join view table (see CREATE VIEW statement ), columns may exist that can only be updated in conjunction with other columns (determine the column combination for a column or a join view table ). To update the value of the relevant column, a value must be specified for all of the columns in the column combination. This is true of all target columns that fulfill the following conditions:

  • The target columns are located in a base table that is not a key table of the join view table and does not have a 1 : 1 relationship with the key table of the join view table.
  • The target columns are foreign key columns of a referential CONSTRAINT definition that is relevant for the join view table.

CURRENT OF

If CURRENT OF is specified, the table name in the FROM clause of the QUERY statement, with which the result table was built, must be identical to the table name in the UPDATE statement.

If CURRENT OF is specified and the cursor is positioned on a row in the result table, the corresponding values are assigned to the target columns of the corresponding row. The corresponding row is the row of the table specified in the FROM clause of the query statement, from which the result table row was formed. This procedure requires that the result table was specified with FOR UPDATE. It is impossible to predict whether or not the updated values in the corresponding row are visible the next time the same row of the result table is accessed.

Reasons for an UPDATE statement failure

If CONSTRAINT definitions exist for base tables in which rows were updated with the UPDATE statement, each row that was updated is checked against the CONSTRAINT definitions. The UPDATE statement fails if this is not the case for at least one modified row.

For each row in which the value of foreign key columns has been updated with the UPDATE statement, the database system checks whether the respective resulting foreign key exists as a key or as a value of an index defined with UNIQUE (see CREATE INDEX statement ) in the corresponding referenced table. The UPDATE statement fails if this is the case for at least one modified row.

For each row in which the value of a referenced column of a referential CONSTRAINT definition is to be updated using the update statement, the database system checks whether there are rows in the corresponding foreign key table that contain the old column values as foreign keys. The UPDATE statement fails if this is the case for at least one row.

If triggers that are to be executed after an UPDATE statement were defined for base tables in which rows are to be updated with the UPDATE statement, they are executed accordingly. The UPDATE statement will fail if one of these triggers fails.

Further information

The update statement can only be used to assign a value to columns with the data type LONG if it contains a parameter or NULL specification. The assignment of values to LONG columns is therefore only possible with some database tools.

In the case of the UPDATE statement, the third entry of SQLERRD in the SQLCA is set to the number of updated rows. Rows are also counted as updated when the old value was overwritten with a new but identical value.

If errors occur while rows are updated, the UPDATE statement fails, leaving the table unchanged.


SET UPDATE clause (MaxDB: Reference Manual)

SET UPDATE clause

SET UPDATE clause

Syntax

<set_update_clause> ::= <column_name> = <extended_expression>
| <column_name>,... = (<extended_expression>,...)
| (<column_name>,...) = (<extended_expression>,...)
| <column_name> = <subquery>
| (<column_name>,...) = <subquery>

column_name , extended_expression , subquery

Explanation

The expression of a SET UPDATE clause must not contain a set function .

The subquery must produce a result table with at most one row. The number of columns must be equal to the number of target columns specified.

SQL statement in which the SET UPDATE clause is used

UPDATE statement


Column combination for a given column of a join view table (MaxDB: Reference Manual)

Column combination for a given column of a join view table

To determine the combination of columns for a given column v in the join view table V, use the following procedure:

  1. Determine the base table Tj containing the column which corresponds to v.
  2. Determine the unique table sequence Til...Tik that contains Tj.
  3. Determine the last table Til in this sequence that has a 1:1 relationship with the key table.
  4. The columns of V, which correspond to the foreign key columns of Til of the referential CONSTRAINT definition between Til and Til+I that is relevant for V, are elements of the column combination.
  5. All columns of V which correspond to columns of the tables Til+l...Tik are elements of the column combination.

To update the column value of the column v in an UPDATE statement , a value must be specified for each of the columns of the column combination.


DELETE statement (MaxDB: Reference Manual)

DELETE statement

The DELETE statement deletes rows in a table.

Syntax

<delete_statement> ::=
  DELETE [FROM] <table_name> [<reference_name>] [KEY <key_spec>,...] [WHERE <search_condition>]
| DELETE [FROM] <table_name> [<reference_name>] WHERE CURRENT OF <result_table_name>

table name , reference name , key spec , search condition , result table name

Explanation

The table name must denote an existing base table, view table (see Table ), or a synonym .

The current user must have the DELETE privilege for the specified table. If the table name identifies a view table, even the owner of the view table may not have the DELETE privilege because the view table cannot be changed.

Table name identifies a view table: the rows of the tables on which the view tables are based are deleted.

Table name identifies a join view table: only the following rows are deleted:

  • Rows in the key table of the join view table
  • Rows in base tables on which the view table is based and that have a 1:1: relationship with the key table.

The following specifications determine the rows in the table that are deleted:

  • Optional sequence of key specifications and optional search condition
    Key specification and no search condition: a row with the specified key values already exists. This row is deleted. No rows are deleted if a row with the specified key values does not exist.
    Key specification and a search condition: a row containing the specified key values exists. The search condition is applied to this row. If the search condition is satisfied, then the row is deleted. No rows are deleted if a row with the specified key values does not exist or if a search condition applied to a row is not fulfilled.
    No key specification and a search condition: the search condition is applied to each row in the specified table. All rows for which the search condition is satisfied are deleted.
  • If CURRENT OF is used, i.e. if the cursor position in the result table (result_table_name) is specified: no rows are deleted if the cursor is not positioned on a row in the result table.
  • If none of the above specifications were made, all of the rows in the specified table are deleted.
  • If no row is found that satisfies the conditions defined by the optional clauses, the following message appears: 100 row not found.

CURRENT OF

If CURRENT OF is specified, the table name in the FROM clause of the QUERY statement, with which the result table was built, must be identical to the table name in the DELETE statement.

If CURRENT OF is specified and the cursor is positioned on a row in the result table, the corresponding row is deleted. The corresponding row is the row of the table specified in the FROM clause of the query statement, from which the result table row was formed. This procedure requires that the result table was specified with FOR UPDATE. Afterwards, the cursor is positioned behind the result table row. It is impossible to predict whether or not the updated values in the corresponding row are visible the next time the same row of the result table is accessed.

DELETE rule

For each row deleted in the course of the delete statement which originates from a referenced table of at least one referential CONSTRAINT definition , one of the following actions is carried out - depending on the DELETE rule of the referential constraint definition:

  • DELETE CASCADE: all matching rows in the corresponding foreign key table are deleted.
  • DELETE RESTRICT: if there are matching rows in the corresponding foreign key table, the delete statement fails.
  • DELETE SET NULL: the NULL value is assigned to the respective foreign key columns of all matching rows in the corresponding foreign key table.
  • DELETE SET DEFAULT: the DEFAULT value that was set with a DEFAULT specification is assigned to the respective foreign key columns of all matching rows in the corresponding foreign key table.

Trigger

If triggers that are to be executed after a DELETE statement were defined for base tables from which rows are to be deleted with the DELETE statement, they are executed accordingly. The DELETE statement will fail if one of these triggers fails.

Further information

In the case of the DELETE statement, the third entry of SQLERRD in the SQLCA is set to the number of deleted rows. If this counter has the value -1, either a significant part of the table or the entire table was deleted by the delete statement.

If errors occur in the course of the delete statement, the statement fails, leaving the table unchanged.


NEXT STAMP statement (MaxDB: Reference Manual)

NEXT STAMP statement

The NEXT STAMP statement supplies a unique key that was generated by the database system.

Syntax

<next_stamp_statement> ::= NEXT STAMP [INTO] <parameter_name>

parameter_name

Explanation

The database system is able to generate unique values. This is a serial number that starts with X'0000000000001'. The values are assigned in ascending order. It cannot be ensured that a sequence of values is uninterrupted. These values can be stored in a column with the data type CHAR (n) BYTE with n>=8.

The NEXT STAMP statement assigns the next key generated by the database system to the variable denoted by parameter name.

The NEXT STAMP statement can only be embedded in a programming language and cannot be used in interactive mode.

The keyword STAMP can be also used in an INSERT statement or an UPDATE statement if the next value is to be generated by the database system and stored in a column without the user knowing the value.


CALL Statement (call_statement) (MaxDB: Reference Manual)

CALL Statement (call_statement)

The CALL statement causes a database procedure to be executed.

Syntax

<call_statement> ::= CALL <dbproc_name> [(<expression>,...)] [WITH COMMIT]

dbproc_name, expression

Explanation

The specified database procedure name must identify an existing database procedure.

The current user must have the EXECUTE privilege for the database procedure.

The number of expressions must be equal to the number of formal parameters for the database procedure.

The data type of the ith expression must be compatible with the data type of the ith formal parameter for the database procedure.

If the ith formal parameter for the database procedure has the OUT or INOUT mode (see CREATE DBPROC statement), the corresponding expression must be a parameter specification.

WITH COMMIT

If WITH COMMIT is specified, the current transaction is terminated with COMMIT after the database procedure has been executed without errors. If execution of the database procedure fails, the current transaction is terminated with ROLLBACK.


Data Query (MaxDB: Reference Manual)

Data Query

The following sections provide an introduction to the query language (also referred to as the data retrieval language) used by the database system.

SQL statements for data queries

QUERY statement | SINGLE SELECT statement | EXPLAIN statement
OPEN CURSOR statement | FETCH statement | CLOSE statement


QUERY statement (MaxDB: Reference Manual)

QUERY statement

A QUERY statement specifies a result table that can be ordered (see result table name ). There are four different ways of formulating a QUERY statement.

Syntax

<query_statement> ::= <declare_cursor_statement> | <recursive_declare_cursor_statement>
| <named_select_statement> | <select_statement>

declare_cursor_statement , recursive_declare_cursor_statement , named_select_statement , select_statement

Explanation

A QUERY statement generates a named/unnamed result table .

A distinction is made between the following QUERY statements:

Basic types of QUERY statement |
DECLARE CURSOR statement | A named result table is defined. The table is generated with an OPEN CURSOR statement .
Recursive DECLARE CURSOR statement | This statement can be used to generate bills of material.
SELECT statement ( named_select_statement ) | A named result table is defined and generated.
SELECT statement ( select_statement ) | An unnamed result table is defined and generated.

The SELECT statement ( named_select_statement ) and SELECT statement ( select_statement ) are subject to the rules that were specified for the DECLARE CURSOR statement and those that were specified for the OPEN CURSOR statement.

The order of rows in the result table depends on the internal search strategies of the system and is arbitrary. The only reliable means of sorting the result rows is to specify an ORDER clause .

Updateable result table

A result table or the underlying base tables are updateable if the query statement satisfies the following conditions:

  • See the section entitled "Updateable result table" in the SELECT statement (named_select_statement) or SELECT statement (select_statement)
  • The result table is a named result table, i.e. it must not have been generated by a select statement ( select_statement ).


Named/Unnamed Result Table (MaxDB: Reference Manual)

Named/Unnamed Result Table

The difference between a named result table and an unnamed result table (see result table name ) is that the unnamed result table cannot be specified in a FROM clause or in CURRENT OF <result_table_name> of a subsequent SQL statement.

QUERY statement |
DECLARE CURSOR statement (declare_cursor_statement) | A named result table is generated. The column names of a result table defined by this QUERY statement do not have to be unique.
SELECT statement (select_statement) | A unnamed result table is generated. The column names of a result table defined by this QUERY statement do not have to be unique.
SELECT Statement (named_select_statement) | A named result table is generated. The column names of a result table generated by this QUERY statement must be unique.


DECLARE CURSOR statement (MaxDB: Reference Manual)

DECLARE CURSOR statement

The DECLARE CURSOR statement defines a named result table (see named/unnamed result table ) with the name result_table_name .

Syntax

<declare_cursor_statement> ::= DECLARE <result_table_name> CURSOR FOR <select_statement>

result_table_name , select_statement

Explanation

An OPEN CURSOR statement with the name of the result table is required to actually generate the result table defined with a DECLARE CURSOR statement.

See also:

SELECT statement (select_statement)


Recursive DECLARE CURSOR statement (MaxDB: Reference Manual)

Recursive DECLARE CURSOR statement

The recursive DECLARE CURSOR statement can be used to receive bills of material by means of a command.

Syntax

<recursive_declare_cursor_statement> ::= DECLARE <result_table_name> CURSOR FOR
WITH RECURSIVE <reference_name> (<alias_name>,...) AS
(<initial_select> UNION ALL <recursive_select>) <final_select>

<initial_select> ::= <query_spec>
<recursive_select> ::= <query_spec>
<final_select> ::= <select_statement>

result_table_name , reference_name , alias_name , query_spec , select_statement

DECLARE C CURSOR FOR
WITH RECURSIVE PX (MAJOR, MINOR, NUMBER, MAINMAJOR) AS
  (SELECT W,X,Y,W FROM T WHERE W = 'aaa' UNION ALL
   SELECT W,X,Y,MAINMAJOR FROM T, PX WHERE MINOR = T.W)
 SELECT MAINMAJOR,MINOR,NUMBER FROM PX ORDER BY NUMBER

Explanation

  • The QUERY specification initial_select is executed and the result is entered in a temporary result table whose name is defined by specifying the reference name. The column names contained in it receive the names from the list of alias names. The number of output columns in the QUERY specification must be identical to the number of alias names.
  • The QUERY specification recursive select should comprise a SELECT statement that contains at least the reference name in the FROM clause and one JOIN predicate between this table and a different table from the FROM clause.
    The QUERY specification     recursive_select is repeated until it does not produce a result. The respective results are (logically) entered in the temporary result table whose name is defined by the reference name. This table is extended continuously. It is ensured, however, that the results of the n th execution are used for the n+1 th execution to avoid an endless loop.
  • The SELECT statement final_select must only contain one QUERY expression that comprises a QUERY specification .
    This is a SELECT statement across the table with the specified reference name in which the following elements can be used:     set function names , GROUP clause , HAVING clause , ORDER clause , LOCK option

If a result table name with the specified reference name existed before the recursive DECLARE CURSOR statement was executed, the corresponding cursor is closed implicitly.


SELECT Statement (named_select_statement) (MaxDB: Reference Manual)

SELECT Statement (named_select_statement)

A SELECT statement (named_select_statement) defines and creates a result table with the name result_table_name (see named/unnamed result table ).

Syntax

<named_select_statement> ::= <named_query_expression>
[<order_clause>] [<update_clause>] [<lock_option>] [FOR REUSE]

named query expression , order clause , update clause , lock option

Explanation

An OPEN CURSOR statement is not permitted for result tables created with this SELECT statement.

The SELECT statement (named select statement) is subject to the rules that were specified for the DECLARE CURSOR statement and those that were specified for the OPEN CURSOR statement.

Depending on the search strategy, either all the rows in the result table are searched when the SELECT statement (named select statement) is executed and the result table is physically generated, or each next result table row is searched when a FETCH statement is executed, without being physically stored. This must be taken into account for the time behavior of FETCH statements.

Updateable result table

A result table or the underlying base tables are updateable if the query statement satisfies the following conditions:

  • The QUERY expression (named_query_expression) must only comprise one QUERY specification (named_query_spec) .
  • Only one base table or one updateable view table may be specified in the FROM clause of the QUERY specification (named query spec).
  • The DISTINCT keyword (see DISTINCT specification ), a GROUP clause , or HAVING clause must not be specified.
  • Expressions must not contain a set function (set_function_spec) .
  • See also the section entitled "Updateable result table" under QUERY statement .

ORDER clause

The ORDER clause specifies a sort sequence for a result table.

UPDATE clause

An UPDATE clause can only be specified for updateable result tables. For updateable result tables, a position within a particular result table always corresponds to a position in the underlying tables and thus, ultimately, to a position in one or more base tables.

If an UPDATE clause was specified, the base tables can be updated using the position in the result table (CURRENT OF <result table name>) by means of an UPDATE statement or a DELETE statement . A lock can be requested for the affected lines of each of the affected base tables using a LOCK statement .

LOCK option

The LOCK option determines which locks are to be set on the read rows.

FOR REUSE

If the result table is to be specified in the from clause of a subsequent QUERY statement , the table should be specified with FOR REUSE keywords. If FOR REUSE is not specified, the reusability of the result table depends on internal system strategies.

Since specifying FOR REUSE increases the response times of some query statements, it should only be specified if it is required to reuse the result table.

See also:

SELECT statement (select_statement)


SELECT Statement (select_statement) (MaxDB: Reference Manual)

SELECT Statement (select_statement)

A SELECT statement (select_statement) defines and creates an unnamed result table (see named/unnamed result table ).

Syntax

<select_statement> ::= <query_expression> [<order_clause>] [<update_clause>] [<lock_option>] [FOR REUSE]

query expression , order clause , update clause , lock option

Explanation

An OPEN CURSOR statement is not permitted for result tables created with this SELECT statement.

The SELECT statement (select_statement) is subject to the rules that were specified for the DECLARE CURSOR statement and those that were specified for the OPEN CURSOR statement.

Depending on the search strategy, either all the rows in the result table are searched when the SELECT statement (select_statement) is executed and the result table is physically generated, or each next result table row is searched when a FETCH statement is executed, without being physically stored. This must be taken into account for the time behavior of FETCH statements.

Updateable result table

A result table or the underlying base tables are updateable if the query statement satisfies the following conditions:

  • The QUERY statement comprises a DECLARE CURSOR statement.
  • The QUERY expression (query_expression) must only comprise one QUERY specification (query_spec) .
  • Only one base table or one updateable view table may be specified in the FROM clause of the QUERY specification (query_spec).
  • The DISTINCT keyword (see DISTINCT specification ), a GROUP clause , or HAVING clause must not be specified.
  • Expressions must not contain a set function (set_function_spec) .
  • See also the section entitled "Updateable result table" under QUERY statement .

ORDER clause

The ORDER clause specifies a sort sequence for a result table.

UPDATE clause

An UPDATE clause can only be specified for updateable result tables. For updateable result tables, a position within a particular result table always corresponds to a position in the underlying tables and thus, ultimately, to a position in one or more base tables.

If an UPDATE clause was specified, the base tables can be updated using the position in the result table (CURRENT OF <result table name>) by means of an UPDATE statement or a DELETE statement . A lock can be requested for the affected lines of each of the affected base tables using a LOCK statement .

LOCK option

The LOCK option determines which locks are to be set on the read rows.

FOR REUSE

If the result table is to be specified in the from clause of a subsequent QUERY statement , the table should be specified with FOR REUSE keywords. If FOR REUSE is not specified, the reusability of the result table depends on internal system strategies.

Since specifying FOR REUSE increases the response times of some query statements, it should only be specified if it is required to reuse the result table.

See also:

SELECT Statement (named_select_statement)


QUERY Expression (query_expression) (MaxDB: Reference Manual)

QUERY Expression (query_expression)

QUERY expressions are required to generate an unordered result table in a SELECT statement.

Syntax

<query_expression> ::= <query_term> | <query_expression> UNION [ALL] <query_term> | <query_expression> EXCEPT [ALL] <query_term>

query_term

Explanation

If the QUERY expressions consists of only one QUERY specification (query spec) (specified in query term), the result of the expression is the unchanged result of the QUERY specification.

If a QUERY expression consists of more than one QUERY specification, the number of selected columns in all QUERY specifications of the QUERY expression must be the same. The respective ith selected columns of the QUERY specifications must be comparable.

Column type (select column) |
Numeric columns | Are comparable. If all ith selected columns are numeric columns, the ith column of the result table is a numeric column.
Alphanumerical column, code attribute BYTE | Are comparable.
Alphanumerical column, code attribute ASCII, UNICODE | Are comparable. Are also comparable with date, time, and timestamp values.
All ith columns are date values | The ith column of the result table is a date value.
All ith columns are time values | The ith column of the result table is a time value.
All ith columns are timestamp values | The ith column of the result table is a timestamp value.
Columns of the type BOOLEAN | Are comparable.
All ith columns are of the type BOOLEAN | The ith column of the result table is of the type BOOLEAN.
Columns of any other data type (not mentioned above) | The ith column of the result table is an alphanumeric column. Comparable columns with differing code attributes are converted.

If columns are comparable but have different lengths, the corresponding column of the result table has the maximum length of the underlying columns.

Column names in the result table

The names of the result table columns are formed from the names of the selected columns of the first QUERY specification.

Let T1 be the left operand of UNION, EXCEPT, or INTERSECT (defined in query term). Let T2 be the right operand. Let R be the result of the operation on T1 and T2.

· A row is a duplicate of another row if both have identical values in each column. NULL values are assumed to be identical. Special NULL values are assumed to be identical.

· UNION: R contains all rows from T1 and T2.

· EXCEPT: R contains all rows from T1 which have no duplicate rows in T2.

· INTERSECT: R contains all rows from T1 which have a duplicate row in T2. A row from T2 can only be a duplicate row of exactly one row from T1. More than one row from T1 cannot have the same duplicate row in T2.

· DISTINCT is implicitly assumed for the query expressions belonging to T1 and T2 if ALL is not specified. All duplicate rows are removed from R.

If parentheses are missing, then INTERSECT will be evaluated before UNION and EXCEPT. UNION and EXCEPT have the same precedence and will be evaluated from left to right in the case that parentheses are missing.


QUERY term (query_term) (MaxDB: Reference Manual)

QUERY term (query_term)

A QUERY term ( query_term ) is part of the syntax in a QUERY expression ( query_expression or named_query_expression ).

Syntax

<query_term> ::= <query_primary> | <query_term> INTERSECT [ALL] <query_primary>

<query_primary> ::= <query_spec> | (<query_expression>)

query_spec , query_expression

Explanation

See QUERY expression or QUERY expression (named_query_expression)


QUERY Expression (named_query_expression) (MaxDB: Reference Manual)

QUERY Expression (named_query_expression)

QUERY expressions (named_query_expressions) are required to generate an unordered result table in a SELECT statement (named_select_statement).

Syntax

<named_query_expression> ::= <named_query_term> | <named_query_expression> UNION [ALL] <query_term> | <named_query_expression> EXCEPT [ALL] <query_term>

named_query_term, query_term

Explanation

If the QUERY expressions consists of more than one QUERY specification (query_spec) (specified in named_query_term or in query_term), the only the first QUERY specification in the QUERY expression may be a QUERY specification (named_query_spec).

If the QUERY expressions consists of only one QUERY specification (named_query_spec) (specified in named_query_term), the result of the expression is the unchanged result of the QUERY specification.

If a QUERY expression consists of more than one QUERY specification, the number of selected columns in all QUERY specifications of the QUERY expression must be the same. The respective ith selected columns of the QUERY specifications must be comparable.

Column type (select column) |
Numeric columns | Are comparable. If all ith selected columns are numeric columns, the ith column of the result table is a numeric column.
Alphanumerical column, code attribute BYTE | Are comparable.
Alphanumerical column, code attribute ASCII, UNICODE | Are comparable. Are also comparable with date, time, and timestamp values.
All ith columns are date values | The ith column of the result table is a date value.
All ith columns are time values | The ith column of the result table is a time value.
All ith columns are timestamp values | The ith column of the result table is a timestamp value.
Columns of the type BOOLEAN | Are comparable.
All ith columns are of the type BOOLEAN | The ith column of the result table is of the type BOOLEAN.
Columns of any other data type (not mentioned above) | The ith column of the result table is an alphanumeric column. Comparable columns with differing code attributes are converted.

If columns are comparable but have different lengths, the corresponding column of the result table has the maximum length of the underlying columns.

Column names in the result table

The names of the result table columns are formed from the names of the selected columns of the first QUERY specification.

Let T1 be the left operand of UNION, EXCEPT, or INTERSECT (defined in named_query_term). Let T2 be the right operand. Let R be the result of the operation on T1 and T2.

· A row is a duplicate of another row if both have identical values in each column. NULL values are assumed to be identical. Special NULL values are assumed to be identical.

· UNION: R contains all rows from T1 and T2.

· EXCEPT: R contains all rows from T1 which have no duplicate rows in T2.

· INTERSECT: R contains all rows from T1 which have a duplicate row in T2. A row from T2 can only be a duplicate row of exactly one row from T1. More than one row from T1 cannot have the same duplicate row in T2.

· DISTINCT is implicitly assumed for the query expressions belonging to T1 and T2 if ALL is not specified. All duplicate rows are removed from R.

If parentheses are missing, then INTERSECT will be evaluated before UNION and EXCEPT. UNION and EXCEPT have the same precedence and will be evaluated from left to right in the case that parentheses are missing.


QUERY term (named query term) (MaxDB: Reference Manual)

QUERY term (named query term)

A QUERY term ( named_query_term ) is part of the syntax in a QUERY expression ( named_query_expression ).

Syntax

<named_query_term> ::= <named_query_primary> | <named_query_term> INTERSECT [ALL] <query_primary>

<named_query_primary> ::= <named_query_spec> | (<named_query_expression>)
<query_primary> ::= <query_spec> | (<query_expression>)

named_query_spec , named_query_expression , query_spec , query_expression

Explanation

See QUERY expression (named_query_expression)


QUERY specification (query_spec) (MaxDB: Reference Manual)

QUERY specification (query_spec)

QUERY specifications ( query_spec ) are required to generate an unordered result table in a SELECT statement . A QUERY specification is part of the syntax in a QUERY term (query_term) or QUERY term (named_query_term) .

Syntax

<query_spec> ::= SELECT [<distinct_spec>] <select_column>,... <table_expression>

distinct_spec , select_column , table_expression

Explanation

A QUERY specification specifies a result table. The result table is generated from a temporary result table. The temporary result table is the result of the table expression .


DISTINCT function (distinct spec) (MaxDB: Reference Manual)

DISTINCT function (distinct spec)

The DISTINCT specification (distinct_spec) is specified in a QUERY specification (query_spec) , QUERY specification (named_query_spec) , or SINGLE SELECT statement to remove duplicate rows.

Syntax

<distinct_spec> ::= DISTINCT | ALL

Explanation

A row is a duplicate of another row if both have identical values in each column. NULL values are assumed to be identical. Special NULLvalues are also assumed to be identical.

DISTINCT: all duplicate rows are removed from the result table.

ALL: no duplicate rows are removed from the result table.

If no DISTINCT specification is specified, no duplicate rows are removed from the result table.


Selected Column (select_column) (MaxDB: Reference Manual)

Selected Column (select_column)

Selected columns (select_column) must be specified in a QUERY specification (query_spec) or a QUERY specification (named_query_spec) to specify a result table.

The sequence of selected columns defines the columns in the result table. The columns in the result table are produced from the columns of the temporary result table and by the rowno columns or stamp columns, if these exist. The columns of the temporary result table are determined by the FROM clause of the table expression . The order of the column names in the temporary result table is determined by the order of the table names in the FROM clause.

Syntax

<select_column> ::= <table_columns> | <derived_column> | <rowno_column> | <stamp_column>

<table_columns> ::= * | <table_name>.* | <reference_name>.*
<derived_column> ::= <expression> [ [AS] <result_column_name>] | <result_column_name> = <expression>
<rowno_column> ::= ROWNO [<result_column_name>] | <result_column_name> = ROWNO
<stamp_column> ::= STAMP [<result_column_name>] | <result_column_name> = STAMP

<result_column_name> ::= <identifier>
 table_name , reference_name , expression , identifier

Explanation

Every column name that is specified as a selected column must uniquely denote a column in a QUERY specification (query spec) of the underlying tables. If necessary, the column name must be qualified with the table name.

The specification of a column with the data type LONG in a selected column is only valid in the uppermost sequence of selected columns in a QUERY statement or SINGLE SELECT statement if the DISTINCT specification was not used there.

The specification of a column with the data type LONG in a selected column is only valid in the uppermost sequence of select columns in a CREATE VIEW statement which is based on exactly one base table.

If a selected column contains a set function (set function spec) , the sequence of selected columns to which the selected column belongs must not contain any table columns, and every column name occurring in an expression must denote a grouping column, or the expression must consist of grouping columns.

It is possible to specify scalar subqueries .

  • Specifying table columns in a selected column is a quick way of specifying the result table columns.
    • Specifying a selected column of the type * is a quick way of specifying all temporary result table columns.
      Columns for which the user has not the SELECT privilege and the implicitly generated column SYSKEY are not passed.
    • Specifying <table_name>.* or <reference_name>.* is quick way of specifying all the columns in the underlying table. The first column name of the result table is taken from the first column name of the underlying table, the second column name of the result table corresponds to the second column name of the underlying table, etc. The order of column names in the underlying table corresponds to the order determined when the underlying table is defined.
      Columns for which the user has not the SELECT privilege and the implicitly generated column SYSKEY are not passed.
  • Specifying derived column in a selected column defines a column in the result table. If a column of the result table has the form <expression> [AS] <result_column_name> or the form <result_column_name> = <expression>, this result column receives the name result_column_name.
    If no     <result_column_name> is specified and the expression is a column specification that denotes a column in the temporary result table, the column in the result table receives the column name of the temporary result table.
    If no     <result_column_name> is specified and the expression is not a column specification, the column receives the name EXPRESSION_, where "_" denotes a number with a maximum of three digits, starting with EXPRESSION1, EXPRESSION2, etc.
  • A ROWNO column may only be used in a selected column that belongs to a QUERY statement.
    If a rowno column is specified, a column with the data type     FIXED (10) is generated with the name ROWNO. It contains the values 1, 2, 3,... which the numbers of the result table rows.
    If the ROWNO column was specified in the form     ROWNO <result_column_name> or the form <result_column_name> = ROWNO, this result column receives the name result_column_name.
    A rowno column>must not be ordered by using ORDER BY.
  • A STAMP column may only be specified in a selected column that belongs to a QUERY- expression of an INSERT statement .
    The database system is able to generate unique values. This is a serial number that starts with X'000000000001'. The values are assigned in ascending order. It cannot be ensured that a sequence of values is uninterrupted.
    If a stamp column is specified, the next value of the data type     CHAR (8) BYTE generated by the database system is produced for each row in the temporary result table.

Each column of a result table has exactly the same data type, the same length, the same precision, and the same scale as the derived column or the column underlying the table columns.

This does not apply to the data types DATE and TIMESTAMP. To enable the representation of any date and time format, the length of the result table column is set to the maximum length required for the representation of a date value (length 10) or a timestamp value (length 26).


QUERY specification (named_query_spec) (MaxDB: Reference Manual)

QUERY specification (named_query_spec)

QUERY specifications ( named_query_spec ) are required to generate an unordered result table in a SELECT statement (named_select_statement) . A QUERY specification is part of the syntax in a QUERY term (named_query_term) .

Syntax

<named_query_spec> ::= SELECT [<distinct_spec>] <result_table_name> (<select_column>,...) <table_expression>

distinct_spec , result_table_name , select_column , table_expression

Explanation

A QUERY specification specifies a result table with the name result_table_name . The result table is generated from a temporary result table. The temporary result table is the result of the table expression .


Table expression (MaxDB: Reference Manual)

Table expression

A table expression specifies a single or a simple or grouped result table (see result table name ).

Syntax

<table_expression> ::= <from_clause> [<where_clause>] [<group_clause>] [<having_clause>]

from_clause , where_clause , group_clause , having_clause

Explanation

A table expression produces a temporary result table. If there are no optional clauses, this temporary result table is the result of the from clause. Otherwise, each specified clause is applied to the result of the previous condition and the table is the result of the last specified clause. The temporary result table contains all of the columns in all the tables listed in the from clause.

The order of the GROUP and HAVING clauses is random.


FROM clause (MaxDB: Reference Manual)

FROM clause

A FROM clause specifies a table in a table expression that is formed from one or more tables.

Syntax

<from_clause> ::= FROM <from_table_spec>,...

from_table_spec

Explanation

The from clause specifies a table. This table can be derived from several base, view, and result tables (see Table ). The number of underlying tables in a FROM clause is equal to the total number of underlying tables in each FROM TABLE specification. The number of underlying tables in a from clause must not exceed 64.

The user must have the SELECT privilege for each specified table or for at least one column in the specified table.

The result of a FROM clause is a table that is generated from the specified tables as follows:

  • If the FROM clause comprises a single FROM TABLE specification, the result is the specified table.
  • If the from clause contains more than one from table specification, a result table is built that includes all possible combinations of all rows of the first table with all rows of the second table, etc. From a mathematical perspective, this is the Cartesian product of all the tables.

This rule describes the effect of the from clause, not its actual implementation.


FROM TABLE Specification (from_table_spec) (MaxDB: Reference Manual)

FROM TABLE Specification (from_table_spec)

Each FROM TABLE specification (from_table_spec) in a FROM clause specifies either no table identifier, one table identifier, or any number of table identifiers.

Syntax

<from_table_spec> ::= <table_name> [AS] [<reference_name>]
| <result_table_name> [AS] [<reference_name>]
| (<query_expression>) [AS] [<reference_name>]
| <joined_table>

table_name, reference_name, result_table_name, query_expression, joined_table

Explanation

Reference Name (reference_name)

If a FROM TABLE specification does not contain a reference name, the table name (table_name) or result table name (result_table_name) is the table identifier.

If a FROM TABLE specification contains a reference name, the reference name is the table identifier.

Each reference name must be different from each identifier that specifies a table name. If a results table name is a table identifier, there must not be any table identifier <table_name> of the form [<owner.]<result_table_name> (the owner is the current user). Each table identifier must differ from any other table identifier.

The validity range of the table identifiers is the entire QUERY specification within which the FROM TABLE specification is used. If column names are to be qualified within the query specification, table identifiers must be used for this purpose.

Reference names are essential for formulating JOIN conditions within a table. For example, FROM HOTEL, HOTEL Xdefines a reference name X for the second occurrence of the HOTEL table. Reference names are also necessary sometimes to formulate correlated subqueries. Similarly, a reference name is required if a column in the result of a QUERY expression can only be identified uniquely by specifying the reference name.

Number of Underlying Tables

If a from table specification denotes a base table, result table, or the result of a query expression, the number of tables underlying this from table specification is equal to 1.

If a from table specification denotes a complex view table, the number of tables underlying this from table specification is equal to 1.

If a from table specification denotes a view table that is not a complex view table, the number of underlying tables is equal to the number of tables underlying the FROM condition of the view table.

If a from table specification denotes a JOINED TABLE, the number of tables underlying this from table specification is equal to the total number of underlying tables of the FROM TABLE specifications contained in it.

QUERY Expression (query_expression)

A FROM TABLE specification that contains a QUERY expression specifies a table identifier only if a reference name is specified.

If a FROM TABLE specification contains a QUERY expression, a result table is built that matches this QUERY expression. This result table obtains a system-internal name that collides neither with an unnamed nor a named result table. While the from condition is being processed, the result of the query expression is used in the same way as a named result table and is deleted implicitly after processing.

A table expression containing at least one OUTER JOIN indicator (see JOIN predicate) or OUTER JOIN TYPE (LEFT | RIGHT | FULL) (see joined_table) is subject to strict restrictions if it is to be based on more than two tables. For this reason, a QUERY expression is frequently required to formulate a QUERY specification that is to be based on at least three tables and in which at least one OUTER JOIN indicator is used in a JOIN predicate.

JOINED TABLE (joined_table)

A from table specification containing a JOINED TABLE (joined_table) specifies the number of table identifiers that are specified by the FROM TABLE specifications it contains.


Joined Table (joined_table) (MaxDB: Reference Manual)

Joined Table (joined_table)

A joined table (joined_table) can be specified as part of a FROM TABLE specification (from_table_spec).

Syntax

<joined_table> ::=
<from_table_spec> CROSS JOIN <from_table_spec>
| <from_table_spec> [INNER] JOIN <from_table_spec> <join_spec>
| <from_table_spec> [<LEFT|RIGHT|FULL> [OUTER]] JOIN <from_table_spec> <join_spec>

<join_spec> ::= ON <search_condition>

from_table_spec, search_condition

Explanation

If a FROM TABLE specification comprises a joined table, the result is generated as follows:

Let FT1 be the set of all rows in the table specified by the first from table specification. Let FT2 be the set of all rows in the table specified by the second from table specification.

· If the joined table is specified as CROSS JOIN, a table is created that comprises all possible combinations of FT1 and FT2. From a mathematical perspective, the Cartesian product of the two tables is calculated.

· If the joined table is specified with the keyword JOIN without the optional keywords INNER, LEFT, RIGHT, FULL, or OUTER, the join type is assumed to be INNER.

Let T be the set of result rows consisting of all possible combinations of FT1 and FT2. Each result row satisfies the join specification for this set.

· If the joined table is specified with the join type INNER, the result is the set T.

· If the joined table is specified with the join type LEFT, the result is the set T plus the rows from FT1 that are not in T. The result columns that are not formed from FT1 are assigned the NULL value.

· If the joined table is specified with the join type RIGHT, the result is the set T plus the rows from FT2 that are not in T. The result columns that are not formed from FT2 are assigned the NULL value.

· If the joined table is specified with the join type FULL, the result is the set T plus the rows from FT1 that are added by the join types LEFT and RIGHT.

The rules specified for the WHERE condition apply to the JOIN specification (join_spec) ON <search_condition> with the restriction that no links using the Boolean operator OR are permitted.


WHERE Clause (where_clause) (MaxDB: Reference Manual)

WHERE Clause (where_clause)

The WHERE clause ( where_clause) specifies the conditions for building a results table .

Syntax

<where_clause> ::= WHERE <search_condition>

search_condition

Explanation

The search condition is applied to each row in the temporary result table formed by the FROM clause. The result of the WHERE clause is a table that only contains those rows from the result table for which the search condition is true.

The search condition may only contain column specifications for which the user has the SELECT privilege.

Each column specification directly contained in the search condition must uniquely identify a column from the tables specified in the FROM clause of the table expression. If necessary, the column name must be qualified with the table identifier. If reference names are defined in the FROM clause for table names, they must be used as table identifiers in the search condition.

Expressions in the search condition must not contain a set function (set_function_spec), except in the exception below.

SELECT ... FROM uppertab,...
HAVING ... (SELECT ...
                  WHERE MIN(uppertab, ...)...
           )

The SELECT statement is allowed in the specified format.

HAVING clause: In a subquery used in this clause, it is possible to use WHERE clauses that contain Set functions for the columns of the table used in the SELECT … HAVING statement (Correlated Subquery).

In the case of correlated subqueries, a column specification can identify a column in a table that was specified in a FROM clause of a different table expression in the QUERY specification.

Each subquery in the search condition is usually evaluated only once. In the case of a correlated subquery, the subquery is executed for each row in the result table generated by the from clause.


GROUP Clause (group_clause) (MaxDB: Reference Manual)

GROUP Clause (group_clause)

The GROUP clause specifies grouping criteria for a result table (see result table name).

Syntax

<group_clause> ::= GROUP BY <expression>,...

expression

Explanation

Each column name specified in the GROUP clause must identify a result_column_name in the selected columns of the QUERY specification or uniquely identify a column in the tables on which the QUERY specification is based. If necessary, the column name must be qualified with the table identifier.

The GROUP clause allows the functions SUM, AVG, MAX/MIN, COUNT, STDDEV, and VARIANCE to be applied not only to entire result tables but also to groups of rows within a result table. A group is defined by the grouping columns specified in GROUP BY. All rows of a group have the same values in the grouping columns. Rows containing the NULL value in a grouping column are combined to form a group. The same is true for the special NULL value.

GROUP BY generates one row for each group in the result table. The selected columns in the QUERY specification, therefore, may only contain those grouping columns and operations on grouping columns, as well as those expressions that use the functions SUM, AVG, MAX/MIN, COUNT, STDDEV, and VARIANCE.

If no rows satisfy the conditions indicated in the WHERE clause and a group clause was specified, the result table is empty.

Specifying scalable subqueries is not permissible in a GROUP clause.

See also:

Technical Specifications


HAVING clause (MaxDB: Reference Manual)

HAVING clause

The HAVING clause specifies the properties of a group.

Syntax

<having_clause> ::= HAVING <search_condition>

search_condition

Explanation

Each expression in the search condition that does not occur in the argument of a set function (set_function_spec) must identify a grouping column.

If the having clause is used without a GROUP clause , the result table built so far is regarded as a group.

The search condition is applied to each group in the result table. The result of the HAVING clause is a table that only contains those groups for which the search condition is true.


Subquery (MaxDB: Reference Manual)

Subquery

A subquery specifies a result table (see result table name ) that can be used in certain predicates and for updating column values.

Syntax

<subquery> ::= (<query_expression>)

query_expression

Explanation

Subqueries can be used in a SET UPDATE condition of an UPDATE statement . In this case, the subquery must produce a result table that contains a maximum of one row.

Subqueries can be used in an INSERT statement ( INSERT statement) ).

Subqueries can be used in the following predicates:

Comparison predicate
EXISTS predicate
IN predicate
Quantified predicate

See also:

Scalar Subquery

Correlated Subquery


Correlated Subquery (MaxDB: Reference Manual)

Correlated Subquery

Certain predicates can contain subqueries. These subqueries, in turn, can contain other subqueries, etc. A subquery with further subqueries is the higher-level subquery of the subqueries it contains.

· The search condition of a subquery can contain column names that belong to tables that are contained in higher levels in the FROM clause. This type of subquery is called a correlated subquery.

· Tables that are used in subqueries in this way are called correlated tables. No more than 16 correlated tables are allowed within an SQL statement.

· Columns that are used in subqueries in this way are called correlated columns. A total of 64 correlated columns can be used in an SQL statement.

If the qualifying table name or reference name does not clearly identify a table at a higher level, the table at the lowest level is taken from these non-unique tables.

If the column name is not qualified by the table name or reference name, the tables at higher levels are searched. The column name must be unique in all tables of the from clause to which the table found belongs.

If a correlated subquery is used, the values of one or more columns in a temporary result row at a higher level are included in the searchcondition of a subquery at a lower level, whereby the result of the subquery is used to uniquely qualify the higher-level temporary result row.

Example tables hotel and room.
For every city, the names of all hotels are searched which have single room prices less than the average price of the city concerned.

SELECT name, city FROM hotel X, room

WHERE X.hno = room.hno AND room.roomtype = 'SINGLE' AND room.price <

(SELECT AVG(room.price) FROM hotel, room

WHERE hotel.hno = room.hno AND hotel.city = X.city AND room.roomtype = 'SINGLE' )

Name | City
Eight Avenue | Los Angeles
Sunshine | Los Angeles
Atlantic | New York


Scalar Subquery (scalar_subquery) (MaxDB: Reference Manual)

Scalar Subquery (scalar_subquery)

A scalar subquery (scalar_subquery) is a special subquery.

Syntax

<scalar_subquery> ::= <subquery>

subquery

Explanation

Scalar subqueries are produced through the restriction of the result set of a result table to a maximum of one value.

Scalar subqueries can be used as expressions (see factor).

Scalar subqueries are not allowed in a GROUP clause or an ORDER clause.

Scalar subquery in the list of the values to be inserted in an INSERT statement for the table hotel:

INSERT hotel VALUES((SELECT MAX(hno)+10 FROM hotel), 'Three Seasons', 90014, 'Los Angeles', '247 Broad Street')

Scalar subquery in a selected column:

SELECT hno, price, (SELECT MIN(price) FROM room) FROM room


ORDER Clause (order_clause) (MaxDB: Reference Manual)

ORDER Clause (order_clause)

The ORDER clause specifies a sort sequence for a result table.

Syntax

<order_clause> ::= ORDER BY <sort_spec>,...

<sort_spec> ::= <unsigned_integer> [ASC | DESC] | <expression> [ASC | DESC]

unsigned_integer, expression

Explanation

The sort columns specified in the order clause determine the sequence of the sort criteria.

A number n specified in the sorting specification (sort_spec) identifies the nth column in the result table. n must be less than or equal to the number of columns in the result table.

Scalable subqueries are not permissible in an ORDER clause.

ASC/DESC

ASC: the values are sorted in ascending order.

DESC: the values are sorted in descending order.

The default setting is ASC.

Further Information

If a QUERY expression consists of more than one QUERY specification, sort specifications must be specified in the form <unsigned_integer> [ASC | DESC].

If a query specification was specified with DISTINCT, the total of the internal lengths of all sorting columns must not exceed 1016 characters; otherwise it can comprise 1020 characters.

Column names in the sort specifications must be columns in the tables of the FROM clause or a result_column_namein the selected columns of the QUERY specification.

If DISTINCT or a set function was used in a selected column, the sort specification must identify a column in the result table.

Values are compared in accordance with the rules for the comparison predicate. For sorting purposes, NULL values are greater than non-NULL values, and special NULL values are greater than non-NULL values but less than NULL values.

See also:

Technical Specifications


UPDATE Clause (update_clause) (MaxDB: Reference Manual)

UPDATE Clause (update_clause)

The UPDATE clause specifies that a result table (see result table name) is to be updateable. The system sets exclusive locks for all rows that form this result table.

Syntax

<update_clause> ::= FOR UPDATE [OF <column_name>,...] [NOWAIT]

column_name

Explanation

The specified column names must identify columns in the tables underlying the QUERY specification. They do not have to occur in a selected column.

The QUERY statement that contains the UPDATE clause must generate an updateable result table.

The UPDATE clause is a prerequisite for using the results table with CURRENT OF <result_table_name> in the UPDATE statement, in the DELETE statement, and in the LOCK statement. The update clause is meaningless for other forms of the above mentioned SQL statements, as well as in interactive mode.

All columns of the underlying base tables are updateable if the user has the corresponding privileges, irrespective of whether they were specified as a column name.

For performance reasons, it is recommended to specify column names only if the cursor is to be used in an update statement.

Assume that the a column x fulfills the following conditions:

· x is contained in the primary key or an index

· x is contained in the search condition of the QUERY statement

· x is contained in a SET UPDATE clause of the UPDATE statement in the type x = <expression>, where the expression contains the column x.

If all of the conditions are fulfilled, it is essential that you specify the column x as a column name in the UPDATE clause.

If at least one of these conditions is not satisfied, the column name should not be specified.

NOWAIT

If NOWAIT is not specified and a lock collision occurs, the system waits for the locked data object to be released (but only as long as is specified by the special database parameter REQUEST_TIMEOUT).

If NOWAIT is specified, the database system does not wait until another user has released a data object. Instead, it returns a message if a collision occurs. If there is no collision, the requested lock is set.


LOCK Option (lock_option) (MaxDB: Reference Manual)

LOCK Option (lock_option)

The LOCK option requests a lock for each selected row.

Syntax

<lock_option> ::=
  WITH LOCK [(IGNORE)|(NOWAIT)] [EXCLUSIVE|OPTIMISTIC] [ISOLATION LEVEL <unsigned_integer>]

unsigned_integer may only have the values 0, 1, 2, 3, 10, 15, 20, or 30

Explanation

IGNORE

If (IGNORE) is not specified and a lock collision occurs, the system waits for a locked row to be released (but only as long as is specified by the database parameter special database parameter REQUEST_TIMEOUT).

If (IGNORE) is specified, the system does not wait for a locked row to be released by another transaction. Instead, it ignores this row if a lock collision occurs. If there is no collision, the requested lock is set. (IGNORE) can only be specified in isolation level 1.

NOWAIT

If (NOWAIT) is not specified and a lock collision occurs, the system waits for the locked data object to be released (but only as long as is specified by the database parameter REQUEST_TIMEOUT).

If (NOWAIT) is specified, the database system does not wait until another user has released a data object. Instead, it returns a message if a collision occurs. If there is no collision, the requested lock is set.

EXCLUSIVE

An exclusive lock is defined. As long as the locked row has not been changed or deleted, the exclusive lock can be released using the UNLOCK statement.

OPTIMISTIC

An optimistic lock is defined on rows. This is only meaningful in connection with the isolation levels 0, 1, 10, and 15.

Share Lock

If neither EXCLUSIVE nor OPTIMISTIC is specified, a share lock is set on the corresponding rows.

ISOLATION LEVEL

The locks are set independently of the ISOLATION specification (isolation_spec) of the CONNECT statement. The isolation level of the LOCK option can have a higher or lower value than that in the CONNECT statement.

If an isolation level is specified by the lock option, it is only valid for the duration of the SQL statement which contains the LOCK option specification. Afterwards, the isolation level that was specified in the CONNECT statement is applicable again. In the case of a SELECT statement (named_select_statement), SELECT statement (select_statement), or an OPEN CURSOR statement, for which the result table is not actually physically generated, the specified isolation level is valid for this SQL statement and all FETCH statements that refer to the result table. The isolation level that was specified in the CONNECT statement is applicable for other SQL statements that were executed in the meantime.


OPEN CURSOR statement (MaxDB: Reference Manual)

OPEN CURSOR statement

An OPEN CURSOR statement generates the result table defined under the specified name with a DECLARE CURSOR statement .

Syntax

<open_cursor_statement> ::= OPEN <result_table_name>

result_table_name

Explanation

Existing result tables are implicitly deleted when a result table is generated with the same name.

All result tables generated within the current transaction are implicitly deleted at the end of the transaction using the ROLLBACK statement .

All result tables are implicitly deleted at the end of the session using the RELEASE statement . A CLOSE statement can be used to delete them explicitly beforehand.

If the name of a result table is identical with that of a base table, view table (see Table ), or a synonym , these tables cannot be accessed as long as the result table exists.

At any given time when a result table is processed, there is a position which may be before the first row, on a row, after the last row or between two rows. After generating the result table, this position is before the first row of the result table.

Depending on the search strategy, either all the rows in the result table are searched when the OPEN CURSOR statement is executed and the result table is physically generated, or each next result table row is searched when a FETCH statement is executed, without being physically stored. This must be considered for the time behavior of open cursor statements and fetch statements.

If the result table is empty, the return code 100 – row not found - is set.

The number of rows in the result table is returned in the SQLCA in the third entry of SQLERRD. If this counter has the value -1, there is at least one result row.


FETCH Statement (fetch_statement) (MaxDB: Reference Manual)

FETCH Statement (fetch_statement)

The FETCH statement assigns the values of the current row in a result table (see result table name) to parameters.

Syntax

<fetch_statement> ::=
FETCH [FIRST | LAST | NEXT | PREV | <position> | SAME] [<result_table_name>] INTO <parameter_spec>,...

<position> ::= POS (<unsigned_integer>) | POS (<parameter_spec>)
| ABSOLUTE <integer> | ABSOLUTE <parameter_spec>
| RELATIVE <integer> | RELATIVE <parameter_spec>

result_table_name, parameter_spec, unsigned_integer, integer

Explanation

If no result table name is specified, the fetch statement refers to the last unnamed result table that was generated (see named/unnamed result table).

Depending on the search method, either all the rows in the result table are searched when the OPEN CURSOR statement, the SELECT statement (select_statement), or the SELECT statement (named_select_statement) is executed and the result table is generated, or each subsequent row in the result table is searched when a FETCH statement is executed, but they are not physically stored. This must be taken into account for the time behavior of FETCH statements. Depending on the isolation level selected, this can also cause locking problems with a FETCH, e.g. return code 500 - LOCK REQUEST TIMEOUT.

Row not found

Let C be the position in the result table. The return code 100 - ROW NOT FOUND - is output and no values are assigned to the parameters if any of the following conditions is satisfied:

· The result table is empty.

· C is positioned on or after the last result table row, and FETCH or FETCH NEXT is specified.

· C is positioned on or before the first row of the result table and FETCH PREV is specified.

· FETCH is specified with a position which does not lie within the result table.

FIRST | LAST | NEXT | PREV

· FETCH FIRST or FETCH LAST: the result table is not empty. C is positioned in the first or last row of the result table and the values of this row are assigned to the parameters.

· FETCH or FETCH NEXT: C is positioned before a row in the result table. C is positioned in this row and the values of this row are assigned to the parameters.

· FETCH or FETCH NEXT: C is positioned in a row that is not the last row in the result table. C is positioned in the next row and the values in this row are assigned to the parameters.

· FETCH PREV: C is positioned behind a row in the result table. C is positioned in this row and the values of this row are assigned to the parameters.

· FETCH PREV: C is positioned in a row that is not the first row in the result table. C is positioned in the previous row and the values in this row are assigned to the parameters.

Position: POS

Independently of whether an ORDER clause is specified, there is an implicit order of the rows in a result table, to enable internal numbering. This can be displayed by specifying a rowno column as a selected column. The specified position refers to this internal numbering.

If a position is defined with POS, the parameter specification must denote a positive integer.

If a position that is less than or equal to the number of rows in the result table was defined with POS, C is set to the corresponding row and the values of this row are assigned to the parameters. If a position that is greater than the number of rows in the result table was specified, the message 100 – ROW NOT FOUND is output.

Position: ABSOLUTE

Let x be the value of the integer or parameter specification specified with the position. Let abs_x be the absolute value of x.

· FETCH ABSOLUTE and x is : FETCH ABSOLUTE is the same as a FETCH POS.

· FETCH ABSOLUTE and x=0: the return code 100 – row not foundis set.

· FETCH ABSOLUTE and x is negative: C is set after the last row of the result table where FETCH PREV is executed abs_x times. The last row found is the result of the SQL statement. This description refers to the logic and not the flow of the statement. If abs_x is larger than the number of rows in the result table, the message 100 – ROW NOT FOUND is output.

Position: RELATIVE

Let x be the value of the integer or parameter specification specified with the position. Let abs_x be the absolute value of x.

· FETCH RELATIVE and x is positive: FETCH NEXT is executed x times from the current position in the result table C.

· FETCH RELATIVE and x=0: corresponds to a FETCH SAME.

· FETCH RELATIVE and x is negative: FETCH PREV is executed abs_x times starting from C. This description refers to the logic and not the flow of the statement. The return code 100 – row not found is output if one of the conditions in the section "row not found" is fulfilled.

FETCH SAME

The last row found in the result table is output again.

Parameter specification

The parameter specification specified in position must denote an integer.

The remaining parameters in the parameter specification are output parameters. The parameter identified by the nth parameter specification corresponds to the nth value in the current result table row. If the number of columns in this row exceeds the number of specified parameters, the column values for which no corresponding parameters exist are ignored. If the number of columns in the row is less than the number of specified parameters, no values are assigned to the remaining parameters. You must specify an indicator name in order to assign NULL values or special NULL values.

Numbers are converted and character strings are truncated or lengthened, if necessary, to suit the corresponding parameters. If an error occurs when assigning a value to a parameter, the value is not assigned and no further values are assigned to the corresponding parameters for this fetch statement. Any values that have already been assigned to parameters remain unchanged.

Let p be a parameter and v the corresponding value in the current row of the result table.

· v is a number: p must be a numeric parameter and v must be within the permissible range of p.

· v is a character string: p must be an alphanumeric parameter.

Further Information

If no FOR REUSE was specified in the QUERY statement (see SELECT statement), subsequent INSERT, update, or delete statements that refer to the underlying base table and are executed by the current user or by other users can cause several executions of a fetch statement to denote different rows in the result table, even though the same position was specified.

You can prevent other users from making changes by executing a LOCK statement for the entire table or by using the isolation level 2, 3, 15, 20, or 30 with the CONNECT statement or the LOCK option of the query statement.
FOR REUSE must be specified if this is not possible or if the user makes changes to this table. Changes made in the meantime are not visible in this case.

If a result table that was physically created contains LONG columns and if the isolation levels 0, 1, and 15 are used, consistency between the content of the LONG columns and that of the other columns is not ensured. If the result table was not physically generated, consistency is not ensured at isolation level 0 only. For this reason, it is advisable to ensure consistency by using a LOCK statement or the isolation levels 2, 3, 20, or 30.


CLOSE statement (MaxDB: Reference Manual)

CLOSE statement

The CLOSE statement deletes a result table (see result table name ).

Syntax

<close_statement> ::= CLOSE [<result_table_name>]

result_table_name

Explanation

  • If the name of a result table is specified, this result table is deleted. This name can be used to denote another result table.
  • If no result table name is specified, an existing unnamed result table is deleted.

An unnamed result table is implicitly deleted by the next SELECT statement .

Result tables are implicitly deleted when a result table with the same name is generated.

All result tables generated within the current transaction are implicitly deleted at the end of the transaction using the ROLLBACK statement .

All result tables are implicitly deleted at the end of the session using the RELEASE statement .


SINGLE SELECT statement (MaxDB: Reference Manual)

SINGLE SELECT statement

A SINGLE SELECT statement specifies a result table with one row (see result table name ) and assigns the values in this row to parameters.

Syntax

<single_select_statement> ::=
SELECT [<distinct_spec>] <select_column>,...
INTO <parameter_spec>,... FROM <from_table_spec>,...
[<where_clause>] [<group_clause>] [<having_clause>] [<lock_option>]

distinct_spec , select_column , parameter_spec , from_table_spec , where_clause , group_clause , having_clause , lock_option

Explanation

The number of rows in the result table must not be greater than one. If the result table is empty or contains more than one row, corresponding messages or error codes are issued and no values are assigned to the parameters specified in the parameter specifications. The return code 100 – row not found - is set if the result table is empty.

If the result table contains just one row, the values of this row are assigned to the corresponding parameters. The FETCH statement rules apply for assigning the values to the parameters.

The order of the GROUP and HAVING clauses is random.

A LONG column can only be specified in a selected column in the uppermost sequence of selected columns in a single select statement if the DISTINCT specification DISTINCT was not used there.


EXPLAIN Statement (explain_statement) (MaxDB: Reference Manual)

EXPLAIN Statement (explain_statement)

The EXPLAIN statement describes the search strategy used internally by the database system for a QUERY statement or SINGLE SELECT statement (statements for searching for certain rows in specific tables). This statement indicates, in particular, whether and in which form key columns or indexes are used for the search.

Syntax

<explain_statement> ::=
EXPLAIN [(<result_table_name>)] <query_statement>
| EXPLAIN [(<result_table_name>)] <single_select_statement>

result_table_name, query_statement, single_select_statement

Explanation

The explain statement can be used to check the effect of creating or deleting indexes (see index) on the choice of search strategy for the specified SQL statement. You can also estimate the time needed by the database system to process the specified SQL statement. The specified QUERY or SINGLE SELECT statement is not executed while the EXPLAIN statement is being executed.

The EXPLAIN statement generates a result table (see Result Table Name). This result table may be named. If the optional name specification is missing, the result table is given the name SHOW.

Structure of the EXPLAIN Result Table

OWNER | CHAR(64)
TABLENAME | CHAR(64)
COLUMN_OR_INDEX | CHAR(64)
STRATEGY | CHAR(40)
PAGECOUNT | CHAR(10)

The sequence in which the SELECT is processed is described by the order of the rows in the result table.

STRATEGY

The STRATEGY column shows which search strategy or strategies are used and whether a result table is generated. A result table is physically generated if the column STRATEGY contains RESULT IS COPIED in the last result row.

For more information, see Entries in the Strategy Column.

COLUMN_OR_INDEX

The COLUMN_OR_INDEX column shows which key column or indexed column or which index is used for the strategy.

PAGECOUNT

The PAGECOUNT column shows which sizes are assumed for the tables or, in the case of certain strategies, for the indexes. These sizes influence the choice of the search strategy.

The assumed sizes are updated using the UPDATE STATISTICS statement and can be requested by selecting the system table OPTIMIZERSTATISTICS. You can check the current sizes of tables or indexes by selecting the TABLESTATISTICS and INDEXSTATISTICS system tables. If there are large discrepancies between the values contained in the OPTIMIZERSTATISTICS and TABLESTATISTICS, perform the update statistics statement for this table.

If the system discovers during a search in a table that the values determined by the last UPDATE STATISTICS statement are extremely low, a row is entered in the sysupdstatwanted system table that contains the table name. In all other cases, rows are entered in this system table that describe columns in tables. The UPDATE STATISTICS statement should be executed for tables and columns in tables that are described in the SYSUPDSTATWANTED system table.

The last row contains the estimated SELECT cost value in the PAGECOUNT column. The specifications for COSTLIMIT and COSTWARNING in the CREATE USER, CREATE USERGROUP, ALTER USER, and ALTER USERGROUP statements refer to this estimated SELECT cost value.

See also:

SQL Optimizer


Transactions (MaxDB: Reference Manual)

Transactions

The first transaction is opened when a database session is opened with the CONNECT statement. The transaction is concluded with the COMMIT statement or the ROLLBACK statement.

A transaction can be divided into other basic units, subtransactions.

Locks

Since the database system permits concurrent transactions on the same database objects, locks on rows, tables, and the database catalog are necessary to isolate individual transactions.

· The assignment of implicit locks can be affected by setting the isolation level using the CONNECT statement.

· Locks can be assigned explicitly using the LOCK statement or by the assignment of a LOCK option.

· Exclusive locks for rows that have not yet been modified, and share locks on rows can be released by the UNLOCK statement before the end of the transaction.

The locks assigned to a transaction are usually released at the end of the transaction, making the respective database objects accessible again to other transactions.

SQL Statements for Transaction Management

CONNECT Statement | SET statement |
COMMIT Statement | ROLLBACK Statement | SUBTRANS Statement
LOCK Statement | UNLOCK Statement | RELEASE Statement


CONNECT Statement (connect_statement) (MaxDB: Reference Manual)

CONNECT Statement (connect_statement)

A CONNECT statement opens a database session and a transaction for a database user.

Syntax

<connect_statement> ::=
  CONNECT <parameter_name> IDENTIFIED BY <parameter_name> [<connect_option>...]
| CONNECT <parameter_name> IDENTIFIED BY <password> [<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <parameter_name> [<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <password> [<connect_option>...]

<connect_option> ::=
  SQLMODE <INTERNAL|ANSI|DB2|ORACLE>
| ISOLATION LEVEL <unsigned_integer>
| TIMEOUT <unsigned_integer>

parameter_name, password, user_name, unsigned_integer

Explanation

If the parameter name/user name and parameter name/password combination is valid, the user opens a database session and gains access to the database instance. As a result, he or she is the current user in this database session.

A transaction is implicitly opened.

Each connect option (connect_option) may only be specified once.

SQLMODE

The specification SQLMODE <INTERNAL|ANSI|DB2|ORACLE> can be used to select the SQL mode. The default SQL mode is INTERNAL.

The CONNECT option SQLMODE <INTERNAL|ANSI|DB2|ORACLE> is not allowed in programs. The appropriate precompiler option must be used to specify an SQLMODE other than INTERNAL.

ISOLATION LEVEL

The isolation level specified in the connect statement is applied to each new transaction. This specification determines the lock operation type (Locks).

The isolation level is set using an integer without a plus/minus sign after the keywords ISOLATION LEVEL. The following values are permissible: 0, 1, 2, 3, 10, 15, 20, and 30. If no isolation level is specified, isolation level 1 is used.

TIMEOUT

The specified timeout value must be smaller than or equal to the database parameter SESSION_TIMEOUT, and the user-specific timeout value of the user or user group. If it is not, an error is displayed at logon.

If no timeout value is specified, the smaller of the two other values is adopted as the timeout value.

If the TIMEOUT value is set to 0, the inactivity period is not monitored. This can result in a situation where database resources are not available again even though the associated application was concluded or aborted without a RELEASE statement.

Users with the NOT EXCLUSIVE attribute

Users defined with the attribute NOT EXCLUSIVE can open several sessions at the same time. Whenever this is the case, or whenever two users of the same user group open a session at the same time, the sessions are considered to be distinct. This means that lock requests of the sessions involved may result in conflict.


SET Statement (set_statement) (MaxDB: Reference Manual)

SET Statement (set_statement)

The SET statement alters the properties of a database session.

Syntax

<set_statement> ::= SET ROLE ALL [EXCEPT <role_name>] | SET ROLE NONE
| SET ROLE <role_name> [IDENTIFIED BY <password>]
| SET ISOLATION LEVEL <unsigned_integer>

role_name, password, unsigned_integer

Explanation

SET ROLE

DEFAULT ROLE in the ALTER USER statement or ALTER USERGROUP statement specifies which of the roles assigned to the current user or user group is active in the user session or group member session. If a role is active, the current user has all the privileges that are included in the role.

If the ALTER USER statement or ALTER USERGROUP statement assigns a role to the current user that is activated automatically when a session is opened, then this role is deactivated when the SET statement is executed, if it has not been identified by the SET ROLE specification in the SET statement.

· ALL: all roles assigned to the current user are active. EXCEPT can be used to exclude specified roles from activation.

· NONE: none of the roles is active.

· Role name specified: the roles specified here must exist and be assigned to the current user. If a password exists for the role, it must be defined in the set statement in addition to the owner of the role.
The role identified with role name is activated.

ISOLATION LEVEL

Specifying an isolation level changes the lock behavior for all subsequent SQL statements of the current database session. The isolation level is set using an integer without a plus/minus sign after the keywords ISOLATION LEVEL. The following values are permissible: 0, 1, 2, 3, 10, 15, 20, and 30.


COMMIT Statement (commit_statement) (MaxDB: Reference Manual)

COMMIT Statement (commit_statement)

A COMMIT statement (commit_statement) terminates the current transaction and starts a new one (see transactions.

Syntax

<commit_statement> ::= COMMIT [WORK]

Explanation

The commit statement terminates the current transaction (COMMIT).

The COMMIT statement implicitly opens a new transaction. Any locks set within the new transaction are assigned to this transaction. The setting of locks in the new transaction is controlled by the isolation level declared in the CONNECT statement (see Isolation Level).


ROLLBACK Statement (rollback_statement) (MaxDB: Reference Manual)

ROLLBACK Statement (rollback_statement)

The ROLLBACK statement cancels the current transaction and starts a new transaction.

Syntax

<rollback_statement> ::= ROLLBACK [WORK]

Explanation

The ROLLBACK statement implicitly opens a new transaction. Any locks set within the new transaction are assigned to this transaction. The isolation leveldeclared in the CONNECT statement also applies for setting locks in the new transaction.


SUBTRANS Statement (subtrans_statement) (MaxDB: Reference Manual)

SUBTRANS Statement (subtrans_statement)

The SUBTRANS statement divides a transaction into units known as subtransactions.

Syntax

<subtrans_statement> ::= SUBTRANS BEGIN | SUBTRANS END | SUBTRANS ROLLBACK

Explanation

SUBTRANS BEGIN

A subtransaction is opened, that is, the database records the current point in the transaction. This can be followed by any sequence of SQL statements. If this sequence does not contain an additional SUBTRANS BEGIN, all database modifications performed since the SUBTRANS BEGIN can be reversed using a SUBTRANS ROLLBACK.

The sequence, however, can also contain additional SUBTRANS BEGIN statements that open additional subtransactions. This means several nested subtransactions may be open at the same time.

SUBTRANS END

A subtransaction is closed, that is, the database system "forgets" the point in the transaction recorded with SUBTRANS BEGIN. An open subtransaction must exist for this purpose. An open subtransaction must exist for this purpose.

SUBTRANS ROLLBACK

SUBTRANS ROLLBACK reverses all database modifications performed within a subtransaction and then closes the subtransaction. Any database modifications performed by any subtransactions within the subtransaction are reversed, irrespective of whether they were ended with SUBTRANS END or SUBTRANS ROLLBACK. All result tables generated within the subtransaction are closed.

An open subtransaction must exist for this purpose. If more than one open subtransaction exists, the last opened subtransaction is rolled back. The subtransaction concerned is then no longer considered open.

Further Information

The subtrans statement does not affect locks assigned to the transaction. In particular, SUBTRANS END and SUBTRANS ROLLBACK do not release any locks.

The subtrans statement is particularly useful in keeping the effects of subroutines or database procedures atomic; that is, it ensures that they either fulfil all their tasks or else have no effect. To this end, a SUBTRANS BEGIN is issued initially. If the subroutine succeeds in fulfilling its task, it is ended with a SUBTRANS END; in the event of an error, a SUBTRANS ROLLBACK is used to reverse all the modifications performed by the subroutine.

The COMMIT statement and the ROLLBACK statement close any open subtransactions implicitly.


LOCK Statement (lock_statement) (MaxDB: Reference Manual)

LOCK Statement (lock_statement)

The LOCK statement assigns a lock to the current transaction (see lock).

Syntax

<lock_statement> ::=
LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN SHARE MODE
LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN EXCLUSIVE MODE
LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN SHARE MODE <lock_spec> IN EXCLUSIVE MODE
LOCK [(WAIT)|(NOWAIT)] <row_spec>... OPTIMISTIC

<lock_spec> ::= TABLE <table_name>,... | <row_spec>...
| TABLE <table_name>,... <row_spec>...

row_spec, table_name

Explanation

The specified table cannot be a base table, a view table (see table ), nor a synonym . If the table name identifies a view table, locks are set on the base tables on which the view table is based.

WAIT/NOWAIT

· If (NOWAIT) is specified, the database does not wait for a lock to be released by another transaction. Instead, it issues an error message if a lock collision occurs. If there is no collision, the requested lock is set.

· In the event of a lock collision, if either the wait option is omitted or (WAIT) is specified, the system waits for locks to be released, until the period specified by the database parameter REQUEST_TIMEOUT has elapsed.

<row_spec>...

A <row_spec>... creates a lock for the table row denoted by the key values or a position in a result table.

Specifying a row_spec requires that the specified table has a key column; that is, if the table name identifies a view table, this must be modifiable.

TABLE <table_name>,...

If TABLE <table_name>,... is specified, a lock is created for the table in question.

If the view table identified by the table name is not changeable, only a share lock can be set for this view table. As a result of this SQL statement, share locks are set for all base tables underlying the view table.

SHARE

SHARE defines a share lock for the listed objects. To set share locks, the current user must have the SELECT privilege.

EXCLUSIVE

EXCLUSIVE defines an exclusive lock for the listed objects. To set exclusive locks, the current user must have the UPDATE, DELETE, or INSERT privilege.

OPTIMISTIC

OPTIMISTIC defines an optimistic lock on rows. This is only meaningful in connection with the isolation levels 0, 1, 10, and 15.

Deadlock

If the database system recognizes a deadlock caused by locks, it ends the transaction with an implicit ROLLBACK WORK.

Reproducibility

If reproducible results are needed to read rows using a select statement, the read objects must be locked and the locks must be kept until reproduction. Reproducibility usually requires that the tables concerned are locked either explicitly using one or more lock statements or implicitly by using the isolation level 3. This ensures that other users cannot modify the table.


ROW specification (row spec) (MaxDB: Reference Manual)

ROW specification (row spec)

The ROW specification (row_spec) is a syntax element in a LOCK statement or an UNLOCK statement .

Syntax

<row_spec> ::= ROW <table_name> KEY <key_spec>,...
| ROW <table_name> CURRENT OF <result_table_name>

table_name , result_table_name

Explanation

For tables defined without key columns, the implicit key column SYSKEY CHAR(8) BYTE can be used in a key specification.

If CURRENT OF <result_table_name> is specified, the result table must have been specified with FOR UPDATE.


UNLOCK Statement (unlock_statement) (MaxDB: Reference Manual)

UNLOCK Statement (unlock_statement)

The UNLOCK statement releases rows on rows.

Syntax

<unlock_statement> ::= UNLOCK <row_spec>... IN SHARE MODE
| UNLOCK <row_spec>... IN EXCLUSIVE MODE
| UNLOCK <row_spec>... IN SHARE MODE <row_spec>... IN EXCLUSIVE MODE
| UNLOCK <row_spec>... OPTIMISTIC

row_spec

Explanation

Using the UNLOCK statement, locks of the following types can be released within a transaction for single table rows that have not yet been changed: share locks, optimistic locks, and exclusive locks.

If a row has not been inserted, changed, or deleted, its exclusive lock cannot be released using the UNLOCK statement.

The unlock statement does not fail if the specified lock does not exist or cannot be released.


RELEASE Statement (release_statement) (MaxDB: Reference Manual)

RELEASE Statement (release_statement)

The RELEASE statement terminates a user's transaction and database session.

Syntax

<release_statement> ::= COMMIT [WORK] RELEASE | ROLLBACK [WORK] RELEASE

Explanation

Ending a session using a release statement implicitly deletes all result tables, the data stored in temporary base tables, and the metadata of these tables.

COMMIT WORK RELEASE

The current transaction is aborted without opening a new one. The user session is ended.

If the database system has to reverse the current transaction implicitly, COMMIT WORK RELEASE fails, and a new transaction is opened. The user session is not ended in this case.

ROLLBACK WORK RELEASE

The current transaction is aborted without opening a new one. Any database modifications performed during the current transaction are undone. The user session is ended. ROLLBACK WORK RELEASE has the same effect as a ROLLBACK statement followed by COMMIT WORK RELEASE.

If the accounting function in the database system is activated, information on the session is added to the table SYSACCOUNT.


Statistics (MaxDB: Reference Manual)

Statistics

The database system addresses disks in units of 8KB. The term ‘page’ is used to refer to these units.

SQL statements for statistics management

UPDATE STATISTICS statement

MONITOR statement


UPDATE STATISTICS Statement (update_statistics_statement) (MaxDB: Reference Manual)

UPDATE STATISTICS Statement (update_statistics_statement)

The UPDATE STATISTICS statement (update_statistics_statement) defines the storage requirements of tables and indexes as well as the value distribution of columns, and stores this information in the database catalog.

Syntax

<update statistics statement> ::=
UPDATE STAT[ISTICS] COLUMN <table name>.<column name> [ESTIMATE [<sample definition>]]
| UPDATE STAT[ISTICS] COLUMN (<column name>,...) FOR <table name> [ESTIMATE [<sample definition>]]
| UPDATE STAT[ISTICS] COLUMN (*) FOR <table name> [ESTIMATE [<sample definition>]]
| UPDATE STAT[ISTICS] <table name> [ESTIMATE [<sample definition>]]
| UPDATE STAT[ISTICS] [<owner>.][<identifier>]* [ESTIMATE [<sample definition>]]

table_name, column_name, sample_definition, owner, identifier

Explanation

When the update statistics statement is executed, information on the table, such as the number of rows, the number of pages used, the sizes of indexes, the value distribution within columns or indexes, and so on, is stored in the database catalog. These values are used by the SQL Optimizer to determine the best strategy for executing SQL statements.

The update statistics statement implicitly performs a COMMIT statement for each base table; i.e. the transaction within which the update statistics statement has been executed is closed.

When a CREATE INDEX statement is executed, the above-mentioned information is stored in the database catalog for the index as well as for the base table for which this index is being defined. No information is stored for other indexes defined on this base table.

The statistical values stored in the database catalog can be retrieved by selecting the system table OPTIMIZERSTATISTICS. Each row of the table describes statistical values of indexes, columns or the size of a table.

For a definition of the statistics system tables, see the System Tables manual, section Definition of the System Tables .

<table_name>

If a table name is specified, the table must be a non-temporary base table and the user must have a privilege for it.

<column_name>

If a column name is specified, this column must exist in specified table.

If * is specified, all columns in the table are assumed.

<identifier>*

Specifying <identifier>* has the same effect as issuing the update statistics statement for all base tables for which the current user has a privilege, and whose table name begins with the identifier.

UPDATE STATISTICS *

The database system administrator (SYSDBA user) can use UPDATE STATISTICS * to execute the update statistics statement for all base tables, even if the SYSDBA has not been assigned a privilege for these tables.

ESTIMATE

· If ESTIMATE and a sample definition are specified, the database system estimates the statistical values by selecting data at random. The number of random selects can be given as number of rows or as percentage. For a specification of 50% or more, all rows are analyzed. The runtime of the update statistics statement can be considerably reduced by specifying ESTIMATE. In most cases, the precision of the statistical values determined is sufficient.

· If ESTIMATE is specified without a sample definition, the database system estimates the statistical values by selecting data at random. The number of selects was defined with the CREATE TABLE statement or an ALTER TABLE statement by means of a sample_definition for the specified table. For a specification of 50% or more, all rows are analyzed. The runtime of the update statistics statement can be considerably reduced by specifying ESTIMATE. In most cases, the precision of the statistical values determined is sufficient.

· If ESTIMATE is not specified, the database system determines exact statistical values by considering the complete data of the table. For large tables, the runtime can be considerably long.


MONITOR Statement (monitor_statement) (MaxDB: Reference Manual)

MONITOR Statement (monitor_statement)

The MONITOR statement can be used to initialize counters for monitoring the database with 0.

Syntax

<monitor statement> ::= MONITOR INIT

Explanation

The database system always records result counters. These are initialized with 0 when the system is started. The MONITOR statement can be used to reset them to 0.

The event counters recorded by the database system can be retrieved by selecting monitor system tables.

For a definition of the monitor system tables, see System Tables, Definition of the System Tables .


Terms and Concepts (MaxDB: Reference Manual)

Terms and Concepts

Application Data

ASCII Code

BOOLEAN

Character String

Code Attribute

Column

Database Catalog

Database Function

Database Procedure

Database Session

Data Integrity

Data Type

Date Value

Domain

Functions

Index

LONG Column

NULL Value

Number

Parameter

Privilege

Role

Role Concept

SERIAL

Special NULL Value

SQL Mode

Subtransaction

Synonym

Table

Time Stamp Value

Time Value

Transactions

Trigger

UNICODE

Users and User Groups

See also:

Additional database-specific terms


ASCII code (MaxDB: Reference Manual)

ASCII code

The ASCII code (in accordance with ISO 8859/1.2) is as follows:

possibly used by the operating system


BOOLEAN (MaxDB: Reference Manual)

BOOLEAN

Boolean is a data type that can only have one of the two states TRUE or FALSE, or the NULL value.

A BOOLEAN value can only be compared to other BOOLEAN values.

See also:

BOOLEAN


Users and User Groups (MaxDB: Reference Manual)

Users and User Groups

The following user names and passwords are defined when the database system is installed.

· Database manager user (DBM user)

· Database system administrator (SYSDBA user)

· DOMAIN user

There are four database user classes when the database is operating:

· Database system administrator (SYSDBA)

· Database administrator (DBA user)

· RESOURCE user

· STANDARD user

You can also define user groups.

See also:

User Name

User Group Name

Authorization


Code Attribute (MaxDB: Reference Manual)

Code Attribute

For column values with the following data types, a code attribute can be entered as part of a column definition, if required: CHAR[ACTER], VARCHAR, LONG[VARCHAR]

A code attribute defines the sort sequence to be used for comparing values.

Code Attribute | Column Values
No code attribute | Have the code attribute defined in the database system
ASCII | In ASCII code
BYTE | Code-neutral, that is, the column values are not converted by the database system
UNICODE | In UNICODE

If you do not specify a code attribute, the code defined in the database system is used.

· The code can be defined for particular users using appropriate SQL statements (for more information, see: CREATE/ALTER USER Statement or CREATE/ALTER USERGROUP Statement).

· The code can be defined globally during the installation of the database system using the special database parameter DEFAULT_CODE.

The code defined for a user overrides the code specified globally in the database system.


Database Function (MaxDB: Reference Manual)

Database Function

A database function is a subprogram that runs in the database kernel and gets a result value.

When you formulate a database function, you use the language specified when you formulate database procedures. Unlike database procedures, database functions are not executed by an explicit EXECUTE. Instead, they are executed by a function call of an SQL statement (see Database Function Call).

See also:

Name of a Database Function


Database Procedure (MaxDB: Reference Manual)

Database Procedure

In a well-structured database application, SQL statements are typically not distributed over the entire application but concentrated in a single access layer instead. This access layer has a procedural interface to the rest of the application at which the operations for application objects are made available in form of abstract data types.

In client/server configurations, the client and server interact when an SQL statement is executed in the access layer. The number of these interactions can be reduced considerably by transferring the SQL access layer from the client to the server.

MySQL MaxDB provides a language (special SQL syntax) for this purpose that allows an SQL access layer to be formulated on the server side. This special SQL syntax can be used to define database procedures and triggers.

This has three main advantages:

· The number of interactions between client and server is reduced considerably (several factors). Client/server communication is only required for each operation on the application object, and not for each SQL statement. This enhances the performance of client-server configurations considerably.

· The SQL access layer contains the procedurally formulated integrity and business rules. By concentrating these rules on the server side and eliminating them from the database applications, modifications can be made centrally and thus become valid immediately in all database applications. In this way, the integrity and decision rules also become a part of the catalog in the database system.

· An SQL access layer in the form of database procedures transferred to the server side is an essential customizing tool, as it allows customer-specific database functionality to be included.

To execute a database procedure, users must have the call privilege. This call privilege is independent of the user privileges for the tables and columns used in the database procedure. As a result, users may be able to use a database procedure to execute SQL statements that they otherwise would not have access to.

Database procedures are called explicitly from the programming language of the application. They can contain parameters, except for LONG columns. The extent to which LONG columns can be used within database procedures depends on the length of the LONG columns and the amount of storage space available.

As with any SQL statement, precautions must be taken to ensure that calling a database procedure has the desired effect, and that errors do not have any lasting effects on the database system. MySQL MaxDB provides nested transactions for this purpose. Each database procedure call can run in a subtransaction that can be reset without interfering with transaction control in the database application.

You can define any number of database procedures.

See also:

Name of a database procedure


Data integrity (MaxDB: Reference Manual)

Data integrity

  • Integrity rules: the database system provides a wide range of declarative integrity rules, thus reducing the programming requirements for applications. Integrity rules that refer to a table can also be specified (see constraint name ).
  • Key: a key comprising one or more columns can be defined for each table. The database system ensures that each key is unique. A key can also consist of columns of different data types (see key definition ).
  • UNIQUE definition: the uniqueness of the values in other columns and column combinations can also be ensured by using other mechanisms (see UNIQUE definition for "alternate keys").
  • NOT NULL: by specifying NOT NULL, you can ensure that the NULL value is not accepted in individual columns.
  • DEFAULT definition: you can define default values for each column (see DEFAULT specification ).
  • Referential integrity conditions: by specifying referential integrity conditions, you can declare deletion and existence dependencies between the rows in two tables (see name of a referential constraint ).
  • Database procedures and triggers: complex integrity rules that require access to further tables can be formulated with database procedures or triggers .


Data Type (MaxDB: Reference Manual)

Data Type

A data type is a set of the following values that can be represented:

· NULL value

· Special NULL value

· Non-NULL value
Character string, LONG column, number, date value, time value, time stamp value, BOOLEAN

Use

As well as specifying the column name when you define columns, you can also specify data types.

If required, a code attribute can also be entered for LONG columns and some kinds of character strings.

See also:

Using data types in SQL statements: data_type


Date Value (MaxDB: Reference Manual)

Date Value

The date value date type is a special character string.

A date value can be compared to other date values and to character strings with the code attributes ASCII and UNICODE.

See also:

DATE

Date and time format


index (MaxDB: Reference Manual)

Index

Indexes speed up access to rows in a table. They can be created for a single column or for a series of columns. When defining indexes, you specify whether the indexed column values in the different rows must be unique or not.

The assigned index name and table name must be unique.


LONG column (MaxDB: Reference Manual)

LONG column

A LONG column is a data type that contains a sequence of characters of any length to which no functions can be applied.

LONG columns cannot be compared to one another. The contents of LONG columns cannot be compared to character strings or other data types.

See also:

LONG[VARCHAR]

In a column definition , a code attribute can be entered for the data type LONG[VARCHAR].


NULL value (MaxDB: Reference Manual)

NULL value

The data type NULL value (that is, an unspecified value) is a special value. Its relationship to any other value is always unknown.


Parameter (MaxDB: Reference Manual)

Parameter

SQL statements for the database system can be embedded in programming languages such as C and C++. This enables the database system to be accessed from various programs. The values to be retrieved from stored in the database system can be transferred with the SQL statements using parameters. The parameters are declared variables (so-called host variables) within the embedding program.

The data type of the host variables is defined when they are declared in the programming language. If possible, the values of the host variables are implicitly converted from the programming language data type to the data type of the database system, and vice versa.

Each parameter can be combined with an indicator variable that indicates irregularities which may have occurred when the values were assigned, for example, different value and parameter lengths, NULL value , special NULL value , etc. Indicator variables are essential for transferring NULL values and special NULL values. The indicator variables are declared as variables in the embedding program.

See also:

Parameter name

Indicator name


Privilege (MaxDB: Reference Manual)

Privilege

A privilege is used to impose restrictions on operations carried out on certain objects.

Users can only execute operations on objects if they have been granted the privileges to do so. The owner of an object receives all of the relevant privileges when the object is created. Privileges can be explicitly granted to other users. Privileges are not granted to other users implicitly.

Users who are not the owner of an object can only grant privileges to other users if they have already been granted these privileges and are allowed to pass them on, i.e. with the relevant option.

See also:

Privilege type

Privilege Specification


Role (MaxDB: Reference Manual)

Role

A role is a collection of privileges.

Like a privilege, a role can be assigned to a different role or to a user.

While privileges are always valid, roles are always inactive, that is, the privileges they contain are not valid. Roles can be activated for individual database sessions. Every user to whom roles have been assigned can also define which of the roles should be active in each of his or her database sessions. This definition can be changed after a database session has been opened.

All roles are inactive for the current database session while data definition statements are being executed.

See also:

Role Name

Role Concept


Role Concept (MaxDB: Reference Manual)

Role Concept

The database system supports a role concept. A role is a group of privileges that can be assigned to database users, user groups, or to other roles.

Procedure

1. The CREATE ROLE statement creates a role. Initially, the new role is empty. Only a database administrator (DBA user) can create roles. The name of a new role cannot be the same as the name of an existing role, user, or user group.

2. You use the GRANT statement to assign privileges to a role. You use the REVOKE statement to remove privileges from a role.

3. You can also use the GRANT statement together with the role name to assign a role to database users, user groups or other roles.

4. You use the ALTER USER or ALTER USERGROUP statement to specify which roles (assigned to a user or a user group) are used when opening a database session.

5. During a database session, you can use the SET statement to activate other roles assigned to the user or user group.
If a password has been defined for a role, users assigned to this role can only activate it by specifying the password in the SET statement.

Result

The existence and properties of a role are registered as metadata in the database catalog. A user who creates a role becomes the owner of this role.

Any roles assigned to the user with the ALTER USER or ALTER USERGROUP statements are activated when the database session is opened.

Roles are not active while data definition statements are being executed.


SERIAL (MaxDB: Reference Manual)

SERIAL

SERIAL is a number generator that generates positive integers starting with 1 or a specified value.

SERIAL can be used as a DEFAULT specification for columns (DEFAULT SERIAL) that can only contain fixed point numbers. The maximum value generated is (10**n)-1 if DEFAULT SERIAL is defined for a column of the data type FIXED (n).

SERIAL columns can only be assigned a value when a row is inserted. The values of a SERIAL column cannot be changed with an UPDATE statement. A SERIAL column, therefore, can be used to determine the insertion sequence and identify a row in a table uniquely.


Column (MaxDB: Reference Manual)

Column

All values in a table column have the same data type . A value in a column within a row is the smallest unit of data that can be modified or selected from a table or to which functions can be applied.

  • An alphanumeric column is a character string column.
    All character strings in an alphanumeric column have the same length.
  • A numeric column is either a floating point or a fixed point column.
    All numbers in a floating point column (floating point     number ) have the same mantissa length.
    All numbers in a fixed point column (fixed point     number ) have the same format; that is, the same number of digits before and after the decimal point.

Each column in a base table has a name that is unique within the table.

See also:

Column name

Using column definitions in SQL statements: column_definition


Special NULL value (MaxDB: Reference Manual)

Special NULL value

A special NULL value is a special data type and is the result of arithmetic operations that lead to an overflow or a division by 0.

The special NULL value is only permitted for output columns and for columns in the ORDER clause . If an overflow occurs in an arithmetic operation or a division by 0 at another point, the SQL statement is abnormally terminated.

The comparison of a special NULL value with any value is always undefined.

As far as sorting is concerned, the special NULL value is greater than all non-NULL values, but less than the NULL value .


SQL Mode (MaxDB: Reference Manual)

SQL Mode

This document describes the database system functions provided by the SQL Mode INTERNAL.

Only those SQL statements are described for which the same SQL mode is used to both generate the object and execute the statement for the object. If database objects are created in one SQL mode and addressed in another, the object may have properties that are not known in the current SQL mode, and therefore cannot be described.

SQL Statement for Specifying the SQL Mode

CONNECT Statement


Subtransaction (MaxDB: Reference Manual)

Subtransaction

The purpose of closed, nested transactions (subtransactions) is to let a series of database operations within a transaction appear as a unit with regard to modifications to the database.

Subtransactions are preceded by SUBTRANS BEGIN and closed by SUBTRANS END or SUBTRANS ROLLBACK.

  • If a subtransaction is concluded with SUBTRANS END, any modifications made are kept.
  • If a subtransaction is closed with SUBTRANS ROLLBACK, all modifications made to the database system are reversed. Modifications made by subtransactions contained in this subtransaction are also reversed, even if they were concluded with SUBTRANS END.

SUBTRANS END and SUBTRANS ROLLBACK do not affect locks. These are only released by COMMIT or ROLLBACK. COMMIT or ROLLBACK implicitly close all subtransactions.

See also:

SUBTRANS statement

COMMIT statement

ROLLBACK statement


Synonym (MaxDB: Reference Manual)

Synonym

A synonym is another name for a table.

Every synonym has a name that is unique within the entire database system and differs from all the other table names.

See also:

Synonym Name


Table (MaxDB: Reference Manual)

Table

· A table is a set of rows.
A row is an ordered list of values.
The row is the smallest unit of data that can be inserted in or deleted from a table.
Each row in a table has the same number of columns and contains a value for each column.

· A base table is a table that usually has a permanent memory representation and description.
It is also possible to create a base table that has only a temporary memory representation and description. This table and its description are implicitly dropped when a user stops working with the database system (end of session).

· A result table is a temporary table that is generated from one or more base table(s) by means of a SELECT statement (result table name).

· A temporary table has the owner TEMP. Temporary tables only exist during a database session of one user. When the session ends, the table and its content are deleted.

· A view table is a table derived from base tables. A view table has a permanent description in the form of a SELECT statement.

· AJoin table links tables (Join, Join Table (joined_table), JOIN Predicate (join_predicate))

Each table has a name that is unique within the whole database system. The names of existing tables can be used to name result tables. The original tables, however, cannot be accessed as long as the result tables exist.

If a table name was defined without an owner, the catalog sections (part catalogs) are searched in the following order to locate the specified table name:

1. Catalog part of the current user

2. Set of PUBLIC synonyms

3. Catalog part of the DBA who created the current user

4. Catalog part of the SYSDBA

5. Catalog part of the owner of the system tables

.

A table of another user can only be used if the relevant privileges have been granted.

See also:

Table name

Reference name


Trigger (MaxDB: Reference Manual)

Trigger

While database procedures are called explicitly from the programming language of the application, triggers are special procedures that run implicitly on a base table (or a view table based on this base table) after a data manipulation statement has been executed.

The conditions under which a trigger is to be executed can be restricted further.

The trigger is executed for each row to which the SQL statement refers. The trigger can access both the old values (values before update or deletion) and the new values (values after update or insertion) in this row.

A trigger can call further triggers implicitly.

Triggers can be used to check complicated integrity rules, to initiate derived database modifications for the row in question, or to implement complex access protection rules.

The database system provides a language (special SQL syntax) that can be used to define database procedures and triggers.

See also:

Trigger name


Domain (MaxDB: Reference Manual)

Domain

Domain definitions enable ranges of values to be defined and designated for table columns.

Each value range definition has a name that is unique within the overall database system.

If a domain was defined without an owner, the catalog sections (part catalogs) are searched in the following order to locate the specified value range:

1. Catalog part of the current user

2. Catalog part of the DBA who created the current user

3. Catalog part of the SYSDBA

See also:

Domain name


Number (MaxDB: Reference Manual)

Number

A number is a special data type . There are fixed point and floating point numbers:

  • Fixed point number

A fixed point number is described by the number of significant digits and the scale. The maximum number of significant digits is 38.

Examples: FIXED , INT[EGER] , SMALLINT
  • Floating point number

A floating point number consists of a mantissa and an exponent. The mantissa may have up to 38 significant digits. The valid range of values for floating point numbers consists of the intervals from -9. 9999999999999999999999999999999999999E +62 to -1E-64 and from +1E-64 to +9. 9999999999999999999999999999999999999E +62 and the value 0.0.

Example: FLOAT

All numbers can be compared to one another.


Character String (MaxDB: Reference Manual)

Character String

A character string is a data type that consists of a series of alphanumeric characters.

Examples: CHAR[ACTER], VARCHAR, DATE, TIME, TIMESTAMP

In a column definition, a code attribute can be entered for the data types CHAR[ACTER] and VARCHAR.

The following comparison options exist for data types CHAR[ACTER] and VARCHAR:

Character strings with the same code attribute | These character strings can be compared to each other.
Character strings with the code attributes ASCII or UNICODE | These character strings are comparable with the character strings of code attributes ASCII and UNICODE, and with date, time, and timestamp values.


Timestamp Value (MaxDB: Reference Manual)

Timestamp Value

The timestamp value data type is a special character string. A timestamp consists of a date and time value and a microsecond specification.

A timestamp value can be compared to other timestamp values and to character strings with the code attributes ASCII and UNICODE.

See also:

TIMESTAMP

Date and Time Format


Time Value (MaxDB: Reference Manual)

Time Value

The time value date type is a special character string.

A time value can be compared to other time values and to character strings with the code attributes ASCII and UNICODE.

See also:

TIME

Date and Time Format


Syntax List (MaxDB: Reference Manual)

Syntax List

The syntax notation used in this document is BNF.

A

<add_definition> ::=
  ADD <column_definition>,...
| ADD (<column_definition>,...)
| ADD <constraint_definition>
| ADD <referential_constraint_definition>
| ADD <key_definition>

<alias_name> ::=
  <identifier>

<all_function> ::=
  <set_function_name> ( [ALL] <expression> )

<alter_definition> ::=
  ALTER CONSTRAINT <constraint_name> CHECK <search_condition>
| ALTER <key_definition>

<alter_index_statement> ::=
  ALTER INDEX <index_name> [ON <table_name>] ENABLE
| ALTER INDEX <index_name> [ON <table_name>] DISABLE
| ALTER INDEX <index_name> [ON <table_name>] INIT USAGE

<alter_password_statement>::=
  ALTER PASSWORD <old_password> TO <new_password>
| ALTER PASSWORD <user_name> <new_password>

<alter_table_statement> ::=
  ALTER TABLE <table_name> <add_definition>
| ALTER TABLE <table_name> <drop_definition>
| ALTER TABLE <table_name> <alter_definition>
| ALTER TABLE <table_name> <column_change_definition>
| ALTER TABLE <table_name> <modify_definition>
| ALTER TABLE <table_name> <referential_constraint_definition>
| ALTER TABLE <table_name> DROP FOREIGN KEY <referential_constraint_name>
| ALTER TABLE <table_name> <sample_definition>

<alter_user_statement> ::=
  ALTER USER <user_name> [<user_mode>]
    [TIMEOUT <unsigned_integer> | TIMEOUT NULL]
    [COSTWARNING <unsigned_integer> | COSTWARNING NULL]
    [COSTLIMIT <unsigned_integer> | COSTLIMIT NULL]
    [DEFAULT ROLE ALL [EXCEPT <role_name>] | DEFAULT ROLE NONE
    | DEFAULT ROLE <role_name> [IDENTIFIED BY <password>]]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]

<alter_usergroup_statement> ::=
  ALTER USERGROUP <usergroup_name> [<usergroup_mode>]
    [TIMEOUT <unsigned_integer> | TIMEOUT NULL]
    [COSTWARNING <unsigned_integer> | COSTWARNING NULL]
    [COSTLIMIT <unsigned_integer> | COSTLIMIT NULL]
    [DEFAULT ROLE ALL [EXCEPT <role_name>] | DEFAULT ROLE NONE
    | DEFAULT ROLE <role_name> [IDENTIFIED BY <password>]]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]

<argument> ::=
  <identifier>

<argument1> ::=
  <identifier>

<arithmetic_function> ::=
  TRUNC ( <expression>[, <expression>] )
| ROUND ( <expression>[, <expression>] )
| NOROUND ( <expression> )
| FIXED ( <expression>[, <unsigned_integer> [, <unsigned_integer] ] )
| FLOAT ( <expression>[, <unsigned_integer> ] )
| CEIL ( <expression> )
| FLOOR ( <expression> )
| SIGN ( <expression> )
| ABS ( <expression> )
| POWER ( <expression>, <expression> )
| EXP ( <expression> )
| SQRT ( <expression> )
| LN ( <expression> )
| LOG ( <expression>, <expression> )
| PI
| LENGTH ( <expression> )
| INDEX ( <string_spec>, <string_spec> [,<expression>[, <expression>] ] )

<assignment_statement> ::=
  SET <variable_name> = <expression>

B

<between_predicate> ::=
  <expression> [NOT] BETWEEN <expression> AND <expression>

<bool_predicate> ::=
  <column_spec> [ IS [NOT] <TRUE | FALSE>]

<boolean_factor> ::=
  [NOT] <predicate>
| [NOT] (<search_condition>)

<boolean_term> ::=
  <boolean_factor>
| <boolean_term> AND <boolean_factor>

C

<call_statement> ::=
  CALL <dbproc_name> [(<expression>,...)] [WITH COMMIT]

<cascade_option> ::=
  CASCADE
| RESTRICT

<case_else_clause> ::=
  ELSE <statement>

<case_function> ::=
  <simple_case_function>
| <searched_case_function>

<case_statement> ::=
  <simple_case_statement>
| <searched_case_statement>

<character> ::=
  <digit>
| <letter>
| <extended_letter>
| <hex_digit>
| <language_specific_character>
| <special_character>

<close_statement> ::=
  CLOSE [<result_table_name>]

<column_attributes> ::=
  [<key_or_not_null_spec>] [<default_spec>] [UNIQUE] [<constraint_definition>]
    [REFERENCES <referenced_table> [(<referenced_column>)] [<delete_rule>]]

<column_change_definition> ::=
  COLUMN <column_name> NOT NULL
| COLUMN <column_name> DEFAULT NULL
| COLUMN <column_name> ADD <default_spec>
| COLUMN <column_name> ALTER <default_spec>
| COLUMN <column_name> DROP DEFAULT

<column_definition> ::=
  <column_name> <data_type> [<column_attributes>]
| <column_name> <domain_name> [<column_attributes>]

<column_list> ::=
  <column_name>
| <column_list>, <column_name>

<column_name> ::=
  <identifier>

<column_spec> ::=
  <column_name>
| <table_name>.<column_name>
| <reference_name>.<column_name>
| <result_table_name>.<column_name>

<comment> ::=
  <string_literal>
| <parameter_name>

<comment_on_statement> ::=
  COMMENT ON <object_spec> IS <comment>

<commit_statement> ::=
  COMMIT [WORK]

<comp_op> ::=
  <
| >
| <>
| !=
| =
| <=
| >=
| ~= | ~< | ~> (for machines with ASCII code)

<comparison_predicate> ::=
  <expression> <comp_op> <expression>
| <expression> <comp_op> <subquery>
| <expression_list> <equal_or_not> (<expression_list>)
| <expression_list> <equal_or_not> <subquery>

<connect_option> ::=
  SQLMODE <INTERNAL | ANSI | DB2 | ORACLE>
| ISOLATION LEVEL <unsigned_integer>
| TIMEOUT <unsigned_integer>

<connect_statement> ::=
  CONNECT <parameter_name> IDENTIFIED BY <parameter_name> [<connect_option>...]
| CONNECT <parameter_name> IDENTIFIED BY <password> [<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <parameter_name> [<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <password> [<connect_option>...]

<constraint_definition> ::=
  CHECK <search_condition>
| CONSTRAINT <search_condition>
| CONSTRAINT <constraint_name> CHECK <search_condition>

<constraint_name> ::=
  <identifier>

<conversion_function> ::=
  NUM (<expression>)
| CHR (<expression>[,<unsigned_integer>])
| HEX (<expression>)
| HEXTORAW (<expression>)
| CHAR (<expression>[,<datetimeformat>])

<create_dbproc_statement> ::=
  CREATE DBPROC <procedure_name> [(<formal_parameter>,..)] [RETURNS CURSOR] AS <routine>

<create_domain_statement> ::=
  CREATE DOMAIN <domain_name> <data_type> [<default_spec>] [<constraint_definition>]

<create_function_statement> ::=
  CREATE FUNCTION <dbfunction_name>
    [(<formal_parameter1>,...)] RETURNS <data_type> AS <routine>

<create_index_statement> ::=
  CREATE [UNIQUE] INDEX <index_name> ON <table_name> (<index_spec>)

<create_role_statement> ::=
  CREATE ROLE <role_name> [IDENTIFIED BY <password>]

<create_sequence_statement> ::=
  CREATE SEQUENCE [<owner>.]<sequence_name>
    [INCREMENT BY <integer>]
    [START WITH <integer>]
    [MAXVALUE <integer> | NOMAXVALUE]
    [MINVALUE <integer> | NOMINVALUE]
    [CYCLE | NOCYCLE]
    [CACHE <unsigned_integer> | NOCACHE]
    [ORDER|NOORDER]

<create_synonym_statement> ::=
  CREATE [PUBLIC] SYNONYM [<owner>.]<synonym_name> FOR <table_name>

<create_table_statement> ::=
CREATE TABLE <table_name> (<column_definition> [,<table_description_element>,...])
[IGNORE ROLLBACK] [NO FIXED LENGTH COLUMN] [<sample_definition>]
| CREATE TABLE <table_name> [(<table_description_element>,...)]
[IGNORE ROLLBACK] [NO FIXED LENGTH COLUMN] [<sample_definition>]
AS <query_expression> [<duplicates_clause>]
| CREATE TABLE <table_name> LIKE <table_name> [IGNORE ROLLBACK]

<create_table_temp> :: =
  <create_table_statement> for creating temporary tables,
    that is, the table name table_name in the CREATE TABLE statement
    must have the format TEMP.<identifier>.

<create_trigger_statement> ::=
  CREATE TRIGGER <trigger_name> FOR <table_name> AFTER <trigger_event,..>
    EXECUTE (<routine>) [WHENEVER <search_condition>]

<create_user_statement> ::=
  CREATE USER <user_name> PASSWORD <password>
    [<user_mode>]
    [TIMEOUT <unsigned_integer>]
    [COSTWARNING <unsigned_integer>]
    [COSTLIMIT <unsigned_integer>]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]
| CREATE USER <user_name> PASSWORD <password> LIKE <source_user>
| CREATE USER <user_name> PASSWORD <password> USERGROUP <usergroup_name>

<create_usergroup_statement> ::=
  CREATE USERGROUP <usergroup_name>
    [<usergroup_mode>]
    [TIMEOUT <unsigned_integer>]
    [COSTWARNING <unsigned_integer>]
    [COSTLIMIT <unsigned_integer>]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]

<create_view_statement> ::=
  CREATE [OR REPLACE] VIEW <table_name> [(<alias_name>,...)]
    AS <query_expression> [WITH CHECK OPTION]

D

<data_type> ::=
  CHAR[ACTER] [(<unsigned_integer>)] [ASCII | BYTE | UNICODE]
| VARCHAR [(<unsigned_integer>)] [ASCII | BYTE | UNICODE]
| LONG [VARCHAR] [ASCII | BYTE | UNICODE]
| BOOLEAN
| FIXED (<unsigned_integer> [,<unsigned_integer>])
| FLOAT (<unsigned_integer>)
| INT[EGER]
| SMALLINT
| DATE
| TIME
| TIMESTAMP

<date_function> ::=
  ADDDATE (<date_or_timestamp_expression>, <expression>)
| SUBDATE ( <date_or_timestamp_expression>, <expression> )
| DATEDIFF ( <date_or_timestamp_expression>, <date_or_timestamp_expression> )
| DAYOFWEEK ( <date_or_timestamp_expression> )
| WEEKOFYEAR ( <date_or_timestamp_expression> )
| DAYOFMONTH ( <date_or_timestamp_expression> )
| DAYOFYEAR ( <date_or_timestamp_expression> )
| MAKEDATE ( <expression>, <expression> )
| DAYNAME ( <date_or_timestamp_expression> )
| MONTHNAME ( <date_or_timestamp_expression> )

<date_or_timestamp_expression> ::=
  <expression>

<datetimeformat> ::=
  EUR
| INTERNAL
| ISO
| JIS
| USA

<dbfunction_call> ::=
  <dbfunction_name> ( [<expression>,...] )

<dbfunction_name> ::=
  [<owner>.]<identifier>

<dbproc_name> ::=
  [<owner>.]<procedure_name>

<declare_cursor_statement> ::=
  DECLARE <result_table_name> CURSOR FOR <select_statement>

<default_predicate> ::=
  <column_spec> <comp_op> DEFAULT

<default_spec> ::=
  DEFAULT <literal >
| DEFAULT NULL
| DEFAULT USER
| DEFAULT USERGROUP
| DEFAULT SYSDBA
| DEFAULT DATE
| DEFAULT TIME
| DEFAULT TIMESTAMP
| DEFAULT UTCDATE
| DEFAULT UTCDIFF
| DEFAULT TIMEZONE
| DEFAULT TRUE
| DEFAULT FALSE
| DEFAULT TRANSACTION
| DEFAULT STAMP
| DEFAULT SERIAL[(<unsigned_integer>)]

delete_rule> ::=
  ON DELETE CASCADE
| ON DELETE RESTRICT
| ON DELETE SET DEFAULT
| ON DELETE SET NULL

<delete_statement> ::=
  DELETE [FROM] <table_name> [<reference_name>]
    [KEY <key_spec>,...] [WHERE <search_condition>]
| DELETE [FROM] <table_name> [<reference_name>]
    WHERE CURRENT OF <result_table_name >

<delimiter_token> ::=
  ( | ) | , | . | + | - | * | / | < | > | <> | != | = | <= | >=
| ~= | ~< | ~> (for machines with ASCII code)

<derived_column> ::=
  <expression> [ [AS] <result_column_name >]
| <result_column_name> = <expression>

<digit> ::=
  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<digit_sequence> ::=
  <digit>...

<distinct_function>::=
  <set_function_name> ( DISTINCT <expression > )

<distinct_spec> ::=
  DISTINCT
| ALL

<domain_name> ::=
  [<owner>.]<identifier>

<doubles_quotes> ::=
  "

<drop_dbproc_statement> ::=
  DROP DBPROC <dbproc_name>

<drop_definition> ::=
  DROP <column_name>,... [<cascade_option >] [RELEASE SPACE]
| DROP (<column_name>,...) [<cascade_option>] [RELEASE SPACE]
| DROP CONSTRAINT <constraint_name>
| DROP PRIMARY KEY

<drop_domain_statement> ::=
  DROP DOMAIN <domain_name>

<drop_function_statement> ::=
  DROP FUNCTION <dbfunction_name>

<drop_index_statement> ::=
  DROP INDEX <index_name> [ON <table_name>]

<drop_role_statement> ::=
  DROP ROLE <role_name>

<drop_sequence_statement> ::=
  DROP SEQUENCE [<owner>.]<sequence_name>

<drop_synonym_statement> ::=
  DROP [PUBLIC] SYNONYM [<owner>.]<synonym_name>

<drop_table_statement> ::=
  DROP TABLE <table_name> [<cascade_option>]

<drop_trigger_statement> ::=
  DROP TRIGGER <trigger_name> OF <table_name>

<drop_user_statement> ::=
  DROP USER <user_name> [<cascade_option>]

<drop_usergroup_statement> ::=
  DROP USERGROUP <usergroup_name> [<cascade_option>]

<drop_view_statement> ::=
  DROP VIEW <table_name> [<cascade_option>]

<duplicates_clause> ::=
  REJECT DUPLICATES
| IGNORE DUPLICATES
| UPDATE DUPLICATES

E

<equal_or_not> ::=
  <>
| =
| ~= (for machines with ASCII code)

<exists_predicate> ::=
  EXISTS <subquery >

<exists_table_statement> ::=
  EXISTS TABLE <table_name >

<explain_statement> ::=
  EXPLAIN [(<result_table_name>)] <query_statement>
| EXPLAIN [(<result_table_name>)] <single_select_statement >

<exponent> ::=
  [<sign>][[<digit>]<digit>]<digit>

<expression> ::=
  <term>
| <expression> + <term>
| <expression> - <term>

<expression_list> ::=
  (<expression>,...)

<extended_expression> ::=
  <expression>
| DEFAULT
| STAMP

<extended_letter> ::=
  #
| @
| $

<extended_value_spec> ::=
  <value_spec>
| DEFAULT
| STAMP

<extraction_function> ::=
  YEAR ( <date_or_timestamp_expression > )
| MONTH ( <date_or_timestamp_expression> )
| DAY ( <date_or_timestamp_expression> )
| HOUR ( <time_or_timestamp_expression > )
| MINUTE ( <time_or_timestamp_expression> )
| SECOND ( <time_or_timestamp_expression> )
| MICROSECOND ( <expression> )
| TIMESTAMP ( <expression>[, <expression> ] )
| DATE ( <expression> )
| TIME ( <expression> )

F

<factor> ::=
  [<sign>] <value_spec>
| [<sign>] <column_spec>
| [<sign>] <function_spec>
| [<sign>] <set_function_spec>
| <scalar_subquery>
| <expression>

<fetch_statement> ::=
  FETCH [FIRST | LAST | NEXT | PREV | <position> | SAME] [<result_table_name>]
    INTO <parameter_spec>,...

<final_select> ::=
  <select_statement>

<first_character> ::=
  <letter>
| <extended_letter>
| <language_specific_character>

<first_password_character> ::=
  <letter>
| <extended_letter>
| <language_specific_letter>
| <digit>

<fixed_point_literal> ::=
  [<sign>]<digit_sequence>[.<digit_sequence>]
| [sign]<digit_sequence>.
| [sign].<digit_sequence>

<floating_point_literal> ::=
  <mantissa>E<exponent>
| <mantissa>e<exponent>

<formal_parameter> ::=
  IN <argument> <data_type>
| OUT <argument> <data_type>
| INOUT <argument> <data_type>

<formal_parameter1> ::=
  <argument1> <data_type>

<from_clause> ::=
  FROM <from_table_spec>,...

<from_table_spec> ::=
  <table_name> [AS][<reference_name>]
| <result_table_name> [AS][<reference_name>]
| (<query_expression>) [AS][<reference_name>]
| <joined_table>

<function_spec> ::=
  <arithmetic_function>
| <trigonometric_function>
| <string_function>
| <date_function>
| <time_function>
| <extraction_function>
| <special_function>
| <conversion_function>

G

<grant_statement> ::=
  GRANT <priv_spec>,... TO <grantee>,... [WITH GRANT OPTION]
| GRANT EXECUTE ON <dbproc_name>  TO <grantee>,...
| GRANT SELECT ON <sequence_name> TO <grantee>,... [WITH GRANT OPTION]

<grant_user_statement> ::=
  GRANT USER <granted_users> [FROM <user_name>] TO <user_name>

<grant_usergroup_statement> ::=
  GRANT USERGROUP <granted_usergroups> [FROM <user_name>] TO <user_name>

<granted_usergroups> ::=
  <usergroup_name>,...
| *

<granted_users> ::=
  <user_name>,...
| *

<grantee> ::=
  PUBLIC
| <user_name>
| <usergroup_name>
| <role_name>

<group_clause> ::=
  GROUP BY <expression>,...

H

<having_clause> ::=
  HAVING <search_condition>

<hex_digit> ::=
  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
| A | B | C | D | E | F
| a | b | c | d | e | f

<hex_digit_seq> ::=
  <hex_digit><hex_digit>
| <hex_digit_seq><hex_digit><hex_digit>

<hex_literal> ::=
  x''
| X''
| x'<hex_digit_seq>'
| X'<hex_digit_seq>'

<hours> ::=
  <expression>

I

<identifier> ::=
  <simple_identifier>
| <double quotes><special_identifier><double_quotes>

<identifier_tail_character> ::=
  <letter>
| <extended_letter>
| <language_specific_character>
| <digit>
| <underscore>

<if_statement> ::=
  IF <search_condition> THEN <statement> [ELSE <statement>]

<in_predicate> ::=
  <expression> [NOT] IN <subquery>
| <expression> [NOT] IN <expression_list>
| <expression_list> [NOT] IN <subquery>
| <expression_list> [NOT] IN (<expression_list>,...)

<index_name> ::=
  <identifier>

<index_spec> ::=
  <column_name> [ASC|DESC],...
| <dbfunction_name> (<column_name>,...) [ASC|DESC]

<indicator_name> ::=
  <parameter_name>

<initial_select> ::=
  <query_spec>

<insert_expression> ::=
  <extended_expression>
| <subquery>

<insert_statement> ::=
  INSERT [INTO] <table_name> [(<column_name>,...)]
    VALUES (<insert_expression>,...) [<duplicates_clause>]
| INSERT [INTO] <table_name> [(<column_name>,...)]
<query_expression> [<duplicates_clause>]
| INSERT [INTO] <table_name> SET <set_insert_clause>,... [<duplicates_clause>]

<integer> ::=
  [sign]<unsigned_integer>

J

<join_predicate> ::=
  <expression> [<outer_join_indicator>] <comp_op> <expression> [<outer_join_indicator>]

<join_spec> ::=
  ON <search_condition>

<joined_table> ::=
  <from_table_spec> CROSS JOIN <from_table_spec>
| <from_table_spec> [INNER] JOIN <from_table_spec> <join_spec>
| <from_table_spec> [<LEFT|RIGHT|FULL> [OUTER]] JOIN
    <from_table_spec> <join_spec>

K

<key_definition> ::
  PRIMARY KEY (<column_name>,...)

<key_or_not_null_spec> ::=
  [PRIMARY] KEY
| NOT NULL [WITH DEFAULT]

<key_spec> ::=
  <column_name> = <value_spec>

<key_word> ::=
  <not_reserved_key_word>
| <reserved_keyword>

L

<language_specific_character> ::=
  <every letter that occurs in a Northern, Central, or Southern European language
  and is not included in the <letter> list>
| <for UNICODE-enabled databases: every character that is not included in the ASCII code list from 0 to 127>

<letter> ::=
  A | B | C | D | E | F | G | H | I | J | K | L | M
| N | O | P | Q | R | S | T | U | V | W | X | Y | Z
| a | b | c | d | e | f | g | h | i | j | k | l | m
| n | o | p | q | r | s | t | u | v | w | x | y | z

<like_expression> ::=
  <expression>
| '<pattern_element>...'

<like_predicate> ::=
  <expression> [NOT] LIKE <like_expression> [ESCAPE <expression>]

<literal> ::=
  <string_literal>
| <numeric_literal>

<local_variable> ::=
  <variable_name> <data_type>

<local_variable_list> ::=
  <local_variable>
| <local_variable_list>;<local_variable>

<local_variables> ::=
  VAR <local_variable_list>;

<lock_option> ::=
  WITH LOCK [(IGNORE)|(NOWAIT)] [EXCLUSIVE | OPTIMISTIC] [ISOLATION LEVEL <unsigned_integer>]

<lock_spec> ::=
  TABLE <table_name>,...
| <row_spec>...
| TABLE <table_name>,... <row_spec>...

<lock_statement> ::=
  LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN SHARE MODE
| LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN EXCLUSIVE MODE
| LOCK [(WAIT)|(NOWAIT)] <row_spec>... OPTIMISTIC
| LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN SHARE MODE <lock_spec> IN EXCLUSIVE MODE

M

<mantissa> ::=
  <fixed_point_literal>

<mapchar_set_name> ::=
  <identifier>

<match_char> ::=
  Every character except
    %
  | X'1F'
  | <underscore>
  | X'1E'

<match_set> ::=
  <underscore>
| X'1E'
| <match_char>

<match_string> ::=
  %
| X'1F'

<minutes> ::=
  <expression>

<modify_definition> ::=
  MODIFY (<column_name> [<data_type>] [<column_attributes>]...)

<monitor_statement> ::=
  MONITOR INIT

N

<named_query_expression> ::=
  <named_query_term>
| <named_query_expression> UNION [ALL] <query_term>
| <named_query_expression> EXCEPT [ALL] <query_term>

<named_query_primary> ::=
  <named_query_spec>
| (<named_query_expression>)

<named_query_spec> ::=
  SELECT [<distinct_spec>] <result_table_name> (<select_column>,...) <table_expression>

<named_query_term> ::=
  <named_query_primary>
| <named_query_term> INTERSECT [ALL] <query_primary>

<named_select_statement> ::=
  <named_query_expression> [<order_clause>] [<update_clause>] [<lock_option>] [FOR REUSE]

<new_index_name> ::=
  <index_name>

<new_table_name> ::=
  <table_name>

<next_stamp_statement> ::=
  NEXT STAMP [INTO] <parameter_name>

<not_reserved_key_word> ::=

ADD | ADDRESS | ADD_MONTHS | AFTER | ALTERIN
ANALYZE | AND | ANSI | APPEND | ARCHIVE
AS | ASC | AT | AUTHORIZATION | AUTO
AUTOSAVE |  |  |  |
BACKUP_PAGES | BAD | BEFORE | BEGIN | BEGINLOAD
BEGINPROC | BETWEEN | BLOCK | BLOCKSIZE | BOTH
BREAK | BUFFER | BUFFERPOOL | BWHIERARCHY | BY
CACHE | CACHELIMIT | CACHES | CALL | CANCEL
CASCADE | CATALOG | CATCH | CHECKPOINT | CLEAR
CLOSE | CLUSTER | COMMENT | COMMIT | COMPUTE
CONFIG | CONNECT | CONSTRAINTS | CONTAINER | CONTINUE
COSTLIMIT | COSTWARNING | CREATE | CREATEIN | CURRENT_DATE
CURRENT_SCHEMA | CURRENT_TIME | CURRENT_TIMESTAMP | CURRVAL | CURSOR
CYCLE |  |  |  |
DATA | DAYS | DB2 | DBA | DBPROC
DBPROCEDURE | DB_ABOVE_LIMIT | DB_BELOW_LIMIT | DEBUG | DECLARE
DEFAULTCODE | DEGREE | DESC | DESCRIBE | DEVICE
DIAGNOSE | DIMENSION | DISABLE | DIV | DO
DOMAIN | DROP | DROPIN | DSETPASS | DUPLICATES
DYNAMIC |  |  |  |
EDITPROC | ELSE | ENABLE | END | ENDLOAD
ENDPROC | ERROR | ESCAPE | ESTIMATE | EUR
EVENT | EXCLUSIVE | EXECUTE | EXPLAIN | EXPLICIT
EXTENDED |  |  |  |
FACT | FALSE | FETCH | FILE | FLUSH
FORCE | FOREIGN | FORMAT | FREEPAGE | FUNCTION
FVERSION |  |  |  |
GET | GRANT |  |  |
HIGH | HOLD | HOURS |  |
IDENTIFIED | IF | IMPLICIT | IN | INCREMENT
INDEXNAME | INDICATOR | INFO | INIT | INITRANS
INOUT | INPROC | INSTANCE | INSTR | IS
ISO | ISOLATION |  |  |
JAVA | JIS |  |  |
LABEL | LANGUAGE | LAST_DAY | LEVEL | LIKE
LOAD | LOCAL | LOCK | LOGFULL | LOGWRITER
LOG_ABOVE_LIMIT | LOW |  |  |
MAXTRANS | MAXVALUE | MEDIANAME | MEDIUM | MICROSECONDS
MIGRATE | MINUS | MINUTES | MINVALUE | MODE
MODIFY | MONITOR | MONTHS | MONTHS_BETWEEN |
NAME | NEW | NEW_TIME | NEXTVAL | NEXT_DAY
NLSSORT | NLS_DATE_FORMAT | NLS_DATE_LANGUAGE | NLS_LANGUAGE | NLS_SORT
NOCACHE | NOCYCLE | NOLOG | NOMAXVALUE | NOMINVALUE
NONE | NOORDER | NOREWIND | NORMAL | NOSORT
NOWAIT | NUMBER | NVL |  |
OBID | OFF | ONLY | OPEN | OPTIMISTIC
OPTIMIZE | OPTION | OR | ORACLE | OUT
OUTER | OVERWRITE |  |  |
PACKAGE | PAGE | PAGES | PARAM | PARSE
PARSEID | PASSWORD | PCTFREE | PCTUSED | PERCENT
PING | PIPE | POS | PRECISION | PREPARE
PRIV | PRIVILEGES | PROC | PROCEDURE | PSM
PUBLIC |  |  |  |
QUICK |  |  |  |
RANGE | RAW | RAWTOHEX | READ | RECURSIVE
REFERENCES | REGISTER | RELEASE | REMOTE | REMOVE
RENAME | REPLICATION | RESOURCE | RESTART | RESTORE
RESTRICT | RESUME | RETURN | RETURNS | REUSE
REVOKE | ROLE | ROLLBACK | ROW | ROWNUM
ROWS |  |  |  |
SAME | SAMPLE | SAPR3 | SAVE | SAVEPOINT
SCHEMA | SECONDS | SELECTIVITY | SEQUENCE | SERVERDB
SESSION | SHARE | SHUTDOWN | SNAPSHOT | SOUNDS
SQLID | SQLMODE | STANDARD | STANDBY | START
STARTPOS | STAT | STATE | STATIC | STOP
STORAGE | SUBPAGES | SUBTRANS | SUSPEND | SWITCH
SYNCHRONIZE | SYNONYM | SYSDATE |  |
TABID | TABLESPACE | TAKEOVER | TAPE | TEMP
THEN | TIMEOUT | TOPIC | TO_CHAR | TO_DATE
TO_NUMBER | TRACE | TRIGGER | TRUE | TRY
TYPE |  |  |  |
UNIQUE | UNKNOWN | UNLOAD | UNLOCK | UNTIL
UNUSED | USA | USAGE | USERID |
VALIDPROC | VARCHAR2 | VERIFY | VERSION | VIEW
VOLUME | VSIZE | VTRACE |  |
WAIT | WHENEVER | WHILE | WORK | WRITE
WRITER |  |  |  |
YEARS |  |  |  |

<null_predicate> ::=
  <expression> IS [NOT] NULL

<numeric_literal> ::=
  <fixed_point_literal >
| <floating_point_literal>

O

<object_spec> ::=
  COLUMN <table_name>.<column_name>
| DBPROC[EDURE] <dbproc_name>
| DOMAIN <domain_name>
| FOREIGN KEY <table_name>.<referential_constraint_name>
| INDEX <index_name> ON <table_name>
| SEQUENCE <sequence_name>
| [PUBLIC] SYNONYM <synonym_name>
| TABLE <table_name>
| TRIGGER <trigger_name>.<table_name>
| USER <user_name>
| USERGROUP <usergroup_name>
| <parameter_name>

<old_index_name> ::=
  <index_name>

<old_table_name> ::=
  <table_name>

<open_cursor_statement> ::=
  OPEN <result_table_name>

<order_clause> ::=
  ORDER BY <sort_spec>,...

<outer_join_inidicator> ::=
  (+)

<owner> ::=
  <user_name>
| <usergroup_name>
| TEMP

P

<parameter_name> ::=
  :<identifier>
| :<identfier>(<identifier>)
| :<identfier>(.<identifier>.)

<parameter_spec> ::=
  <parameter_name> [<indicator_name>]

<password> ::=
  <identifier>
| <first_password_character>[<identifier_tail_character>...]

<pattern_element> ::=
  <match_string>
| <match_set>

<position> ::=
  POS (<unsigned_integer>)
| POS (<parameter_spec>)
| ABSOLUTE <integer>
| ABSOLUTE <parameter_spec>
| RELATIVE <integer>
| RELATIVE <parameter_spec>

<predicate> ::=
  <between_predicate>
| <bool_predicate>
| <comparison_predicate>
| <default_predicate>
| <exists_predicate>
| <in_predicate>
| <join_predicate>
| <like_predicate>
| <null_predicate>
| <quantified_predicate>
| <rowno_predicate>
| <sound_predicate>

<priv_spec> ::=
  ALL [PRIV[ILEGES]] ON [TABLE] <table_name>,...
| <privilege>,...  ON [TABLE] <table_name>,...
| <role_name>

<privilege> ::=
  INSERT
| UPDATE [(<column_name>,...)]
| SELECT [(<column_name>,...)]
| SELUPD [(<column_name>,...)]
| DELETE
| INDEX
| ALTER
| REFERENCES [(<column_name>,...)]

<procedure_name> ::=
  <identifier>

Q

<quantified_predicate> ::=
  <expression> <comp_op> <quantifier> <expression_list>
| <expression> <comp_op> <quantifier> <subquery>
| <expression_list> <equal_or_not> <quantifier> (<expression_list>,...)
| <expression_list> <equal_or_not> <quantifier> <subquery>

<quantifier> ::=
  ALL
| SOME
| ANY

<query_expression> ::=
  <query_term>
| <query_expression> UNION [ALL] <query_term>
| <query_expression> EXCEPT [ALL] <query_term>

<query_primary> ::=
  <query_spec>
| (<query_expression>)

<query_spec> ::=
  SELECT [<distinct_spec>] <select_column>,... <table_expression>

<query_statement> ::=
  <declare_cursor_statement>
| <recursive_declare_cursor_statement>
| <named_select_statement>
| <select_statement>

<query_term> ::=
  <query_primary>
| <query_term> INTERSECT [ALL] <query_primary>

R

<recursive_declare_cursor_statement> ::=
  DECLARE <result_table_name> CURSOR FOR WITH RECURSIVE <reference_name>     (<alias_name>,...) AS (<initial_select> UNION ALL <recursive_select>) <final_select>

<recursive_select> ::=
  <query_spec>

<reference_name> ::=
  <identifier>

<referenced_column> ::=
  <column_name>

<referenced_table> ::=
  <table_name>

<referencing_column> ::=
  <column_name>

<referential_constraint_definition> ::=
  FOREIGN KEY [<referential_constraint_name>] (<referencing_column>,...)
REFERENCES <referenced_table> [(<referenced_column>,...)] [<delete_rule>]

<referential_constraint_name> ::=
  <identifier>

<regular_token> ::=
  <literal>
| <key_word>
| <identifier>
| <parameter_name>

<release_statement> ::=
  COMMIT [WORK] RELEASE
| ROLLBACK [WORK] RELEASE

<rename_column_statement> ::=
  RENAME COLUMN <table_name>.<column_name> TO <column_name>

<rename_index_statement> ::=
  RENAME INDEX <old_index_name> [ON <table_name>] TO <new_index_name>

<rename_synonym_statement> ::=
  RENAME [PUBLIC] SYNONYM <old_synonym_name> TO <new_synonym_name>

<rename_table_statement> ::=
  RENAME TABLE <old_table_name> TO <new_table_name>

<rename_user_statement> ::=
  RENAME USER <user_name> TO <new_user_name>

<rename_usergroup_statement> ::=
  RENAME USERGROUP <usergroup_name> TO <new_usergroup_name>

<rename_view_statement> ::=
  RENAME VIEW <old_table_name> TO <new_table_name>

<reserved_key_word> ::=

ABS | ABSOLUTE | ACOS | ADDDATE | ADDTIME
ALL | ALPHA | ALTER | ANY | ASCII
ASIN | ATAN | ATAN2 | AVG |
BINARY | BIT | BOOLEAN | BYTE |
CASE | CEIL | CEILING | CHAR | CHARACTER
CHECK | CHR | COLUMN | CONCAT | CONSTRAINT
COS | COSH | COT | COUNT | CROSS
CURDATE | CURRENT | CURTIME |  |
DATABASE | DATE | DATEDIFF | DAY | DAYNAME
DAYOFMONTH | DAYOFWEEK | DAYOFYEAR | DEC | DECIMAL
DECODE | DEFAULT | DEGREES | DELETE | DIGITS
DISTINCT | DOUBLE |  |  |
EXCEPT | EXISTS | EXP | EXPAND |
FIRST | FIXED | FLOAT | FLOOR | FOR
FROM | FULL |  |  |
GET_OBJECTNAME | GET_OWNER | GRAPHIC | GREATEST | GROUP
HAVING | HEX | HEXTORAW | HOUR |
IFNULL | IGNORE | INDEX | INITCAP | INNER
INSERT | INT | INTEGER | INTERNAL | INTERSECT
INTO |  |  |  |
JOIN |  |  |  |
KEY |  |  |  |
LAST | LCASE | LEAST | LEFT | LENGTH
LFILL | LIST | LN | LOCATE | LOG
LOG10 | LONG | LONGFILE | LOWER | LPAD
LTRIM |  |  |  |
MAKEDATE | MAKETIME | MAPCHAR | MAX | MBCS
MICROSECOND | MIN | MINUTE | MOD | MONTH
MONTHNAME |  |  |  |
NATURAL | NCHAR | NEXT | NO | NOROUND
NOT | NOW | NULL | NUM | NUMERIC
OBJECT | OF | ON | ORDER |
PACKED | PI | POWER | PREV | PRIMARY
RADIANS | REAL | REJECT | RELATIVE | REPLACE
RFILL | RIGHT | ROUND | ROWID | ROWNO
RPAD | RTRIM |  |  |
SECOND | SELECT | SELUPD | SERIAL | SET
SHOW | SIGN | SIN | SINH | SMALLINT
SOME | SOUNDEX | SPACE | SQRT | STAMP
STATISTICS | STDDEV | SUBDATE | SUBSTR | SUBSTRING
SUBTIME | SUM | SYSDBA |  |
TABLE | TAN | TANH | TIME | TIMEDIFF
TIMESTAMP | TIMEZONE | TO | TOIDENTIFIER | TRANSACTION
TRANSLATE | TRIM | TRUNC | TRUNCATE |
UCASE | UID | UNICODE | UNION | UPDATE
UPPER | USER | USERGROUP | USING | UTCDATE
UTCDIFF |  |  |  |
VALUE | VALUES | VARCHAR | VARGRAPHIC | VARIANCE
WEEK | WEEKOFYEAR | WHEN | WHERE | WITH
YEAR |  |  |  |
ZONED |  |  |  |

<result_column_name> ::=
  <identifier>

<result_table_name> ::=
  <identifier>

<revoke_statement> ::=
  REVOKE <priv_spec>,... FROM <grantee>,... [<cascade_option>]
| REVOKE EXECUTE ON <dbproc_name> FROM <grantee>,...
| REVOKE SELECT ON <sequence_name> FROM <grantee>,... [<cascade_option>]

<role_name> ::=
  <identifier>

<rollback_statement> ::=
  ROLLBACK [WORK]

<routine>

::=
[<local_variables>]

<statement_list>;

<routine_sql_statement> ::=
  <call_statement>
| <close_statement>
| <create_table_temp>
| <declare_cursor_statement>
| <delete_statement>
| <fetch_statement>
| <insert_statement>
| <lock_statement>
| <named_select_statement>
| <select_statement>
| <single_select_statement>
| <subtrans_statement>
| <update_statement>

<row_spec> ::=
  ROW <table_name> KEY <key_spec>,...
| ROW <table_name> CURRENT OF <result_table_name>

<rowno_column> ::=
  ROWNO [<result_column_name>]
| <result_column_name> = ROWNO

<rowno_predicate> ::=
  ROWNO < <unsigned_integer>
| ROWNO < <parameter_spec>
| ROWNO <= <unsigned_integer>
| ROWNO <= <parameter_spec>

S

<sample_definition> ::=
  SAMPLE <unsigned_integer> ROWS
| SAMPLE <unsigned_integer> PERCENT

<scalar_subquery> ::=
  <subquery>

<search_and_result_spec> ::=
  <search_expression>, <result_expression>

<search_condition> ::=
  <boolean_term>
| <search_condition> OR <boolean_term>

<searched_case_function> ::=
  WHEN <search_condition> THEN <result_expression>
    [...]
  [ELSE <default_expression>]
END

<searched_case_statement> ::=
  CASE
    <searched_case_when_clause>…
    [<case_else_clause>]
  END [CASE]

<searched_case_when_clause> ::=
  WHEN <search_condition> THEN <statement>

<seconds> ::=
  <expression>

<select_column> ::=
  <table_columns>
| <derived_column>
| <rowno_column>
| <stamp_column>

<select_statement> ::=
  <query_expression> [<order_clause>] [<update_clause>] [<lock_option>]
    [FOR REUSE]

<sequence_name> ::=
  <identifier>

<set_function_name> ::=
  COUNT
| MAX
| MIN
| SUM
| AVG
| STDDEV
| VARIANCE

<set_function_spec> ::=
  COUNT (*)
| <distinct_function>
| <all_function>

<set_insert_clause> ::=
  <column_name> = <extended_value_spec>

<set_statement> ::=
  SET ROLE ALL [EXCEPT <role_name>]
| SET ROLE NONE
| SET ROLE <role_name> [IDENTIFIED BY <password>]
| SET ISOLATION LEVEL <unsigned_integer>

<set_update_clause> ::=
  <column_name> = <extended_expression >
| <column_name>,... = (<extended_expression>,...)
| (<column_name>,...) = (<extended_expression>,...)
| <column_name> = <subquery>
| (<column_name>,...) = <subquery>

<sign> ::=
  +
| -

<simple_case_function> ::=
  CASE <check_expression>,
    WHEN <search_expression> THEN <result_expression>
      [...]
    [ELSE <default_expression>]
  END

<simple_case_statement> ::=
  CASE <expression>
    <simple_case_when_clause>...
    [<case_else_clause>]
  END [CASE]

<simple_case_when_clause> ::=
  WHEN <literal>[, ...] THEN <statement>

<simple_identifier> ::=
  <first_character>[<identifier_tail_character>...]

<single_select_statement> ::=
  SELECT [<distinct_spec>] <select_column>,... INTO <parameter_spec>,...
    FROM <from_table_spec>,...[<where_clause>] [<group_clause>]
    [<having_clause>] [<lock_option>]

<sort_spec> ::=
  <unsigned_integer> [ASC | DESC]
| <expression> [ASC | DESC]

<sound_predicate> ::=
  <expression> [NOT] SOUNDS [LIKE] <expression>

<source_user> ::=
  <user_name>

<special_character> ::=
  every character except
    <digit>
  | <letter>
  | <extended_letter>
  | <hex_digit>
  | <language_specific_character >
  | <character for the end of a line in a file>

<special_function> ::=
  VALUE (<expression>,<expression>,...)
| GREATEST (<expression>,<expression>,...)
| LEAST (<expression>,<expression>,...)
| DECODE (<check_expression>,<search_and_result_spec>,...[,<default_expression>])
| case_function

<special_identifier> ::=
  <special_identifier_character>...

<special_identifier_character> ::=
  Any character

<sql_comment> ::=
  /*<comment text>*/
| --<comment text>

<stamp_column> ::=
  STAMP [<result_column_name>]
| <result_column_name> = STAMP

<statement> ::=
  BEGIN <statement_list> END
| BREAK
| CONTINUE
| CONTINUE EXECUTE
| <if_statement>
| <while_statement>
| <assignment_statement>
| <case_statement>
| RETURN [<expression>]| STOP (<expression> [,<expression>] )
| TRY <statement_list>; CATCH <statement>
| <routine_sql_statement>

<statement_list> ::=
  <statement>
| <statement_list> ; <statement>

<string_function> ::=
  <string_spec> || <string_spec>
| <string_spec> & <string_spec>
| SUBSTR (<string_spec>,<expression>[,<expression>])
| LFILL (<string_spec>,<string_literal>[,<unsigned_integer>])
| RFILL (<string_spec>,<string_literal>[,<unsigned_integer>])
| LPAD (<string_spec>,<expression>,<string_literal>[,<unsigned_integer>])
| RPAD (<string_spec>,<expression>,<string_literal>[,<unsigned_integer>])
| TRIM (<string_spec>[,<string_spec>])
| LTRIM (<string_spec>[,<string_spec>])
| RTRIM (<string_spec>[,<string_spec>])
| EXPAND (<string_spec>,<unsigned_integer>)
| UPPER (<string_spec>)
| LOWER (<string_spec>)
| INITCAP (<string_spec>)
| REPLACE (<string_spec>,<string_spec>[,<string_spec>])
| TRANSLATE (<string_spec>,<string_spec>,<string_spec>)
| MAPCHAR (<string_spec>[,<unsigned_integer>][,<mapchar_set_name>])
| ALPHA (<string_spec>[,<unsigned_integer>])
| ASCII (<string_spec>)
| SOUNDEX (<string_spec>)
| GET_OBJECTNAME (<string_literal)
| GET_OWNER (<string_literal>)

<string_literal> ::=
  ''
| '<character>...'
| <hex_literal>

<string_spec> ::=
  <expression >

<subquery> ::=
  (<query_expression>)

<subtrans_statement> ::=
  SUBTRANS BEGIN
| SUBTRANS END
| SUBTRANS ROLLBACK

<synonym_name> ::=
  <identifier>

T

<table_columns> ::=
  *
| <table_name>.*
| <reference_name>.*

<table_description_element> ::=
  <column_definition>
| <constraint_definition>
| <referential_constraint_definition>
| <key_definition>
| <unique_definition>

<table_expression> ::=
  <from_clause> [<where_clause>] [<group_clause>] [<having_clause>]

<table_name> ::=
  [<owner>.]<identifier>

<term> ::=
  <factor>
| <term> * <factor>
| <term> / <factor>
| <term> DIV <factor>
| <term> MOD <factor>

<time_expression> ::=
  <expression>

<time_or_timestamp_expression> ::=
  <expression>

<time_function> ::=
  ADDTIME (<time_or_timestamp_expression>, <time_expression> )
| SUBTIME ( <time_or_timestamp_expression>, <time_expression> )
| TIMEDIFF ( <time_or_timestamp_expression>, <time_or_timestamp_expression> )
| MAKETIME (<hours>, <minutes>, <seconds> )

<trigger_event> ::
  INSERT
| UPDATE [(<column_list>)]
| DELETE

<trigger_name> ::=
  <identifier>

<trigonometric_function> ::=
  COS ( <expression> )
| SIN ( <expression> )
| TAN ( <expression> )
| COT ( <expression> )
| COSH ( <expression> )
| SINH ( <expression> )
| TANH ( <expression> )
| ACOS ( <expression> )
| ASIN ( <expression> )
| ATAN ( <expression> )
| ATAN2 ( <expression>, <expression> )
| RADIANS ( <expression> )
| DEGREES ( <expression> )

U

<underscore> ::=
  _

<unique_definition> ::=
  [CONSTRAINT <index_name>] UNIQUE (<column_name>,...)

<unlock_statement> ::=
  UNLOCK <row_spec>... IN SHARE MODE
| UNLOCK <row_spec>... IN EXCLUSIVE MODE
| UNLOCK <row_spec>... IN SHARE MODE <row_spec>... IN EXCLUSIVE MODE
| UNLOCK <row_spec>... OPTIMISTIC

<unsigned_integer> ::=
  <numeric_literal>

<update_clause> ::=
  FOR UPDATE [OF <column_name>,...] [NOWAIT]

<update_statement> ::=
  UPDATE [OF] <table_name> [<reference_name>] SET <set_update_clause>,...
[KEY <key_spec>,...] [WHERE <search_condition>]
| UPDATE [OF] <table_name> [<reference_name>] (<column_name>,...)
    VALUES (<extended_value_spec>,...) [KEY <key_spec>,...]
    [WHERE <search_condition>]
| UPDATE [OF] <table_name> [<reference_name>] SET <set_update_clause>,...
    WHERE CURRENT OF <result_table_name>
| UPDATE [OF] <table_name> [<reference_name>] (<column_name>,...)
    VALUES (<extended_value_spec>,...) WHERE CURRENT OF <result_table_name>

<update_statistics_statement> ::=
  UPDATE STAT[ISTICS] COLUMN <table_name>.<column_name>
    [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] COLUMN (<column_name>,...) FOR <table_name>
    [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] COLUMN (*) FOR <table_name>
    [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] <table_name> [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] [<owner>.][<identifier>]* [ESTIMATE [<sample_definition>]]

<user_mode> ::=
  DBA
| RESOURCE
| STANDARD

<user_name> ::=
  <identifier>

<usergroup_mode> ::=
  RESOURCE
| STANDARD

<usergroup_name> ::=
  <identifier>

V

<value_spec> ::=
  <literal>
| <parameter_spec>
| NULL
| USER
| USERGROUP
| SYSDBA
| UID
| [<owner >.]<sequence_name>.NEXTVAL
| [<owner>.]<sequence_name>.CURRVAL
| <table_name>.CURRVAL
| DATE
| TIME
| TIMESTAMP
| UTCDATE
| TIMEZONE
| UTCDIFF
| TRUE
| FALSE
| TRANSACTION

<variable_name> ::=
  <identifier>

W

<where_clause> ::=
  WHERE <search_condition>

<while_statement> ::=
  WHILE <search_condition> DO <statement>


add_definition (MaxDB: Reference Manual)

add_definition

<add_definition> ::=
  ADD <column_definition>,...
| ADD (<column_definition>,...)
| ADD <constraint_definition>
| ADD <referential_constraint_definition>
| ADD <key_definition>


alias_name (MaxDB: Reference Manual)

alias_name

< alias_name > ::=
  < identifier >


all_function (MaxDB: Reference Manual)

all_function

< all_function > ::=
  < set_function_name > ( [ALL] < expression > )


alter_definition (MaxDB: Reference Manual)

alter_definition

< alter_definition > ::=
  ALTER CONSTRAINT < constraint_name > CHECK < search_condition >
| ALTER < key_definition >


alter_index_statement (MaxDB: Reference Manual)

alter_index_statement

< alter_index_statement > ::=
  ALTER INDEX < index_name > [ON < table_name >] ENABLE
| ALTER INDEX <index_name> [ON <table_name>] DISABLE
| ALTER INDEX <index_name> [ON <table_name>] INIT USAGE


alter_password_statement (MaxDB: Reference Manual)

alter_password_statement

< alter_password_statement >::=
  ALTER PASSWORD <old_ password > TO <new_password>
| ALTER PASSWORD < user_name > <new_password>


alter_table_statement (MaxDB: Reference Manual)

alter_table_statement

< alter_table_statement > ::=
  ALTER TABLE < table_name > < add_definition >
| ALTER TABLE <table_name> < drop_definition >
| ALTER TABLE <table_name> < alter_definition >
| ALTER TABLE <table_name> < column_change_definition >
| ALTER TABLE <table_name> < modify_definition >
| ALTER TABLE <table_name> < referential_constraint_definition >
| ALTER TABLE <table_name> DROP FOREIGN KEY < referential_constraint_name >
| ALTER TABLE <table_name> < sample_definition >


alter_user_statement (MaxDB: Reference Manual)

alter_user_statement

<alter_user_statement> ::=
  ALTER USER <user_name> [<user_mode>]
    [TIMEOUT <unsigned_integer> | TIMEOUT NULL]
    [COSTWARNING <unsigned_integer> | COSTWARNING NULL]
    [COSTLIMIT <unsigned_integer> | COSTLIMIT NULL]
    [DEFAULT ROLE ALL [EXCEPT <role_name>] | DEFAULT ROLE NONE
    | DEFAULT ROLE <role_name> [IDENTIFIED BY <password>]]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]


alter_usergroup_statement (MaxDB: Reference Manual)

alter_usergroup_statement

<alter_usergroup_statement> ::=
  ALTER USERGROUP <usergroup_name> [<usergroup_mode>]
    [TIMEOUT <unsigned_integer> | TIMEOUT NULL]
    [COSTWARNING <unsigned_integer> | COSTWARNING NULL]
    [COSTLIMIT <unsigned_integer> | COSTLIMIT NULL]
    [DEFAULT ROLE ALL [EXCEPT <role_name>] | DEFAULT ROLE NONE
    | DEFAULT ROLE <role_name> [IDENTIFIED BY <password>]]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]


argument (MaxDB: Reference Manual)

argument

< argument > ::=
  < identifier >


argument1 (MaxDB: Reference Manual)

argument1

<argument1> ::=
  <identifier>


arithmetic_function (MaxDB: Reference Manual)

arithmetic_function

< arithmetic_function > ::=
  TRUNC ( < expression >[, <expression>] )
| ROUND ( <expression>[, <expression>] )
| NOROUND ( <expression> )
| FIXED ( <expression>[, < unsigned_integer > [, <unsigned_integer] ] )
| FLOAT ( <expression>[, <unsigned_integer> ] )
| CEIL ( <expression> )
| FLOOR ( <expression> )
| SIGN ( <expression> )
| ABS ( <expression> )
| POWER ( <expression>, <expression> )
| EXP ( <expression> )
| SQRT ( <expression> )
| LN ( <expression> )
| LOG ( <expression>, <expression> )
| PI
| LENGTH ( <expression> )
| INDEX ( < string_spec >, <string_spec> [,<expression>[, <expression>] ] )


assignment_statement (MaxDB: Reference Manual)

assignment_statement

< assignment_statement > ::=
  SET < variable_name > = < expression >


between_predicate (MaxDB: Reference Manual)

between_predicate

< between_predicate > ::=
  < expression > [NOT] BETWEEN <expression> AND <expression>


bool_predicate (MaxDB: Reference Manual)

bool_predicate

< bool_predicate > ::=
  < column_spec > [ IS [NOT] <TRUE | FALSE>]


boolean_factor (MaxDB: Reference Manual)

boolean_factor

< boolean_factor > ::=
  [NOT] < predicate >
| [NOT] (< search_condition >)


boolean_term (MaxDB: Reference Manual)

boolean_term

< boolean_term > ::=
  < boolean_factor >
| <boolean_term> AND <boolean_factor>


call_statement (MaxDB: Reference Manual)

call_statement

< call_statement > ::=
  CALL < dbproc_name > [(< expression >,...)] [WITH COMMIT]


cascade_option (MaxDB: Reference Manual)

cascade_option

< cascade_option > ::=
  CASCADE
| RESTRICT


case_else_clause (MaxDB: Reference Manual)

case_else_clause

< case_else_clause > ::=
  ELSE < statement >


case_function (MaxDB: Reference Manual)

case_function

< case_function > ::=
  < simple_case_function >
| < searched_case_function >


case_statement (MaxDB: Reference Manual)

case_statement

< case_statement > ::=
  < simple_case_statement >
| < searched_case_statement >


character (MaxDB: Reference Manual)

character

< character > ::=
  < digit >
| < letter >
| < extended_letter >
| < hex_digit >
| < language_specific_character >
| < special_character >


close_statement (MaxDB: Reference Manual)

close_statement

< close_statement > ::=
  CLOSE [< result_table_name >]


column_attributes (MaxDB: Reference Manual)

column_attributes

< column_attributes > ::=
  [< key_or_not_null_spec >] [< default_spec >] [UNIQUE] [< constraint_definition >]
    [REFERENCES < referenced_table > [(< referenced_column >)] [< delete_rule >]]


column_change_definition (MaxDB: Reference Manual)

column_change_definition

< column_change_definition > ::=
  COLUMN < column_name > NOT NULL
| COLUMN <column_name> DEFAULT NULL
| COLUMN <column_name> ADD < default_spec >
| COLUMN <column_name> ALTER <default_spec>
| COLUMN <column_name> DROP DEFAULT


column_definition (MaxDB: Reference Manual)

column_definition

< column_definition > ::=
  < column_name > < data_type > [< column_attributes >]
| <column_name> < domain_name > [<column_attributes>]


column_list (MaxDB: Reference Manual)

column_list

< column_list > ::=
  < column_name >
| <column_list>, <column_name>


column_name (MaxDB: Reference Manual)

column_name

< column_name > ::=
  < identifier >


column_spec (MaxDB: Reference Manual)

column_spec

< column_spec > ::=
  < column_name >
| < table_name >.<column_name>
| < reference_name >.<column_name>
| < result_table_name >.<column_name>


comment (MaxDB: Reference Manual)

comment

< comment > ::=
  < string_literal >
| < parameter_name >


comment_on_statement (MaxDB: Reference Manual)

comment_on_statement

< comment_on_statement > ::=
  COMMENT ON < object_spec > IS < comment >


commit_statement (MaxDB: Reference Manual)

commit_statement

< commit_statement > ::=
  COMMIT [WORK]


comp_op (MaxDB: Reference Manual)

comp_op

<comp_op> ::=
  <
| >
| <>
| !=
| =
| <=
| >=
| ~= | ~< | ~> (for machines with ASCII code)


comparison_predicate (MaxDB: Reference Manual)

comparison_predicate

< comparison_predicate > ::=
  < expression > < comp_op > <expression>
| <expression> <comp_op> < subquery >
| < expression_list > < equal_or_not > (<expression_list>)
| <expression_list> <equal_or_not> <subquery>


connect_option (MaxDB: Reference Manual)

connect_option

< connect_option > ::=
  SQLMODE <INTERNAL | ANSI | DB2 | ORACLE>
| ISOLATION LEVEL < unsigned_integer >
| TIMEOUT <unsigned_integer>


connect_statement (MaxDB: Reference Manual)

connect_statement

< connect_statement > ::=
  CONNECT < parameter_name > IDENTIFIED BY <parameter_name> [< connect_option >...]
| CONNECT <parameter_name> IDENTIFIED BY < password > [<connect_option>...]
| CONNECT < user_name > IDENTIFIED BY <parameter_name> [<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <password> [<connect_option>...]


constraint_definition (MaxDB: Reference Manual)

constraint_definition

< constraint_definition > ::=
  CHECK < search_condition >
| CONSTRAINT <search_condition>
| CONSTRAINT < constraint_name > CHECK <search_condition>


constraint_name (MaxDB: Reference Manual)

constraint_name

< constraint_name > ::=
  < identifier >


conversion_function (MaxDB: Reference Manual)

conversion_function

< conversion_function > ::=
  NUM (< expression >)
| CHR (<expression>[,< unsigned_integer >])
| HEX (<expression>)
| HEXTORAW (<expression>)
| CHAR (<expression>[,< datetimeformat >])


create_dbproc_statement (MaxDB: Reference Manual)

create_dbproc_statement

< create_dbproc_statement > ::=
  CREATE DBPROC < procedure_name > [(< formal_parameter >,..)] [RETURNS CURSOR] AS < routine >


create_domain_statement (MaxDB: Reference Manual)

create_domain_statement

< create_domain_statement > ::=
  CREATE DOMAIN < domain_name > < data_type > [< default_spec >] [< constraint_definition >]


create_function_statement (MaxDB: Reference Manual)

create_function_statement

<create_function_statement> ::=
  CREATE FUNCTION <dbfunction_name>
    [(<formal_parameter1>,...)] RETURNS <data_type> AS <routine>


create_index_statement (MaxDB: Reference Manual)

create_index_statement

<create_index_statement> ::=
CREATE [UNIQUE] INDEX <index_name> ON <table_name> (<index_spec>)


create_role_statement (MaxDB: Reference Manual)

create_role_statement

< create_role_statement > ::=
  CREATE ROLE < role_name > [IDENTIFIED BY < password >]


create_sequence_statement (MaxDB: Reference Manual)

create_sequence_statement

< create_sequence_statement > ::=
  CREATE SEQUENCE [< owner >.]< sequence_name >
    [INCREMENT BY < integer >]
    [START WITH <integer>]
    [MAXVALUE <integer> | NOMAXVALUE]
    [MINVALUE <integer> | NOMINVALUE]
    [CYCLE | NOCYCLE]
    [CACHE < unsigned_integer > | NOCACHE]
    [ORDER|NOORDER]


create_synonym_statement (MaxDB: Reference Manual)

create_synonym_statement

<create_synonym_statement> ::=
  CREATE [PUBLIC] SYNONYM [<owner>.]<synonym_name> FOR <table_name>


create_table_statement (MaxDB: Reference Manual)

create_table_statement

<create_table_statement> ::=
CREATE TABLE <table_name> (<column_definition> [,<table_description_element>,...])
[IGNORE ROLLBACK] [NO FIXED LENGTH COLUMN] [<sample_definition>]
| CREATE TABLE <table_name> [(<table_description_element>,...)]
[IGNORE ROLLBACK] [NO FIXED LENGTH COLUMN] [<sample_definition>]
AS <query_expression> [<duplicates_clause>]
| CREATE TABLE <table_name> LIKE <table_name> [IGNORE ROLLBACK]


create_table_temp (MaxDB: Reference Manual)

create_table_temp

< create_table_temp > :: =
  < create_table_statement > for creating temporary tables,
    that is, the table_name in the CREATE TABLE statement
    must have the format TEMP.< identifier >.


create_trigger_statement (MaxDB: Reference Manual)

create_trigger_statement

< create_trigger_statement > ::=
  CREATE TRIGGER < trigger_name > FOR < table_name > AFTER < trigger_event ,..>
    EXECUTE (< routine >) [WHENEVER < search_condition >]


create_user_statement (MaxDB: Reference Manual)

create_user_statement

<create_user_statement> ::=
  CREATE USER <user_name> PASSWORD <password>
    [<user_mode>]
    [TIMEOUT <unsigned_integer>]
    [COSTWARNING <unsigned_integer>]
    [COSTLIMIT <unsigned_integer>]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]
| CREATE USER <user_name> PASSWORD <password> LIKE <source_user>
| CREATE USER <user_name> PASSWORD <password> USERGROUP <usergroup_name>


create_usergroup_statement (MaxDB: Reference Manual)

create_usergroup_statement

<create_usergroup_statement> ::=
  CREATE USERGROUP <usergroup_name>
    [<usergroup_mode>]
    [TIMEOUT <unsigned_integer>]
    [COSTWARNING <unsigned_integer>]
    [COSTLIMIT <unsigned_integer>]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE <ASCII | UNICODE>]


create_view_statement (MaxDB: Reference Manual)

create_view_statement

< create_view_statement > ::=
  CREATE [OR REPLACE] VIEW < table_name > [(< alias_name >,...)]
    AS < query_expression > [WITH CHECK OPTION]


data_type (MaxDB: Reference Manual)

data_type

<data_type> ::=
  CHAR[ACTER] [(<unsigned_integer>)] [ASCII | BYTE | UNICODE]
| VARCHAR [(<unsigned_integer>)] [ASCII | BYTE | UNICODE]
| LONG [VARCHAR] [ASCII | BYTE | UNICODE]
| BOOLEAN
| FIXED (<unsigned_integer> [,<unsigned_integer>])
| FLOAT (<unsigned_integer>)
| INT[EGER]
| SMALLINT
| DATE
| TIME
| TIMESTAMP


date_function (MaxDB: Reference Manual)

date_function

< date_function > ::=
  ADDDATE ( < date_or_timestamp_expression >, < expression > )
| SUBDATE ( <date_or_timestamp_expression>, <expression> )
| DATEDIFF ( <date_or_timestamp_expression>, <date_or_timestamp_expression> )
| DAYOFWEEK ( <date_or_timestamp_expression> )
| WEEKOFYEAR ( <date_or_timestamp_expression> )
| DAYOFMONTH ( <date_or_timestamp_expression> )
| DAYOFYEAR ( <date_or_timestamp_expression> )
| MAKEDATE ( <expression>, <expression> )
| DAYNAME ( <date_or_timestamp_expression> )
| MONTHNAME ( <date_or_timestamp_expression> )


date_or_timestamp_expression (MaxDB: Reference Manual)

date_or_timestamp_expression

< date_or_timestamp_expression > ::=
  < expression >


datetimeformat (MaxDB: Reference Manual)

datetimeformat

< datetimeformat > ::=
  EUR
| INTERNAL
| ISO
| JIS
| USA


dbfunction_call (MaxDB: Reference Manual)

dbfunction_call

<dbfunction_call> ::=
  <dbfunction_name> ( [<expression>,...) )


dbfunction_name (MaxDB: Reference Manual)

dbfunction_name

<dbfunction_name> ::=
  [<owner>.]<identifier>


dbproc_name (MaxDB: Reference Manual)

dbproc_name

< dbproc_name > ::=
  [< owner >.]< procedure_name >


declare_cursor_statement (MaxDB: Reference Manual)

declare_cursor_statement

< declare_cursor_statement > ::=
  DECLARE < result_table_name > CURSOR FOR < select_statement >


default_predicate (MaxDB: Reference Manual)

default_predicate

< default_predicate > ::=
  < column_spec > < comp_op > DEFAULT


default_spec (MaxDB: Reference Manual)

default_spec

< default_spec > ::=
  DEFAULT < literal >
| DEFAULT NULL
| DEFAULT USER
| DEFAULT USERGROUP
| DEFAULT SYSDBA
| DEFAULT DATE
| DEFAULT TIME
| DEFAULT TIMESTAMP
| DEFAULT UTCDATE
| DEFAULT UTCDIFF
| DEFAULT TIMEZONE
| DEFAULT TRUE
| DEFAULT FALSE
| DEFAULT TRANSACTION
| DEFAULT STAMP
| DEFAULT SERIAL[(< unsigned_integer >)]


delete_rule (MaxDB: Reference Manual)

delete_rule

< delete_rule > ::=
  ON DELETE CASCADE
| ON DELETE RESTRICT
| ON DELETE SET DEFAULT
| ON DELETE SET NULL


delete_statement (MaxDB: Reference Manual)

delete_statement

< delete_statement > ::=
  DELETE [FROM] < table_name > [< reference_name >]
    [KEY < key_spec >,...] [WHERE < search_condition >]
| DELETE [FROM] <table_name> [<reference_name>]
    WHERE CURRENT OF < result_table_name >


Delimiter token (MaxDB: Reference Manual)

Delimiter token

<delimiter_token> ::=
  ( | ) | , | . | + | - | * | / | < | > | <> | != | = | <= | >=
| ¬= | ¬< | ¬>(for machines with ASCII code)


derived_column (MaxDB: Reference Manual)

derived_column

< derived_column > ::=
  < expression > [ [AS] < result_column_name >]
| <result_column_name> = <expression>


digit (MaxDB: Reference Manual)

digit

< digit > ::=
  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9


digit_sequence (MaxDB: Reference Manual)

digit_sequence

< digit_sequence > ::=
  < digit >...


distinct_function (MaxDB: Reference Manual)

distinct_function

< distinct_function >::=
  < set_function_name > ( DISTINCT < expression > )


distinct_spec (MaxDB: Reference Manual)

distinct_spec

< distinct_spec > ::=
  DISTINCT
| ALL


domain_name (MaxDB: Reference Manual)

domain_name

< domain_name > ::=
  [< owner >.]< identifier >


double_quotes (MaxDB: Reference Manual)

double_quotes

< double_quotes > ::=
  "


drop_dbproc_statement (MaxDB: Reference Manual)

drop_dbproc_statement

< drop_dbproc_statement > ::=
  DROP DBPROC < dbproc_name >


drop_definition (MaxDB: Reference Manual)

drop_definition

< drop_definition > ::=
  DROP < column_name >,... [< cascade_option >] [RELEASE SPACE]
| DROP (<column_name>,...) [<cascade_option>] [RELEASE SPACE]
| DROP CONSTRAINT < constraint_name >
| DROP PRIMARY KEY


drop_domain_statement (MaxDB: Reference Manual)

drop_domain_statement

< drop_domain_statement > ::=
  DROP DOMAIN < domain_name >


drop_function_statement (MaxDB: Reference Manual)

drop_function_statement

<drop_function_spec> ::=
  DROP FUNCTION <dbfunction_name>


drop_index_statement (MaxDB: Reference Manual)

drop_index_statement

< drop_index_statement > ::=
  DROP INDEX < index_name > [ON < table_name >]


drop_role_statement (MaxDB: Reference Manual)

drop_role_statement

< drop_role_statement > ::=
  DROP ROLE < role_name >


drop_sequence_statement (MaxDB: Reference Manual)

drop_sequence_statement

< drop_sequence_statement > ::=
  DROP SEQUENCE [< owner >.]< sequence_name >


drop_synonym_statement (MaxDB: Reference Manual)

drop_synonym_statement

< drop_synonym_statement > ::=
  DROP [PUBLIC] SYNONYM [< owner >.]< synonym_name >


drop_table_statement (MaxDB: Reference Manual)

drop_table_statement

< drop_table_statement > ::=
  DROP TABLE < table_name > [< cascade_option >]


drop_trigger_statement (MaxDB: Reference Manual)

drop_trigger_statement

< drop_trigger_statement > ::=
  DROP TRIGGER < trigger_name > OF < table_name >


drop_user_statement (MaxDB: Reference Manual)

drop_user_statement

< drop_user_statement > ::=
  DROP USER < user_name > [< cascade_option >]


drop_usergroup_statement (MaxDB: Reference Manual)

drop_usergroup_statement

< drop_usergroup_statement > ::=
  DROP USERGROUP < usergroup_name > [< cascade_option >]


drop_view_statement (MaxDB: Reference Manual)

drop_view_statement

< drop_view_statement > ::=
  DROP VIEW < table_name > [< cascade_option >]


duplicates_clause (MaxDB: Reference Manual)

duplicates_clause

< duplicates_clause > ::=
  REJECT DUPLICATES
| IGNORE DUPLICATES
| UPDATE DUPLICATES


equal_or_not (MaxDB: Reference Manual)

equal_or_not

<equal_or_not> ::=
  <>
| =
| ~= (for machines with ASCII code)


exists_predicate (MaxDB: Reference Manual)

exists_predicate

< exists_predicate > ::=
  EXISTS < subquery >


exists_table_statement (MaxDB: Reference Manual)

exists_table_statement

< exists_table_statement > ::=
  EXISTS TABLE < table_name >


explain_statement (MaxDB: Reference Manual)

explain_statement

< explain_statement > ::=
  EXPLAIN [(< result_table_name >)] < query_statement >
| EXPLAIN [(<result_table_name>)] < single_select_statement >


exponent (MaxDB: Reference Manual)

exponent

< exponent > ::=
  [< sign >][[< digit >]<digit>]<digit>


expression (MaxDB: Reference Manual)

expression

< expression > ::=
  < term >
| <expression> + <term>
| <expression> - <term>


expression_list (MaxDB: Reference Manual)

expression_list

< expression_list > ::=
  (< expression >,...)


extended_expression (MaxDB: Reference Manual)

extended_expression

< extended_expression > ::=
  < expression >
| DEFAULT
| STAMP


extended_letter (MaxDB: Reference Manual)

extended_letter

< extended_letter > ::=
  #
| @
| $


extended_value_spec (MaxDB: Reference Manual)

extended_value_spec

< extended_value_spec > ::=
  < value_spec >
| DEFAULT
| STAMP


extraction_function (MaxDB: Reference Manual)

extraction_function

< extraction_function > ::=
  YEAR ( < date_or_timestamp_expression > )
| MONTH ( <date_or_timestamp_expression> )
| DAY ( <date_or_timestamp_expression> )
| HOUR ( < time_or_timestamp_expression > )
| MINUTE ( <time_or_timestamp_expression> )
| SECOND ( <time_or_timestamp_expression> )
| MICROSECOND ( < expression > )
| TIMESTAMP ( <expression>[, <expression> ] )
| DATE ( <expression> )
| TIME ( <expression> )


factor (MaxDB: Reference Manual)

factor

< factor > ::=
  [< sign >] < value_spec >
| [<sign>] < column_spec >
| [<sign>] < function_spec >
| [<sign>] < set_function_spec >
| < scalar_subquery >
| < expression >


fetch_statement (MaxDB: Reference Manual)

fetch_statement

< fetch_statement > ::=
  FETCH [FIRST | LAST | NEXT | PREV | < position > | SAME] [< result_table_name >]
    INTO < parameter_spec >,...


final_select (MaxDB: Reference Manual)

final_select

< final_select > ::=
  < select_statement >


first_character (MaxDB: Reference Manual)

first_character

< first_character > ::=
  < letter >
| < extended_letter >
| < language_specific_character >


first_password_character (MaxDB: Reference Manual)

first_password_character

< first_password_character > ::=
  < letter >
| < extended_letter >
| < language_specific_letter >
| < digit >


fixed_point_literal (MaxDB: Reference Manual)

fixed_point_literal

< fixed_point_literal > ::=
  [< sign >]< digit_sequence >[.<digit_sequence>]
| [sign]<digit_sequence>.
| [sign].<digit_sequence>


floating_point_literal (MaxDB: Reference Manual)

floating_point_literal

< floating_point_literal > ::=
  < mantissa >E< exponent >
| <mantissa>e<exponent>


formal_parameter (MaxDB: Reference Manual)

formal_parameter

< formal_parameter > ::=
  IN < argument > < data_type >
| OUT <argument> <data_type>
| INOUT <argument> <data_type>


formal_parameter1 (MaxDB: Reference Manual)

formal_parameter1

<formal_parameter1> ::=
  <argument1> <data_type>


from_clause (MaxDB: Reference Manual)

from_clause

< from_clause > ::=
  FROM < from_table_spec >,...


from_table_spec (MaxDB: Reference Manual)

from_table_spec

< from_table_spec > ::=
  < table_name > [AS] [< reference_name >]
| < result_table_name > [AS] [<reference_name>]
| (< query_expression >) [AS] [<reference_name>]
| < joined_table >


function_spec (MaxDB: Reference Manual)

function_spec

<function_spec> ::=
  <arithmetic_function>
| <trigonometric_function>
| <string_function>
| <date_function>
| <time_function>
| <extraction_function>
| <special_function>
| <conversion_function>
| <dbfunction_call>


grant_statement (MaxDB: Reference Manual)

grant_statement

< grant_statement > ::=
  GRANT < priv_spec >,... TO < grantee >,... [WITH GRANT OPTION]
| GRANT EXECUTE ON < dbproc_name > TO <grantee>,...
| GRANT SELECT ON < sequence_name > TO <grantee>,... [WITH GRANT OPTION]


grant_user_statement (MaxDB: Reference Manual)

grant_user_statement

< grant_user_statement > ::=
  GRANT USER < granted_users > [FROM < user_name >] TO <user_name>


grant_usergroup_statement (MaxDB: Reference Manual)

grant_usergroup_statement

< grant_usergroup_statement > ::=
  GRANT USERGROUP < granted_usergroups > [FROM < user_name >] TO <user_name>


granted_usergroups (MaxDB: Reference Manual)

granted_usergroups

< granted_usergroups > ::=
  < usergroup_name >,...
| *


granted_users (MaxDB: Reference Manual)

granted_users

< granted_users > ::=
  < user_name >,...
| *


grantee (MaxDB: Reference Manual)

grantee

< grantee > ::=
  PUBLIC
| < user_name >
| < usergroup_name >
| < role_name >


group_clause (MaxDB: Reference Manual)

group_clause

< group_clause > ::=
  GROUP BY < expression >,...


having_clause (MaxDB: Reference Manual)

having_clause

< having_clause > ::=
  HAVING < search_condition >


hex_digit (MaxDB: Reference Manual)

hex_digit

< hex_digit > ::=
  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
| A | B | C | D | E | F
| a | b | c | d | e | f


hex_digit_seq (MaxDB: Reference Manual)

hex_digit_seq

< hex_digit_seq > ::=
  < hex_digit ><hex_digit>
| <hex_digit_seq><hex_digit><hex_digit>


hex_literal (MaxDB: Reference Manual)

hex_literal

< hex_literal > ::=
  x''
| X''
| x'< hex_digit_seq >'
| X'<hex_digit_seq>'


hours (MaxDB: Reference Manual)

hours

< hours > ::=
  < expression >


identifier (MaxDB: Reference Manual)

identifier

< identifier > ::=
  < simple_identifier >
| < double quotes >< special_identifier ><double_quotes>


identifier_tail_character (MaxDB: Reference Manual)

identifier_tail_character

< identifier_tail_character > ::=
  < letter >
| < extended_letter >
| < language_specific_character >
| < digit >
| < underscore >


if_statement (MaxDB: Reference Manual)

if_statement

< if_statement > ::=
  IF < search_condition > THEN < statement > [ELSE <statement>]


in_predicate (MaxDB: Reference Manual)

in_predicate

< in_predicate > ::=
  < expression > [NOT] IN < subquery >
| <expression> [NOT] IN < expression_list >
| <expression_list> [NOT] IN <subquery>
| <expression_list> [NOT] IN (<expression_list>,...)


index_name (MaxDB: Reference Manual)

index_name

< index_name > ::=
  < identifier >


index_spec (MaxDB: Reference Manual)

index_spec

<index_spec> ::=
  <column_name> [ASC|DESC]
| <dbfunction_name> (<column_name>,...) [ASC|DESC]


indicator_name (MaxDB: Reference Manual)

indicator_name

< indicator_name > ::=
  < parameter_name >


initial_select (MaxDB: Reference Manual)

initial_select

< initial_select > ::=
  < query_spec >


insert_expression (MaxDB: Reference Manual)

insert_expression

< insert_expression > ::=
  < extended_expression >
| < subquery >


insert_statement (MaxDB: Reference Manual)

insert_statement

< insert_statement > ::=
  INSERT [INTO] < table_name > [(< column_name >,...)]
    VALUES (< insert_expression >,...) [< duplicates_clause >]
| INSERT [INTO] <table_name> [(<column_name>,...)]
    < query_expression > [<duplicates_clause>]
| INSERT [INTO] <table_name> SET < set_insert_clause >,... [<duplicates_clause>]


integer (MaxDB: Reference Manual)

integer

< integer > ::=
  [ sign ]< unsigned_integer >


join_predicate (MaxDB: Reference Manual)

join_predicate

< join_predicate > ::=
  < expression > [< outer_join_indicator >] < comp_op > <expression> [<outer_join_indicator>]


join_spec (MaxDB: Reference Manual)

join_spec

<join_spec> ::=
  ON <search_condition>


joined_table (MaxDB: Reference Manual)

joined_table

< joined_table > ::=
  < from_table_spec > CROSS JOIN <from_table_spec>
| <from_table_spec> [INNER] JOIN <from_table_spec> < join_spec >
| <from_table_spec> [<LEFT|RIGHT|FULL> [OUTER]] JOIN
    <from_table_spec> <join_spec>


key_definition (MaxDB: Reference Manual)

key_definition

< key_definition > ::
  PRIMARY KEY (< column_name >,...)


key_or_not_null_spec (MaxDB: Reference Manual)

key_or_not_null_spec

< key_or_not_null_spec > ::=
  [PRIMARY] KEY
| NOT NULL [WITH DEFAULT]


key_spec (MaxDB: Reference Manual)

key_spec

< key_spec > ::=
  < column_name > = < value_spec >


key_word (MaxDB: Reference Manual)

key_word

< key_word > ::=
  < not_reserved_key_word >
| < reserved_keyword >


language_specific_character (MaxDB: Reference Manual)

language_specific_character

< language_specific_character > ::=
  <every letter that occurs in a Northern, Central, or Southern European language
    and is not included in the < letter > list>
| <for UNICODE-enabled databases: every character that is not included in the ASCII code list from 0 to 127>


letter (MaxDB: Reference Manual)

letter

< letter > ::=
  A | B | C | D | E | F | G | H | I | J | K | L | M
| N | O | P | Q | R | S | T | U | V | W | X | Y | Z
| a | b | c | d | e | f | g | h | i | j | k | l | m
| n | o | p | q | r | s | t | u | v | w | x | y | z


like_expression (MaxDB: Reference Manual)

like_expression

< like_expression > ::=
  < expression >
| '< pattern_element >...'


like_predicate (MaxDB: Reference Manual)

like_predicate

< like_predicate > ::=
  < expression > [NOT] LIKE < like_expression > [ESCAPE <expression>]


literal (MaxDB: Reference Manual)

literal

< literal > ::=
  < string_literal >
| < numeric_literal >


local_variable (MaxDB: Reference Manual)

local_variable

< local_variable > ::=
  < variable_name > < data_type >


local_variable_list (MaxDB: Reference Manual)

local_variable_list

< local_variable_list > ::=
  < local_variable >
| <local_variable_list>;<local_variable>


local_variables (MaxDB: Reference Manual)

local_variables

< local_variables > ::=
  VAR < local_variable_list >;


lock_option (MaxDB: Reference Manual)

lock_option

< lock_option > ::=
  WITH LOCK [(IGNORE)|(NOWAIT)] [EXCLUSIVE | OPTIMISTIC] [ISOLATION LEVEL < unsigned_integer >]


lock_spec (MaxDB: Reference Manual)

lock_spec

< lock_spec > ::=
  TABLE < table_name >,...
| < row_spec >...
| TABLE <table_name>,... <row_spec>...


lock_statement (MaxDB: Reference Manual)

lock_statement

< lock_statement > ::=
  LOCK [(WAIT)|(NOWAIT)] < lock_spec > IN SHARE MODE
| LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN EXCLUSIVE MODE
| LOCK [(WAIT)|(NOWAIT)] < row_spec >... OPTIMISTIC
| LOCK [(WAIT)|(NOWAIT)] <lock_spec> IN SHARE MODE <lock_spec> IN EXCLUSIVE MODE


mantissa (MaxDB: Reference Manual)

mantissa

< mantissa > ::=
  < fixed_point_literal >


mapchar_set_name (MaxDB: Reference Manual)

mapchar_set_name

< mapchar_set_name > ::=
  < identifier >


match_char (MaxDB: Reference Manual)

match_char

< match_char > ::=
  Every character except
    %
  | *
  | X'1F'
  | < underscore >
  | ?
  | X'1E'
  | (


match_set (MaxDB: Reference Manual)

match_set

<match_set> ::=
  <underscore>
| X'1E'
| <match_char>


match_string (MaxDB: Reference Manual)

match_string

<match_string> ::=
  %
| X'1F'


minutes (MaxDB: Reference Manual)

minutes

< minutes > ::=
  < expression >


modify_definition (MaxDB: Reference Manual)

modify_definition

< modify_definition > ::=
  MODIFY (< column_name > [< data_type >] [< column_attributes >]...)


monitor_statement (MaxDB: Reference Manual)

monitor_statement

< monitor_statement > ::=
  MONITOR INIT


named_query_expression (MaxDB: Reference Manual)

named_query_expression

<named_query_expression> ::=
<named_query_term>
| <named_query_expression> UNION [ALL] <query_term>
| <named_query_expression> EXCEPT [ALL] <query_term>


named_query_primary (MaxDB: Reference Manual)

named_query_primary

<named_query_primary> ::=
<named_query_spec>
| (<named_query_expression>)


named_query_spec (MaxDB: Reference Manual)

named_query_spec

<named_query_spec> ::=
SELECT [<distinct_spec>] <result_table_name>
(<select_column>,...) <table_expression>


named_query_term (MaxDB: Reference Manual)

named_query_term

<named_query_term> ::=
<named_query_primary>
| <named_query_term> INTERSECT [ALL] <query_primary>


named_select_statement (MaxDB: Reference Manual)

named_select_statement

<named_select_statement>

::=
<named_query_expression>

[<order_clause>]
[<update_clause>]

[<lock_option>]

[FOR REUSE]


new_index_name (MaxDB: Reference Manual)

new_index_name

< new_index_name > ::=
  < index_name >


new_table_name (MaxDB: Reference Manual)

new_table_name

< new_table_name > ::=
  < table_name >


next_stamp_statement (MaxDB: Reference Manual)

next_stamp_statement

< next_stamp_statement > ::=
  NEXT STAMP [INTO] < parameter_name >


not_reserved_key_word (MaxDB: Reference Manual)

not_reserved_key_word

<not_reserved_key_word> ::=

ADD | ADDRESS | ADD_MONTHS | AFTER | ALTERIN
ANALYZE | AND | ANSI | APPEND | ARCHIVE
AS | ASC | AT | AUTHORIZATION | AUTO
AUTOSAVE |  |  |  |
BACKUP_PAGES | BAD | BEFORE | BEGIN | BEGINLOAD
BEGINPROC | BETWEEN | BLOCK | BLOCKSIZE | BOTH
BREAK | BUFFER | BUFFERPOOL | BWHIERARCHY | BY
CACHE | CACHELIMIT | CACHES | CALL | CANCEL
CASCADE | CATALOG | CATCH | CHECKPOINT | CLEAR
CLOSE | CLUSTER | COMMENT | COMMIT | COMPUTE
CONFIG | CONNECT | CONSTRAINTS | CONTAINER | CONTINUE
COSTLIMIT | COSTWARNING | CREATE | CREATEIN | CURRENT_DATE
CURRENT_SCHEMA | CURRENT_TIME | CURRENT_TIMESTAMP | CURRVAL | CURSOR
CYCLE |  |  |  |
DATA | DAYS | DB2 | DBA | DBPROC
DBPROCEDURE | DB_ABOVE_LIMIT | DB_BELOW_LIMIT | DEBUG | DECLARE
DEFAULTCODE | DEGREE | DESC | DESCRIBE | DEVICE
DIAGNOSE | DIMENSION | DISABLE | DIV | DO
DOMAIN | DROP | DROPIN | DSETPASS | DUPLICATES
DYNAMIC |  |  |  |
EDITPROC | ELSE | ENABLE | END | ENDLOAD
ENDPROC | ERROR | ESCAPE | ESTIMATE | EUR
EVENT | EXCLUSIVE | EXECUTE | EXPLAIN | EXPLICIT
EXTENDED |  |  |  |
FACT | FALSE | FETCH | FILE | FLUSH
FORCE | FOREIGN | FORMAT | FREEPAGE | FUNCTION
FVERSION |  |  |  |
GET | GRANT |  |  |
HIGH | HOLD | HOURS |  |
IDENTIFIED | IF | IMPLICIT | IN | INCREMENT
INDEXNAME | INDICATOR | INFO | INIT | INITRANS
INOUT | INPROC | INSTANCE | INSTR | IS
ISO | ISOLATION |  |  |
JAVA | JIS |  |  |
LABEL | LANGUAGE | LAST_DAY | LEVEL | LIKE
LOAD | LOCAL | LOCK | LOGFULL | LOGWRITER
LOG_ABOVE_LIMIT | LOW |  |  |
MAXTRANS | MAXVALUE | MEDIANAME | MEDIUM | MICROSECONDS
MIGRATE | MINUS | MINUTES | MINVALUE | MODE
MODIFY | MONITOR | MONTHS | MONTHS_BETWEEN |
NAME | NEW | NEW_TIME | NEXTVAL | NEXT_DAY
NLSSORT | NLS_DATE_FORMAT | NLS_DATE_LANGUAGE | NLS_LANGUAGE | NLS_SORT
NOCACHE | NOCYCLE | NOLOG | NOMAXVALUE | NOMINVALUE
NONE | NOORDER | NOREWIND | NORMAL | NOSORT
NOWAIT | NUMBER | NVL |  |
OBID | OFF | ONLY | OPEN | OPTIMISTIC
OPTIMIZE | OPTION | OR | ORACLE | OUT
OUTER | OVERWRITE |  |  |
PACKAGE | PAGE | PAGES | PARAM | PARSE
PARSEID | PASSWORD | PCTFREE | PCTUSED | PERCENT
PING | PIPE | POS | PRECISION | PREPARE
PRIV | PRIVILEGES | PROC | PROCEDURE | PSM
PUBLIC |  |  |  |
QUICK |  |  |  |
RANGE | RAW | RAWTOHEX | READ | RECURSIVE
REFERENCES | REGISTER | RELEASE | REMOTE | REMOVE
RENAME | REPLICATION | RESOURCE | RESTART | RESTORE
RESTRICT | RESUME | RETURN | RETURNS | REUSE
REVOKE | ROLE | ROLLBACK | ROW | ROWNUM
ROWS |  |  |  |
SAME | SAMPLE | SAPR3 | SAVE | SAVEPOINT
SCHEMA | SECONDS | SELECTIVITY | SEQUENCE | SERVERDB
SESSION | SHARE | SHUTDOWN | SNAPSHOT | SOUNDS
SQLID | SQLMODE | STANDARD | STANDBY | START
STARTPOS | STAT | STATE | STATIC | STOP
STORAGE | SUBPAGES | SUBTRANS | SUSPEND | SWITCH
SYNCHRONIZE | SYNONYM | SYSDATE |  |
TABID | TABLESPACE | TAKEOVER | TAPE | TEMP
THEN | TIMEOUT | TOPIC | TO_CHAR | TO_DATE
TO_NUMBER | TRACE | TRIGGER | TRUE | TRY
TYPE |  |  |  |
UNIQUE | UNKNOWN | UNLOAD | UNLOCK | UNTIL
UNUSED | USA | USAGE | USERID |
VALIDPROC | VARCHAR2 | VERIFY | VERSION | VIEW
VOLUME | VSIZE | VTRACE |  |
WAIT | WHENEVER | WHILE | WORK | WRITE
WRITER |  |  |  |
YEARS |  |  |  |


null_predicate (MaxDB: Reference Manual)

null_predicate

< null_predicate > ::=
  < expression > IS [NOT] NULL


numeric_literal (MaxDB: Reference Manual)

numeric_literal

< numeric_literal > ::=
  < fixed_point_literal >
| < floating_point_literal >


object_spec (MaxDB: Reference Manual)

object_spec

< object_spec > ::=
  COLUMN < table_name >.< column_name >
| DBPROC[EDURE] < dbproc_name >
| DOMAIN < domain_name >
| FOREIGN KEY <table_name>.< referential_constraint_name >
| INDEX < index_name > ON <table_name>
| SEQUENCE < sequence_name >
| [PUBLIC] SYNONYM < synonym_name >
| TABLE <table_name>
| TRIGGER < trigger_name >.<table_name>
| USER < user_name >
| USERGROUP < usergroup_name >
| < parameter_name >


old_index_name (MaxDB: Reference Manual)

old_index_name

< old_index_name > ::=
  < index_name >


old_table_name (MaxDB: Reference Manual)

old_table_name

< old_table_name > ::=
  < table_name >


open_cursor_statement (MaxDB: Reference Manual)

open_cursor_statement

< open_cursor_statement > ::=
  OPEN < result_table_name >


order_clause (MaxDB: Reference Manual)

order_clause

< order_clause > ::=
  ORDER BY < sort_spec >,...


outer_join_inidicator (MaxDB: Reference Manual)

outer_join_inidicator

< outer_join_inidicator > ::=
  (+)


owner (MaxDB: Reference Manual)

owner

< owner > ::=
  < user_name >
| < usergroup_name >
| TEMP


parameter_name (MaxDB: Reference Manual)

parameter_name

< parameter_name > ::=
  :< identifier >
| :<identfier>(<identifier>)
| :<identfier>(.<identifier>.)


parameter_spec (MaxDB: Reference Manual)

parameter_spec

< parameter_spec > ::=
  < parameter_name > [< indicator_name >]


password (MaxDB: Reference Manual)

password

< password > ::=
  < identifier >
| < first_password_character >[< identifier_tail_character >...]


pattern_element (MaxDB: Reference Manual)

pattern_element

< pattern_element > ::=
  < match_string >
| < match_set >


position (MaxDB: Reference Manual)

position

< position > ::=
  POS (< unsigned_integer >)
| POS (< parameter_spec >)
| ABSOLUTE < integer >
| ABSOLUTE <parameter_spec>
| RELATIVE <integer>
| RELATIVE <parameter_spec>


predicate (MaxDB: Reference Manual)

predicate

< predicate > ::=
  < between_predicate >
| < bool_predicate >
| < comparison_predicate >
| < default_predicate >
| < exists_predicate >
| < in_predicate >
| < join_predicate >
| < like_predicate >
| < null_predicate >
| < quantified_predicate >
| < rowno_predicate >
| < sound_predicate >


priv_spec (MaxDB: Reference Manual)

priv_spec

< priv_spec > ::=
  ALL [PRIV[ILEGES]] ON [TABLE] < table_name >,...
| < privilege >,... ON [TABLE] <table_name>,...
| < role_name >


privilege (MaxDB: Reference Manual)

privilege

< privilege > ::=
  INSERT
| UPDATE [(< column_name >,...)]
| SELECT [(<column_name>,...)]
| SELUPD [(<column_name>,...)]
| DELETE
| INDEX
| ALTER
| REFERENCES [(<column_name>,...)]


procedure_name (MaxDB: Reference Manual)

procedure_name

< procedure_name > ::=
  < identifier >


quantified_predicate (MaxDB: Reference Manual)

quantified_predicate

< quantified_predicate > ::=
  < expression > < comp_op > < quantifier > < expression_list >
| <expression> <comp_op> <quantifier> < subquery >
| <expression_list> < equal_or_not > <quantifier> (<expression_list>,...)
| <expression_list> <equal_or_not> <quantifier> <subquery>


quantifier (MaxDB: Reference Manual)

quantifier

< quantifier > ::=
  ALL
| SOME
| ANY


query_expression (MaxDB: Reference Manual)

query_expression

< query_expression > ::=
  < query_term >
| <query_expression> UNION [ALL] <query_term>
| <query_expression> EXCEPT [ALL] <query_term>


query_primary (MaxDB: Reference Manual)

query_primary

< query_primary > ::=
  < query_spec >
| (< query_expression >)


query_spec (MaxDB: Reference Manual)

query_spec

< query_spec > ::=
  SELECT [< distinct_spec >] < select_column >,... < table_expression >


query_statement (MaxDB: Reference Manual)

query_statement

<query_statement> ::=
<declare_cursor_statement>
| <recursive_declare_cursor_statement>
| <named_select_statement>
| <select_statement>


query_term (MaxDB: Reference Manual)

query_term

< query_term > ::=
  < query_primary >
| <query_term> INTERSECT [ALL] <query_primary>


recursive_declare_cursor_statement (MaxDB: Reference Manual)

recursive_declare_cursor_statement

< recursive_declare_cursor_statement > ::=
  DECLARE < result_table_name > CURSOR FOR WITH RECURSIVE < reference_name >
    (< alias_name >,...) AS (< initial_select > UNION ALL < recursive_select >) < final_select >


recursive_select (MaxDB: Reference Manual)

recursive_select

< recursive_select > ::=
  < query_spec >


reference_name (MaxDB: Reference Manual)

reference_name

< reference_name > ::=
  < identifier >


referenced_column (MaxDB: Reference Manual)

referenced_column

< referenced_column > ::=
  < column_name >


referenced_table (MaxDB: Reference Manual)

referenced_table

< referenced_table > ::=
  < table_name >


referencing_column (MaxDB: Reference Manual)

referencing_column

< referencing_column > ::=
  < column_name >


referential_constraint_definition (MaxDB: Reference Manual)

referential_constraint_definition

< referential_constraint_definition > ::=
  FOREIGN KEY [< referential_constraint_name >] (< referencing_column >,...)
    REFERENCES < referenced_table > [(< referenced_column >,...)] [< delete_rule >]


referential_constraint_name (MaxDB: Reference Manual)

referential_constraint_name

< referential_constraint_name > ::=
  < identifier >


regular_token (MaxDB: Reference Manual)

regular_token

< regular_token > ::=
  < literal >
| < key_word >
| < identifier >
| < parameter_name >


release_statement (MaxDB: Reference Manual)

release_statement

< release_statement > ::=
  COMMIT [WORK] RELEASE
| ROLLBACK [WORK] RELEASE


rename_column_statement (MaxDB: Reference Manual)

rename_column_statement

< rename_column_statement > ::=
  RENAME COLUMN < table_name >.< column_name > TO <column_name>


rename_index_statement (MaxDB: Reference Manual)

rename_index_statement

< rename_index_statement > ::=
  RENAME INDEX < old_index_name > [ON < table_name >] TO < new_index_name >


rename_synonym_statement (MaxDB: Reference Manual)

rename_synonym_statement

< rename_synonym_statement > ::=
  RENAME [PUBLIC] SYNONYM <old_ synonym_name > TO <new_synonym_name>


rename_table_statement (MaxDB: Reference Manual)

rename_table_statement

< rename_table_statement > ::=
  RENAME TABLE < old_table_name > TO < new_table_name >


rename_user_statement (MaxDB: Reference Manual)

rename_user_statement

< rename_user_statement > ::=
  RENAME USER < user_name > TO <new_ user_name >


rename_usergroup_statement (MaxDB: Reference Manual)

rename_usergroup_statement

< rename_usergroup_statement > ::=
  RENAME USERGROUP < usergroup_name > TO <new_ usergroup_name >


rename_view_statement (MaxDB: Reference Manual)

rename_view_statement

< rename_view_statement > ::=
  RENAME VIEW < old_table_name > TO < new_table_name >


reserved_key_word (MaxDB: Reference Manual)

reserved_key_word

<reserved_key_word> ::=

ABS | ABSOLUTE | ACOS | ADDDATE | ADDTIME
ALL | ALPHA | ALTER | ANY | ASCII
ASIN | ATAN | ATAN2 | AVG |
BINARY | BIT | BOOLEAN | BYTE |
CASE | CEIL | CEILING | CHAR | CHARACTER
CHECK | CHR | COLUMN | CONCAT | CONSTRAINT
COS | COSH | COT | COUNT | CROSS
CURDATE | CURRENT | CURTIME |  |
DATABASE | DATE | DATEDIFF | DAY | DAYNAME
DAYOFMONTH | DAYOFWEEK | DAYOFYEAR | DEC | DECIMAL
DECODE | DEFAULT | DEGREES | DELETE | DIGITS
DISTINCT | DOUBLE |  |  |
EXCEPT | EXISTS | EXP | EXPAND |
FIRST | FIXED | FLOAT | FLOOR | FOR
FROM | FULL |  |  |
GET_OBJECTNAME | GET_OWNER | GRAPHIC | GREATEST | GROUP
HAVING | HEX | HEXTORAW | HOUR |
IFNULL | IGNORE | INDEX | INITCAP | INNER
INSERT | INT | INTEGER | INTERNAL | INTERSECT
INTO |  |  |  |
JOIN |  |  |  |
KEY |  |  |  |
LAST | LCASE | LEAST | LEFT | LENGTH
LFILL | LIST | LN | LOCATE | LOG
LOG10 | LONG | LONGFILE | LOWER | LPAD
LTRIM |  |  |  |
MAKEDATE | MAKETIME | MAPCHAR | MAX | MBCS
MICROSECOND | MIN | MINUTE | MOD | MONTH
MONTHNAME |  |  |  |
NATURAL | NCHAR | NEXT | NO | NOROUND
NOT | NOW | NULL | NUM | NUMERIC
OBJECT | OF | ON | ORDER |
PACKED | PI | POWER | PREV | PRIMARY
RADIANS | REAL | REJECT | RELATIVE | REPLACE
RFILL | RIGHT | ROUND | ROWID | ROWNO
RPAD | RTRIM |  |  |
SECOND | SELECT | SELUPD | SERIAL | SET
SHOW | SIGN | SIN | SINH | SMALLINT
SOME | SOUNDEX | SPACE | SQRT | STAMP
STATISTICS | STDDEV | SUBDATE | SUBSTR | SUBSTRING
SUBTIME | SUM | SYSDBA |  |
TABLE | TAN | TANH | TIME | TIMEDIFF
TIMESTAMP | TIMEZONE | TO | TOIDENTIFIER | TRANSACTION
TRANSLATE | TRIM | TRUNC | TRUNCATE |
UCASE | UID | UNICODE | UNION | UPDATE
UPPER | USER | USERGROUP | USING | UTCDATE
UTCDIFF |  |  |  |
VALUE | VALUES | VARCHAR | VARGRAPHIC | VARIANCE
WEEK | WEEKOFYEAR | WHEN | WHERE | WITH
YEAR |  |  |  |
ZONED |  |  |  |


result_column_name (MaxDB: Reference Manual)

result_column_name

< result_column_name > ::=
  < identifier >


result_table_name (MaxDB: Reference Manual)

result_table_name

< result_table_name > ::=
  < identifier >


revoke_statement (MaxDB: Reference Manual)

revoke_statement

< revoke_statement > ::=
  REVOKE < priv_spec >,... FROM < grantee >,... [< cascade_option >]
| REVOKE EXECUTE ON < dbproc_name > FROM <grantee>,...
| REVOKE SELECT ON < sequence_name > FROM <grantee>,... [<cascade_option>]


role_name (MaxDB: Reference Manual)

role_name

< role_name > ::=
  < identifier >


rollback_statement (MaxDB: Reference Manual)

rollback_statement

< rollback_statement > ::=
  ROLLBACK [WORK]


routine (MaxDB: Reference Manual)

routine

< routine > ::=
  [< local_variables >] < statement_list >;


routine_sql_statement (MaxDB: Reference Manual)

routine_sql_statement

<routine_sql_statement> ::=
  <call_statement>
| <close_statement>
| <create_table_temp>
| <declare_cursor_statement>
| <delete_statement>
| <fetch_statement>
| <insert_statement>
| <lock_statement>
| <named_select_statement>
| <select_statement>
| <single_select_statement>
| <subtrans_statement>
| <update_statement>


row_spec (MaxDB: Reference Manual)

row_spec

< row_spec > ::=
  ROW < table_name > KEY < key_spec >,...
| ROW <table_name> CURRENT OF < result_table_name >


rowno_column (MaxDB: Reference Manual)

rowno_column

< rowno_column > ::=
  ROWNO [< result_column_name >]
| <result_column_name> = ROWNO


rowno_predicate (MaxDB: Reference Manual)

rowno_predicate

< rowno_predicate > ::=
  ROWNO < < unsigned_integer >
| ROWNO < < parameter_spec >
| ROWNO <= < unsigned_integer >
| ROWNO <= < parameter_spec >


sample_definition (MaxDB: Reference Manual)

sample_definition

< sample_definition > ::=
  SAMPLE < unsigned_integer > ROWS
| SAMPLE <unsigned_integer> PERCENT


scalar_subquery (MaxDB: Reference Manual)

scalar_subquery

< scalar_subquery > ::=
  < subquery >


search_and_result_spec (MaxDB: Reference Manual)

search_and_result_spec

< search_and_result_spec > ::=
  <search_ expression >, <result_expression>


search_condition (MaxDB: Reference Manual)

search_condition

< search_condition > ::=
  < boolean_term >
| <search_condition> OR <boolean_term>


searched_case_function (MaxDB: Reference Manual)

searched_case_function

< searched_case_function > ::=
  WHEN < search_condition > THEN <result_ expression >
    [...]
  [ELSE <default_expression>]
END


searched_case_statement (MaxDB: Reference Manual)

searched_case_statement

< searched_case_statement > ::=
  CASE
    < searched_case_when_clause >…
    [< case_else_clause >]
  END [CASE]


searched_case_when_clause (MaxDB: Reference Manual)

searched_case_when_clause

< searched_case_when_clause > ::=
  WHEN < search_condition > THEN < statement >


seconds (MaxDB: Reference Manual)

seconds

< seconds > ::=
  < expression >


select_column (MaxDB: Reference Manual)

select_column

< select_column > ::=
  < table_columns >
| < derived_column >
| < rowno_column >
| < stamp_column >


select_statement (MaxDB: Reference Manual)

select_statement

< select_statement > ::=
  < query_expression > [< order_clause >] [< update_clause >] [< lock_option >]
    [FOR REUSE]


sequence_name (MaxDB: Reference Manual)

sequence_name

< sequence_name > ::=
  < identifier >


set_function_name (MaxDB: Reference Manual)

set_function_name

< set_function_name > ::=
  COUNT
| MAX
| MIN
| SUM
| AVG
| STDDEV
| VARIANCE


set_function_spec (MaxDB: Reference Manual)

set_function_spec

< set_function_spec > ::=
  COUNT (*)
| < distinct_function >
| < all_function >


set_insert_clause (MaxDB: Reference Manual)

set_insert_clause

< set_insert_clause > ::=
  < column_name > = < extended_value_spec >


set_statement (MaxDB: Reference Manual)

set_statement

< set_statement > ::=
  SET ROLE ALL [EXCEPT < role_name >]
| SET ROLE NONE
| SET ROLE <role_name> [IDENTIFIED BY < password >]
| SET ISOLATION LEVEL < unsigned_integer >


set_update_clause (MaxDB: Reference Manual)

set_update_clause

< set_update_clause > ::=
  < column_name > = < extended_expression >
| <column_name>,... = (<extended_expression>,...)
| (<column_name>,...) = (<extended_expression>,...)
| <column_name> = < subquery >
| (<column_name>,...) = <subquery>


sign (MaxDB: Reference Manual)

sign

< sign > ::=
  +
| -


simple_case_function (MaxDB: Reference Manual)

simple_case_function

<simple_case_function> ::=
  CASE <check_expression>
    WHEN <search_expression> THEN <result_expression>
      [...]
    [ELSE <default_expression>]
  END


simple_case_statement (MaxDB: Reference Manual)

simple_case_statement

< simple_case_statement > ::=
  CASE < expression >
    < simple_case_when_clause >...
    [< case_else_clause >]
  END [CASE]


simple_case_when_clause (MaxDB: Reference Manual)

simple_case_when_clause

< simple_case_when_clause > ::=
  WHEN < literal >[, ...] THEN < statement >


simple_identifier (MaxDB: Reference Manual)

simple_identifier

< simple_identifier > ::=
  < first_character >[< identifier_tail_character >...]


single_select_statement (MaxDB: Reference Manual)

single_select_statement

< single_select_statement > ::=
  SELECT [< distinct_spec >] < select_column >,... INTO < parameter_spec >,...
    FROM < from_table_spec >,...[< where_clause >] [< group_clause >]
    [< having_clause >] [< lock_option >]


sort_spec (MaxDB: Reference Manual)

sort_spec

< sort_spec > ::=
  < unsigned_integer > [ASC | DESC]
| < expression > [ASC | DESC]


sound_predicate (MaxDB: Reference Manual)

sound_predicate

< sound_predicate > ::=
  < expression > [NOT] SOUNDS [LIKE] <expression>


source_user (MaxDB: Reference Manual)

source_user

< source_user > ::=
  < user_name >


special_character (MaxDB: Reference Manual)

special_character

< special_character > ::=
  every character except
    < digit >
  | < letter >
  | < extended_letter >
  | < hex_digit >
  | < language_specific_character >
  | <character for the end of a line in a file>


special_function (MaxDB: Reference Manual)

special_function

< special_function > ::=
  VALUE (< expression >,<expression>,...)
| GREATEST (<expression>,<expression>,...)
| LEAST (<expression>,<expression>,...)
| DECODE (<check_ expression >,< search_and_result_spec >,...[,<default_expression>])
| case_function


special_identifier (MaxDB: Reference Manual)

special_identifier

< special_identifier > ::=
  < special_identifier_character >...


special_identifier_character (MaxDB: Reference Manual)

special_identifier_character

< special_identifier_character > ::=
  any character.


sql_comment (MaxDB: Reference Manual)

sql_comment

< sql_comment > ::=
  /*<comment text>*/
| --<comment text>


stamp_column (MaxDB: Reference Manual)

stamp_column

< stamp_column > ::=
  STAMP [< result_column_name >]
| <result_column_name> = STAMP


statement (MaxDB: Reference Manual)

statement

<statement> ::=
BEGIN <statement_list> END
| BREAK
| CONTINUE
| CONTINUE EXECUTE
| <if_statement>
| <while_statement>
| <assignment_statement>
| <case_statement>
| <RETURN> [<expression>]
| STOP (<expression> [,<expression>] )
| TRY <statement_list>; CATCH <statement>
| <routine_sql_statement>


statement_list (MaxDB: Reference Manual)

statement_list

< statement_list > ::=
  < statement >
| <statement_list> ; <statement>


string_function (MaxDB: Reference Manual)

string_function

< string_function> ::=
  < string_spec> || <string_spec>
| <string_spec> & <string_spec>
| SUBSTR (<string_spec>,< expression>[,<expression>])
| LFILL (<string_spec>,< string_literal>[,< unsigned_integer>])
| RFILL (<string_spec>,<string_literal>[,<unsigned_integer>])
| LPAD (<string_spec>,<expression>,<string_literal>[,<unsigned_integer>])
| RPAD (<string_spec>,<expression>,<string_literal>[,<unsigned_integer>])
| TRIM (<string_spec>[,<string_spec>])
| LTRIM (<string_spec>[,<string_spec>])
| RTRIM (<string_spec>[,<string_spec>])
| EXPAND (<string_spec>,<unsigned_integer>)
| UPPER (<string_spec>)
| LOWER (<string_spec>)
| INITCAP (<string_spec>)
| REPLACE (<string_spec>,<string_spec>[,<string_spec>])
| TRANSLATE (<string_spec>,<string_spec>,<string_spec>)
| MAPCHAR (<string_spec>[,<unsigned_integer>][,< mapchar_set_name>])
| ALPHA (<string_spec>[,<unsigned_integer>])
| ASCII (<string_spec>)
| SOUNDEX (<string_spec>)
| GET_OBJECTNAME (<string_literal)
| GET_OWNER (<string_literal>)


string_literal (MaxDB: Reference Manual)

string_literal

< string_literal > ::=
  ''
| '< character >...'
| < hex_literal >


string_spec (MaxDB: Reference Manual)

string_spec

< string_spec > ::=
  < expression >


subquery (MaxDB: Reference Manual)

subquery

< subquery > ::=
  (< query_expression >)


subtrans_statement (MaxDB: Reference Manual)

subtrans_statement

< subtrans_statement > ::=
  SUBTRANS BEGIN
| SUBTRANS END
| SUBTRANS ROLLBACK


synonym_name (MaxDB: Reference Manual)

synonym_name

< synonym_name > ::=
  < identifier >


table_columns (MaxDB: Reference Manual)

table_columns

< table_columns > ::=
  *
| < table_name >.*
| < reference_name >.*


table_description_element (MaxDB: Reference Manual)

table_description_element

< table_description_element > ::=
  < column_definition >
| < constraint_definition >
| < referential_constraint_definition >
| < key_definition >
| < unique_definition >


table_expression (MaxDB: Reference Manual)

table_expression

< table_expression > ::=
  < from_clause > [< where_clause >] [< group_clause >] [< having_clause >]


table_name (MaxDB: Reference Manual)

table_name

< table_name > ::=
  [< owner >.]< identifier >


term (MaxDB: Reference Manual)

term

< term > ::=
  < factor >
| <term> * <factor>
| <term> / <factor>
| <term> DIV <factor>
| <term> MOD <factor>


time_expression (MaxDB: Reference Manual)

time_expression

< time_expression > ::=
  < expression >


time_or_timestamp_expression (MaxDB: Reference Manual)

time_or_timestamp_expression

< time_or_timestamp_expresion > ::=
  < expression >


time_function (MaxDB: Reference Manual)

time_function

< time_function > ::=
  ADDTIME ( < time_or_timestamp_expression >, < time_expression > )
| SUBTIME ( <time_or_timestamp_expression>, <time_expression> )
| TIMEDIFF ( <time_or_timestamp_expression>, <time_or_timestamp_expression> )
| MAKETIME ( < hours >, < minutes >, < seconds > )


trigger_event (MaxDB: Reference Manual)

trigger_event

< trigger_event > ::
  INSERT
| UPDATE [(< column_list >)]
| DELETE


trigger_name (MaxDB: Reference Manual)

trigger_name

< trigger_name > ::=
  < identifier >


trigonometric_function (MaxDB: Reference Manual)

trigonometric_function

< trigonometric_function > ::=
  COS ( < expression > )
| SIN ( <expression> )
| TAN ( <expression> )
| COT ( <expression> )
| COSH ( <expression> )
| SINH ( <expression> )
| TANH ( <expression> )
| ACOS ( <expression> )
| ASIN ( <expression> )
| ATAN ( <expression> )
| ATAN2 ( <expression>, <expression> )
| RADIANS ( <expression> )
| DEGREES ( <expression> )


underscore (MaxDB: Reference Manual)

underscore

< underscore > ::=
  _


unique_definition (MaxDB: Reference Manual)

unique_definition

< unique_definition > ::=
  [CONSTRAINT < index_name >] UNIQUE (< column_name >,...)


unlock_statement (MaxDB: Reference Manual)

unlock_statement

< unlock_statement > ::=
  UNLOCK < row_spec >... IN SHARE MODE
| UNLOCK <row_spec>... IN EXCLUSIVE MODE
| UNLOCK <row_spec>... IN SHARE MODE <row_spec>... IN EXCLUSIVE MODE
| UNLOCK <row_spec>... OPTIMISTIC


unsigned_integer (MaxDB: Reference Manual)

unsigned_integer

< unsigned_integer > ::=
  < numeric_literal >


update_clause (MaxDB: Reference Manual)

update_clause

<update_clause> ::=
  FOR UPDATE [OF <column_name>,...] [NOWAIT]


update_statement (MaxDB: Reference Manual)

update_statement

< update_statement > ::=
  UPDATE [OF] < table_name > [< reference_name >] SET < set_update_clause >,...
    [KEY < key_spec >,...] [WHERE < search_condition >]
| UPDATE [OF] <table_name> [<reference_name>] (< column_name >,...)
    VALUES (< extended_value_spec >,...) [KEY <key_spec>,...]
    [WHERE <search_condition>]
| UPDATE [OF] <table_name> [<reference_name>] SET <set_update_clause>,...
    WHERE CURRENT OF < result_table_name >
| UPDATE [OF] <table_name> [<reference_name>] (<column_name>,...)
    VALUES (<extended_value_spec>,...) WHERE CURRENT OF <result_table_name>


update_statistics_statement (MaxDB: Reference Manual)

update_statistics_statement

< update_statistics_statement > ::=
  UPDATE STAT[ISTICS] COLUMN < table_name >.< column_name >
    [ESTIMATE [< sample_definition >]]
| UPDATE STAT[ISTICS] COLUMN (<column_name>,...) FOR <table_name>
    [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] COLUMN (*) FOR <table_name>
    [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] <table_name> [ESTIMATE [<sample_definition>]]
| UPDATE STAT[ISTICS] [< owner >.][< identifier >]* [ESTIMATE [<sample_definition>]]


user_mode (MaxDB: Reference Manual)

user_mode

< user_mode > ::=
  DBA
| RESOURCE
| STANDARD


user_name (MaxDB: Reference Manual)

user_name

< user_name > ::=
  < identifier >


usergroup_mode (MaxDB: Reference Manual)

usergroup_mode

< usergroup_mode > ::=
  RESOURCE
| STANDARD


usergroup_name (MaxDB: Reference Manual)

usergroup_name

< usergroup_name > ::=
  < identifier >


value_spec (MaxDB: Reference Manual)

value_spec

<value_spec> ::=
  <literal>
| <parameter_spec>
| NULL
| USER
| USERGROUP
| SYSDBA
| UID
| [<owner>.]<sequence_name>.NEXTVAL
| [<owner>.]<sequence_name>.CURRVAL
| <table_name>.CURRVAL
| DATE
| TIME
| TIMESTAMP
| UTCDATE
| TIMEZONE
| UTCDIFF
| TRUE
| FALSE
| TRANSACTION


variable_name (MaxDB: Reference Manual)

variable_name

< variable_name > ::=
  < identifier >


where_clause (MaxDB: Reference Manual)

where_clause

< where_clause > ::=
  WHERE < search_condition >


while_statement (MaxDB: Reference Manual)

while_statement

< while_statement > ::=
  WHILE < search_condition > DO < statement >


Syntax Notation (MaxDB: Reference Manual)

Syntax Notation

This documentation uses the BNF syntax notation with the following conventions:

 | Explanation
KEYWORDS | Keywords are shown in uppercase letters for the sake of clarity. They can be entered in uppercase or lowercase letters.
<xyz> | Terms in angle brackets are placeholders for syntactical units explained in this document. Do not use angle brackets when entering an SQL statement.
clause ::= rule | Clauses are the building blocks of SQL statements. Rules describe how these building blocks are put together to form more complex clauses and also dictate the notation that is used.
clause1 clause2 | The two clauses are written one after the other, separated by at least one blank.
[clause] | Optional clause. This clause can be ignored. Do not use square brackets when entering an SQL statement.
Clause1 | clause2 | ... | clausen | Alternative clauses. You can use exactly one of these clauses.
Clause,... | The clause can be repeated as often as required. The individual repetitions must be written one after the other and separated by a comma and any number of blanks.
Clause... | The clause can be repeated as often as required. The individual repetitions must be written directly one after the other without a separating comma or blank.


System Tables (MaxDB: Reference Manual)

System Tables

The database system contains a series of system tables that contain information about the database objects and their connection to each other, statistics system tables, and monitor system tables.

The following examples show you how to evaluate the system tables.

· When you specify SELECT statements for the system tables, you have to bear in mind some general information.

· If you want to find out which system table contains information for a particular database term, consult the list of database terms.

· If you want to find out which information a particular system table can provide, see the section Evaluating System Tables.

For a complete definition of the most important system tables, see Definition of the System Tables.

For general information on the database system, see the documentation Database Administration.


General Information (MaxDB: Reference Manual)

General Information

If you want to evaluate system tables, note the following information:

· When system tables are evaluated, the system only outputs information for objects of which the current user is the owner, or for which the user has at least a privilege (the user therefore knows the object). This authorization concept may mean that the table definition visible for the current user differs from the actual definition.
The definition of a view table is only visible for the owner of the view table.

· When you query the system table(s), you should enter conditions that describe the required object as precisely as possible. Entering the object owner considerably speeds up the search for the relevant information.

· When you specify search commands, you should specify equivalence conditions where possible. Specifying LIKE conditions is less effective.

· For performance reasons, when you query information from system tables, you should use not only the SQL statement SELECT * but also limit the number of output columns to those columns that you actually require.
When you query statistical information from system tables, in particular, additional actions are performed to determine column values in the database system when certain output columns are requested. As a result, you should only have the system determine this column information if you really need it.

· Simple identifiers are always created in the database instance in capital letters, regardless of how they were entered during definition of the data.
If you use simple identifiers in a search condition, you must enter the single quotes typically used when specifying literals.
For performance reasons, you should not leave the conversion of the simple identifier to capital letters to the database system at the execution of the SQL statement; you should enter the simple identifier directly in capital letters in the search condition.

CREATE TABLE mytab (…)
SELECT … FROM … WHERE … = 'MYTAB'

· Special identifiers are always specified in double quotes in the data definition. In the database instance, these are stored as they were entered, meaning they are not converted to capital letters.
If you use special identifiers in a search condition, you must enter the single quotes typical for specifying literals.

CREATE TABLE "this is mytab" (…)
SELECT … FROM … WHERE … = 'this is mytab'


Database Terms (MaxDB: Reference Manual)

Database Terms

To determine information about your database system, its objects, structures, status information, and so on, you have to evaluate the relevant system tables.

A list of database terms and references to the system tables that can provide the information on the terms is provided below. The terms are listed in alphabetical order.


A-C (MaxDB: Reference Manual)

A-C

Database terms from A-C

 | Term | Explanation | System table
C | char set (character set) | MapChar set | MAPCHARSETS
 | column | definition domain for definition default value inverted primary key privilege in referential constraint of a table in view definition | COLUMNS COLUMNS COLUMNS INDEXCOLUMNS COLUMNS COLUMNS FOREIGNKEYCOLUMNS VIEWCOLUMNS
 | constraint | of a column or table of a domain referential NOT-NULL columns primary key UNIQUE |


D-H (MaxDB: Reference Manual)

D-H

Database terms from D-H

 | Term | Explanation | System table
D | database instance | in the current database session | USERS
 | database procedure | database procedure parameter | DBPROCEDURES DBPROCPARAMS
 | database session | own all active active roles in the current database session | CONNECTPARAMETERS CONNECTEDUSERS SESSION_ROLES
 | default | of a column of a domain default role | COLUMNS DOMAINS ROLES
 | domain | domain constraint of a domain during column definition | DOMAINS DOMAINCONSTRAINTS COLUMNS
F | foreign key (referential constraint) | referential constraint columns in the referential constraint |


I-R (MaxDB: Reference Manual)

I-R

Database terms from I-R

 | Term | Explanation | System table
I | identification | internal identification of a table internal identification of a user | TABLES USERS
 | index | indexes column UNIQUE | INDEXES INDEXCOLUMNS INDEXES
 | isolation level | of the current database session | CONNECTPARAMETERS
K | key | primary key secondary key foreign key (referential constraint) | COLUMNS FOREIGNKEYCOLUMNS FOREIGNKEYS
L | lock | currently held | LOCKS
M | MapChar set | MapChar set | MAPCHARSETS
O | Operating System | on which the current database instance instance is running | VERSIONS
P | parameter | of a database procedure | DBPROCPARAMS
 | privilege | of a role of a column of a table | ROLEPRIVILEGES COLUMNS TABLES TABLEPRIVILEGES
R | referential constraint | referential constraint columns | FOREIGNKEYS FOREIGNKEYCOLUMNS
 | release (version) | of the database software | VERSIONS
 | result table | existence | TABLES
 | role | role, default role role privilege active roles in the current database session |


S (MaxDB: Reference Manual)

S

Database terms

Term | Explanation | System table
sequence | current value | SEQUENCES
server node | server node used in the current database session | USERS
session (database session) | own all active active roles in the current database session | CONNECTPARAMETERS CONNECTEDUSERS SESSION_ROLES
SQL mode | of the current database session | CONNECTPARAMETERS
statistics | time of last update-statistics run for a table sample values of the update-statistics run of a table | TABLES
synonym | synonyms existence |


T (MaxDB: Reference Manual)

T

Database terms

Term | Explanation | System table
table | tables, existence table definition synonym privilege in view definition constraint referential constraint index view table primary key secondary key trigger | TABLES COLUMNS SYNONYMS TABLES , TABLEPRIVILEGES VIEWCOLUMNS CONSTRAINTS FOREIGNKEYS INDEXES VIEWS COLUMNS FOREIGNKEYCOLUMNS TRIGGERS
timeout | of the current database session | CONNECTPARAMETERS
trigger | trigger | TRIGGERS


U-Z (MaxDB: Reference Manual)

U-Z

Database terms from U-Z

 | Term | Explanation | System table
U | UNIQUE | index | INDEXES
 | user | defined currently active | USERS CONNECTEDUSERS
V | version | of the database software | VERSIONS
 | view table | view tables definition text existence synonym underlying tables and columns |


Evaluating System Tables (MaxDB: Reference Manual)

Evaluating System Tables

The following sections contain examples of how to evaluate information in the system tables:

COLUMNS

CONNECTEDUSERS

CONNECTPARAMETERS

CONSTRAINTS

DBPROCEDURES

DBPROCPARAMS

DOMAINCONSTRAINTS

DOMAINS

FOREIGNKEYCOLUMNS

FOREIGNKEYS

INDEXCOLUMNS

INDEXES

LOCKS

MAPCHARSETS

ROLEPRIVILEGES

ROLES

SEQUENCES

SESSION_ROLES

SYNONYMS

TABLEPRIVILEGES

TABLES

TRIGGERS

USERS

VERSIONS

VIEWCOLUMNS

VIEWDEFS

VIEWS


COLUMNS (MaxDB: Reference Manual)

COLUMNS

Using the system table COLUMNS, you can determine the following database information, among other things:

· Columns of table RESERVATION in the sequence in which they were defined, together with the relevant comments
SELECT columnname, comment
  FROM DOMAIN.COLUMNS
    WHERE tablename = 'RESERVATION' ORDER BY pos

· Data types of all columns of table CUSTOMER
SELECT columnname, datatype, len, dec, codetype
  FROM DOMAIN.COLUMNS
    WHERE tablename = 'CUSTOMER'

· All columns of your own Basis tables that have the data type DATE
SELECT tablename,columnname
  FROM DOMAIN.COLUMNS
    WHERE owner = user
      AND tabletype = 'TABLE'
      AND datatype = 'DATE'

· All columns of your own table HOTEL for which a default value was defined, plus this default value
SELECT columnname, default
  FROM DOMAIN.COLUMNS
    WHERE owner = user
      AND tablename = 'HOTEL'
      AND default IS NOT NULL

· All primary table columns of table ROOM, sorted according to their sequence in the primary key
SELECT columnname
  FROM DOMAIN.COLUMNS
    WHERE tablename = 'ROOM' AND mode = 'KEY' ORDER BY keypos

· All columns defined with NOT NULL of table CUSTOMER
SELECT columnname
  FROM DOMAIN.COLUMNS
    WHERE tablename = 'CUSTOMER' AND mode = 'MAN'

· All columns of table RESERVATION that can be changed by the current user
SELECT columnname
  FROM DOMAIN.COLUMNS
    WHERE tablename = 'RESERVATION' AND columnprivileges LIKE '*UPD*'

· All columns of table RESERVATION that can be changed by the current user and for which the user can pass on this privilege
SELECT columnname
  FROM DOMAIN.COLUMNS
    WHERE tablename = 'RESERVATION' AND columnprivileges LIKE '*UPD+*'

· All table columns that were specified as MYDOMAIN during definition of the domain
SELECT owner, tablename, columnname
  FROM DOMAIN.COLUMNS
    WHERE domainname = 'MYDOMAIN'

Columns in the index: see INDEXCOLUMNS

Columns in the referential constraint: see FOREIGNKEYCOLUMNS

Primary table or view table columns in the view table: see VIEWCOLUMNS


CONNECTEDUSERS (MaxDB: Reference Manual)

CONNECTEDUSERS

Using the system table CONNECTEDUSERS, you can determine the following database information, among other things:

· All currently logged-on users and the terminal used by the user in question
SELECT username, termid
  FROM DOMAIN.CONNECTEDUSERS

· Name of the terminal that the user logged on to
SELECT termid
  FROM DOMAIN.CONNECTEDUSERS cu, DOMAIN.CONNECTPARAMETERS cp
    WHERE cu.session = cp.session

All defined users: see USERS


CONNECTPARAMETERS (MaxDB: Reference Manual)

CONNECTPARAMETERS

Using the system table CONNECTPARAMETERS, you can determine the following database information, among other things:

Parameters of your own database session
SELECT sqlmode, isolevel, timeout, session
  FROM DOMAIN.CONNECTPARAMETERS


CONSTRAINTS (MaxDB: Reference Manual)

CONSTRAINTS

Using the system table CONSTRAINTS, you can determine the following database information, among other things:

All conditions of the columns of table CUSTOMER that represent explicit value checks
SELECT definition
  FROM DOMAIN.CONSTRAINTS
    WHERE tablename = 'CUSTOMER'

Constraints (integrity conditions) that relate to NOT NULL definitions, primary keys, UNIQUE definitions or referential constrains are not found with this SELECT statement.

NOT-NULL columns: see COLUMNS

Primary keys: see COLUMNS

UNIQUE columns: see INDEXES

Referential constraint: see FOREIGNKEYS

Columns in a referential constraint: see FOREIGNKEYCOLUMNS

Constraint of a domain: see DOMAINCONSTRAINTS


DBPROCEDURES (MaxDB: Reference Manual)

DBPROCEDURES

Using the system table DBPROCEDURES, you can determine the following database information, among other things:

All database procedures and their comments generated in the last 10 days
SELECT owner, dbprocname, comment
  FROM DOMAIN.DBPROCEDURES
    WHERE createdate >= subdate(date,10)

Parameters of a database procedure: see DBPROCPARAMS


DBPROCPARAMS (MaxDB: Reference Manual)

DBPROCPARAMS

Using the system table DBPROCPARAMS, you can determine the following database information, among other things:

· All input parameters of your own database procedure MYPROC and the following parameter information: data type, length and specification of which number in the sequence the parameter has within the database procedure
SELECT parametername, datatype, len, dec, pos
  FROM DOMAIN.DBPROCPARAMS
    WHERE owner = user
      AND dbprocname = 'MYPROC'
      AND "IN/OUT-TYPE" = 'IN'

· Total number of parameters in your own database procedure MYPROC
SELECT COUNT(*)
  FROM DOMAIN.DBPROCPARAMS
    WHERE owner = user
      AND dbprocname = 'MYPROC'

Database procedures: see DBPROCEDURES


DOMAINCONSTRAINTS (MaxDB: Reference Manual)

DOMAINCONSTRAINTS

Using the system table DOMAINCONSTRAINTS, you can determine the following database information, among other things:

All domains for which a restriction of the permitted values was defined, and this definition
SELECT domainname, definition
  FROM DOMAIN.DOMAINCONSTRAINTS

All domains: see DOMAINS


DOMAINS (MaxDB: Reference Manual)

DOMAINS

Using the system table DOMAINS, you can determine the following database information, among other things:

· All domains and their comments defined for data type DATE
SELECT owner, domainname, comment
  FROM DOMAIN.DOMAINS
    datatype = 'DATE'

· All your own domains in which a default value was agreed
SELECT domainname, datatype, len, dec, default
  FROM DOMAIN.DOMAINS
    WHERE owner = user
      AND default IS NOT NULL

Constraint of a domain: see DOMAINCONSTRAINTS

Domain for column definition: see COLUMNS


FOREIGNKEYCOLUMNS (MaxDB: Reference Manual)

FOREIGNKEYCOLUMNS

Using the system table FOREIGNKEYCOLUMNS, you can determine the following database information, among other things:

· All referential constraints in which the column CNO of table CUSTOMER is the referenced column
SELECT owner, tablename, columnname, fkeyname, rule
  FROM DOMAIN.FOREIGNKEYCOLUMNS
    WHERE reftablename = 'CUSTOMER'
      AND refcolumnname = 'CNO'

· All referential constraints in which the column HNO of table RESERVATION is the referencing column
SELECT fkeyname, rule
  FROM DOMAIN.FOREIGNKEYCOLUMNS
    WHERE tablename = 'RESERVATION'
      AND columnname = 'HNO'

· All referential constraints in which the referencing columns come from table RESERVATION
SELECT DISTINCT fkeyname, rule, refowner, reftablename
  FROM DOMAIN.FOREIGNKEYCOLUMNS
    WHERE tablename = 'RESERVATION'

All referential constraints: see FOREIGNKEYS


FOREIGNKEYS (MaxDB: Reference Manual)

FOREIGNKEYS

Using the system table FOREIGNKEYS, you can determine the following database information, among other things:

All referential constraints in which table CUSTOMER is the referenced table
SELECT columnname, fkeyname, rule
  FROM DOMAIN.FOREIGNKEYS
    WHERE tablename = 'CUSTOMER'

Columns in referential constraints: see FOREIGNKEYCOLUMNS


INDEXCOLUMNS (MaxDB: Reference Manual)

INDEXCOLUMNS

Using the system table INDEXCOLUMNS, you can determine the following database information, among other things:

· All inverted columns (those assigned an index) of table HOTEL
SELECT DISTINCT columnname
  FROM DOMAIN.INDEXCOLUMNS
    WHERE tablename = 'HOTEL'

· All inversions for table RESERVATION, sorted by index, and then by the column sequence specified during index definition
SELECT indexname, type, columnname, sort
  FROM DOMAIN.INDEXCOLUMNS
    WHERE tablename = 'RESERVATION' ORDER BY indexname, columnno

· Information about the columns that make up the index MYINDEX of your own table MYTABLE
SELECT columnname, sort, datatype, len
  FROM DOMAIN.INDEXCOLUMNS
    WHERE tablename = 'MYTAB'
      AND indexname ='MYINDEX' ORDER BY columnno

All indexes: see INDEXES


INDEXES (MaxDB: Reference Manual)

INDEXES

Using the system table INDEXES, you can determine the following database information, among other things:

· All indexes of the table ROOM and specification of which of the indexes currently has the status disabled
SELECT indexname, disabled
  FROM DOMAIN.INDEXES
    WHERE tablename = 'ROOM'

· All UNIQUE indexes (regardless of which of the possible SQL statements was used to generate these indexes: CREATE INDEX statement or UNIQUE definition)
SELECT owner, tablename, indexname
  FROM DOMAIN.INDEXES
    WHERE type = 'UNIQUE'

Columns of an index: see INDEXCOLUMNS


LOCKS (MaxDB: Reference Manual)

LOCKS

Using the system table LOCKS, you can determine the following database information, among other things:

· All locks that are currently held on the table ROOM
SELECT lockmode, lockstate, rowidlength, rowidhex, rowid
  FROM DOMAIN.LOCKS
    WHERE tablename = 'ROOM'

· All locks that the current user is holding in the database session on table ROOM
SELECT lockmode, lockstate, rowidlength, rowidhex, rowid
  FROM DOMAIN.LOCKS l DOMAIN.CONNECTPARAMETERS cp
    WHERE tablename = 'ROOM'
      AND l.session = cp.session

· All locks that are currently being held on the table with the hexadecimal internal identification 0000000000D34BA8
SELECT lockmode, lockstate, rowidlength, rowidhex, rowid
  FROM DOMAIN.LOCKS
    WHERE tableid = X'0000000000D34BA8'

If the current user is the database administrator (DBA-Benutzer) or the database system administrator (SYSDBA user), then all currently held locks are shown.

Users that belong to other user class only see the locks held by that one user.


MAPCHARSETS (MaxDB: Reference Manual)

MAPCHARSETS

Using the system table MAPCHARSETS, you can determine the following database information, among other things:

· Name of all MapChar sets
SELECT DISTINCT mapcharsetname
  FROM DOMAIN.MAPCHARSETS

· Conversion of hexadecimal value D6 in MapChar set DEFAULTMAP
SELECT map_code, map_character
  FROM DOMAIN.MAPCHARSETS
    WHERE mapcharsetname = 'DEFAULTMAP'
      AND intern = X'D6'


ROLEPRIVILEGES (MaxDB: Reference Manual)

ROLEPRIVILEGES

Using the system table ROLEPRIVILEGES, you can determine the following database information, among other things:

· All privileges that have been given to role NEW_ROLE directly for your own table MYTABLE. Privileges granted indirectly, that is, granted for table MYTABLE via a different role, are not displayed.
SELECT privileges
  FROM DOMAIN.ROLEPRIVILEGES
    WHERE grantee = 'NEW_ROLE'
      AND owner = user
      AND tablename = 'MYTABLE'

· All roles that were granted to role NEW_ROLE. Specification of who granted the role.
SELECT role, grantor
  FROM DOMAIN.ROLEPRIVILEGES
    WHERE grantee = 'NEW_ROLE'
      AND role IS NOT NULL

All roles: see ROLES

All roles that are used as a default value: see ROLES

All roles that are active in the current database session: see SESSION_ROLES


ROLES (MaxDB: Reference Manual)

ROLES

Using the system table ROLES, you can determine the following database information, among other things:

· All roles that require a password to be specified before they can be activated
SELECT owner, role
  FROM DOMAIN.ROLES
    WHERE password_required = 'YES'

· All roles that the current user uses as a default value
SELECT role
  FROM DOMAIN.ROLES
    WHERE defaultrole = 'YES'

All roles that are active in the current database session: see SESSION_ROLES

Role privilege: see ROLEPRIVILEGES


SEQUENCES (MaxDB: Reference Manual)

SEQUENCES

Using the system table SEQUENCES, you can determine the following database information, among other things:

· All sequences with an incremental value that is not +1 and the value limits of the sequences
SELECT owner, sequence_name, increment_by, min_value, max_value
  FROM DOMAIN.SEQUENCES
    WHERE increment_by <> 1

· All sequences with a positive incremental value. The values are not assigned cyclically, and there are, at most, only 1000 free values remaining.
SELECT owner, sequence_name, last_number, max_value
  FROM DOMAIN.SEQUENCES
    WHERE increment_by > 0
      AND cycle_flag = 'N'
      AND max_value - last_number <= 1000

· Current value of your own sequence MYSEQ
SELECT last_number
  FROM DOMAIN.SEQUENCES
    WHERE owner = user
      AND sequence_name = 'MYSEQ'

· Last value assigned by the current database session to the own sequence MYSEQ
SELECT user.myseq.currval
FROM DUAL


SESSION_ROLES (MaxDB: Reference Manual)

SESSION_ROLES

Using the system table SESSION_ROLES, you can determine the following database information, among other things:

All roles that are active in the current database session
SELECT role
FROM DOMAIN.SESSION_ROLES

All roles: see ROLES

All roles that are used as a default value: see ROLES

Role privilege: see ROLEPRIVILEGES


SYNONYMS (MaxDB: Reference Manual)

SYNONYMS

Using the system table SYNONYMS, you can determine the following database information, among other things:

· All tables (Basis tables, view tables) for which the PUBLIC synonym SHORT-TAB was defined
SELECT tableowner, tablename
  FROM DOMAIN.SYNONYMS
    WHERE public = 'YES'
      AND synonymname = 'SHORT_TAB'

· Private synonym for table HIS_TAB of user USER2
SELECT synonymname
  FROM DOMAIN.SYNONYMS
    WHERE owner = user
      AND tableowner = 'USER2'
      AND tablename = 'HIS_TAB'

Existence of a synonym: see TABLES


TABLEPRIVILEGES (MaxDB: Reference Manual)

TABLEPRIVILEGES

Using the system table TABLEPRIVILEGES, you can determine the following database information, among other things:

· All tables for which the current user has been given a privilege. Own tables are not output.
SELECT owner, tablename, privileges
  FROM DOMAIN.TABLEPRIVILEGES
    WHERE grantee = user

· All tables for which the current user has been given the SELECT privilege and is allowed to pass this on. Own tables are not output.
SELECT owner, tablename
  FROM DOMAIN.TABLEPRIVILEGES
    WHERE grantee = user
      AND privileges LIKE '*SEL*'
      AND is_grantable = 'YES'

· All privileges that the current user has passed on to user USER2
SELECT owner, tablename, privileges
  FROM DOMAIN.TABLEPRIVILEGES
    WHERE grantor = user
      AND grantee = 'USER2'

All tables: see TABLES

Existence of a table: see TABLES

Table definition: see COLUMNS

Synonym for a table: see SYNONYMS

Table privilege: see TABLES

Table in a view definition: see VIEWCOLUMNS


TABLES (MaxDB: Reference Manual)

TABLES

Using the system table TABLES, you can determine the following database information, among other things:

· All tables, view tables and synonyms for which the current user can execute SELECT statements
SELECT owner, tablename
  FROM DOMAIN.TABLES
    WHERE privileges LIKE '*SEL*'

· All result tables of the current user
SELECT tablename
  FROM DOMAIN.TABLES
    WHERE type = 'RESULT'

· All the user’s own tables for which the last update statistics run is more than 30 days in the past
SELECT tablename, updstatdate
  FROM DOMAIN.TABLES
    WHERE updstatdate <= subdate (DATE,30)

· Information on which sample values are used to carry out an update statistics run on table CUSTOMER
SELECT sample_percent, sample_rows
  FROM DOMAIN.TABLES
    WHERE tablename = 'CUSTOMER'

· Internal identification of table HOTEL
SELECT tableid
  FROM DOMAIN.TABLES
    WHERE tablename = 'HOTEL'
If this relates to a Basis table, the internal identification of a table can be used, for example, during the lock query (see LOCKS).

Table definition: see COLUMNS

Primary key: COLUMNS

Synonym for a table: see SYNONYMS

Table privilege: see TABLEPRIVILEGES

Table in a view definition: see VIEWCOLUMNS

Constraint of a column or table: see CONSTRAINTS

Referential constraint: see FOREIGNKEYS

Index: see INDEXES

View table: VIEWS

Secondary key: see FOREIGNKEYCOLUMNS

Trigger: see TRIGGERS


TRIGGERS (MaxDB: Reference Manual)

TRIGGERS

Using the system table TRIGGERS, you can determine the following database information, among other things:

· Insert trigger for the table HOTEL
SELECT triggername, definition
  FROM DOMAIN.TRIGGERS
    WHERE tablename = 'HOTEL'
      AND INSERT = 'YES'

· Table and action for which the trigger MYTRIGGER was defined
SELECT owner, triggername, insert, update, delete
  FROM DOMAIN.TRIGGERS
    WHERE triggername = 'MYTRIGGER'


USERS (MaxDB: Reference Manual)

USERS

Using the system table USERS, you can determine the following database information, among other things:

· All defined STANDARD users
SELECT username, groupname
  FROM DOMAIN.USERS
    WHERE usermode = 'STANDARD'

· All users who have not changed their password for over six months
SELECT username, pwcreatedate, pwcreatetime
  FROM DOMAIN.USERS
    WHERE pwcreatedate <= subdate (date,183)

· All users who are members of a user group and are allowed to log on to the database instance several times simultaneously
SELECT groupname, username, usermode
  FROMDOMAIN.USERS
    WHERE groupname <> username
      AND connectmode = 'MULTIPLE'

· Name of the database instance on which the current database session was opened. Name of the server on which this database instance is running.
SELECT DISTINCT serverdb, servernode
  FROM DOMAIN.USERS

Currently active user: see CONNECTEDUSERES


VERSIONS (MaxDB: Reference Manual)

VERSIONS

Using the system table VERSIONS, you can determine the following database information, among other things:

Version of the software with which the current database instance is running, and the operating system that the instance is running on
SELECT *
  FROM DOMAIN.VERSIONS


VIEWCOLUMNS (MaxDB: Reference Manual)

VIEWCOLUMNS

Using the system table VIEWCOLUMNS, you can determine the following database information, among other things:

· All tables or view tables that form the basis for your own view table MYVIEW
SELECT tableowner, tablename
  FROM DOMAIN.VIEWCOLUMNS
    WHERE owner = user
      AND viewname = 'MYVIEW'

· Column of the table or view table that forms the basis for column V_COL of your own view table
SELECT tableowner, tablename, columnname
  FROM DOMAIN.VIEWCOLUMNS
    WHERE owner = user
      AND viewname = 'MYVIEW'
      AND viewcolumnname = 'V_COL'

· Determine whether the column TITLE of table CUSTOMER forms the basis of a view table
SELECT owner, viewname, viewcolumnname
  FROM DOMAIN.VIEWCOLUMNS
    WHERE tablename = 'CUSTOMER'
      AND columnname = 'TITLE'

All views: see VIEWS

Definition of a view: see VIEWDEFS

Existence of a view: see TABLES


VIEWDEFS (MaxDB: Reference Manual)

VIEWDEFS

Using the system table VIEWDEFS, you can determine the following database information, among other things:

Text that was entered for the definition of your own view table MYVIEW
SELECT definition
  FROM DOMAIN.VIEWDEFS
    WHERE owner = user
      AND viewname = 'MYVIEW'

Only the owner of a view table can select the definition. No output is provided for any other users.

All view tables: see VIEWS

Existence of a view table: see TABLES

Tables and columns forming the basis for a view table: see VIEWCOLUMNS


VIEWS (MaxDB: Reference Manual)

VIEWS

Using the system table VIEWS, you can determine the following database information, among other things:

· All privileges of your own view table MYVIEW
SELECT privileges
  FROM DOMAIN.VIEWS
    WHERE owner = user
      AND viewname = 'MYVIEW'

· All view tables and their comments that the current user can see without being the owner
SELECT owner, viewname, comment
  FROM DOMAIN.VIEWS
    WHERE owner <> user

Definition text of a view table: see VIEWDEFS

Existence of a view table: see TABLES

Synonym for a view table: see SYNONYMS

Tables and columns forming the basis for a view table: see VIEWCOLUMNS


Definitions of the System Tables (MaxDB: Reference Manual)

Definitions of the System Tables

System Tables with Information on Database Objects

The database system contains a series of system tables that contain information about the database objects and their connection to each other. These system tables are available in every SQL mode. Their owner is the DOMAIN user. The owner has to be specified when accessing these tables in every SQL mode other than INTERNAL.

Definitions of the most important system tables:

COLUMNS | CONNECTEDUSERS | CONNECTPARAMETERS
CONSTRAINTS | DBPROCEDURES | DBPROCPARAMS
DOMAINCONSTRAINTS | DOMAINS | FOREIGNKEYCOLUMNS
FOREIGNKEYS | INDEXCOLUMNS | INDEXES
LOCKS | MAPCHARSETS | PACKAGES
ROLEPRIVILEGES | ROLES | SCHEMAS
SEQUENCES | SESSION_ROLES | SYNONYMS
TABLEPRIVILEGES | TABLES | TRIGGERS
USERS | VERSIONS | VIEWCOLUMNS
VIEWDEFS | VIEWS |

System Tables with Information on Database States

The database system contains a series of system tables that contain information about the system configuration and system load. These system tables are available in every SQL mode. Their owner is the SYSINFO user. You do not need to specify the owner when accessing these tables.

Definitions of the most important system tables:

ACTIVECONFIGURATION | CACHESTATISTICS | COMMANDCACHESTATISTICS
COMMANDSTATISTICS | DATASTATISTICS | DATAVOLUMES
DIAGNOSE | HOTSTANDBYCOMPONENT | HOTSTANDBYGROUP
INSTANCE | LOGVOLUMES | MACHINECONFIGURATION
MACHINEUTILIZATION | MEMORYALLOCATORSTATISTICS | OPTIMIZERINFORMATION
SESSIONS | SNAPSHOTS | SPINLOCKSTATISTICS
VERSION |  |

Statistics System Tables

The database system contains a number of system tables that you can use to select information about the configuration, structures, and sizes of database objects. The owner of these statistics system tables is the database system administrator (SYSDBA user). You do not need to specify the owner when accessing these tables.

Statistics System Tables

DBPARAMETERS | INDEXSTATISTICS | LOCKLISTSTATISTICS
OPTIMIZERSTATISTICS | SERVERDBSTATISTICS | TABLESTATISTICS
TRANSACTIONS | USERSTATISTICS |

Monitor System Tables

The database system contains a number of system tables that you can use to access monitor information. The owner of these monitor system tables is the SYSDBA user. You do not need to specify the owner when accessing these tables.

The monitor system tables return results for the SYSDBA user and for all users of the database user class database administrator (DBA user). Non-authorized users receive the error message 100 – Row not found.

The monitor system tables have the following structure:

DESCRIPTION | CHAR(40)
VALUE | FIXED(20)

Each row contains a counter value. The meaning of this value is in the DESCRIPTION column.

Monitor System Tables

MONITOR | MONITOR_CACHES | MONITOR_LOAD
MONITOR_LOCK | MONITOR_LOG | MONITOR_LONG
MONITOR_PAGES | MONITOR_ROW | MONITOR_TRANS

Loader System Tables

The database system contains a range of system tables that are used by the loader. The owner of these loader system tables is the SYSDBA user. You do not need to specify the owner when accessing these tables.

Loader System Tables

CODEPAGE | TRANSFORMATIONMODEL | TRANSFORMATIONMONITOR
TRANSFORMATIONPACKAGES | TRANSFORMATIONRESOURCES | TRANSFORMATIONSTATISTICS
TRANSFORMATIONSTEPS |  |


ACTIVECONFIGURATION (MaxDB: Reference Manual)

ACTIVECONFIGURATION

The system table ACTIVECONFIGURATION contains the names and values of the currently active database parameters.

ACTIVECONFIGURATION

PARAMETERNAME | CHAR(32) | Name of the database parameter
VALUE | CHAR(256) | Value of the database parameter


CACHESTATISTICS (MaxDB: Reference Manual)

CACHESTATISTICS

The system table CACHESTATISTICS contains information on accesses to caches since the last time the database instance was started. A row is written for each cache in the request communication layer.

CACHESTATISTICS

SESSIONID | FIXED(10) | Session ID, if the corresponding cache is session-specific; otherwise NULL
NAME | CHAR(20) | Name of the cache
ACCESSCOUNT | FIXED(20) | Number of accesses to the cache
SUCCESSFULACCESSCOUNT | FIXED(20) | Number of successful accesses to the cache
UNSUCCESSFULACCESSCOUNT | FIXED(20) | Number of unsuccessful accesses to the cache
HITRATE | FIXED(3) | Hit rate (successful cache accesses as a percentage of total cache accesses)


COLUMNS (MaxDB: Reference Manual)

COLUMNS

The system table COLUMNS contains the columns of all the tables, view tables, result tables, and synonyms for which the current user has privileges.

COLUMNS

OWNER | CHAR(32) | Name of owner of database object
TABLENAME | CHAR(32) | Name of database object
COLUMNNAME | CHAR(32) | Name of column
MODE | CHAR(3) | Type of column (KEY | MAN | OPT)
DATATYPE | CHAR(10) | Data type of column (BOOLEAN | CHAR | DATE | FIXED | FLOAT | INTEGER | LONG | SMALLINT | TIME | TIMESTAMP)
CODETYPE | CHAR(8) | Code attribute of column (ASCII | EBCDIC | BYTE | UNICODE)
LEN | FIXED(4) | Length or precision of column
DEC | FIXED(3) | Number of places after the comma for columns of data type FIXED
NULLABLE | CHAR(3) | Column can accept null values (YES | NO)
COLUMNPRIVILEGES | CHAR(8) | Privileges of current user for column
DEFAULT | CHAR(254) | Default value (DEFAULT) for column
DEFAULTFUNCTION | CHAR(12) | Name, if the DEFAULT value is one of the following value specifications: NULL | USER | USERGROUP | SYSDBA | UID | DATE | TIME | TIMESTAMP | UTCDATE | TIMEZONE | UTCDIFF | TRUE | FALSE | TRANSACTION Otherwise NULL value
DOMAINOWNER | CHAR(32) | Name of domain owner
DOMAINNAME | CHAR(32) | Name of domain
POS | FIXED(4) | Original position of column in table
KEYPOS | FIXED(4) | Original position of key column in table
PHYSICALPOS | FIXED(4) | Position of the column on the disk
CREATEDATE | DATE(10) | Creation date of column
CREATETIME | TIME(8) | Creation time of column
ALTERDATE | DATE(10) | Change date of column
ALTERTIME | TIME(8) | Change time of column
TABLETYPE | CHAR(8) | Type of table (SYSTEMS | TABLES)
COMMENT | LONG | Comment about column

See also:

Evaluating System Tables ® COLUMNS


COMMANDCACHESTATISTICS (MaxDB: Reference Manual)

COMMANDCACHESTATISTICS

The system table COMMANDCACHESTATISTICS contains the statistical information collected about the command cache activities since the last time the database instance was started. The command cache contains the SQL statements and their execution plans shared by different database sessions (the following refers to the SQL statement and execution plan collectively as a command).

COMMANDCACHESTATISTICS

USABLESIZE | FIXED(10) | Size of the command cache (KB)
USEDSIZE | FIXED(10) | Size of the area of the command cache that is actually used (KB)
USEDSIZEPERCENTAGE | FIXED(3) | Size of the area of the command cache that is actually used (%)
MAXUSEDSIZE | FIXED(10) | Maximum used area of the command cache (KB)
MAXUSEDSIZEPERCENTAGE | FIXED(3) | Maximum used area of the command cache (%)
COMMANDCOUNT | FIXED(10) | Number of stored commands
MAXCOMMANDCOUNT | FIXED(10) | Maximum number of stored commands
INSERTCOMMANDCOUNT | FIXED(10) | Number of inserts
DELETECOMMANDCOUNT | FIXED(10) | Number of deletes
FAILEDALLOCATECOUNT | FIXED(10) | Number of memory requests not fulfilled
CLEANUPCOUNT | FIXED(10) | Number of operations that encountered a lack of space in the main memory
CLEANUPCOMMANDCOUNT | FIXED(10) | Number of commands modified due to lack of space in the main memory
INVALIDATECOUNT | FIXED(10) | Number of data definition statements that made execution plans invalid
UNLOADSTATEMENTCOUNT | FIXED(10) | Number of SQL statements displaced to disk
CURRENTUNLOADSTATEMENTCOUNT | FIXED(10) | Number of SQL statements currently displaced to disk
RELOADSTATEMENTCOUNT | FIXED(10) | Number of SQL statements reloaded to the main memory
DELETEPLANCOUNT | FIXED(10) | Number of execution plans deleted due to lack of space in the main memory
HASHTABLESLOTCOUNT | FIXED(5) | Number of slots in the hash table
USEDHASHTABLESLOTCOUNT | FIXED(5) | Number of used slots in the hash table
MAXUSEDHASHTABLESLOTCOUNT | FIXED(5) | Maximum number of used slots in the hash table
AVGHASHTABLECHAINENTRYCOUNT | FIXED(5) | Average length of the hash entry overflow chains
MAXHASHTABLECHAINENTRYCOUNT | FIXED(5) | Maximum length of the hash entry overflow chains


COMMANDSTATISTICS (MaxDB: Reference Manual)

COMMANDSTATISTICS

The system table COMMANDSTATISTICS describes SQL statements that are stored in the command cache, and also contains statistical information on the activities of these SQL statements collected since the last time the database instance was started. The command cache contains the SQL statements and their execution plans shared by different database sessions

COMMANDSTATISTICS

COMMANDID | CHAR(8) BYTE | ID of the SQL statement
INTERNAL | CHAR(3) | SQL statement generated implicitly by the database instance (YES|NO)
HASHVALUE | FIXED(10) | Hash value
HASHTABLESLOT | FIXED(5) | Slot in the hash table
STATUS | CHAR(10) | Status (PREPARING | PREPARED | INVALID)
USERNAME | CHAR(32) | Name of the database user
SCHEMANAME | CHAR(32) | Current schema when execution plan created
SQLMODE | CHAR(10) | SQL mode
ISOLATIONLEVEL | CHAR(3) | Isolation level
DATEFORMAT | CHAR(50) | Date and time format
MASSCOMMAND | CHAR(3) | Command can be used as an array command (YES|NO)
STATEMENTSIZE | FIXED(10) | Length of the SQL statement (bytes)
STATEMENT | LONG | SQL statement
PLANSIZE | FIXED(10) | Memory requirements of the execution plan (bytes)
PREPARECOUNT | FIXED(10) | Number of execution preparations
REFERENCECOUNT | FIXED(5) | Number of database sessions for which the SQL statement has been prepared for execution
CURRENTEXECUTECOUNT | FIXED(5) | Current number of executions
EXECUTECOUNT | FIXED(10) | Number of executions
PREPARETIME | FIXED(20) | Parse time (ms)
EXECUTETIME | FIXED(20) | Total duration of executions (ms)
AVGEXECUTETIME | FIXED(20) | Average execution time (ms)
MINEXECUTETIME | FIXED(20) | Minimum execution time (ms)
MAXEXECUTETIME | FIXED(20) | Maximum execution time (ms)
READROWCOUNT | FIXED(20) | Number of rows read
QUALIFIEDROWCOUNT | FIXED(20) | Number of qualified rows
VIRTUALREADCOUNT | FIXED(20) | Number of reads in the data cache
PHYSICALREADCOUNT | FIXED(20) | Number of reads in the data cache that triggered reads on the disk
FETCHROWCOUNT | FIXED(20) | Number of rows (in the result tables generated by the SQL statement) sent to the application
SUSPENDCOUNT | FIXED(20) | Number of suspends
WAITCOUNT | FIXED(20) | Number of waits caused by lock collisions


CONNECTEDUSERS (MaxDB: Reference Manual)

CONNECTEDUSERS

The system table CONNECTEDUSERS contains all the database users who have logged on.

CONNECTEDUSERS

USERNAME | CHAR(32) | Name of user
TERMID | CHAR(18) | Terminal identification
SESSION | FIXED(10) | Session
CATALOG_CACHE_SIZE | FIXED(10) | Size of cache for catalog information of this database session

See also:

Evaluating System Tables ® CONNECTEDUSERS


CONNECTPARAMETERS (MaxDB: Reference Manual)

CONNECTPARAMETERS

The system table CONNECTPARAMETERS contains information about session-specific parameters.

CONNECTPARAMETERS

SQLMODE | CHAR(8) | SQL mode
ISOLEVEL | FIXED(10) | Isolation level
TIMEOUT | FIXED(10) | Value of the session timeout (timeout value)
SESSION | FIXED(10) | Database session

See also:

Evaluating System Tables ® CONNECTPARAMETERS


CONSTRAINTS (MaxDB: Reference Manual)

CONSTRAINTS

The system table CONSTRAINTS contains the CONSTRAINT definitions for all the tables for which the current user has privileges.

CONSTRAINTS

OWNER | CHAR(32) | Name of table owner
TABLENAME | CHAR(32) | Name of table with CONSTRAINT definition
CONSTRAINTNAME | CHAR(32) | Name of CONSTRAINT definition
DEFINITION | LONG | Text of CONSTRAINT definition

See also:

Evaluating System Tables ® CONSTRAINTS


DATASTATISTICS (MaxDB: Reference Manual)

DATASTATISTICS

The system table DATASTATISTICS describes the current fill level of the database instance and the maximum fill level since the last time the database instance was started.

DATASTATISTICS

USABLESIZE | FIXED(20) | Data area available for data (KB)
USEDSIZE | FIXED(20) | Memory in data area that is actually used for data (KB)
USEDSIZEPERCENTAGE | FIXED(3) | Percentage of the memory in the data area that is used for data
DATAFULL | CHAR(3) | Data area is full (YES|NO)
USEDSIZEONVOLUMES | FIXED(20) | Amount of data written to the data area (KB)
USEDSIZENOTONVOLUMES | FIXED(20) | Amount of permanent data that has to be written to the data area at the next savepoint (KB)
USEDPERMANENTSIZE | FIXED(20) | Data area used for permanent data (KB)
USEDTEMPORARYSIZE | FIXED(20) | Data area used for temporary data (KB)
MAXUSEDSIZE | FIXED(20) | Maximum data area used for data at a savepoint (KB)
MAXUSEDPERMANENTSIZE | FIXED(20) | Maximum data area used for permanent data at the last savepoint (KB)
MAXUSEDTEMPORARYSIZE | FIXED(20) | Maximum data area used for temporary data at the last savepoint (KB)
INCREMENTALBACKUPSIZE | FIXED(20) | Amount of data that needs to be backed up in the next incremental backup (KB)
LASTEMERGENCYHISTORYCLEANUP | TIMESTAMP | Time at which the undo log files were last deleted due to lack of space in the data area (according to the history file)
CONVERTERVERSION | FIXED(10) | The converter data saved to the data area at the last savepoint gets a unique number (converter version). This number is stored in the restart record.
MAXTEMPORARYDATAPAGENUMBER | FIXED(10) | Highest page number available for temporary pages
MAXPERMANENTDATAPAGENUMBER | FIXED(10) | Highest page number available for permanent pages
MAXPERMANENTSTATICDATAPAGENUMBER | FIXED(10) | Highest page number available for permanent, static pages


DATAVOLUMES (MaxDB: Reference Manual)

DATAVOLUMES

The system table DATAVOLUMES describes the data volumes in which data is stored.

DATAVOLUMES

ID | FIXED(5) | Number of the volume
MODE | CHAR(10) | Mode of the volume (NORMAL|SEQUENTIAL)
PATH | CHAR(256) | Name of the volume
CONFIGUREDSIZE | FIXED(20) | Configured size of the volume (KB)
USABLESIZE | FIXED(20) | Area of the volume that can be used for data (KB)
USEDSIZE | FIXED(20) | Area of the volume used for data (KB)
USEDSIZEPERCENTAGE | FIXED(3) | Area of the volume used as a percentage of the total area that can be used for data


DBPARAMETERS (MaxDB: Reference Manual)

DBPARAMETERS

The statistics system table DBPARAMETERS contains the parameters that were defined for the database instance by using the Database Manager tool.

DBPARAMETERS

DESCRIPTION | CHAR(18) | Description of how to interpret the VALUE column
VALUE | CHAR(256) | Value


DBPROCEDURES (MaxDB: Reference Manual)

DBPROCEDURES

The system table DBPROCEDURES contains all the database procedures for which the current user has privileges.

DBPROCEDURES

OWNER | CHAR(32) | Name of owner of database procedure
DBPROCNAME | CHAR(32) | Name of database procedure
PACKAGE | CHAR(32) | Package that contains the database procedure
PARAMETER | FIXED(4) | Number of parameters of database procedure
CREATEDATE | DATE(10) | Creation date of database procedure
CREATETIME | TIME(8) | Creation time of database procedure
EXCECUTION_KIND | CHAR(6) | Execution location of database procedure (INPROC | LOCAL | REMOTE)
LANGUAGE | CHAR(32) | Implementation language of the database procedure (SPL | C++ | JAVA | ...)
SQL_SUPPORT | CHAR(3) | Database procedure may contain SQL statements (YES | NO)
WAIT_FOR_CHCKPT | CHAR(3) | Database procedure waits for a checkpoint (YES | NO)
REMOTE_LOCATION | CHAR(132) | Execution location
DEFINITION | LONG | SQL statement for defining the database procedure
COMMENT | LONG | Comment about database procedure

See also:

Evaluating System Tables ® DBPROCEDURES


DBPROCPARAMS (MaxDB: Reference Manual)

DBPROCPARAMS

The system table DBPROCPARAMS contains all the parameters of a database procedure for which the current user has privileges.

DBPROCPARAMS

OWNER | CHAR(32) | Name of owner of database procedure
DBPROCNAME | CHAR(32) | Name of database procedure
PARAMETERNAME | CHAR(32) | Name of parameter
POS | FIXED(4) | Original position of parameter in database procedure
IN/OUT-TYPE | CHAR(6) | Type of parameter (IN | OUT)
DATATYPE | CHAR(10) | Datatype of parameter (BOOLEAN | CHAR | DATE | FIXED | FLOAT | TIME | TIMESTAMP)
CODETYPE | CHAR(8) | Code attribute of the column (ASCII | BYTE | UNICODE)
LEN | FIXED(4) | Length or precision of parameter
DEC | FIXED(3) | Number of places after the comma for the parameter of data type FIXED
CREATEDATE | DATE(10) | Creation date of database procedure
CREATETIME | TIME(8) | Creation time of database procedure

See also:

Evaluating System Tables ® DBPROCPARAMS


DIAGNOSE (MaxDB: Reference Manual)

DIAGNOSE

The system table DIAGNOSE describes the possible diagnosis options.

DIAGNOSE

TYPE | CHAR(10) | Type of the diagnosis option (ANALYZE|CHECK| JOIN|LVCMONITOR|MONITOR|OPTIMIZE| TOPIC|TRACE|TRACECHECK|TRIGGER)
NAME | CHAR(32) | Name of the diagnosis option
VALUE | FIXED(10) | State of the diagnosis option (0: option is deactivated | 1 or specified value: option is activated)
DESCRIPTION | CHAR(64) | Description of the diagnosis option


DOMAINCONSTRAINTS (MaxDB: Reference Manual)

DOMAINCONSTRAINTS

The system table DOMAINCONSTRAINTS contains the CONSTRAINT definition of a domain.

DOMAINCONSTRAINTS

OWNER | CHAR(32) | Name of domain owner
DOMAINNAME | CHAR(32) | Name of domain
CONSTRAINTNAME | CHAR(32) | Name of CONSTRAINT definition
DEFINITION | LONG | Text of CONSTRAINT definition

See also:

Evaluating System Tables ® DOMAINCONSTRAINTS


DOMAINS (MaxDB: Reference Manual)

DOMAINS

The system table DOMAINS contains all domains.

DOMAINS

OWNER | CHAR(32) | Name of domain owner
DOMAINNAME | CHAR(32) | Name of domain
DATATYPE | CHAR(10) | Data type of domain (BOOLEAN | CHAR | DATE | FIXED | FLOAT | INTEGER | LONG | SMALLINT | TIME | TIMESTAMP)
CODETYPE | CHAR(8) | Code attribute of the domain (ASCII | BYTE | UNICODE)
LEN | FIXED(4) | Length or precision of domain
DEC | FIXED(3) | Number of places after the comma for domains of data type FIXED
DEFAULT | CHAR(254) | Default value for domain
DEFAULTFUNCTION | CHAR(12) | Name, if the DEFAULT value is one of the following value specifications: NULL | USER | USERGROUP | SYSDBA | UID | DATE | TIME | TIMESTAMP | UTCDATE | TIMEZONE | UTCDIFF | TRUE | FALSE | TRANSACTION Otherwise NULL value
DEFINITION | LONG | Text of domain definition
CREATEDATE | DATE(10) | Creation date of domain
CREATETIME | TIME(8) | Creation time of domain
COMMENT | LONG | Comment about domain

See also:

Evaluating System Tables ® DOMAINS


FOREIGNKEYCOLUMNS (MaxDB: Reference Manual)

FOREIGNKEYCOLUMNS

The system table FOREIGNKEYCOLUMNS contains the columns of all the referential CONSTRAINT definitions for which the current user has privileges.

FOREIGNKEYCOLUMNS

OWNER | CHAR(32) | Name of table owner
TABLENAME | CHAR(32) | Name of the table
COLUMNNAME | CHAR(32) | Name of column
FKEYNAME | CHAR(32) | Name of referential CONSTRAINT definition
REFOWNER | CHAR(32) | Name of owner of referenced table
REFTABLENAME | CHAR(32) | Name of referenced table
REFCOLUMNNAME | CHAR(32) | Name of column of referenced table
RULE | CHAR(18) | Rules for deleting the table
CREATEDATE | DATE(10) | Creation date of referential CONSTRAINT definition
CREATETIME | TIME(8) | Creation time of referential CONSTRAINT definition
COMMENT | LONG | Comment about referential CONSTRAINT definition

See also:

Evaluating System Tables ® FOREIGNKEYCOLUMNS


FOREIGNKEYS (MaxDB: Reference Manual)

FOREIGNKEYS

The system table FOREIGNKEYS contains all the referential CONSTRAINT definitions for which the current user has privileges.

FOREIGNKEYS

OWNER | CHAR(32) | Name of table owner
TABLENAME | CHAR(32) | Name of the table
FKEYNAME | CHAR(32) | Name of referential CONSTRAINT definition
RULE | CHAR(18) | Rules for deleting the table
CREATEDATE | DATE(10) | Creation date of referential CONSTRAINT definition
CREATETIME | TIME(8) | Creation time of referential CONSTRAINT definition

See also:

Evaluating System Tables ® FOREIGNKEYS


HOTSTANDBYCOMPONENT (MaxDB: Reference Manual)

HOTSTANDBYCOMPONENT

The system table HOTSTANDBYCOMPONENT describes some of the details of the hot standby component in which the information of this system table is queried.

HOTSTANDBYCOMPONENT

LOCALNODE | CHAR(64) | Name with which the hot standby component can be addressed
MASTERLOCALNODE | CHAR(64) | Name with which the corresponding master hot standby component can be addressed
STANDBYROLE | CHAR(8) | Role within the hot standby configuration (MASTER | STANDBY | UNKNOWN)
TAKEOVERDATE | TIMESTAMP | Time at which the TAKEOVER statement was received
DELAYTIME | FIXED(10) | Minimum number of seconds that must pass between the change being made in the master hot standby component, and the change also being made in this hot standby component
STANDBYSTATEDATE | TIMESTAMP | Time at which the STANDBY state was reached
SYNCHRONIZERECEIVECOUNT | FIXED(10) | Number of received SYNCHRONIZE statements
FIRSTNEEDEDLOGOFFSET | FIXED(10) | Oldest position in the log area from which the log entries have to be redone
LASTVALIDLOGOFFSETRECEIVED | FIXED(10) | Position in the log area up to which the log entries can be redone by this hot standby component with the STANDBY role
INITSTANDBYDATE | TIMESTAMP | Time at which the INIT STANDBY statement was received
RESTARTSTANDBYDATE | TIMESTAMP | Time at which the RESTART STANDBY statement was sent
LASTSYNCHRONIZEDATE | TIMESTAMP | Time at which the last SYNCHRONIZE statement was received
PREPARESTANDBYDATE | TIMESTAMP | Time at which the PREPARE STANDBY statement was sent
REGISTERSTANDBYDATE | TIMESTAMP | Time at which the REGISTER STANDBY statement was sent


HOTSTANDBYGROUP (MaxDB: Reference Manual)

HOTSTANDBYGROUP

The system table HOTSTANDBYGROUP describes information that the hot standby component (that is, the hot standby component in which the information from this system table is queried) holds about the other hot standby components with the STANDBY role.

HOTSTANDBYGROUP

LOCALNODE | CHAR(64) | Name with which the hot standby component can be addressed
ADDNODEDATE | TIMESTAMP | Time at which the hot standby component was added to the hot standby configuration
REMOVENODEDATE | TIMESTAMP | Time at which the hot standby component was deleted from the hot standby configuration
STATE | CHAR(20) | Status of the hot standby component (UNKNOWN | BELIEVED TO BE DEAD | PREPARE PENDING | REGISTER PENDING | SYNC PENDING | STANDBY)
PREPARESTANDBYDATE | TIMESTAMP | Time at which the PREPARE STANDBY statement was received
REGISTERSTANDBYDATE | TIMESTAMP | Time at which the REGISTER STANDBY statement was received
SYNCHRONIZEDATE | TIMESTAMP | Time at which the last SYNCHRONIZE statement was sent
SUCCESSFULSYNCHRONIZEDATE | TIMESTAMP | Time at which the last successful SYNCHRONIZE statement was executed
LASTVALIDLOGOFFSETSENT | FIXED(10) | Last position sent by the master component in the log area, up to which the log entries can be redone by hot standby components with the STANDBY role
FIRSTNEEDELOGOFFSET | FIXED(10) | Oldest position in the log area from which the log entries have to be redone
SYNCHRONIZESENDCOUNT | FIXED(10) | Number of sent SYNCHRONIZE statements
SYNCHRONIZERETRYCOUNT | FIXED(10) | Number of SYNCHRONIZE statements sent repeatedly


INDEXCOLUMNS (MaxDB: Reference Manual)

INDEXCOLUMNS

The system table INDEXCOLUMNS contains detailed information about the indexes for which the current user has privileges.

INDEXCOLUMNS

OWNER | CHAR(32) | Name of index owner
TABLENAME | CHAR(32) | Name of the table
INDEXNAME | CHAR(32) | Name of the index
TYPE | CHAR(6) | Type of index (UNIQUE | NULL)
COLUMNNAME | CHAR(32) | Name of column
SORT | CHAR(4) | Sort sequence for column (ASC | DESC)
COLUMNNO | FIXED(4) | Number of column in index
DATATYPE | CHAR(10) | Data type of domain (BOOLEAN | CHAR | DATE | FIXED | FLOAT | INTEGER | LONG | SMALLINT | TIME | TIMESTAMP)
LEN | FIXED(4) | Length or precision of column definition
CREATEDATE | DATE(10) | Creation date of index
CREATETIME | TIME(8) | Creation time of index
INDEX_USED | FIXED(10) | Usage frequency of index for searches
DISABLED | CHAR(3) | Index not activated for searches (YES | NO)
COMMENT | LONG | Comment about index

See also:

Evaluating System Tables ® INDEXCOLUMNS


INDEXES (MaxDB: Reference Manual)

INDEXES

The system table INDEXES contains all the indexes for which the current user has privileges.

INDEXES

OWNER | CHAR(32) | Name of index owner
TABLENAME | CHAR(32) | Name of the table
INDEXNAME | CHAR(32) | Name of the index
TYPE | CHAR(6) | Type of index (UNIQUE | NULL)
CREATEDATE | DATE(10) | Creation date of index
CREATETIME | TIME(8) | Creation time of index
INDEX_USED | FIXED(10) | Usage frequency of index for searches
DISABLED | CHAR(3) | Index not activated for searches (YES | NO)
COMMENT | LONG | Comment about index

See also:

Evaluating System Tables ® INDEXES


INDEXSTATISTICS (MaxDB: Reference Manual)

INDEXSTATISTICS

The statistics system table INDEXSTATISTICS contains information about the structure and sizes of indexes.

INDEXSTATISTICS

OWNER | CHAR(32) | Table owner
TABLENAME | CHAR(32) | Table name
INDEXNAME | CHAR(32) | Index name (NULL for unknown indexes)
COLUMNNAME | CHAR(32) | Name of an inverted column
DESCRIPTION | CHAR(40) | Description (see table Column DESCRIPTION) of how to interpret following columns
CHAR_VALUE | CHAR(12) | Alphanumeric value
NUMERIC_VALUE | FIXED(10) | Numeric value

Column DESCRIPTION

Value | Explanation
Root pno | NUMERIC_VALUE contains the page number of the root of the B* tree
Filetype | CHAR_VALUE contains the type of the B* tree
Used pages | NUMERIC_VALUE indicates how many pages are used by the index
Index pages | NUMERIC_VALUE indicates how many pages are used by the index in the B* tree index
Leaf pages | NUMERIC_VALUE indicates how many leaf pages are used by the index
Index levels | NUMERIC_VALUE contains the number of index levels in the B* tree
Space used in all pages(%) | NUMERIC_VALUE contains the used space of all pages in the B* tree (as a percentage)
Space used in root page(%) | NUMERIC_VALUE contains the used space of the root page in the B* tree (as a percentage)
Space used in index pages(%) | NUMERIC_VALUE contains the used space of the index pages in the B* tree (as a percentage)
Space used in index pages(%) min | NUMERIC_VALUE contains the minimum used space of the index pages in the B* tree (as a percentage)
Space used in index pages(%) max | NUMERIC_VALUE contains the maximum used space of the index pages in the B* tree (as a percentage)
Space used in leaf pages(%) | NUMERIC_VALUE contains the used space of the leaf pages in the B* tree (as a percentage)
Space used in leaf pages(%) min | NUMERIC_VALUE contains the minimum used space of the leaf pages in the B* tree (as a percentage)
Space used in leaf pages(%) max | NUMERIC_VALUE contains the maximum used space of the leaf pages in the B* tree (as a percentage)
Secondary keys (index lists) | NUMERIC_VALUE contains the number of different values of the indexed columns
Avg secondary key length | NUMERIC_VALUE contains the average length of an index value
Min secondary key length | NUMERIC_VALUE contains the minimum length of an index value
Max secondary key length | NUMERIC_VALUE contains the maximum length of an index value
Avg separator length | NUMERIC_VALUE contains the average length of a separator in the B* tree
Min separator length | NUMERIC_VALUE contains the minimum length of a separator
Max separator length | NUMERIC_VALUE contains the maximum length of a separator
Primary keys | NUMERIC_VALUE contains the number of rows in the table identified by OWNER and TABLENAME
Avg primary keys per list | NUMERIC_VALUE contains the average number of keys for each invert list
Min primary keys per list | NUMERIC_VALUE contains the minimum number of keys for each invert list
Max primary keys per list | NUMERIC_VALUE contains the maximum number of keys for each invert list
Values with selectivity <= 1% | NUMERIC_VALUE contains the number of invert lists with a selectivity <= 1%
Values with selectivity <= 5% | NUMERIC_VALUE contains the number of invert lists with a selectivity between 1% and 5%
Values with selectivity <= 10% | NUMERIC_VALUE contains the number of invert lists with a selectivity between 5% and 10%
Values with selectivity <= 25% | NUMERIC_VALUE contains the number of invert lists with a selectivity between 10% and 25%
Values with selectivity > 25% | NUMERIC_VALUE contains the number of invert lists with a selectivity > 25%


INSTANCE (MaxDB: Reference Manual)

INSTANCE

The system table INSTANCE describes some details about the database instance.

INSTANCE

NODE | CHAR(64) | Name with which the database instance can be addressed
LOCALNODE | CHAR(64) | Name with which the hot standby component can be addressed (if you have a hot standby configuration)
ADMINSTATEDATE | TIMESTAMP | Time at which the ADMIN operational state was reached
ONLINESTATEDATE | TIMESTAMP | Time at which the ONLINE operational state was reached


LOCKLISTSTATISTICS (MaxDB: Reference Manual)

LOCKLISTSTATISTICS

The statistics system table LOCKLISTSTATISTICS contains information about the used space in the lock list.

LOCKLISTSTATISTICS

DESCRIPTION | CHAR(40) | Description (see table Column DESCRIPTION) of how to interpret the content of the VALUE column
VALUE | CHAR(12) | Value

Column DESCRIPTION

Value | Explanation
MAX LOCKS | VALUE contains the number of available locks in the lock list
TRANS LIST REGIONS | VALUE contains the number of semaphores for transactions
TABLE LIST REGIONS | VALUE contains the number of semaphores for tables
ROW LIST REGIONS | VALUE contains the number of semaphores for rows
ENTRIES | VALUE contains an internal database measure (entries) for the size of the lock list
USED ENTRIES | VALUE contains the number of currently used entries for set and requested locks
USED ENTRIES (%) | VALUE contains the number of currently used entries for set and requested locks (as a percentage)
AVG USED ENTRIES | VALUE contains the average number of entries for set and requested locks
AVG USED ENTRIES (%) | VALUE contains the average number of entries for set and requested locks (as a percentage)
MAX USED ENTRIES | VALUE contains the maximum number of entries for set and requested locks
MAX USED ENTRIES(%) | VALUE contains the maximum number of entries for set and requested locks (as a percentage)
LOCK ESCALATION VALUE | VALUE contains the number of table rows from which point row locks are converted into a table lock (lock escalation)
LOCK ESCALATIONS | VALUE contains the number of lock escalations
LOCK COLLISIONS | VALUE contains the number of lock requests that could not be granted (immediately)
DEADLOCKS | VALUE contains the number of situations where at least two transactions collided with each other due to held and requested locks in such a way that this collision can be resolved only by implicitly ending a transaction
SQL REQUEST TIMEOUTS | VALUE contains the number of lock requests that could not be set because they exceeded the maximum waiting time
TRANSACTIONS HOLDING LOCKS | VALUE contains the number of transactions that have locks assigned to them
TRANSACTIONS REQUESTING LOCKS | VALUE contains the number of transactions that request locks
CHECKPOINT WANTED | If the VALUE column contains the value TRUE, the lock list is closed. This means that a transaction that does not yet have an exclusive lock cannot be assigned an exclusive lock because a checkpoint has been requested.
SHUTDOWN WANTED | If the VALUE column contains the value TRUE, the lock list is closed because a shutdown has been requested.


LOCKS (MaxDB: Reference Manual)

LOCKS

The system table LOCKS describes the current lock entries and entries for lock requests.

LOCKS

SESSION | FIXED(10) | ID of the database session
TRANSCOUNT | CHAR(20) | ID of the transaction in the database session
PROCESS | FIXED(10) | ID of the process in the database instance
USERNAME | CHAR(32) | Name of user
DATE | DATE(10) | Creation date of the lock
TIME | TIME(8) | Creation time of the lock
TERMID | CHAR(18) | ID of the user terminal
LASTWRITE | CHAR(10) | Time that has elapsed since the last SQL statement for data manipulation
LOCKMODE | CHAR(14) | Type of lock
LOCKSTATE | CHAR(10) | Status of lock
APPLPROCESS | FIXED(10) | ID of the process on the client hardware
APPLNODE | CHAR(64) | ID of the client hardware
OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Name of the table
TABLEID | CHAR(8) BYTE | Table ID
ROWIDLENGTH | FIXED(4) | Length of the key of the locked row
ROWIDHEX | CHAR(64) BYTE | Start of the key of the locked row in hexadecimal format
ROWID | CHAR(128) | Start of the key of the locked row

See also:

Evaluating System Tables ® LOCKS


LOGVOLUMES (MaxDB: Reference Manual)

LOGVOLUMES

The system table LOGVOLUMES describes the log volumes in which log entries are stored.

LOGVOLUMES

ID | FIXED(5) | Number of the volume
PATH | CHAR(256) | Name of the volume
CONFIGUREDSIZE | FIXED(20) | Configured size of the volume (KB)


MACHINECONFIGURATION (MaxDB: Reference Manual)

MACHINECONFIGURATION

The system table MACHINECONFIGURATION contains information about the configuration of the host on which the database kernel is installed.

MACHINECONFIGURATION

CPUNUMBER | FIXED(5) | Number of CPUs
PHYSICALMEMORYSIZE | FIXED(10) | Size of physical memory (MB)
VIRTUALMEMORYSIZE | FIXED(10) | Size of virtual memory (MB)


MACHINEUTILIZATION (MaxDB: Reference Manual)

MACHINEUTILIZATION

The system table MACHINEUTILIZATION contains information about the utilization of the host on which the database kernel is installed.

MACHINEUTILIZATION

PHYSICALMEMORYUSABLE | FIXED(10) | Size of free physical memory
VIRTUALMEMORYUSABLE | FIXED(10) | Size of free virtual memory
PROCESSUSEDUSERTIME | FIXED(10) | Time the database kernel process has spent in user mode since database startup (s)
PROCESSUSEDSYSTEMTIME | FIXED(10) | Time the database kernel process has spent in system mode since database startup (s)
MACHINEUSEDUSERTIME | FIXED(10) | Time the host has spent in user mode since database startup (s)
MACHINEUSEDIDLETIME | FIXED(10) | Time the host has spent in system mode since database startup (s)
CPULOAD | CHAR(12) | CPU load on the host


MAPCHARSETS (MaxDB: Reference Manual)

MAPCHARSETS

The system table MAPCHARSETS contains all the MapChar sets.

MAPCHARSETS

MAPCHARSETNAME | CHAR(32) | Name of the MapChar set
CODE | CHAR(8) | Code attribute for which the MapChar set was defined (ASCII)
INTERN | CHAR(1) BYTE | Original form in hexadecimal format
MAP_CODE | CHAR(2) BYTE | Target form in hexadecimal format
MAP_CHARACTER | CHAR(2) | Target form in plain text format

See also:

Evaluating System Tables ® MAPCHARSETS


MEMORYALLOCATORSTATISTICS (MaxDB: Reference Manual)

MEMORYALLOCATORSTATISTICS

The system table MEMORYALLOCATORSTATISTICS contains information on accesses to allocators since the last time the database instance was started.

MEMORYALLOCATORSTATISTICS

ALLOCATORNAME | CHAR(40) | Name of the allocator
USEDSIZE | FIXED(20) | Reserved area of the memory (bytes)
MAXUSEDSIZE | FIXED(20) | Maximum reserved area of the memory (bytes)
ALLOCATEDSIZE | FIXED(20) | Used area of the memory (bytes)
ALLOCATECOUNT | FIXED(20) | Number of memory allocations
DEALLOCATECOUNT | FIXED(20) | Number of memory deallocations
FAILEDALLOCATECOUNT | FIXED(20) | Number of memory requests not fulfilled
FOUNDERRORCOUNT | FIXED(10) | Number of errors found in the allocator and corrected internally
BASEALLOCATORNAME | CHAR(40) | Name of the allocator that provides this allocator with memory
BASEALLOCATECOUNT | FIXED(20) | Number of memory reservations for the allocator BASEALLOCATORNAME
BASEDEALLOCATECOUNT | FIXED(20) | Number of memory deallocations sent to the allocator BASEALLOCATORNAME


MONITOR (MaxDB: Reference Manual)

MONITOR

The table MONITOR combines the following monitor system tables: MONITOR_CACHES MONITOR_LOAD MONITOR_LOCK MONITOR_LOG MONITOR_LONG MONITOR_PAGES MONITOR_ROW MONITOR_TRANS

MONITOR

TYPE | CHAR(8)
DESCRIPTION | CHAR(40)
VALUE | FIXED(20)


MONITOR_CACHES (MaxDB: Reference Manual)

MONITOR_CACHES

This monitor system table MONITOR_CACHES contains information about operations on the various caches.

Column DESCRIPTION

Value | Explanation
Data cache accesses | Number of accesses to pages in the data cache (number of accesses to data pages and pages with rollback information)
Data cache accesses successful | Number of successful accesses to pages in the data cache
Data cache accesses unsuccessful | Number of unsuccessful accesses to pages in the data cache
Data cache hit rate (%) | Percentage of successful accesses to pages in the data cache
Catalog cache accesses | Number of accesses to the session-specific catalog cache
Catalog cache accesses successful | Number of successful accesses to the session-specific catalog cache
Catalog cache accesses unsuccessful | Number of unsuccessful accesses to the session-specific catalog cache
Catalog cache hit rate (%) | Percentage of successful accesses to the session-specific catalog cache
Sequence cache accesses | Number of accesses to the sequence cache
Sequence cache accesses successful | Number of successful accesses to the sequence cache
Sequence cache accesses unsuccessful | Number of unsuccessful accesses to the sequence cache
Sequence cache hit rate (%) | Percentage of successful accesses to the sequence cache
Data cache sqlpage accesses | Number of accesses to data pages in the data cache
Data cache sqlpage accesses successful | Number of successful accesses to data pages in the data cache
Data cache sqlpage accesses unsuccessful | Number of unsuccessful accesses to data pages in the data cache
Data cache sqlpage hit rate(%) | Percentage of successful accesses to pages in the data cache
Data history/undo accesses | Number of accesses to pages with rollback information in the data cache
Data history/undo accesses successful | Number of successful accesses to pages with rollback information in the data cache
Data history/undo accesses unsuccessful | Number of unsuccessful accesses to pages with rollback information in the data cache
Data history/undo hit rate (%) | Percentage of successful accesses to pages with rollback information in the data cache

If you run the operating system Windows NT/2000 with the Intel memory extension PSE36, the table contains the following additional information:

Column DESCRIPTION

Value | Explanation
PSE36 data cache accesses | Number of accesses to the PSE36 data cache
PSE36 data cache accesses successful | Number of successful accesses to the PSE36 data cache
PSE36 data cache accesses unsuccessful | Number of unsuccessful accesses to the PSE36 data cache
PSE36 data cache hit rate (%) | Percentage of successful accesses to the PSE36 data cache


MONITOR_LOAD (MaxDB: Reference Manual)

MONITOR_LOAD

This monitor system table MONITOR_LOAD contains information about executed SQL statements and access methods.

Column DESCRIPTION

Value | Explanation
SQL commands | Number of executed SQL statements
PREPAREs | Number of parsed SQL statements
PREPAREs repeated | Number of SQL statements that were parsed again after metadata was changed
EXECUTEs | Number of executions of SQL statements that have already been parsed
COMMITs | Number of executed COMMIT statements
ROLLBACKs | Number of executed ROLLBACK statements
LOCKs and UNLOCKs | Number of executed LOCK statements and UNLOCK statements
SUBTRANS BEGINs | Number of SQL statements for opening a subtransaction
SUBTRANS ENDs | Number of SQL statements for closing a subtransaction
SUBTRANS ROLLBACKs | Number of SQL statements for resetting a subtransaction
CREATEs | Number of SQL statements for creating database objects
ALTERs | Number of executed SQL statements for changing database objects
DROPs | Number of executed SQL statements for deleting database objects
SELECTs and FETCHes | Number of executed SQL statements for accessing data
SELECTs and FETCHes, rows read | Number of rows that were read when accessing data
SELECTs and FETCHes, rows qual | Number of rows that were read when accessing data and that fulfilled the conditions
INSERTs | Number of executed SQL statements for inserting rows
INSERTs, rows inserted | Number of inserted rows
UPDATEs | Number of executed SQL statements for changing rows
UPDATEs, rows read | Number of rows that were read when changing data
UPDATEs, rows updated | Number of changed rows
DELETEs | Number of executed SQL statements for deleting rows
DELETEs, rows read | Number of rows that were read when deleting data
DELETEs, rows deleted | Number of deleted rows
Internal DBPROC calls | Number of executions of database procedures
Internal trigger calls | Number of trigger executions
Primary key accesses | Number of searches with direct access by the key
Primary key accesses, rows read | Number of rows that were read by the direct key access
Primary key accesses, rows qual | Number of rows that were read by the direct key access and that fulfilled the conditions
Primary key range accesses | Number of searches with accesses within a key range
Primary key range accesses, rows read | Number of rows read within a key range
Primary key range accesses, rows qual | Number of rows read within a key range that fulfilled the condition
Index accesses | Number of searches with accesses to an index
Index accesses, rows read | Number of rows that were accessed indirectly by an index
Index accesses, rows qual | Number of rows that were accessed indirectly by an index and that fulfilled the condition
Index range accesses | Number of searches using an index range
Index range accesses, rows read | Number of rows that were accessed indirectly by an index using an index range
Index range accesses, rows qual | Number of rows that were accessed indirectly by an index using an index range and that fulfilled the condition
Isolated index accesses | Number of searches that could be successfully performed by an index either partly or completely and without accessing the rows of the base table
Isolated index accesses, rows read | Number of keys that were accessed in the searches described in ISOLATED INDEX ACCESSES
Isolated index accesses, rows qual | Number of keys that were accessed in the searches described in ISOLATED INDEX ACCESSES, and that fulfilled the condition
Isolated index range accesses | Number of searches in which a part of an index was used with values within a range without accessing the rows of the base table
Isolated index range accesses, rows read | Number of primary/secondary keys that were accessed in the searches described in ISOLATED INDEX RANGE ACCESSES
Isolated index range accesses, rows qual | Number of primary/secondary keys that were accessed in the searches described in ISOLATED INDEX RANGE ACCESSES, and that fulfilled the condition
Table scans | Number of searches in the whole base table
Table scans, rows read | Number of rows that were accessed in searches in the whole base table
Table scans, rows qual | Number of rows that were accessed in searches in the whole base table, and that fulfilled the condition
Isolated index scans | Number of searches in which a complete index was accessed without accessing rows in the base table
Isolated index scans, rows read | Number of index rows that were accessed in the searches described in ISOLATED INDEX SCANS
Isolated index scans, rows qual | Number of index rows that were accessed in the searches described in ISOLATED INDEX SCANS, and that fulfilled the condition
Memory sorts / sort&merge | Number of sort transactions in the main memory for creating temporary inversions
Memory sorts / sort&merge, rows read | Number of rows read for creating temporary inversions
Sorts by insertion | Number of sort transactions by inserting
Sorts by insertion, rows inserted | Number of rows that were inserted during the sort transaction


MONITOR_LOCK (MaxDB: Reference Manual)

MONITOR_LOCK

The monitor system table MONITOR_LOCK contains information about operations performed by the lock management functions of the database system.

Column DESCRIPTION

Value | Explanation
Lock list avg used entries | Average number of entries in the lock list
Lock list max used entries | Maximum number of entries in the lock list
Lock list collisions | Number of lock collisions
Lock list escalations | Number of lock escalations
Lock list inserted row entries | Number of inserted row locks
Lock list inserted table entries | Number of inserted table locks
Detected deadlocks | Number of situations where at least two transactions collided with each other due to held and requested locks in such a way that this collision can be resolved only by implicitly ending a transaction
Request timeouts | Number of lock requests that could not be set because they exceeded the maximum waiting time


MONITOR_LOG (MaxDB: Reference Manual)

MONITOR_LOG

The monitor system table MONITOR_LOG contains information about operations by the logging function (redo log management) of the database system.

Column DESCRIPTION

Value | Explanation
Log page physical reads | Number of physically read log pages
Log page physical writes | Number of physically read log pages
Log queue pages | Size of the log queue in pages
Log queue max used pages | Maximum number of pages used by log queue
Log queue inserts | Number of insert operations in the log queue
Log queue overflows | Number of overflows in the log queue
Log queue group commits | Number of group COMMITs
Log queue waits for log page write | Number of wait statuses for write operations to the log
Log queue max waits per log page | Maximum number of wait statuses for each log page
Log queue avg waits per log page | Average number of wait statuses for each log page


MONITOR_LONG (MaxDB: Reference Manual)

MONITOR_LONG

The monitor system table MONITOR_LONG contains information about read and write transactions for LONG columns.

Column DESCRIPTION

Value | Explanation
BD read long | Number of read transactions for LONG columns
BD write long | Number of write transactions for LONG columns


MONITOR_PAGES (MaxDB: Reference Manual)

MONITOR_PAGES

The monitor system table MONITOR_PAGES contains information about accesses to the pages.

Column DESCRIPTION

Value | Explanation
Virtual reads | Number of virtual read operations
Virtual writes | Number of virtual write operations
Physical reads | Number of physical read operations
Physical writes | Number of physical write operations
Catalog virtual read | Number of virtual catalog read operations
Catalog virtual writes | Number of virtual catalog write operations
Catalog physical reads | Number of physical catalog read operations
Catalog physical writes | Number of physical catalog write operations
Converter page physical reads | Number of physically read converter pages
Converter page physical writes | Number of physically written converter pages
Perm page virtual reads | Number of virtually read permanent pages
Perm page virtual writes | Number of virtually written permanent pages
Perm page physical reads | Number of physically read permanent pages
Perm page physical writes | Number of physically written permanent pages
Temp page virtual reads | Number of virtually read temporary pages
Temp page virtual writes | Number of virtually written temporary pages
Temp page physical reads | Number of physically read temporary pages
Temp page physical writes | Number of physically written temporary pages
LONG page virtual reads | Number of virtually read pages for LONG columns
LONG page virtual writes | Number of virtually written pages for LONG columns
LONG page physical reads | Number of physically read pages for LONG columns
LONG page physical writes | Number of physically written pages for LONG columns
Leaf page virtual reads | Number of virtually read leaf pages
Leaf page virtual writes | Number of virtually written leaf pages
Leaf page physical reads | Number of physically read leaf pages
Leaf page physical writes | Number of physically written leaf pages
Level1 page virtual reads | Number of virtually read index pages at level 1
Level1 page virtual writes | Number of virtually written index pages at level 1
Level1 page physical reads | Number of physically read index pages at level 1
Level1 page physical writes | Number of physically written index pages at level 1
Level2 page virtual reads | Number of virtually read index pages at level 2
Level2 page virtual writes | Number of virtually written index pages at level 2
Level2 page physical reads | Number of physically read index pages at level 2
Level2 page physical writes | Number of physically written index pages at level 2
Level3 page virtual reads | Number of virtually read index pages at level 3
Level3 page virtual writes | Number of virtually written index pages at level 3
Level3 page physical reads | Number of physically read index pages at level 3
Level3 page physical writes | Number of physically written index pages at level 3
Level4 page virtual reads | Number of virtually read index pages at level 4
Level4 page virtual writes | Number of virtually written index pages at level 4
Level4 page physical reads | Number of physically read index pages at level 4
Level4 page physical writes | Number of physically written index pages at level 4
Level5 page virtual reads | Number of virtually read index pages at level 5
Level5 page virtual writes | Number of virtually written index pages at level 5
Level5 page physical reads | Number of physically read index pages at level 5
Level5 page physical writes | Number of physically written index pages at level 5
Converter page virtual reads | Number of virtually read converter pages
Converter page virtual writes | Number of virtually written converter pages
Converter page physical reads | Number of physically read converter pages
Converter page physical writes | Number of physically written converter pages


MONITOR_ROW (MaxDB: Reference Manual)

MONITOR_ROW

The monitor system table MONITOR_ROW contains information about operations at row level.

Column DESCRIPTION

Value | Explanation
BD add record perm | Number of inserted rows in permanent tables
BD add record temp | Number of inserted rows in temporary tables
BD repl record perm | Number of changed rows in permanent tables
BD repl record temp | Number of changed rows in temporary tables
BD del record perm | Number of deleted rows in permanent tables
BD del record temp | Number of deleted rows in temporary tables
BD get record perm | Number of rows read in permanent tables by using a key
BD get record temp | Number of rows read in temporary tables by using a key
BD next record perm | Number of rows read in permanent tables by using the predecessor key
BD next record temp | Number of rows read in temporary tables by using the predecessor key
BD prev record perm | Number of rows read in permanent tables by using the successor key
BD prev record temp | Number of rows read in temporary tables by using the successor key
BD select direct record | Number of selected rows with key
BD select next record | Number of selected rows with predecessor key
BD select prev record | Number of selected rows with successor key
BD add to index list perm | Number of insert operations in permanent indexes
BD add to index list temp | Number of insert operations in temporary indexes
BD del from index list perm | Number of delete operations in permanent indexes
BD del from index list temp | Number of delete operations in temporary indexes
BD get index list perm | Number of accesses to permanent indexes
BD get index list temp | Number of accesses to temporary indexes


MONITOR_TRANS (MaxDB: Reference Manual)

MONITOR_TRANS

The monitor system table MONITOR_TRANS contains information about transactions.

Column DESCRIPTION

Value | Explanation
SQL commands | Number of SQL statements
Write transactions | Number of transactions with change operations
KB calls | Number of calls using the internal communication base interface


OPTIMIZERINFORMATION (MaxDB: Reference Manual)

OPTIMIZERINFORMATION

The system table OPTIMIZERINFORMATION contains the information about value distributions that is determined by the UPDATE STATISTICS statement, and used by the SQL optimizer.

OPTIMIZERINFORMATION

OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Name of the table
COLUMNNAME | CHAR(32) | Name of a single non-inverted column
INDEXNAME | CHAR(32) | Name of the index
DISTINCTVALUECOUNT | FIXED(10) | Number of distinct values in the column, index, or primary key
CALCULATEDSIZE | FIXED(10) | Memory requirements of the (primary key) index calculated by the last UPDATE STATISTICS (KB)


OPTIMIZERSTATISTICS (MaxDB: Reference Manual)

OPTIMIZERSTATISTICS

You can select the system table OPTIMIZERSTATISTICS to query those statistical values stored in the database catalog that were generated by an UPDATE STATISTICS statement. Each row in the table describes statistics about indexes, columns, or the size of a table.

OPTIMIZERSTATISTICS

OWNER

CHAR(32)

Owner of a table for which statistics exist

TABLENAME

CHAR(32)

Table name of a table for which statistics exist

INDEXNAME

CHAR(32)

Index name of an index for which statistics exist

COLUMNNAME

CHAR(32)

Name of a column for which statistics exist

DISTINCTVALUES

FIXED(10)

Number of different values if the current row describes a column or an index with one column;
otherwise the number of rows in a table

PAGECOUNT

FIXED(10)

Number of pages used by an index if the current row describes an index;
number of pages of a base table if the current row describes a table;
otherwise NULL


PACKAGES (MaxDB: Reference Manual)

PACKAGES

The system table PACKAGES describes all the packages for which the current user has privileges.

PACKAGES

OWNER | CHAR(32) | Name of package owner
PACKAGE | CHAR(32) | Name of package
CREATEDATE | DATE | Creation date of package
CREATETIME | TIME | Creation time of package
EXCECUTION_KIND | CHAR(6) | Execution location of database procedure (INPROC | LOCAL | REMOTE)
SQL_SUPPORT | CHAR(3) | Database procedure may contain SQL statements (YES | NO)
REMOTE_LOCATION | CHAR(132) | Execution location
COMMENT | LONG | Comment about package


ROLEPRIVILEGES (MaxDB: Reference Manual)

ROLEPRIVILEGES

The system table ROLEPRIVILEGES describes the privileges and roles that are granted to roles for which the current user has privileges.

ROLEPRIVILEGES

OWNER | CHAR(32) | Name of the owner of the object that was granted for the role
TABLENAME | CHAR(32) | Name of the table for which privileges were granted for the role
ROLE | CHAR(32) | Name of the role that was granted
GRANTEE | CHAR(32) | Name of the role to which has been granted
PRIVILEGES | CHAR(30) | Privileges that were granted
GRANTOR | CHAR(32) | Name of the user who granted the privileges or the role
CREATEDATE | DATE(10) | Date when the privileges were granted
CREATETIME | TIME(8) | Time when the privileges were granted

See also:

Evaluating System Tables ® ROLEPRIVILEGES


ROLES (MaxDB: Reference Manual)

ROLES

The system table ROLES describes the roles for which the current user has privileges.

ROLES

OWNER | CHAR(32) | Name of role owner
ROLE | CHAR(32) | Name of role
PASSWORD_REQUIRED | CHAR(3) | Password required for activating the role (YES | NO)
GRANTED | CHAR(3) | Role was granted for the current user (YES | NO)
DEFAULTROLE | CHAR(3) | Role is the default role for the current user (YES | NO)
CREATEDATE | DATE(10) | Creation date of the role
CREATETIME | TIME(8) | Creation time of the role

See also:

Evaluating System Tables ® ROLES


SCHEMAS (MaxDB: Reference Manual)

SCHEMAS

The system table SCHEMAS describes the schemas known to the database instance.

SCHEMAS

OWNER | CHAR(32) | Owner of the schema
SCHEMA_NAME | CHAR(32) | Name of the schema
SCHEMA_HANDLE | FIXED(10) | ID of the schema
CREATEDATE | DATE | Date when schema created
CREATETIME | TIME | Time when schema created


SEQUENCES (MaxDB: Reference Manual)

SEQUENCES

The system table SEQUENCES contains all sequences for which the current user has privileges.

SEQUENCES

OWNER | CHAR(32) | Name of sequence owner
SEQUENCE_NAME | CHAR(32) | Name of the sequence
MIN_VALUE | FIXED(38) | Minimum value of the sequence
MAX_VALUE | FIXED(38) | Maximum value of the sequence
INCREMENT_BY | FIXED(38) | Value by which the sequence is increased
CYCLE_FLAG | CHAR(1) | Does the sequence begin again with the minimum value once the maximum value has been reached?
ORDER_FLAG | CHAR(1) | Are the sequence values granted in the order of the request?
CACHE_SIZE | FIXED(38) | Number of sequence values that are loaded into the cache simultaneously
LAST_NUMBER | FIXED(38) | Last sequence value that was saved
CREATEDATE | DATE(10) | Creation date of the sequence
CREATETIME | TIME(8) | Creation time of the sequence
COMMENT | LONG | Comment about the sequence

See also:

Evaluating System Tables ® SEQUENCES


SERVERDBSTATISTICS (MaxDB: Reference Manual)

SERVERDBSTATISTICS

The statistics system table SERVERDBSTATISTICS contains information about the used space in the database instance.

SERVERDBSTATISTICS

SERVERDBSIZE | FIXED(10) | Size of the database instance in pages
MAXDATAPAGENO | FIXED(10) | Highest page number of the database instance
MAXPERM | FIXED(10) | Number of pages of the database instance that can be used for non-temporary objects
MAXUSEDPAGES | FIXED(10) | Maximum number of used pages for a synchronization point (restart or savepoint)
USEDPERM | FIXED(10) | Number of pages of the database instance that are used for non-temporary objects
PCTUSEDPERM | FIXED(10) | Percentage of pages for non-temporary objects
USEDTMP | FIXED(10) | Number of pages of the database instance that are used for temporary objects
PCTUSEDTMP | FIXED(10) | Percentage of pages for temporary objects
UNUSED | FIXED(10) | Number of unused pages
PCTUNUSED | FIXED(10) | Percentage of unused pages
UPDATEDPERM | FIXED(10) | Number of changed pages for permanent objects
SERVERDBFULL | CHAR(3) | YES: maximum fill level of the database instance has been reached NO: maximum fill level of the database instance has not been reached
USEDBLOCKS | FIXED(10) | Number of blocks on data volumes that are used by pages
LOGSIZE | FIXED(10) | Size of the log area in pages
USEDLOG | FIXED(10) | Number of used log pages
PCTUSEDLOG | FIXED(10) | Percentage of used log pages
LOGNOTSAVED | FIXED(10) | Number of unsaved log pages
PCTLOGNOTSAVED | FIXED(10) | Percentage of unsaved log pages
LOGSINCEBACKUP | FIXED(10) | Number of written log pages since the last complete or incremental data backup
LOGSEGMENTSIZE | FIXED(10) | Size of a log segment in pages
SAVEPOINTS | FIXED(10) | Number of executed savepoints


SESSION_ROLES (MaxDB: Reference Manual)

SESSION_ROLES

The system table SESSION_ROLES contains the roles that are active in the current database session.

SESSION_ROLES

ROLE

CHAR(32)

Name of role

See also:

Evaluating System Tables ® SESSION_ROLES


SESSIONS (MaxDB: Reference Manual)

SESSIONS

The system table SESSIONS describes the connection between an application and a database task.

SESSIONS

SESSIONID | FIXED(10) | ID of the database session
OWN | CHAR(3) | Current database session (YES|NO)
STARTDATE | TIMESTAMP | Time when database session started
APPLICATIONNODE | CHAR(64) | Name of the computer on which the application is running
APPLICATIONPROCESS | FIXED(10) | Operating system ID of the application
APPLICATIONTYPE | CHAR(3) | ID of the tool or interface that the application is using
USERNAME | CHAR(32) UNICODE | Name of the database user
PEERPROCESSID | FIXED(10) | ID of the communication partner of the database task
CONNECTSTATE | CHAR(32) | Status of the connection
TASKID | FIXED(10) | ID of the database task
OMSHEAPUSEDSIZE | FIXED(20) | Memory used in the [image] OMS heap (KB)
TRACE | CHAR(3) | The database trace is written for this database session/all database sessions (YES|NO).
CATALOGCACHEUSEDSIZE | FIXED(10) | Space used by the catalog cache assigned to the database session (KB)
TEMPSPACEUSEDSIZE | FIXED(10) | Space used for temporary information about your database session (KB) | NULL for the other database sessions
PAGINGFILEUSEDSIZE | FIXED(10) | Size of the parse file. This value is determined only if DIAGNOSE COUNT SESSION FILE ON is set.
SQLMODE | CHAR(8) | SQL modes of your database session | NULL for the other database sessions
ISOLATIONLEVEL | FIXED(10) | Isolation level of your database session | NULL for the other database sessions
TIMEOUT | FIXED(10) | Timeout value of your database session | NULL for the other database sessions
DATEFORMAT | CHAR(50) | Date and time format of your database session | NULL for the other database sessions


SNAPSHOTS (MaxDB: Reference Manual)

SNAPSHOTS

The system table SNAPSHOTS contains information about a defined view (snapshot) of the data.

SNAPSHOTS

ID | FIXED(10) | Current converter version when the snapshot was defined
CREATEDATE | TIMESTAMP | Time when the snapshot was defined
USEDSIZE | FIXED(20) | Amount of data used for the snapshot (KB)


SYNONYMS (MaxDB: Reference Manual)

SYNONYMS

The system table SYNONYMS contains all synonyms for which the current user has privileges.

SYNONYMS

OWNER | CHAR(32) | Name of synonym owner
SYNONYMNAME | CHAR(32) | Name of synonym
PUBLIC | CHAR(3) | Synonym is PUBLIC (YES | NO)
TABLEOWNER | CHAR(32) | Name of table owner
TABLENAME | CHAR(32) | Name of the table
CREATEDATE | DATE(10) | Creation date of the synonym
CREATETIME | TIME(8) | Creation time of the synonym
COMMENT | LONG | Comment about synonym

See also:

Evaluating System Tables ® SYNONYMS


TABLEPRIVILEGES (MaxDB: Reference Manual)

TABLEPRIVILEGES

The system table TABLEPRIVILEGES describes the privileges that the current user has for tables.

TABLEPRIVILEGES

OWNER | CHAR(32) | Name of table owner
TABLENAME | CHAR(32) | Name of the table
GRANTOR | CHAR(32) | Name of the user who granted the privileges
GRANTEE | CHAR(32) | Name of the user or the role that was granted the privilege
PRIVILEGES | CHAR(30) | Privileges that were granted
IS_GRANTABLE | CHAR(3) | Privilege to grant the received privilege to another user/role (YES | NO)

See also:

Evaluating System Tables ® TABLEPRIVILEGES


TABLES (MaxDB: Reference Manual)

TABLES

The system table TABLES contains all the tables (base tables, view tables, synonyms, and event tables) for which the current user has privileges.

TABLES

OWNER | CHAR(32) | Name of the owner of the table
TABLENAME | CHAR(32) | Name of the table
PRIVILEGES | CHAR(30) | Privileges that the current user has for the table
TYPE | CHAR(8) | Type of the table (SYSTEMS | TABLES)
TABLETYPE | CHAR(8) | Type of the table (TABLE | VIEW | SYNONYM | RESULT)
CREATEDATE | DATE(10) | Date when table created
CREATETIME | TIME(8) | Time when table created
UPDSTATDATE | DATE(10) | Date of the last UPDATE STATISTICS statement for the table
UPDSTATTIME | TIME(8) | Time of the last UPDATE STATISTICS statement for the table
ALTERDATE | DATE(10) | Date when table changed
ALTERTIME | TIME(8) | Time when table changed
UNLOADED | CHAR(3) | Table is unloaded (YES | NO)
SAMPLE_PERCENT | FIXED(3) | Percentage of the table that is read for updating statistics
SAMPLE_ROWS | FIXED(10) | Number of rows in the table that are read for updating statistics
COMMENT | LONG | Comment about the table
TABLEID | CHAR(8) BYTE | Table ID in hexadecimal format
DYNAMIC | CHAR(3) | Table was defined with DYNAMIC option (YES|NO)
ARCHIVE | CHAR(3) | Table was defined with FOR ARCHIVE option (YES|NO)
VARIABLE_COLUMNS | CHAR(3) | Columns are stored with variable length (YES|NO); see CREATE TABLE Statement

See also:

Evaluating System Tables ® TABLES


TABLESTATISTICS (MaxDB: Reference Manual)

TABLESTATISTICS

The statistics system table TABLESTATISTICS contains information about the structure and sizes of base tables.

TABLESTATISTICS

OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Table name
DESCRIPTION | CHAR(40) | Description (see table Column DESCRIPTION) of how to interpret following columns
CHAR_VALUE | CHAR(12) | Alphanumeric value
NUMERIC_VALUE | FIXED(10) | Numeric value

Column DESCRIPTION

Value | Explanation
Root pno | NUMERIC_VALUE contains the page number of the root of the B* tree
Filetype | CHAR_VALUE contains the type of the B* tree
Used pages | NUMERIC_VALUE indicates how many pages are used by the table
Index pages | NUMERIC_VALUE indicates how many pages are used by the table in the B* tree index
Leaf pages | NUMERIC_VALUE indicates how many leaf pages are used by the table
Index levels | NUMERIC_VALUE contains the number of index levels of the B* tree
Space used in all pages(%) | NUMERIC_VALUE contains the used space of all pages in the B* tree (as a percentage)
Space used in root page(%) | NUMERIC_VALUE contains the used space of the root page in the B* tree (as a percentage)
Space used in index pages(%) | NUMERIC_VALUE contains the used space of the index pages in the B* tree (as a percentage)
Space used in index pages(%) min | NUMERIC_VALUE contains the minimum used space of the index pages in the B* tree (as a percentage)
Space used in index pages(%) max | NUMERIC_VALUE contains the maximum used space of the index pages in the B* tree (as a percentage)
Space used in leaf pages(%) | NUMERIC_VALUE contains the used space of the leaf pages in the B* tree (as a percentage)
Space used in leaf pages(%) min | NUMERIC_VALUE contains the minimum used space of the leaf pages in the B* tree (as a percentage)
Space used in leaf pages(%) max | NUMERIC_VALUE contains the maximum used space of the leaf pages in the B* tree (as a percentage)
Rows | NUMERIC_VALUE contains the number of rows in the table
Avg rows per page | NUMERIC_VALUE contains the average number of rows for each page
Min rows per page | NUMERIC_VALUE contains the minimum number of rows for each page
Max rows per page | NUMERIC_VALUE contains the maximum number of rows for each page
Avg row length | NUMERIC_VALUE contains the average length of a row
Min row length | NUMERIC_VALUE contains the minimum length of a row
Max row length | NUMERIC_VALUE contains the maximum length of a row
Avg key length | NUMERIC_VALUE contains the average length of a key
Min key length | NUMERIC_VALUE contains the minimum length of a key
Max key length | NUMERIC_VALUE contains the maximum length of a key
Avg separator length | NUMERIC_VALUE contains the average length of a separator
Min separator length | NUMERIC_VALUE contains the minimum length of a separator
Max separator length | NUMERIC_VALUE contains the maximum length of a separator
Defined LONG columns | NUMERIC_VALUE contains the number of defined LONG columns
Avg LONG column length | NUMERIC_VALUE contains the average length of a LONG column
Min LONG column length | NUMERIC_VALUE contains the minimum length of a LONG column
Max LONG column length | NUMERIC_VALUE contains the maximum length of a LONG column
LONG column pages | NUMERIC_VALUE contains the number of pages of all the LONG columns in the table
Avg pages per LONG column | NUMERIC_VALUE contains the average number of pages in the table for each LONG column
Min pages per LONG column | NUMERIC_VALUE contains the smallest LONG column in the table (in pages)
Max pages per LONG column | NUMERIC_VALUE contains the largest LONG column in the table (in pages)


TRANSACTIONS (MaxDB: Reference Manual)

TRANSACTIONS

The statistics system table TRANSACTIONS contains information about active transactions of a database instance.

TRANSACTIONS

SESSION | FIXED(10) | ID of the database session
TRANSCOUNT | CHAR(20) | ID of the transaction
SUB_TRANS | FIXED(10) | Number of the current subtransaction
WRITE_TRANS | CHAR(6) BYTE | ID of the current write transaction if the transaction has made changes
PROCESS | FIXED(10) | ID of the user process
USERNAME | CHAR(32) | User name
CONNECTDATE | DATE | Date when the session started
CONNECTTIME | TIME | Time when the session started
TERMID | CHAR(18) | Terminal ID
REQTIMEOUT | CHAR(10) | Seconds remaining until time specified in the database parameter REQUEST_TIMEOUT
LASTWRITE | CHAR(10) | Time elapsed since the last write request in timeout intervals
LOCKMODE | CHAR(14) | Type of lock
LOCKSTATE | CHAR(10) | Status of lock
REQMODE | CHAR(14) | Type of lock request
REQSTATE | CHAR(10) | Status of the lock request
CONSISTENTVIEW | CHAR(6) | For future use
APPLPROCESS | FIXED(10) | ID of the application process
APPLNODEID | CHAR(64) | ID of the client host of the application process


TRIGGERS (MaxDB: Reference Manual)

TRIGGERS

The system table TRIGGERS contains all triggers for which the current user has privileges.

TRIGGERS

OWNER | CHAR(32) | Name of table owner
TABLENAME | CHAR(32) | Name of the table for which the trigger was defined
TRIGGERNAME | CHAR(32) | Name of the trigger
INSERT | CHAR(3) | Type of trigger
UPDATE | CHAR(3) | Type of trigger
DELETE | CHAR(3) | Type of trigger
CREATEDATE | DATE(10) | Creation date of the trigger
CREATETIME | TIME(8) | Creation time of the trigger
DEFINITION | LONG | Text of the trigger definition
COMMENT | LONG | Comment about the trigger

See also:

Evaluating System Tables ® TRIGGERS


USERS (MaxDB: Reference Manual)

USERS

The system table USERS contains all database users.

USERS

OWNER | CHAR(32) | Name of user owner
GROUPNAME | CHAR(32) | Name of the group
USERNAME | CHAR(32) | Name of user
USERMODE | CHAR(8) | Class of the database user (SYSDBA | DBA | RESOURCE | STANDARD)
CONNECTMODE | CHAR(8) | Type of connection (MULTIPLE | SINGLE)
MAXTIMEOUT | FIXED(10) | Timeout value
COSTWARNING | FIXED(10) | Value of the COSTWARNING
COSTLIMIT | FIXED(10) | Value of the COSTLIMIT
DEFAULTCODE | CHAR(8) | Default value for code attribute
CREATEDATE | DATE(10) | Creation date of user
CREATETIME | TIME(8) | Creation time of user
ALTERDATE | DATE(10) | Change date of user
ALTERTIME | TIME(8) | Change time of user
PWCREADATE | DATE(10) | Creation date of password
PWCREATIME | TIME(8) | Creation time of password
SERVERDB | CHAR(18) | Name of database instance
SERVERNODE | CHAR(64) | Host node name of database instance
USER_ID | FIXED(10) | ID of the user
COMMENT | LONG | Comment about user

See also:

Evaluating System Tables ® USERS


USERSTATISTICS (MaxDB: Reference Manual)

USERSTATISTICS

The statistics system table USERSTATISTICS contains information about the resource consumption of users.

USERSTATISTICS

USERNAME | CHAR(32) | User name
USERMODE | CHAR(8) | User class
PERMCOUNT | FIXED(10) | Pages currently used for permanent objects
TEMPCOUNT | FIXED(10) | Pages currently used for temporary objects


VERSION (MaxDB: Reference Manual)

VERSION

The system table VERSION describes the version of the database software (kernel and runtime environment).

VERSIONS

OPERATINGSYSTEM | CHAR(64) | Name of the operating system
PROCESSORTYPE | CHAR(64) | Name of the processor vendor
ADDRESSINGMODE | FIXED(2) | Specifies whether a 32 bit or 64 bit platform is being used
ID | CHAR(40) | Current version, including build level
MAJORVERSION | FIXED(2) | Number of the major version
MINORVERSION | FIXED(2) | Number of the minor version
CORRECTIONLEVEL | FIXED(2) | Number of the correction level
BUILD | FIXED(2) | Build level
KERNELVARIANT | CHAR(8) | Variant of the kernel (SLOW | QUICK | FAST)


VERSIONS (MaxDB: Reference Manual)

VERSIONS

The system table VERSIONS describes the versions of the database software.

VERSIONS

KERNEL | CHAR(40) | Version of the database software
RUNTIMEENVIRONMENT | CHAR(40) | Version of the runtime environment

See also:

Evaluating System Tables ® VERSIONS


VIEWCOLUMNS (MaxDB: Reference Manual)

VIEWCOLUMNS

The system table VIEWCOLUMNS contains all the columns of the view tables for which the current user has privileges.

VIEWCOLUMNS

OWNER | CHAR(32) | Name of the owner of the view table
VIEWNAME | CHAR(32) | Name of the view table
VIEWCOLUMNNAME | CHAR(32) | Name of the column in the view table
TABLEOWNER | CHAR(32) | Name of the owner of the table that the used column belongs to
TABLENAME | CHAR(32) | Name of the table that the used column belongs to
COLUMNNAME | CHAR(32) | Original name of the column in the table
CREATEDATE | DATE(10) | Creation date of the view table
CREATETIME | TIME(8) | Creation time of the view table

See also:

Evaluating System Tables ® VIEWCOLUMNS


VIEWDEFS (MaxDB: Reference Manual)

VIEWDEFS

The system table VIEWDEFS contains the definitions of the view tables for which the current user has privileges.

VIEWDEFS

OWNER | CHAR(32) | Name of the owner of the view table
VIEWNAME | CHAR(32) | Name of the view table
LEN | FIXED(5) | Length of the definition of the view table
DEFINITION | LONG | Text of the definition of the view table

See also:

Evaluating System Tables ® VIEWDEFS


VIEWS (MaxDB: Reference Manual)

VIEWS

The system table VIEWS contains all view tables for which the current user has privileges.

VIEWS

OWNER | CHAR(32) | Name of the owner of the view table
VIEWNAME | CHAR(32) | Name of the view table
PRIVILEGES | CHAR(30) | Privileges of the user for the view table
TYPE | CHAR(8) | Table type
CREATEDATE | DATE(10) | Creation date of the view table
CREATETIME | TIME(8) | Creation time of the view table
UPDSTATDATE | DATE(10) | Date of the last UPDATE STATISTICS statement for the view table
UPDSTATTIME | TIME(8) | Date of the last UPDATE STATISTICS statement for the view table
ALTERDATE | DATE(10) | Change date of the view table
ALTERTIME | TIME(8) | Change time of the view table
UNLOADED | CHAR(3) | View table is unloaded (YES | NO)
COMMENT | LONG | Comment about the view table

See also:

Evaluating System Tables ® VIEWS


ORACLE SQL Mode (MaxDB: Reference Manual)

ORACLE SQL Mode

This documentation describes the differences in logical data storage and the definition of SQL syntax for the database systems Oracle Version 7 and MySQL MaxDB, ORACLE SQL mode.

For general information about the database system, see the Database Administration documentation.

For information about the SQL syntax of the database system, see the Reference Manual.

The differences are described in the following sections:

· General Differences

· SQL Syntax Elements

· SQL Syntax Statements

· System Tables

· Error Messages


General Differences (MaxDB: Reference Manual)

General Differences

Logical database structure

There are basic differences between the logical database structures of the database systems Oracle Version 7 and MySQL MaxDB.

· From a logical point of view, an Oracle database consists of tablespaces, segments, extents, blocks, tables, and data records.

· From a logical point of view, MaxDB consists basically of the tables in the database catalog and the application data in the form of data records.

All Oracle statements referring to the administration of tablespaces, segments, extents, or blocks are therefore meaningless in MaxDB.

Consistent reading/locking

The consistent reading offered by Oracle can be achieved in MaxDB using locks in isolation level >= 2.

Oracle allows an unlimited number of exclusive row locks. In MaxDB, an escalation takes effect from a certain number of row locks; that is, the whole table will be locked. The time of escalation depends on the defined lock list size.

Database procedures/triggers

· In Oracle, database procedures, DB functions, and triggers are defined in PL/SQL, a language similar to ADA.

· In MaxDB, database procedures and triggers are defined in a language similar to C.

Database objects and their schemas

Database users can only create or delete database objects in or from their own schemas, or create database objects that are not assigned to a particular user (index, for example). It is not possible to create database objects in the schema of another user.

DBA users and privileges

In contrast to Oracle, database administrators (DBA users) in MaxDB are also subject to the privileges concept and cannot execute DDL statements (such as CREATE INDEX) or DML statements (such as DELETE) for which they have not received the corresponding privileges.


SQL Syntax Elements (MaxDB: Reference Manual)

SQL Syntax Elements

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the following areas:

· Schema Object

· Name

· Namespace

· Access to Objects

· Integer

· Number

· Data Type

· Pseudo Column

· Operator

· Function

· Format


Schema Object (MaxDB: Reference Manual)

Schema Object

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of possible schema objects.

The following schema objects are not supported by MySQL MaxDB:

· Cluster

· Database link

· Package

· Profile

· Rollback segment

· Snapshot

· Snapshot log

· Tablespace

The following schema objects are supported by MySQL MaxDB, but use a different syntax than Oracle:

Procedure (object in MySQL MaxDB: database procedure)


Name (MaxDB: Reference Manual)

Name

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of names for objects.

If MySQL MaxDB assigns names for objects, these names differ from the names generated by Oracle.

The following keywords are reserved in Oracle 7 but not in MySQL MaxDB:

ACCESS | COMPRESS | ELSE | FILE
IMMEDIATE | INCREMENT | INITIAL | MAXEXTENTS
NOAUDIT | NOCOMPRESS | OFFLINE | ONLINE
PRIOR | SIZE | START | SUCCESSFUL
THEN | VALIDATE |  |

If possible, these key words should not be used to designate objects in MySQL MaxDB.

You can find a list of all the keywords reserved in MySQL MaxDB in the section reserved_key_word of the Reference Manual.

You can find a list of all the keywords not reserved in MySQL MaxDB in the section not_reserved_key_word of the Reference Manual.


Namespace (MaxDB: Reference Manual)

Namespace

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of namespaces.

Differences in the namespace

Oracle 7 | MySQL MaxDB
All indexes of a database instance form a namespace. | All indexes of a table form a namespace.
All constraints of a database instance form a namespace. | All constraints of a table form a namespace.
All triggers of a database instance form a namespace. | All triggers of a table form a namespace.
All sequences, together with the tables, views, synonyms, procedures, and further objects, form a namespace. | All sequences of a database instance form a separate namespace.
All procedures, together with the tables, views, sequences, synonyms, and further objects, form a namespace. | All database procedures of a database instance form a separate namespace.


Access to Objects (MaxDB: Reference Manual)

Access to Objects

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, with regard to object access.

If an owner is not specified when a database object is accessed, and no object belonging to the current user exists with this name, the following procedure, different to the Oracle for MaxDB procedure, applies when the database object is accessed:

...

1. MaxDB searches for this object in the PUBLIC synonyms.

2. If the object was not found, MaxDB searches for this object in the part of the database catalog of the DBA user that the current user generated.

3. If the object was not found, MaxDB searches for this object in SYSDBA user’s part of the database catalog.


Integer (MaxDB: Reference Manual)

Integer

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of integers.

In contrast to Oracle, an integer in MySQL MaxDB has 20 significant characters.


Number (MaxDB: Reference Manual)

Number

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of numbers.

· For Oracle, the permitted value area for numbers covers values from 0.999E-128 to 0.999E126.

· In MySQL MaxDB, the permitted value area for floating point numbers (Number) consists of the interval from -9.9999999999999999999999999999999999999E+62 to -1E-64, the value 0.0, and the interval from +1E-64 to +9.9999999999999999999999999999999999999E+62.


Data Type (MaxDB: Reference Manual)

Data Type

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of data types.

· In contrast to Oracle, columns with the data type CHAR[ACTER] are only stored up to a length of 30 characters with fixed length in MySQL MaxDB.

· The Oracle data type VARCHAR2 does not differ from VARCHAR in MySQL MaxDB.

· The data types INT[EGER] and SMALLINT have 20 significant digits in MySQL MaxDB.

· In MySQL MaxDB, the data type FLOAT is always represented with 20 significant digits.

· In MySQL MaxDB, numerical data types cannot be defined with a negative number of decimal places. It is not possible to specify a scale that is greater than the number of significant digits.

· In MySQL MaxDB, numbers are not implicitly converted into date values or vice versa.

· In Oracle, date values run from 1.1.4712 BC to 31.12.9999 AD.
In MySQL MaxDB, date values run from 1.1.0001 to 31.12.9999.

· My SQL MaxDB does not support the comparison of character strings denoted as "non padded comparison" in Oracle.

· The data types NCHAR, NVARCHAR2, MLSLABEL, BLOB, CLOB, NCLOB, BFILE, and UROWID, which are supported by Oracle, are not supported by MySQL MaxDB.


Pseudo Column (MaxDB: Reference Manual)

Pseudo Column

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of pseudo columns.

· The pseudo column LEVEL is not supported in MySQL MaxDB.

· Pseudo column ROWID can only be used if the option ROWID was specified in the CREATE TABLE statement. In contrast to Oracle, MySQL MaxDB produces a logical column identification of the data type RAW(8).

· In MySQL MaxDB, pseudo column ROWNUM cannot be used in the UPDATE statement.

· The pseudo column ROWNUM is entered into a selected column (select_column) after the result table has been sorted.


Operator (MaxDB: Reference Manual)

Operator

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of operators.

The Oracle operator PRIOR is not supported in MySQL MaxDB.


Function (MaxDB: Reference Manual)

Function

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of functions.

· The following Oracle functions are not supported as functions in MySQL MaxDB:

- CHARTOROWID

- ROWIDTOCHAR

- CONVERT

- DUMP

- USERENV

- NLS_INITCAP

- NLS_LOWER

- NLS_UPPER

- TO_MULTI_BYTE

- TO_SINGLE_BYTE

- INSTRB

- LENGTHB

- SUBSTRB

· When string functions LPAD and RPAD are specified in MySQL MaxDB, the character string x cannot be longer than n.

· When string function SUBSTR is specified in MySQL MaxDB, a cannot be less than 1.

· When the function INSTR is specified in MySQL MaxDB, the parameter "n" must not be smaller than 1.

· When functions TO_CHAR, TO_DATE, and TO_NUMBER are specified in MySQL MaxDB, the parameter "nlsparams" is not available.


Format (MaxDB: Reference Manual)

Format

The SQL syntax elements for Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE differ, among other things, in the definition of the date format.

If not specified otherwise in the ALTER SESSION statement, date format DD-MON-YY, language English, and BINARY sorting are assumed for a database session in MySQL MaxDB.


SQL Statements (MaxDB: Reference Manual)

SQL Statements

This section lists all the Oracle SQL statements with different behavior in Oracle Version 7 and MySQL MaxDB in SQL mode ORACLE.

A detailed description of the syntax of the Oracle SQL statements can be found in the ORACLE7 Server SQL Reference Manual, and not in the sections below. The Oracle SQL statements are listed in the same order that is used in the ORACLE7 Server SQL Reference Manual.

To enable a better understanding of the system explanations, a reference to the syntax description of the relevant MySQL MaxDB-SQL statement in the Reference Manual has been provided where appropriate.

For SQL statements not listed below, it can be assumed that there are no differences other than those described in the section General Differences.


alter_cluster_statement (MaxDB: Reference Manual)

alter_cluster_statement

The schema object cluster is not supported by MySQL MaxDB. The SQL statement ALTER CLUSTER (alter_cluster_statement) is therefore not accepted by MySQL MaxDB.


alter_database_statement (MaxDB: Reference Manual)

alter_database_statement

The SQL statement ALTER DATABASE (alter_database_statement) is not accepted by MySQL MaxDB.


alter_function_statement (MaxDB: Reference Manual)

alter_function_statement

The SQL statement ALTER FUNCTION (alter_function_statement) is rejected by MySQL MaxDB.


alter_index_statement (MaxDB: Reference Manual)

alter_index_statement

Since MySQL MaxDB needs no reorganization, you do not have to modify the memory characteristics for indexes. The SQL statement ALTER INDEX (alter_index_statement) is known in MySQL MaxDB, but has different syntax and semantics to Oracle (ALTER INDEX statement).


alter_package_statement (MaxDB: Reference Manual)

alter_package_statement

The SQL statement ALTER PACKAGE (alter_package_statement) is not accepted by MySQL MaxDB.


alter_procedure_statement (MaxDB: Reference Manual)

alter_procedure_statement

The SQL statement ALTER PROCEDURE (alter_procedure_statement) is not accepted by MySQL MaxDB.


alter_profile_statement (MaxDB: Reference Manual)

alter_profile_statement

The schema object profile is not supported by MySQL MaxDB. The SQL statement ALTER PROFILE (alter_profile_statement) is therefore not accepted by MySQL MaxDB.


alter_resource_cost_statement (MaxDB: Reference Manual)

alter_resource_cost_statement

The SQL statement ALTER RESOURCE COST (alter_resource_cost_statement) is not accepted by MySQL MaxDB.


alter_role_statement (MaxDB: Reference Manual)

alter_role_statement

The SQL statement ALTER ROLE (alter_role_statement) is not accepted by MySQL MaxDB.


alter_rollback_segment_statement (MaxDB: Reference Manual)

alter_rollback_segment_statement

The schema object rollback segment is not supported by MySQL MaxDB. The SQL statement ALTER ROLLBACK SEGMENT (alter_rollback_segment_statement) is therefore not accepted by MySQL MaxDB.


alter_sequence_statement (MaxDB: Reference Manual)

alter_sequence_statement

The SQL statement ALTER SEQUENCE (alter_sequence_statement) is not accepted by MySQL MaxDB.


alter_snapshot_statement (MaxDB: Reference Manual)

alter_snapshot_statement

The schema object snapshot is not supported by MySQL MaxDB. The SQL statement ALTER SNAPSHOT (alter_snapshot_statement) is therefore not accepted by MySQL MaxDB.


alter_snapshot_log_statement (MaxDB: Reference Manual)

alter_snapshot_log_statement

The schema object snapshot log is not supported by MySQL MaxDB. The SQL statement ALTER SNAPSHOT LOG (alter_snapshot_log_statement) is therefore not accepted by MySQL MaxDB.


alter_system_statement (MaxDB: Reference Manual)

alter_system_statement

The SQL statement ALTER SYSTEM (alter_system_statement) is not accepted by MySQL MaxDB.


alter_table_statement (MaxDB: Reference Manual)

alter_table_statement

The SQL statement ALTER TABLE (alter_table_statement) is known in MySQL MaxDB, but has different syntax and semantics to Oracle (ALTER TABLE statement).

· The variants PCTFREE, PCTUSED, INITRANS, MAXTRANS, STORAGE, DROP, and ALLOCATE are meaningless in MySQL MaxDB and are rejected.

· MySQL MaxDB cannot deactivate constraints. MySQL MaxDB therefore ignores the specification of DISABLE.

· MySQL MaxDB cannot delete any UNIQUE constraints using the DROP clause. The DROP INDEX statement must be used for this instead.

· When columns are inserted, MySQL MaxDB automatically inserts these columns in all view tables that use the "*" in the <select_list>, in order to identify all columns of the table.


alter_tablespace_statement (MaxDB: Reference Manual)

alter_tablespace_statement

The schema object tablespace is not supported by MySQL MaxDB. The SQL statement ALTER TABLEPSACE (alter_tablespace_statement) is therefore not accepted by MySQL MaxDB.


alter_trigger_statement (MaxDB: Reference Manual)

alter_trigger_statement

MySQL MaxDB cannot deactivate triggers. The SQL statement ALTER TRIGGER (alter_trigger_statement) is therefore not accepted by MySQL MaxDB.


alter_user_statement (MaxDB: Reference Manual)

alter_user_statement

The SQL statement ALTER USER (alter_user_statement) is supported with a restricted syntax by MySQL MaxDB. In MySQL MaxDB, the ALTER USER- statement can only be used to change the user’s password. MySQL MaxDB rejects the specification of EXTERNALLY.

All other variants of the ALTER USER statement are rejected by MySQL MaxDB.


alter_view_statement (MaxDB: Reference Manual)

alter_view_statement

MySQL MaxDB always keeps view tables in an executable state. The SQL statement ALTER VIEW (alter_view_statement) is therefore not necessary, and is not accepted.


analyze_statement (MaxDB: Reference Manual)

analyze_statement

MySQL MaxDB only supports the variant ANALYZE TABLE for the SQL statement ANALYZE (analyze_statement). The options DELETE, VALIDATE STRUCTURE, and LIST CHAINED ROWS are not valid in MySQL MaxDB.


audit_statement (MaxDB: Reference Manual)

audit_statement

The SQL statement AUDIT (audit_statement) is not accepted by MySQL MaxDB.


commit_statement (MaxDB: Reference Manual)

commit_statement

MySQL MaxDB does not accept the specification of FORCE or COMMENT for the SQL statement COMMIT (commit_statement).


constraint_clause (MaxDB: Reference Manual)

constraint_clause

The following restrictions exist in MySQL MaxDB for the syntax element CONSTRAINT clause used in SQL statements:

· A constraint_name for a key or [NOT] NULL is not stored in the database catalog.

· USING INDEX is allowed within the syntax, but meaningless in MySQL MaxDB.

· MySQL MaxDB ignores the DISABLE option.


create_cluster_statement (MaxDB: Reference Manual)

create_cluster_statement

The schema object cluster is not supported by MySQL MaxDB. The SQL statement CREATE CLUSTER (create_cluster_statement) is therefore not accepted by MySQL MaxDB.


create_controlfile_statement (MaxDB: Reference Manual)

create_controlfile_statement

The SQL statement CREATE CONTROLFILE (create_controlfile_statement) is not accepted by MySQL MaxDB.


create_database_statement (MaxDB: Reference Manual)

create_database_statement

The SQL statement CREATE DATABASE (create_database_statement) is not accepted by MySQL MaxDB.


create_database_link_statement (MaxDB: Reference Manual)

create_database_link_statement

The schema object database link is not supported by MySQL MaxDB. The SQL statement CREATE DATABASE LINK (create_database_link_statement) is therefore not accepted by MySQL MaxDB.


create_function_statement (MaxDB: Reference Manual)

create_function_statement

The SQL statement CREATE FUNCTION (create_function_statement) is not accepted by MySQL MaxDB.


create_index_statement (MaxDB: Reference Manual)

create_index_statement

The SQL statement CREATE INDEX (create_index_statement) is known in MySQL MaxDB, but has different syntax and semantics to Oracle (CREATE INDEX statement).

· The specification of CLUSTER <cluster>, INITRANS <integer>, MAXTRANS <integer>, TABLESPACE <tablespace>, STORAGE <storage_clause>, PCTFREE <integer>, and NOSORT is meaningless in MySQL MaxDB, but is accepted by the syntax.

· The index is generated in descending order in MySQL MaxDB when DESC is specified.


create_package_statement (MaxDB: Reference Manual)

create_package_statement

The SQL statement CREATE PACKAGE (create_package_statement) is not accepted by MySQL MaxDB.


create_package_body_statement (MaxDB: Reference Manual)

create_package_body_statement

The SQL statement CREATE PACKAGE BODY (create_package_body_statement) is not accepted by MySQL MaxDB.


create_procedure_statement (MaxDB: Reference Manual)

create_procedure_statement

The SQL statement CREATE PROCEDURE (create_procedure_statement) is not accepted by MySQL MaxDB.


create_profile_statement (MaxDB: Reference Manual)

create_profile_statement

The schema object profile is not supported by MySQL MaxDB. The SQL statement CREATE PROFILE (create_profile_statement) is therefore not accepted by MySQL MaxDB.


create_rollback_segment_statement (MaxDB: Reference Manual)

create_rollback_segment_statement

The schema object rollback segment is not supported by MySQL MaxDB. The SQL statement CREATE ROLLBACK SEGMENT (create_rollback_segment_statement) is therefore not accepted by MySQL MaxDB.


create_schema_statement (MaxDB: Reference Manual)

create_schema_statement

The SQL statement CREATE SCHEMA (create_schema_statement) is not accepted by MySQL MaxDB.


create_sequence_statement (MaxDB: Reference Manual)

create_sequence_statement

MySQL MaxDB accepts the SQL statement CREATE SEQUENCE (create_sequence_statement) with the following syntax restrictions: the options CACHE and ORDER are meaningless for MySQL MaxDB (CREATE SEQUENCE statement).


create_snapshot_statement (MaxDB: Reference Manual)

create_snapshot_statement

The schema object snapshot is not supported by MySQL MaxDB. The SQL statement CREATE SNAPSHOT (create_snapshot_statement) is not accepted by MySQL MaxDB.


create_snapshot_log_statement (MaxDB: Reference Manual)

create_snapshot_log_statement

The schema object snapshot log is not supported by MySQL MaxDB. The SQL statement CREATE SNAPSHOT LOG (create_snapshot_log_statement) is therefore not accepted by MySQL MaxDB.


create_synonym_statement (MaxDB: Reference Manual)

create_synonym_statement

MySQL MaxDB does not permit any database procedures, synonyms, or synonyms for sequences.

At the time of execution of the SQL statement CREATE SYNONYM (create_synonym_statement), the object for which the synonym is defined in MySQL MaxDB must exist. The current user must have a privilege for this object.


create_table_statement (MaxDB: Reference Manual)

create_table_statement

The SQL statement CREATE TABLE (create_table_statement) is known in MySQL MaxDB, but has different syntax and semantics to Oracle (CREATE TABLE statement).

· The specification of PCTFREE <integer>, PCTUSED <integer>, INITRANS <integer>, MAXTRANS <integer>, TABLESPACE <tablespace>, STORAGE <storage clause>, and CLUSTER <cluster> is allowed by the syntax, but are all meaningless in MySQL MaxDB.

· MySQL MaxDB ignores the specification of DISABLE.

· If a subquery is specified, MySQL MaxDB does not generate NOT NULL constraints.

· In Oracle, each table row has a unique address that can be accessed as ROWID. The row can be addressed directly by using the ROWID. The ROWID also exists if the table has a key. Such an address is not available in MySQL MaxDB, because the rows are always addressed using the key.
Table option ROWID can be used to better imitate Oracle behavior. This has the following effect: The table implicitly received key column ROWID from data type RAW(8). This column is usually invisible and can only be selected using the ROWID function.
- If the CREATE TABLE statement contains a key_definition, an index with the UNIQUE attribute that corresponds to the key definition is generated.

In this way, a row has a ROWID and can be selected with the ROWID and the key.


create_tablespace_statement (MaxDB: Reference Manual)

create_tablespace_statement

The schema object tablespace is not supported by MySQL MaxDB. Nevertheless, MySQL MaxDB still accepts the SQL statement CREATE TABLESPACE (create_tablespace_statement) syntactically, even though it has no effect.


create_trigger_statement (MaxDB: Reference Manual)

create_trigger_statement

In MySQL MaxDB, the SQL statement CREATE TRIGGER (create_trigger_statement) can only be used to define the triggers described in Oracle as “after row triggers”.


create_user_statement (MaxDB: Reference Manual)

create_user_statement

The SQL statement CREATE USER (create_user_statement) is supported in MySQL MaxDB with restricted syntax. In the CREATE USER_statement, MySQL MaxDB does not accept the specification of IDENTIFIED EXTERNALLY, GLOBALLY AS <external_name>, DEFAULT TABLESPACE <tablespace>, TEMPORARY TABLESPACE <tablespace>, QUOTA, and PROFILE <profile>.

The created user has RESOURCE status.


create_view_statement (MaxDB: Reference Manual)

create_view_statement

The SQL statement CREATE VIEW (create_view_statement) is supported in MySQL MaxDB with restricted syntax. The following restrictions exist in MySQL MaxDB for the syntax of the CREATE VIEW statement:

· MySQL MaxDB does not accept the specification of FORCE or NOFORCE.

· A constraint_name given to the CHECK OPTION is not stored in the database catalog. If no constraint name is specified, MySQL MaxDB does not generate a name.

· View tables that are changeable in Oracle are not necessarily changeable in MySQL MaxDB. This is especially true for view tables whose definition contains subqueries.


declare_statement (MaxDB: Reference Manual)

declare_statement

In MySQL MaxDB, it is possible to specify the SQL statement DECLARE (declare_statement) with the following syntax restriction: the specification of a PL/SQL block is not accepted.


declare_table_statement (MaxDB: Reference Manual)

declare_table_statement

The SQL statement DECLARE TABLE (declare_table_statement) is accepted by SAP DB, even though it is meaningless for MySQL MaxDB.


delete_statement (MaxDB: Reference Manual)

delete_statement

The SQL statement DELETE (delete_statement) is supported in MySQL MaxDB with restricted syntax (DELETE statement).

· If CURRENT OF <cursor> is specified in MySQL MaxDB, the result table must be based on an changeable table.

· A cursor built by a join or join view table is rejected in MySQL MaxDB.


describe_statement (MaxDB: Reference Manual)

describe_statement

In MySQL MaxDB, it is possible to specify the SQL statement DESCRIBE (describe_statement) with the following syntax restriction: the specification of a PL/SQL block is not accepted.


drop_cluster_statement (MaxDB: Reference Manual)

drop_cluster_statement

The schema object cluster is not supported by MySQL MaxDB. The SQL statement DROP CLUSTER (drop_cluster_statement) is therefore not accepted by MySQL MaxDB.


drop_database_link_statement (MaxDB: Reference Manual)

drop_database_link_statement

The schema object database link is not supported by MySQL MaxDB. The SQL statement DROP DATABASE LINK (drop_database_link_statement) is therefore not accepted by MySQL MaxDB.


drop_function_statement (MaxDB: Reference Manual)

drop_function_statement

The SQL statement DROP FUNCTION (drop_function_statement) is not accepted by MySQL MaxDB.


drop_index_statement (MaxDB: Reference Manual)

drop_index_statement

The SQL statement DROP INDEX (drop_index_statement) is accepted by MySQL MaxDB with the following restriction: because of the different namespaces for indexes, the specification of an index name does not always uniquely identify an index in MySQL MaxDB. In such a case, the table to which the index refers must be explicitly specified.


drop_procedure_statement (MaxDB: Reference Manual)

drop_procedure_statement

The SQL statement DROP PROCEDURE (drop_procedure_statement) is not accepted by MySQL MaxDB.


drop_profile_statement (MaxDB: Reference Manual)

drop_profile_statement

The schema object profile is not supported by MySQL MaxDB. The SQL statement DROP PROFILE (drop_profile_statement) is therefore not accepted by MySQL MaxDB.


drop_rollback_segment_statement (MaxDB: Reference Manual)

drop_rollback_segment_statement

The schema object rollback segment is not supported by MySQL MaxDB. The SQL statement DROP ROLLBACK SEGMENT (drop_rollback_segment_statement) is therefore not accepted by MySQL MaxDB.


drop_snapshot_statement (MaxDB: Reference Manual)

drop_snapshot_statement

The schema object snapshot is not supported by MySQL MaxDB. The SQL statement DROP SNAPSHOT (drop_snapshot_statement) is therefore not accepted by MySQL MaxDB.


drop_snapshot_log_statement (MaxDB: Reference Manual)

drop_snapshot_log_statement

The schema object snapshot log is not supported by MySQL MaxDB. The SQL statement DROP SNAPSHOT LOG (drop_snapshot_log_statement) is therefore not accepted by MySQL MaxDB.


drop_table_statement (MaxDB: Reference Manual)

drop_table_statement

The SQL statement DROP TABLE (drop_table_statement) is known in MySQL MaxDB but with the following syntax restrictions:

· All synonyms and view tables based on the table are dropped in MySQL MaxDB.

· Specifying CASCADE CONSTRAINTS has no effect in MySQL MaxDB.


drop_tablespace_statement (MaxDB: Reference Manual)

drop_tablespace_statement

The schema object tablespace is not supported by MySQL MaxDB. The SQL statement DROP TABLESPACE (drop_tablespace_statement) is therefore not accepted by MySQL MaxDB.


drop_trigger_statement (MaxDB: Reference Manual)

drop_trigger_statement

Because of the different namespaces for triggers, specification of a trigger name in MySQL MaxDB does not uniquely identify the trigger.

Therefore, MySQL MaxDB only accepts the SQL statement DROP TRIGGER (drop_trigger_statement) with the following restriction: the table that the trigger relates to must be explicitly specified.


drop_view_statement (MaxDB: Reference Manual)

drop_view_statement

In MySQL MaxDB, the SQL statement DROP VIEW (drop_view_statement) is used to drop all the synonyms and view tables based on the view table.


execute_statement (MaxDB: Reference Manual)

execute_statement

In MySQL MaxDB, it is possible to specify the SQL statement EXECUTE (execute_statement) with the following syntax restriction: the specification of a PL/SQL block is not accepted.


explain_plan_statement (MaxDB: Reference Manual)

explain_plan_statement

The SQL statement EXPLAIN PLAN (explain_plan_statement) is not accepted by MySQL MaxDB.

However, there is a similar SQL statement in MySQL MaxDB: EXPLAIN statement.


grant_statement (MaxDB: Reference Manual)

grant_statement

The SQL statement GRANT (grant_statement) is known in MySQL MaxDB, but behaves differently to Oracle in the following areas (GRANT statement):

· MySQL MaxDB does not accept the granting of system privileges.

· The schema object package cannot be specified when object privileges are granted in MySQL MaxDB.


insert_statement (embedded SQL) (MaxDB: Reference Manual)

insert_statement (embedded SQL)

The SQL statement INSERT (insert_statement) is accepted in MySQL MaxDB with the following restriction (INSERT statement): MySQL MaxDB does not accept the specification of array host variables in the WHERE clause.


lock_table_statement (MaxDB: Reference Manual)

lock_table_statement

The SQL statement LOCK TABLE (lock_table_statement) is accepted by MySQL MaxDB with the following syntax restrictions: if ROW EXCLUSIVE, SHARE ROW EXCLUSIVE or EXCLUSIVE are specified, MaxDB assigns an exclusive table lock. Concurrent requests on the table are therefore not possible.


noaudit_statement (MaxDB: Reference Manual)

noaudit_statement

The SQL statement NOAUDIT (noaudit_statement) is not accepted by MySQL MaxDB.


rename_statement (MaxDB: Reference Manual)

rename_statement

The SQL statement RENAME (rename_statement) is known in MySQL MaxDB, but behaves differently to Oracle: in MySQL MaxDB, only Basis tables can be renamed.


revoke_statement (MaxDB: Reference Manual)

revoke_statement

The SQL statement REVOKE (revoke_statement) is known in MySQL MaxDB, but behaves differently to Oracle in the following areas (REVOKE statement):

· MySQL MaxDB does not accept the revoking of system privileges.

· The schema object package cannot be specified when object privileges are revoked in MySQL MaxDB.


rollback_statement (MaxDB: Reference Manual)

rollback_statement

The SQL statement ROLLBACK (rollback_statement) is supported in MaxDB with restricted syntax (ROLLBACK statement).

· MaxDB rejects the specification of FORCE.

· MaxDB does not release any locks when ROLLBACK TO [SAVEPOINT] <savepoint> is specified.


select_statement (MaxDB: Reference Manual)

select_statement

The SQL statement SELECT (select_statement) is supported in MySQL MaxDB with restricted syntax (SELECT statement).

· MySQL MaxDB does not support the specification of START WITH <condition> or CONNECT BY <condition>.

· MySQL MaxDB sometimes rejects outer joins with more than two tables in the FROM clause valid in Oracle.


set_transaction_statement (MaxDB: Reference Manual)

set_transaction_statement

The SQL statement SET TRANSACTION (set_transaction_statement) is not accepted by MySQL MaxDB.


truncate_statement (MaxDB: Reference Manual)

truncate_statement

The SQL statement TRUNCATE (truncate_statement) is supported by MySQL MaxDB with restricted syntax only.

  • The statement TRUNCATE CLUSTER [<schema>.]<cluster> is not accepted by MySQL MaxDB.
  • The syntax elements DROP / REUSE STORAGE are accepted by MySQL MaxDB. They do not have any semantic meaning, however, since they trigger a response that is standard in MySQL MaxDB.


update_statement (MaxDB: Reference Manual)

update_statement

The SQL statement UPDATE (update_statement) is supported in MySQL MaxDB with restricted syntax (UPDATE statement).

· A correlated subquery is not permitted as a subquery of a SET UPDATE clause in MySQL MaxDB.

· If CURRENT OF <cursor> is specified in MySQL MaxDB, the result table must be based on an changeable table. A cursor built by a join or join view table is rejected.


System Tables (MaxDB: Reference Manual)

System Tables

The following system tables are known in MySQL MaxDB, but they are empty because the corresponding objects or information does not exist in MySQL MaxDB:

ALL_ERRORS
ALL_SOURCE
ALL_SNAPSHOTS
ALL_TRIGGER_COLS

DBA_2PC_NEIGHBORS
DBA_2PC_PENDING
DBA_AUDIT_EXISTS
DBA_AUDIT_OBJECT
DBA_AUDIT_SESSION
DBA_AUDIT_STATEMENT
DBA_AUDIT_TRAIL
DBA_BLOCKERS
DBA_CLUSTERS
DBA_CLU_COLUMNS
DBA_DATA_FILES
DBA_DDL_LOCKS
DBA_DML_LOCKS
DBA_ERRORS
DBA_EXP_FILES
DBA_EXP_OBJECTS
DBA_EXTENTS
DBA_LOCKS
DBA_OBJECT_SIZE
DBA_PRIV_AUDIT_OPTS
DBA_PROFILES
DBA_ROLLBACK_SEGS
DBA_SNAPSHOTS
DBA_SNAPSHOT_LOGS
DBA_SOURCE
DBA_STMT_AUDIT_OPTS
DBA_SYS_PRIVS
DBA_TABLESPACES
DBA_TRIGGER_COLS
DBA_TS_QUOTAS

RESOURCE_COST
ROLE_SYS_PRIVS
ROLE_TAB_PRIVS

USER_AUDIT_OBJECT
USER_AUDIT_SESSION
USER_AUDIT_TRAIL
USER_CLUSTERS
USER_CLU_COLUMNS
USER_ERRORS
USER_EXTENTS
USER_OBJECT_SIZE
USER_SNAPSHOTS
USER_SNAPSHOT_LOGS
USER_SOURCE
USER_SYS_PRIVS
USER_TABLESPACES
USER_TRIGGER_COLS
USER_TS_QUOTAS

The following system table columns always contain a NULL value because the information is not available in the format required in MySQL MaxDB:

System Table(s) | Column(s)
ALL_CONSTRAINT, USER_CONSTRAINTS, DBA_CONSTRAINTS | R_CONSTRAINT_NAME
ALL_DEPENDENCIES, USER_DEPENDENCIES, DBA_DEPENDENCIES | REFERENCED_LINK_NAME
ALL_INDEXES, USER_INDEXES, DBA_INDEXES | PREFIX_LENGTH INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENT MAX_EXTENTS PCT_INCREASE PCT_FREE BLEVEL LEAF_BLOCKS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE LAST_ANALYZED DEGREE INSTANCES BUFFER_POOL DUARTION PCT_DIRECT_ACCESS ITYP_OWNER ITYP_NAME PARAMETERS GLOBAL_STATS
ALL_OBJECTS, USER_OBJECTS, DBA_OBJECTS | SUBOBJECT_NAME DATA_OBJECT_ID
ALL_SYNONYMS, USER_SYNONYMS, DBA_SYNONYMS | DB_LINK
ALL_TABLES, USER_TABLES, DBA_TABLES | CLUSTER_NAME IOT_NAME PCT_FREE PCT_USED INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENT MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_SPACE_FREELIST_BLOCKS NUM_FREELIST_BLOCKS DEGREE INSTANCES IOT_TYPE BUFFER_POOL ROW_MOVEMENT GLOBAL_STATS DUARTION SKIP_CORRUPT MONITORING
ALL_TAB_COLUMNS, USER_TAB_COLUMNS, DBA_TAB_COLUMNS | DATA_TYPE_MOD DATA_TYPE_OWNER LOW_VALUE HIGH_VALUE DENSITY NUM_NULLS NUM_BUCKETS LAST_ANALYZED SAMPLE_SIZE GLOBAL_STATS AVG_COL_LENGTH
ALL_TRIGGERS, USER_TRIGGERS, DBA_TRIGGERS | COLUMN_NAME REFERENCING_NAME WHEN_CLAUSE ACTION_TYPE
ALL_VIEWS, USER_VIEWS, DBA_VIEWS | TYPE_TEXT_LENGTH TYPE_TEXT OID_TEXT_LENGTH OID_TEXT VIEW_TYPE_OWNER VIEW_TYPE
DBA_IND_COLUMNS | COLUMN_EXPRESSION
USER_FREE_SPACE, DBA_FREE_SPACE | RELATIVE_FNO
USER_RESOURCE_LIMITS | RESOURCE_NAME LIMIT
USER_SEGMENTS, DBA_SEGMENTS | BYTES BLOCKS EXTENTS INITIAL_EXTENT NEXT_EXTENT IN_EXTENT MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS BUFFER_POOL RESOURCE_NAME
USER_SYS_PRIVS | PRIVILEGE
USER_USERS, DBA_USERS | ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE PROFILE INITIAL_RSRC_CONSUMER_GROUP EXTERNAL_NAME


Error Messages (MaxDB: Reference Manual)

Error Messages

When some errors occur, MySQL MaxDB produces the same error number as Oracle Version 7:

Message number | Message text
1403 | Row not found
-1 | Duplicate key in index
-51 | Lock request timeout
-54 | Lock collision
-602 | System error
-942 | Unknown table name
-955 | Duplicate name
-1007 | Parameter is too long
-1008 | Too many or too few host variables for output
-1034 | Serverdb must be restarted
-1400 | Input parameter cannot be NULL value
-1402 | Integrity violation
-1405 | Missing indicator variable
-1452 | Duplicate secondary key
-1556 | Data space full (emergency shutdown)

For all other errors, MySQL MaxDB produces the error numbers described in the Messages manual. These are different to the numbers for the corresponding Oracle errors.


Messages

The following is a list of all messages issued by the MySQL MaxDB database system: confirmation and error messages from the database core, the database tools and the precompiler. It gives short explanations for the possible cause of the error, and notes on how to eliminate them. Each component has its own number range.

System messages

System messages provide feedback for the user. They are output even if requests are syntactically correct or the program is running smoothly. The system messages are sorted in ascending order (from 0 to 25999).

Database Kernel System Messages

From 0 to 1999

System Messages of the Loader Program

From 25000 to 25999

Error messages

Error messages indicate that an error has occurred which requires action by the user as described. The system messages are sorted in descending order (from -1 to -28999).

Error Messages from the Database Kernel / the Precompiler

From -1 to -699

From -700 to -899

From -900 to -999

From -1000 to -1999

From -2000 to -2999

From -3000 to -3999

From -4000 to -4999

From -5000 to -5999

From -6000 to -6999

From -7000 to -7999

From -8000 to -9799

From -9800 to -9999

Error Messages of the ODBC Program

From -22000 to -22999

Error Messages of the SQL Studio Program

From -23000 to -23999

Error Messages of the Database Manager Program

From -24000 to -24999

Error Messages of the Loader Program

From -25000 to -25999

Error Messages of the liveCache

From -27000 to -28999


Number Ranges (MaxDB: Messages)

Number Ranges

Component | Message Type | Number Range
Database kernel | System messages Error messages | 0 to 1999 –1 to –699 –900 to –999 –1000 to –1999 –2000 to –2999 –3000 to –3999 –4000 to –4999 –5000 to –5999 –6000 to –6999 –7000 to –7999 -8000 to -9799
Precompiler | Error messages Error messages | -700 to -899 -9800 to -9999
ODBC | Error messages | -22000 to -22999
SQL Studio | Error messages | -23000 to -23999
Database Manager | Error messages | -24000 to -24999
Loader | System messages Error messages | 25000 to 25999 -25000 to -25999
liveCache | Error messages | -27000 to -28999


From -1 to -699 (MaxDB: Messages)

From -1 to -699

Database Kernel Error Messages

-1 | Duplicate key in index
-8 | Execution failed, parse again
-20 | Duplicate key
-25 | Duplicate secondary key
-30 | Integrity violation
-32 | View violation
-35 | Referential integrity violated
-36 | Foreign key integrity violation
-40 | Lock collision
-50 | Lock request timeout
-51 | Lock request timeout
-54 | Lock collision
-60 | Work rolled back
-65 | Work rolled back
-70 | Session inactivity timeout (Work rolled back)
-71 | Session terminated by shutdown (Work rolled back)
-75 | Too many SQL statements (Work rolled back)
-101 | SQL statement not available in this DB mode
-102 | SQL statement canceled
-103 | SQL statement not available for this application
-104 | DBM command impossible at this time
-106 | Table unloaded or content deleted
-107 | SQL statement not allowed for this instance
-108 | Table or index dropped or content deleted
-111 | Incompatible incremental backup
-115 | Table is read only
-123 | No more log to save
-126 | Data backup missing (backup history lost)
-530 | Referential integrity violated
-602 | System error


-1: Duplicate key in index (MaxDB: Messages)

-1: Duplicate key in index

Explanation:

There is already a table row with the specified secondary key. UNIQUE was specified for the secondary key.

User Action:

To avoid a key value collision, correct the value of the key to be inserted in the SQL statement.

The error message specifies the column or multiple-column index already containing the specified values.


-8: Execution failed, parse again (MaxDB: Messages)

-8: Execution failed, parse again

Explanation:

The parse identification (parsid) became invalid by modifications made to the database catalog during parsing and executing a statement.

User Action:

Reparse the statement.


-20: Duplicate key (MaxDB: Messages)

-20: Duplicate key

Explanation:

There is already a table row with the key to be inserted.

User Action:

Check whether the existing table row contains the desired values. If this is not the case, check whether values in the existing table row can be replaced with the desired values. If a new table row must be inserted, change the value of the key to be inserted in the SQL statement in order to prevent key collisions.


-25: Duplicate secondary key (MaxDB: Messages)

-25: Duplicate secondary key

Explanation:

There is already a table row with the specified secondary key. UNIQUE was specified for the secondary key.

User Action:

To avoid a key value collision, correct the value of the key to be inserted in the SQL statement.

The error message specifies the column or multiple-column index already containing the specified values.


-30: Integrity violation (MaxDB: Messages)

-30: Integrity violation

Explanation:

Insertions or updates would violate integrity constraints specified in the definition of the base or the view table.

User Action:

The error message specifies the column which would violate the integrity constraints.

Correct the input value for the corresponding column.


-32: View violation (MaxDB: Messages)

-32: View violation

Explanation:

An INSERT or UPDATE statement was issued for a view table. At least one of the rows specified in the SQL statement does not satisfy the search conditions of all underlying view tables defined WITH CHECK OPTION.

User Action:

Display the definition of the view table using a QUERY statement issued on the system table DOMAIN.VIEWDEFS. Correct the INSERT or UPDATE statement according to this definition.


-35: Referential integrity violated (MaxDB: Messages)

-35: Referential integrity violated

Explanation:

This may be caused by one of the following:

1. An INSERT or UPDATE statement issued on a table that is the referencing table in a referential CONSTRAINT definition produces a row that is not a matching row of the CONSTRAINT definition.

2. When deleting rows from a referenced table (referenced_table) of a referential CONSTRAINT definition with ON DELETE RESTRICT in the DELETE RULE, a matching row exists.

3. When executing a referential CONSTRAINT definition, the referenced table or referencing table contains rows that conflict with the CONSTRAINT definition.

User Action:

...

1. Display the definition of the referential CONSTRAINT definition using a QUERY statement issued on the system table DOMAIN.FOREIGNKEYCOLUMNS. Correct the INSERT or UPDATE statement according to this definition.

2. Use an appropriate QUERY statement to find out which row of the referencing table prevents the desired referenced table rows from being deleted.

3. Use an appropriate QUERY statement to find out which row of the referenced table or referencing table conflicts with the referential CONSTRAINT definition. Change or delete this row, or correct the CONSTRAINT definition.


-36: Foreign key integrity violation (MaxDB: Messages)

-36: Foreign key integrity violation

Explanation:

Where there is an INSERT or UPDATE statement issued on a join view table, the column values functionally depending on the referencing columns of the referencing table conflict with the existing column values.

User Action:

This conflict may be solved by changing either the column values specified in the INSERT or UPDATE statement, or the existing values.


-40: Lock collision (MaxDB: Messages)

-40: Lock collision

Explanation:

When the option (NOWAIT) is specified in the LOCK statement or in the LOCK option , this error message signals that the lock request conflicts with the locks of other users.

User Action:

In interactive mode, another job can be activated which does not require the desired lock.

As an alternative, you can wait for the lock to be released by specifying the same SQL statement without the '(NOWAIT)' option.


-50: Lock request timeout (MaxDB: Messages)

-50: Lock request timeout

Explanation:

The lock request or an implicit lock conflicts with the locks of another user. The maximum waiting time for being granted the lock has elapsed (database parameter REQUEST_TIMEOUT).

User Action:

In some cases, the error message contains a more detailed description of the error.

The lock request can be reissued. To avoid possible deadlock situations, it is advisable to roll back the transaction using the ROLLBACK statement.


-51: Lock request timeout (MaxDB: Messages)

-51: Lock request timeout

Explanation:

The lock request or an implicit lock conflicts with the locks of another user. The maximum waiting time for being granted the lock has elapsed (database parameter REQUEST_TIMEOUT).

User Action:

In some cases, the error message contains a more detailed description of the error.

The lock request can be reissued. To avoid possible deadlock situations, it is advisable to roll back the transaction using the ROLLBACK statement.


-54: Lock collision (MaxDB: Messages)

-54: Lock collision

Explanation:

When the option (NOWAIT) is specified in the LOCK statement or in the LOCK option , this error message signals that the lock request conflicts with the locks of other users.

User Action:

...

In interactive mode, another job can be activated which does not require the desired lock.

As an alternative, you can wait for the lock to be released by specifying the same SQL statement without the '(NOWAIT)' option.


-60: Work rolled back (MaxDB: Messages)

-60: Work rolled back

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. for the following possible reasons:

The user failed to carry out any operations in the database system within a certain period of time, but was holding locks which other users were waiting for.

the database instance was in a deadlock situation. The database server was in a situation in which two or more users are holding locks and request further locks that are being held by other users. In the simplest case of two users, one user holds one lock at least and requests another lock. But this lock is held by another user who is himself waiting for the lock held by the first user. This situation can only be resolved if one of the users releases the lock already obtained.

User Action:

In some cases, the error message contains a more detailed description of the error.

In both cases, the lock requests must be checked and modified, if necessary. Repeat the last transaction.


-65: Work rolled back (MaxDB: Messages)

-65: Work rolled back

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement because the log area is full.

User Action:

The error text contains a precise description of the error.

You tried to save the log area (log backup).


-70: Session inactivity timeout (Work rolled back) (MaxDB: Messages)

-70: Session inactivity timeout (Work rolled back)

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. The database session was ended implicitly because the user did not perform any operations in the database system during the time interval defined by the timeout value.

User Action:

Repeat the CONNECT statement, possibly specifying a higher timeout value.

It may also be necessary to check and modify the value of the SESSION_TIMEOUT database parameter.


-71: Session terminated by shutdown (Work rolled back) (MaxDB: Messages)

-71: Session terminated by shutdown (Work rolled back)

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. The database session was terminated because the database administration system shut the database instance down. To speed up a later restart, the database system tries to reset and not just terminate open transactions within a short period.

User Action:

Once the database is ready, repeat the CONNECT statement and the transaction.


-75: Too many SQL statements (Work rolled back) (MaxDB: Messages)

-75: Too many SQL statements (Work rolled back)

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. The database session was implicitly terminated, since you had issued too many SQL statements or had performed too many transactions within a session.

User Action:

After a new CONNECT statement the transaction may be repeated.


-101: SQL statement not available in this DB mode (MaxDB: Messages)

-101: SQL statement not available in this DB mode

Explanation

In order to execute the SQL statement, the database must be in OFFLINE or ONLINE mode.

User action

Ensure that the database instance is in the required mode.

If a system error has occurred and the system has performed a SHUTDOWN, correct the error and re-start the database instance.


-102: SQL statement canceled (MaxDB: Messages)

-102: SQL statement canceled

Explanation:

The SQL statement currently executed was terminated by a user.

User Action:

No user action required in the dialog. In other cases, use a ROLLBACK statement to reset the transaction.


-103: SQL statement not available for this application (MaxDB: Messages)

-103: SQL statement not available for this application

Explanation:

You have attempted to use an application to execute an SQL statement. This application has no privileges for this statement.

User Action:

Use the correct application, or check the syntax of the statement.


-104: DBM command impossible at this time (MaxDB: Messages)

-104: DBM command impossible at this time

Explanation:

You have attempted to execute a database management statement.

You cannot execute this statement if another database statement is already running.

User Action:

Execute the statement later.


-106: Table unloaded or content deleted (MaxDB: Messages)

-106: Table unloaded or content deleted

Explanation:

The table cannot currently be accessed. The following reasons are possible:

...

1. The table was extracted from the database instance with the TABLEEXTRACT command.

2. Another user simultaneously performed a DELETE statement either for a large part of the table or for the whole table. The specified table was not accessible for a short period of time. This error message can only occur if you work with isolation level 0.

User Action:

...

1. Reload the table into the database using the TABLELOAD command.

2. Wait until the processing of the DELETE statement is finished.

Execute the SQL statement.


-107: SQL statement not allowed for this instance (MaxDB: Messages)

-107: SQL statement not allowed for this instance

Explanation:

The database instance is unable to execute this SQL statement.

User Action:

You must do without the SQL statement for this database instance.


-108: Table or index dropped or content deleted (MaxDB: Messages)

-108: Table or index dropped or content deleted

Explanation:

While an SQL statement was processed without any shared locks, another database user deleted a table. The execution of the SQL statement was therefore cancelled.

User Action:

Clarify the organizational error in the user environment.


-111: Incompatible incremental backup (MaxDB: Messages)

-111: Incompatible incremental backup

Explanation:

The database version to be loaded is not the follow-up version of the current database state.

User Action:

Choose the correct database version.


-115: Table is read only (MaxDB: Messages)

-115: Table is read only

Explanation:

The attempt was made to perform an INSERT, UPDATE or DELETE statement. But the specified table only allows reading SQL statements because it was previously loaded with the NOLOG option.

User Action:

You can cancel read-only mode only. Start a data backup using the corresponding database administration tool.


-123: No more log to save (MaxDB: Messages)

-123: No more log to save

Explanation:

You tried to save the log area. This is not possible or necessary, since the database system has written no or very few entries to the log area since the last time the log area was backed up.

User Action:

No user action is required.


-126: Data backup missing (backup history lost) (MaxDB: Messages)

-126: Data backup missing (backup history lost)

Explanation:

You tried to save the log area by starting a log backup (interactive log backup or the automatic log backup was activated). This is not permitted in the present operational state as there is no preceding backup on which to base a later restore of the saved log area.

User Action:

Create a complete data backup in order to start the backup history. You can then repeat the required log backup.


-530: Referential integrity violated (MaxDB: Messages)

-530: Referential integrity violated

Explanation:

The following reasons are possible:

...

An INSERT or UPDATE-statement issued on a table that is the referencing table in a referential CONSTRAINT definition produces a row that is not a matching row of the CONSTRAINT definition.

When deleting rows from a referenced table (referenced_table) of a referential CONSTRAINT definition with ON DELETE RESTRICT in the DELETE RULE, a matching row exists.

User Action:

...

Display the definition of the referential CONSTRAINT definition using a QUERY statement issued on the system table DOMAIN.FOREIGNKEYCOLUMNS. Change the INSERT or UPDATE statement according to this definition.

Use an appropriate QUERY statement to find out which row of the referencing table prevents the desired referenced table rows from being deleted.


-602: System error (MaxDB: Messages)

-602: System error

Explanation:

Normal database operations were disrupted. Possibly the database instance is no longer consistent. An implicit SHUTDOWN may have been performed.

User Action:

Shut down the database and inform your support.

Send the database trace and additional log files to your support so the error can be traced and rectified.


From -700 to -899 (MaxDB: Messages)

From -700 to -899

Precompiler error messages

-702 | Missing variable address in SQLDA
-703 | Duplicate FETCH statement with MFETCH option not allowed
-706 | SQL statement too long (buffer overflow)
-707 | Invalid CONNECT statement syntax
-708 | SERVERDB system not available
-709 | CONNECT failed, check SERVERDB
-710 | Missing SELECT PARSID
-711 | Implicit CONNECT: missing user of SERVERDB
-712 | Too many parameters, SQLMAX too small
-715 | Missing username or password for CONNECT
-719 | Unknown LOCALSYSUSER.SYSPROFILE table
-720 | SQLCODE <no> comes from SYSPROFILE command
-721 | Macro not initiated, no SQLCHECK
-724 | Duplicate substructure name
-729 | Source code may be truncated
-730 | Nested comment not closed
-731 | Component name too long
-732 | Index of component out of range
-733 | Variable is declared as a pointer
-734 | Pointer bariable not allowed here
-735 | No syntax check for CONNECT command
-740 | Array size mismatch
-743 | Input string too long
-750 | FFETCH or ARRAY-FETCH and FETCH mix not allowed
-751 | Numeric input parameter overflow
-752 | Session already connected
-753 | Output parameter with CONST type
-756 | Different SQLMODEs not allowed
-758 | Include file exists on disk
-759 | Include file produced by user
-760 | Memory allocation failed
-762 | EXEC ORACLE command has been deleted
-763 | Variable not allowed as ARRAY
-767 | Unterminated C string
-768 | Invalid escape value
-769 | Pointer component not allowed
-770 | Macro in FETCH set SQLOPT="-B 0"
-771 | LONG column exists in table definition
-772 | Multibyte char set not allowed
-773 | Datafile open error
-774 | Datafile write error
-775 | Datafile read error
-776 | Datafile close error
-777 | Convertion from UNICODE impossible
-778 | Convertion to UNICODE impossible
-801 | Input parameter cannot be NULL value
-802 | Invalid numeric input parameter value
-804 | Parameter list to long
-805 | Program must be precompiled
-806 | DB session numer not allowed
-807 | Connection down, session released
-808 | Not yet implemented
-809 | Missing indicator variable, output parameter with NULL value
-811 | Numeric output parameter overflow
-812 | Parameter list too short
-813 | SERVERDB must be restarted
-814 | Trace file close error
-815 | Trace file open error
-816 | Trace file write error
-817 | Incompatible data types
-818 | Missing macro parameter initialization
-819 | Parameter in SQL statement not allowed
-820 | Invalid declare statement
-822 | Invalid constant definition
-823 | Integer too large, greater than 32767
-824 | Statement in conflict with COMPATIBLE option
-825 | Duplicate field name in record
-826 | Duplicate statement name
-827 | Duplicate type definition
-828 | Duplicate variable name
-829 | File close error
-830 | File open error
-831 | File read error
-832 | File write error
-833 | Illegal INCLUDE position
-834 | INCLUDEs must not be nested
-835 | INCLUDE file open error
-836 | Invalid C preprocessor command
-837 | Data definition not allowed
-838 | Invalid declarator
-839 | Invalid macro value
-840 | Invalid numeric macro value
-841 | Invalid precompiler option
-842 | Parameter and indicator structures do not match
-843 | Invalid parameter name
-844 | Invalid record name
-845 | Invalid SQL statement
-846 | Invalid statement in section
-847 | Invalid type definition
-848 | Invalid unsigned integer
-849 | Invalid variable definition
-850 | Statement termination expected
-851 | Missing input file name
-852 | Missing program file
-853 | Precompiler syntax check only
-854 | Parameters must be question marks
-855 | SQL variable must be an array
-856 | Invalid loop parameter value
-857 | Missing SERVERDB
-858 | Storage class not allowed
-859 | Number of columns < numer of parameters
-860 | To many constants declared
-870 | Too many type definitions
-871 | Too many variable definitions
-872 | Number of columns > numer of parameters
-873 | Unknown constant name
-874 | Unknown cursor name
-876 | Unknown macro number
-877 | Unknown parameter name
-878 | Unknown record name
-879 | Unknown precompiler statement
-880 | Unknown statement name
-881 | Unknown type name
-882 | Missing user name for CONNECT
-883 | Invalid runtime options
-884 | Missing indicator variabeI
-885 | Variable may be truncated
-886 | DECLARE SECTION BEGIN or END missing
-887 | Too long WHENEVER ACTION
-889 | Input line longer than 512 characters
-890 | Input line longer than right margin
-892 | Variable may overflow
-893 | Too many hostvariables
-894 | Trace parameter structure not allowed
-895 | Whole table may be deleted or updated
-899 | Error unknown


-702: Missing variable address in SQLDA (MaxDB: Messages)

-702: Missing variable address in SQLDA

Explanation:

The address of a program variable was not set in the SQLDA.

User Action:

Write the address into the SQLDA at the HOSTVARADDR position.


-703: Duplicate FETCH statement for same select in program (MaxDB: Messages)

-703: Duplicate FETCH statement for same select in program

Explanation:

When the MFETCH option is set, only one FETCH statement is allowed per result table.

The execution of such a FETCH statement can be repeated within a loop.

User Action:

Modify the application or run it without MFETCH option.


-706: SQL statement too long (buffer overflow) (MaxDB: Messages)

-706: SQL statement too long (buffer overflow)

Explanation:

The SQL statement does not fit the buffer used for communication between the application program and the database instance.

User Action:

Change the statement or break down the SQL statement into two or more SQL statements.


-707: Invalid CONNECT statement syntax (MaxDB: Messages)

-707: Invalid CONNECT statement syntax

Explanation:

There is an error in the CONNECT statement syntax.

User Action:

Correct the CONNECT statement.


-708: SERVERDB system not available (MaxDB: Messages)

-708: SERVERDB system not available

Explanation:

The database instance exists, but it is in the startup or shutdown phase, with the result that a connection cannot be established at the moment.

User Action:

Repeat the connection (CONNECT statement) at a later time.


-709: Connect failed, check SERVERDB (MaxDB: Messages)

-709: Connect failed, check SERVERDB

Explanation:

An error was detected while processing the connection (CONNECT statement).

User Action:

...

1. Check the name of the database and correct it if necessary.

2. Check whether the database instance has the operation status ONLINE. If not, start the database instance.

3. If the data transfer to the database instance has been interrupted, you must restore it.


-710: Missing select PARSID (MaxDB: Messages)

-710: Missing select PARSID

Explanation:

The parsing information of a FETCH/CLOSE statement cannot be assigned to any result set.

User Action:

Contact Support.


-711: Implicit CONNECT: missing user or SERVERDB (MaxDB: Messages)

-711: Implicit CONNECT: missing user or SERVERDB

Explanation:

During execution of an implicit CONNECT, the user entries or the database name could not be found.

User Action:

Open an XUSER file, or enter the CONNECT parameters using runtime options.


-712: Too many parameters, SQLMAX too small (MaxDB: Messages)

-712: Too many parameters, SQLMAX too small

Explanation:

In an SQLDA area, an SQLVAR entry was accessed which is no longer available (maximum number of SQLVAR entries <index_of_the_SQLVAR entry).

User Action:

Update the maximum number of SQLVAR elements or correct the index.


-715: Missing username or password for connect (MaxDB: Messages)

-715: Missing username or password for connect

Explanation:

A username or password specification is missing in a CONNECT statement, or there is no XUSER file for an implicit CONNECT.

User Action:

Enter the user name and password for the CONNECT statement via Options, or open an XUSER file.


-719: Unknown LOCALSYSUSER.SYSPROFILE table (MaxDB: Messages)

-719: Unknown LOCALSYSUSER.SYSPROFILE table

Explanation:

When enabling the PROFILE option, no SYSPROFILE table could be found.

User Action:

The LOCALSYSUSER must create this table, or the application program must be started without the PROFILE option.


-720: SQLCODE <no> comes from SYSPROFILE command (MaxDB: Messages)

-720: SQLCODE <no> comes from SYSPROFILE command

Explanation:

The database error <no> occurred when writing the SYSPROFILE.

User Action:

For error analysis and correction refer to the instructions given under the corresponding number.

The application program may also be started without the PROFILE option.


-721: Macro not initiated, no SQLCHECK (MaxDB: Messages)

-721: Macro not initiated, no SQLCHECK

Explanation:

No SET MACRO was performed. Therefore the SQL statement cannot be checked.

User Action:

Ensure that SET MACRO is performed before the SQL statement within the program flow.


-724: Duplicate substructure name (MaxDB: Messages)

-724: Duplicate substructure name

Explanation:

The name specified for the search for an SQL variable is not unique, because it identifies a substructure.

User Action:

Specify the name of the complete structure with the SQL variable.


-729: Source code may be truncated (MaxDB: Messages)

-729: Source code may be truncated

Explanation:

The precompiler only recognizes text that is placed within the line delimiters. The line delimiters depend on the programming language. The warning means that text outside the line delimiters was discovered. This text is ignored by the precompiler.

User Action:

If this effect is desired, the warning may be ignored. Otherwise, the text must be written to the next line or the line delimiters must be modified.


-730: Nested comment not closed (MaxDB: Messages)

-730: Nested comment not closed

Explanation:

Nested comments are not regularly closed in the source program.

User Action:

The number of opening commentary symbols must equal the number of closing commentary symbols.


-731: Component name too long (MaxDB: Messages)

-731: Component name too long

Explanation:

Structure names become longer than 18 bytes by expansion.

User Action:

Shorten the structure names in the table definition. If this is not possible, specify the column names separately.


-732: Index of component out of (MaxDB: Messages)

-732: Index of component out of

Explanation:

The specified index is not in the range of values of the array.

User Action:

Specify an index which is within the range of values.


-733: Variable is declared as a pointer (MaxDB: Messages)

-733: Variable is declared as a pointer

Explanation:

The SQL variable was defined as a pointer in the declaration section.

User Action:

As no fixed size is specified for a pointer, the name of the variable and COLLENGTH are indicated in the next error line. COLLENGTH is the maximum size of the SQL pointer variables. This size is needed for data conversion.


-734: Pointer variable not allowed here (MaxDB: Messages)

-734: Pointer variable not allowed here

Explanation:

SQL variables defined as pointers are not allowed in LONG columns because the maximum length of these variables is not known.

User Action:

Specify the SQL variable as a CHARACTER ARRAY.


-735: No syntax check for CONNECT command (MaxDB: Messages)

-735: No syntax check for CONNECT command

Explanation:

CONNECT statements that are not used to establish the connection to the database instance for the check run are not checked for syntax errors during precompilation.

User Action:

Pay special attention to the correct spelling when entering the statement.


-740: Array size mismatch (MaxDB: Messages)

-740: Array size mismatch

Explanation:

In mass statements the parameters have different sizes.

User Action:

The smallest size of all the parameters is set. If this is not desired, set all the sizes to the same value.


-743: Input string too long (MaxDB: Messages)

-743: Input string too long

Explanation:

The contents of a character string are longer than the database instance is capable of storing.

In ANSI SQL mode, the error message TRUNCATED is output for floating point numbers which were truncated.

User Action:

Set the input variable to a string which corresponds to the length of the database variable or adapt the input variable to the format used in the database.

In ANSI SQL mode, change either the variable values or the external data type.


-750: FFETCH or ARRAY-FETCH and FETCH mix not allo (MaxDB: Messages)

-750: FFETCH or ARRAY-FETCH and FETCH mix not allowed

Explanation:

ARRAY FETCH and FETCH statements cannot be issued on the same result set.

User Action:

All statements which refer to the same result set must be specified either as ARRAY FETCH or FETCH.


-751: Numeric input parameter overflow (MaxDB: Messages)

-751: Numeric input parameter overflow

Explanation:

The numeric input value is too large for the database instance.

User Action:

Check the size of the input value and of the range of values valid for the database instance and modify them, if necessary.


-752: Session already connected (MaxDB: Messages)

-752: Session already connected

Explanation:

A database session has already been opened with this number.

User Action:

Either close the previous database session or remove the CONNECT from the application program.


-753: Output parameter with CONST type (MaxDB: Messages)

-753: Output parameter with CONST type

Explanation:

An output parameter must not be declared as CONST type in C.

User Action:

Declare another parameter in the application program.


-756: Different SQLMODEs not allowed (MaxDB: Messages)

-756: Different SQLMODEs not allowed

Explanation:

An application program may only run in one SQL mode.

User Action:

Change the CONNECT statement. Implicit CONNECTs only function in INTERNAL SQL mode. The specifications made in the XUSER file are not applied in this case.


-758: Include file exists on disk (MaxDB: Messages)

-758: Include file exists on disk

Explanation:

The declare section is not generated during the precompiler run. The file is already available.

User Action:

Check whether the used file is the current one.


-759: Include file produced by user (MaxDB: Messages)

-759: Include file produced by user

Explanation:

During the precompiler run, the declare section is newly created by a CONNECT of the user <user>.

User Action:

Check whether the table of this user is the correct one.


-760: Memory allocation failed (MaxDB: Messages)

-760: Memory allocation failed

Explanation:

The available main memory is too small or write-protected.

User Action:

Check the program for a possible programming error. Increase the main memory or contact your support organization.


-762: EXEC ORACLE command has been deleted (MaxDB: Messages)

-762: EXEC ORACLE command has been deleted

Explanation:

The precompiler removes all statements that are preceded by EXEC ORACLE.

User Action:

This is a warning which may provide indications to possible compiler errors.


-763: Variable not allowed as ARRAY (MaxDB: Messages)

-763: Variable not allowed as ARRAY

Explanation:

Scalar host variables are used in an ARRAY statement.

User Action:

Instead of scalar variables, use arrays only; otherwise do without the ARRAY statement.


-767: Unterminated C string (MaxDB: Messages)

-767: Unterminated C string

Explanation:

The zero byte delimiter is missing.

User Action:

Insert a zero byte.


-768: Invalid escape value (MaxDB: Messages)

-768: Invalid escape value

Explanation:

The input host variable is longer than one character.

User Action:

Use a correct host variable.


-769: Pointer component not allowed (MaxDB: Messages)

-769: Pointer component not allowed

Explanation:

Pointers are not allowed within structures.

User Action:

Do not specify components as pointers.


-770: Macro in FETCH set SQLOPT="-B 0" (MaxDB: Messages)

-770: Macro in FETCH set SQLOPT="-B 0"

Explanation:

FETCH statements are executed as ARRAY statements, whenever possible. If macros are used in the FETCH statement, errors may occur and records be lost.

User Action:

When using macros within FETCH statements, set the runtime option MFETCH(0). This option prevents FETCH statements from being executed as ARRAY statements.


-771: LONG column exists in table definition (MaxDB: Messages)

-771: LONG column exists in table definition

Explanation:

The table from which the host variables are generated contains a LONG column.

User Action:

You can change the host variable that was created for this column.


-772: Multibyte char set not allowed (MaxDB: Messages)

-772: Multibyte char set not allowed

Explanation:

The CONNECT statement received an unknown multibyte specification.

User Action:

Correct the CONNECT statement.


-773: Datafile open error (MaxDB: Messages)

-773: Datafile open error

Explanation:

An error occurred when opening a datafile for the processing of LONG columns.

User Action:

Look up in the trace file *. pct in which column the error occurred. Then check the datafile.


-774: Datafile write error (MaxDB: Messages)

-774: Datafile write error

Explanation:

An error occurred when writing a datafile for the processing of LONG columns.

User Action:

Look up in the trace file *. pct in which column the error occurred. Then check the datafile.


-775: Datafile read error (MaxDB: Messages)

-775: Datafile read error

Explanation:

An error occurred when reading a datafile for the processing of LONG columns.

User Action:

Look up in the trace file *. pct in which column the error occurred. Then check the datafile.


-776: Datafile close error (MaxDB: Messages)

-776: Datafile close error

Explanation:

An error occurred when closing a datafile for the processing of LONG columns.

User Action:

Look up in the trace file *. pct in which column the error occurred. Then check the datafile.


-777: Conversion from UNICODE impossible (MaxDB: Messages)

-777: Conversion from UNICODE impossible

Explanation:

An error occurred when converting UNICODE data into CHAR data.

User Action:

Check whether a conversion such as this is really needed. You may have to change the declaration of the host variables for the CHAR data.


-778: Conversion to UNICODE impossible (MaxDB: Messages)

-778: Conversion to UNICODE impossible

Explanation:

An error occurred when converting CHAR data into UNICODE data.

User Action:

Check whether a conversion such as this is really needed. You may have to change the declaration of the host variables for the CHAR data.


-801: Input parameter cannot be NULL value (MaxDB: Messages)

-801: Input parameter cannot be NULL value

Explanation:

The value of an input parameter must not be a NULL value, because NULL values are not permitted for the column.

User Action:

Modify the program or change the column definition in the CREATE TABLE statement.


-802: Invalid numeric input parameter value (MaxDB: Messages)

-802: Invalid numeric input parameter value

Explanation:

The input value cannot be converted.

User Action:

The value must be specified in a valid notation.


-804: Parameter list too long (MaxDB: Messages)

-804: Parameter list too long

Explanation:

More parameters have been specified in a statement than are permitted in the pertinent EXECUTE statement.

User Action:

Modify the number of parameters in such a way that it corresponds to the specifications made in the column list.


-805: Program must be precompiled (MaxDB: Messages)

-805: Program must be precompiled

Explanation:

The common type definitions of the precompiler runtime system or of the include files no longer correspond to the precompiler types.

User Action:

Check the version numbers of the precompiler, precompiler runtime system, and the include files and precompile again, if necessary.


-806: DB session number not allowed (MaxDB: Messages)

-806: DB session number not allowed

Explanation:

The specified database session number is invalid.

User Action:

Insert a database session number between 1 and 8 into the application program.


-807: Connection down, session released (MaxDB: Messages)

-807: Connection down, session released

Explanation:

All database connections were closed with RELEASE.

User Action:

Establish a new connection using CONNECT.


-808: Not yet implemented (MaxDB: Messages)

-808: Not yet implemented

Explanation:

The function has not yet been implemented.

User Action:

Please consult the release information.


-809: Missing indicator variable, output parameter with NULL val (MaxDB: Messages)

-809: Missing indicator variable, output parameter with NULL value

Explanation:

The indicator variable required for returning the NULL value to the SQL variable is missing.

User Action:

Specify the indicator variable with the parameter.


-811: Numeric output parameter overflow (MaxDB: Messages)

-811: Numeric output parameter overflow

Explanation:

An database value is too large for the SQL variable or the parameter.

User Action:

Enlarge the value range for the SQL variable or parameter.


-812: Parameter list too short (MaxDB: Messages)

-812: Parameter list too short

Explanation:

Fewer parameters have been specified in a statement than are needed in the pertinent EXECUTE statement.

User Action:

Modify the number of parameters in such a way that it corresponds to the specifications made in the column list.


-813: SERVERDB must be restarted (MaxDB: Messages)

-813: SERVERDB must be restarted

Explanation:

The database system is not running, or an invalid database name was specified in the program.

User Action:

The database administrator must start the database instance, or the user must modify the program or XUSER file.


-814: Trace file close error (MaxDB: Messages)

-814: Trace file close error

Explanation:

The trace file could not be closed. The error in the program was ignored.

User Action:

Modify the file attributes (characteristics). For the exact error description, see the file appldiag .


-815: Trace file open error (MaxDB: Messages)

-815: Trace file open error

Explanation:

The trace file could not be opened. Writing of the trace file was disabled. The statement in which the error occurred was not executed.

User Action:

Check the file attributes and change them, if necessary. For the exact error description, see the file appldiag .


-816: Trace file write error (MaxDB: Messages)

-816: Trace file write error

Explanation:

An error occurred when writing into the trace file. Writing of the trace file was cancelled. The statement in which the error occurred was not executed.

User Action:

Check the file attributes and change them, if necessary. For the exact error description, see the file appldiag .


-817: Incompatible data types (MaxDB: Messages)

-817: Incompatible data types

Explanation:

The data type of the SQL variable or parameter is not compatible with the database system’s data type.

User Action:

Change the data type of the SQL variable or parameter to match the database system’s data type for the table column.

If this message is returned during precompilation and the data types are compatible, precompile with NOCHECK option.


-818: Missing macro parameter initialization (MaxDB: Messages)

-818: Missing macro parameter initialization

Explanation:

The macro was not initialized.

User Action:

Insert the SQL statement SET MACRO into the application program.


-819: Parameter in SQL statement not allowed (MaxDB: Messages)

-819: Parameter in SQL statement not allowed

Explanation:

Only an SQL statement without parameter specifications is permitted. Either an SQL statement with parameters but without a USING clause was passed with an EXECUTE, or an error occurred in the parameter list.

User Action:

Add the USING clause, or use an SQL statement without parameters, or correct the parameter list.


-820: Invalid declare statement (MaxDB: Messages)

-820: Invalid declare statement

Explanation:

The keyword FOR was not found in the DECLARE CURSOR statement.

User Action:

Insert the keyword FOR into the DECLARE CURSOR statement.


-822: Invalid constant definition (MaxDB: Messages)

-822: Invalid constant definition

Explanation:

The constant definition is invalid.

User Action:

Correct the constant definition within the declare section.


-823: Integer too large, greater than 32767 (MaxDB: Messages)

-823: Integer too large, greater than 32767

Explanation:

The constant must not be greater than 32767 (two bytes).

User Action:

Choose a smaller constant value.


-824: Statement in conflict with COMPATIBLE option (MaxDB: Messages)

-824: Statement in conflict with COMPATIBLE option

Explanation:

The option COMPATIBLE is set, and an SQL array statement was specified with the keyword FOR. The option COMPATIBLE was used in conjunction with array statements. Array statements are only supported from Release 3.1 onwards.

User Action:

Remove the COMPATIBLE option or change the array statement.


-825: Duplicate field name in record (MaxDB: Messages)

-825: Duplicate field name in record

Explanation:

A name is used twice in an SQL record definition to specify components.

User Action:

Rename one of the record components.


-826: Duplicate statement name (MaxDB: Messages)

-826: Duplicate statement name

Explanation:

The name was already specified for a statement.

User Action:

Rename the statement.


-827: Duplicate type definition (MaxDB: Messages)

-827: Duplicate type definition

Explanation:

The name was already specified for an SQL type definition.

User Action:

Rename the SQL type.


-828: Duplicate variable name (MaxDB: Messages)

-828: Duplicate variable name

Explanation:

The name was already specified for an SQL variable.

User Action:

Rename the SQL variable.


-829: File close error (MaxDB: Messages)

-829: File close error

Explanation:

An error occurred when closing a file. This is a device failure or system error.

User Action:

Try again to close the file. For the exact error description, see the file appldiag.


-830: File open error (MaxDB: Messages)

-830: File open error

Explanation:

A file could not be opened.

User Action:

Check whether the file is available or the spelling of the filename is correct. For the exact error description, see the file appldiag.


-831: File read error (MaxDB: Messages)

-831: File read error

Explanation:

A file could not be read. This may be a device failure.

User Action:

Check whether the file is available or the spelling of the filename is correct. For the exact error description, see the file appldiag.


-832: File write error (MaxDB: Messages)

-832: File write error

Explanation:

A file could not be written. This may be a device failure.

User Action:

Check whether the file is available or the spelling of the filename is correct. For the exact error description, see the file appldiag.


-833: Illegal INCLUDE position (MaxDB: Messages)

-833: Illegal INCLUDE position

Explanation:

An INCLUDE statement is not at the correct position in the module.

User Action:

Place the INCLUDE statement in the correct position.


-834: INCLUDEs must not be nested (MaxDB: Messages)

-834: INCLUDEs must not be nested

Explanation:

Another INCLUDE statement was found within an INCLUDE file.

User Action:

Remove the inner INCLUDE statement.


-835: INCLUDE file open error (MaxDB: Messages)

-835: INCLUDE file open error

Explanation:

The INCLUDE file could not be opened.

User Action:

Check whether the file is available or the spelling of the filename is correct. For the exact error description, see the file appldiag.


-836: Invalid C preprocessor command (MaxDB: Messages)

-836: Invalid C preprocessor command

Explanation:

The C preprocessor command line is incorrect.

User Action:

Correct the command in accordance with the C rules.


-837: Data definition not allowed (MaxDB: Messages)

-837: Data definition not allowed

Explanation:

The syntax of the SQL data type is incorrect or the SQL data type is invalid.

User Action:

Correct the data definition or construct a valid alternative.


-838: Invalid declarator (MaxDB: Messages)

-838: Invalid declarator

Explanation:

The declarator is invalid.

User Action:

Correct the declarator in the declare section.


-839: Invalid macro value (MaxDB: Messages)

-839: Invalid macro value

Explanation:

An error occurred when substituting the macro.

User Action:

Specify the macro value in accordance with the syntax.


-840: Invalid numeric macro value (MaxDB: Messages)

-840: Invalid numeric macro value

Explanation:

The macro number is invalid.

User Action:

Specify a number between 1 and 128 for the macro.


-841: Invalid precompiler option (MaxDB: Messages)

-841: Invalid precompiler option

Explanation:

A precompiler option is incorrect or unknown.

User Action:

For the exact error description, see the precompiler log or the SQLERROR file. Check the options and specify them correctly.


-842: Parameter and indicator do not match (MaxDB: Messages)

-842: Parameter and indicator do not match

Explanation:

Parameters and indicators are defined with different types (Record - Scalar). Valid combinations of SQL variables and indicator variables are Record - Record, Record - Integerarray and Scalar - Scalar.

User Action:

Use indicator variables which have another type.


-843: Invalid parameter name (MaxDB: Messages)

-843: Invalid parameter name

Explanation:

The parameter name is not an identifier.

User Action:

Correct the name in accordance with the notation of identifiers.


-844: Invalid record name (MaxDB: Messages)

-844: Invalid record name

Explanation:

The record name is invalid or unknown.

User Action:

Declare a record or use another SQL variable.


-845: Invalid SQL statement (MaxDB: Messages)

-845: Invalid SQL statement

Explanation:

The SQL statement is invalid or unknown.

User Action:

Correct the SQL statement or use another SQL statement.


-846: Invalid statement in section (MaxDB: Messages)

-846: Invalid statement in section

Explanation:

A statement in the section is invalid.

User Action:

Correct the statement or use another SQL statement.


-847: Invalid type definition (MaxDB: Messages)

-847: Invalid type definition

Explanation:

The type definition or clause is invalid or not allowed.

User Action:

Correct the definition or clause, or remove it from the declare section.


-848: Invalid unsigned integer (MaxDB: Messages)

-848: Invalid unsigned integer

Explanation:

An unsigned integer was expected but not found.

User Action:

Correct the SQL statement.


-849: Invalid data definition (MaxDB: Messages)

-849: Invalid data definition

Explanation:

The SQL variable or data definition is invalid or not allowed. The variable definition is not known as an SQL variable.

User Action:

Declare the SQL variable name or the data in the declare section, or correct the name or data.


-850: Statement termination expected (MaxDB: Messages)

-850: Statement termination expected

Explanation:

The termination symbol is missing in the preceding SQL statement. It is set by the precompiler.

User Action:

If there are no side effects, insert the termination symbol into the statement.


-851: Missing input file name (MaxDB: Messages)

-851: Missing input file name

Explanation:

A name specified for an INCLUDE file is unknown.

User Action:

Check whether the file is available or the spelling of the filename is correct.


-852: Missing program file (MaxDB: Messages)

-852: Missing program file

Explanation:

The source file is unknown.

User Action:

Check whether the file is available or the spelling of the filename is correct.


-853: Precompiler syntax check only (MaxDB: Messages)

-853: Precompiler syntax check only

Explanation:

Although the precompiler option CHECK was specified, the syntax of this statement could only be checked for the precompiler run. No entries were made to the database catalog of the database instance.

User Action:

To obtain information about possible errors, run the application with the TRACE option.


-854: Parameters must be question marks (MaxDB: Messages)

-854: Parameters must be question marks

Explanation:

In PREPARE statements, only question marks are allowed for parameter specifications.

User Action:

Replace the SQL variable with a question mark.


-855: SQL variable must be an array (MaxDB: Messages)

-855: SQL variable must be an array

Explanation:

SQL variables must be array structures in an SQL array statement.

User Action:

Define and specify the SQL variable correctly.


-856: Invalid loop parameter value (MaxDB: Messages)

-856: Invalid loop parameter value

Explanation:

In an SQL array statement, the value of the <LOOP PARAMETER> is set to <= 0.

User Action:

Set the <LOOP PARAMETER> to a value > 0.


-857: Missing SERVERDB (MaxDB: Messages)

-857: Missing SERVERDB

Explanation:

No SET SERVERDB statement was issued for the second or any following database connection.

User Action:

Specify SET SERVERDB before the CONNECT statement or in the XUSER file.


-858: Storage class not allowed (MaxDB: Messages)

-858: Storage class not allowed

Explanation:

The C storage class is not allowed.

User Action:

Choose another storage class.


-859: Number of columns < number_of_parameters (MaxDB: Messages)

-859: Number of columns < number_of_parameters

Explanation:

More SQL variables are specified in the statement than columns are available in the table.

User Action:

If this is not desired, add columns to the table or reduce the number of SQL variables.


-860: Too many constants declared (MaxDB: Messages)

-860: Too many constants declared

Explanation:

Too many SQL constants are declared.

User Action:

The database application should be modularized. The maximum number of constants is 100.


-870: Too many type definitions (MaxDB: Messages)

-870: Too many type definitions

Explanation:

The number of type definitions is too great.

User Action:

Break down the SQL statements into several modules or reduce the number of type definitions. The maximum number is 500.


-871: Too many variable definitions (MaxDB: Messages)

-871: Too many variable definitions

Explanation:

The number of SQL variable definitions is too great.

User Action:

Break down the SQL statements into several modules or reduce the number of SQL variable declarations. The maximum number is 10000.


-872: Number of columns > number of parameters (MaxDB: Messages)

-872: Number of columns > number of parameters

Explanation:

Fewer SQL variables were specified in the statement than columns existed in the table.

User Action:

If this is not desired, either add SQL variables or reduce the number of columns in the table.


-873: Unknown constant name (MaxDB: Messages)

-873: Unknown constant name

Explanation:

The name of the constant is not known.

User Action:

Correct or declare the name.


-874: Unknown cursor name (MaxDB: Messages)

-874: Unknown cursor name

Explanation:

The name of the cursor is not known.

User Action:

Correct the name or define a cursor.


-876: Unknown macro number (MaxDB: Messages)

-876: Unknown macro number

Explanation:

The macro number is not known. The SET MACRO statement was not executed for the specified macro number.

User Action:

Enter the correct number or define an appropriate macro.


-877: Unknown parameter name (MaxDB: Messages)

-877: Unknown parameter name

Explanation:

The name of the parameter is not known.

User Action:

Correct the name or declare an indicator.


-878: Unknown record name (MaxDB: Messages)

-878: Unknown record name

Explanation:

The name of the record is not known.

User Action:

Correct the name or declare a record.


-879: Unknown precompiler statement (MaxDB: Messages)

-879: Unknown precompiler statement

Explanation:

The precompiler statement is unknown or incorrect.

User Action:

Ignore the precompiler statement or correct it.


-880: Unknown statement name (MaxDB: Messages)

-880: Unknown statement name

Explanation:

The name of the statement is not known.

User Action:

Ignore the PREPARE statement or correct it.


-881: Unknown type name (MaxDB: Messages)

-881: Unknown type name

Explanation:

The type definition is not known.

User Action:

Correct the type name or define a type.


-882: Missing user name for connect (MaxDB: Messages)

-882: Missing user name for connect

Explanation:

No user/password combination was found for an implicit CONNECT initiated by the precompiler option CHECK.

User Action:

Write a static CONNECT statement as the first SQL statement in the program, apply the USER option or create an XUSER file for an implicit CONNECT.


-883: Invalid runtime options (MaxDB: Messages)

-883: Invalid runtime options

Explanation:

The precompiler or runtime options are incorrect.

User Action:

Correct the options.


-884: Missing indicator variable (MaxDB: Messages)

-884: Missing indicator variable

Explanation:

The database system allows NULL values for the variable. For this it requires an indicator variable.

User Action:

In addition to the SQL variable you must specify an indicator variable. This specification is not necessary when it is ensured that null values will not occur.


-885: Variable may be truncated (MaxDB: Messages)

-885: Variable may be truncated

Explanation:

The range of values for the database column is smaller than that of the SQL variables. When the value is inserted into the column or when values are compared, the value of the SQL variables may be truncated and consequently be incorrect.

User Action:

If this is not desired, you must change the format of the column or SQL variables.


-886: DECLARE SECTION BEGIN or END missing (MaxDB: Messages)

-886: DECLARE SECTION BEGIN or END missing

Explanation:

The declare section has an incorrect delimiter statement.

User Action:

Each declare section must be included in the BEGIN DECLARE SECTION and END DECLARE SECTION.


-887: Too long WHENEVER action (MaxDB: Messages)

-887: Too long WHENEVER action

Explanation:

A maximum of 50 bytes are available to define the WHENEVER action.

User Action:

Reduce the number of characters, e.g. by shortening the names.


-889: Input line longer than 512 characters (MaxDB: Messages)

-889: Input line longer than 512 characters

Explanation:

A line of a precompiler input file must not exceed 512 characters.

User Action:

Shorten the line concerned.


-890: Input line longer than right margin (MaxDB: Messages)

-890: Input line longer than right margin

Explanation:

A line of the source file is longer than the right margin.

User Action:

If allowed, adjust the right margin using the option MARGINS. Otherwise shorten the line.


-892: Variable my be overflow (MaxDB: Messages)

-892: Variable my be overflow

Explanation:

This warning is set if a numeric value greater than allowed by the column definition can be transferred to a table. At runtime, the error -751 can be returned; i.e. the SQL statement will not be executed then.

User Action:

To avoid error -751 check the size of the value before transferring it into the table.

The handling of this error must be programmed.


-893: Too many hostvariables (MaxDB: Messages)

-893: Too many hostvariables

Explanation:

...

1. Too many parameters are specified in an SQL statement with descriptor.

2. In an SQLDA area, an SQLVAR entry was accessed which is no longer available (maximum number of SQLVAR entries <index_of_the_SQLVAR entry).

User Action:

Reduce the number of parameters in the SQL statement to 300 or less.


-894: Trace parameter structure not allowed (MaxDB: Messages)

-894: Trace parameter structure not allowed

Explanation:

There is a syntax error in SET TRACE LINE.

User Action:

Correct the SET TRACE LINE statement.


-895: Whole table may be deleted or updated (MaxDB: Messages)

-895: Whole table may be deleted or updated

Explanation:

Precompiler warning that all entries of the table will be deleted or updated.

User Action:

Check whether this is the desired effect. Otherwise, insert a WHERE clause into the statement.


-899: Error unknown (MaxDB: Messages)

-899: Error unknown

Explanation:

An unknown error has occurred.

User Action:

Contact Support.


From -900 to -999 (MaxDB: Messages)

From -900 to -999

Database Kernel Error Messages

-900 | Data area full
-901 | Log full
-902 | I/O error
-903 | Hostfile I/O error
-904 | Space for result tables exhausted
-907 | Space for user session exhausted
-910 | COSTLIMIT for this user exhausted
-911 | Work rolled back
-913 | Lock request timeout
-914 | New volume not accessible
-915 | No more memory
-917 | Save/Restore write process crash - I/O error
-918 | Stack overflow
-942 | Unknown table name
-955 | Duplicate name


-900: Data area full (MaxDB: Messages)

-900: Data area full

Explanation:

The data area of the database instance is full.

User Action:

The database instance must be enlarged by assigning additional volumes. The SQL statements started beforehand will be finished afterwards.


-901: Log full (MaxDB: Messages)

-901: Log full

Explanation:

The log area is full. The following reasons are possible:

...

1. Log backup is not active. The Database Manager makes modifications which together with modifications of other transactions result in a log area overflow.

2. Log backups are performed. but the backups are not performed fast enough or there is a very long transaction whose modifications together with the modifications of transactions running in parallel result in a log area overflow. The Database Manager performs change operations.

The issued SQL statement fails.

User Action:

...

1. Save the log area.
Repeat the SQL statement.

2. The database system saves the log area that is required by the very long transaction in other areas of the database instance. The command can then be repeated.

Check whether this state occurs frequently, that is whether the log area is too small for the number of users and average transaction length. In this case, the log area should be increased.

You should also check whether there is an error in the application programming which results in the very long or endless transaction and correct this if necessary.


-902: I/O error (MaxDB: Messages)

-902: I/O error

Explanation:

During the processing of an SQL statement a read or write operation had to be performed on the data area or log area. This operation could not be executed successfully. The following reasons are possible:

...

1. A SHUTDOWN was performed in the meantime.

2. A disk is defective.

User Action:

In some cases, the error message contains an additional description of the error which must be interpreted according to the operating system being used.

...

1. Use the Database Manager to start the database instance.

2. Once the disk error has been corrected, the database instance must be restored.


-903: Hostfile I/O error (MaxDB: Messages)

-903: Hostfile I/O error

Explanation:

An error occurred while operating a command file or host file or a backup device.

User Action:

The error message contains an additional error description which must be interpreted according to the operating system being used.

To find out and remove the error cause, consult the documentation on the operating system.

Check whether a typing error or the specification of a directory instead of a file could have caused the error.


-904: Space for result tables exhausted (MaxDB: Messages)

-904: Space for result tables exhausted

Explanation:

The storage space for result tables is exhausted.

The following reasons are possible:

...

1. The storage space available for result tables is too small or

2. the database application generated too much temporary information.

In both cases, the execution of the SQL statement was terminated and the user was disconnected from ADABAS by an implicit RELEASE statement in the format ROLLBACK WORK RELEASE.

User Action:

...

1. Reissue the SQL statement after a new CONNECT statement. At this time another user may have defined fewer result tables or generated less temporary information.

2. Use the Database Manager to define more disk space.

3. Use the TABLEEXTRACT statement to extract tables and make more space.


-907: Space for user session exhausted (MaxDB: Messages)

-907: Space for user session exhausted

Explanation:

You have not been connected to the database system because there is not sufficient free temporary disk space to connect to a normal database session.

User Action:

...

1. You can connect as soon as another user has disconnected, or when deletion of other users’ result tables frees up sufficient storage space again.

2. You can use the Database Manager to connect and reconfigure the database instance.


-910: COSTLIMIT for this user exhausted (MaxDB: Messages)

-910: COSTLIMIT for this user exhausted

Explanation:

Execution of the SQL statement would exceed the permissible maximum limit for the processing of the SQL statement (COSTLIMIT value of the user) because of the necessary selection of rows. The COSTLIMIT value is defined in the CREATE USER, CREATE USERGROUP, ALTER USER or ALTER USERGROUP statement.

User Action:

You should check whether the SQL statement is needed in the specified format. You should check whether for example the set of data to be processed could be decreased by specifying more conditions in the search condition; thus decreasing the costs.

Should this not be possible, try to achieve the effect of the SQL statement by several less costly SQL statements.

Display the definition of the COSTLIMIT value using a QUERY statement issued on the system table DOMAIN.USERS.

The database administrator or the owner of the user group or user may increase the COSTLIMIT value by using an ALTER USER or ALTER USERGROUP statement.


-911: Work rolled back (MaxDB: Messages)

-911: Work rolled back

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. for the following possible reasons:

...

1. The user failed to carry out any database operations within a certain period of time, but was holding locks which other users were waiting for.

2. the database instance was in a deadlock situation.

A deadlock situation is where two or more users hold locks and request further locks that are held by the other users. In the simplest case of two users, one user holds one lock at least and requests another lock. But this lock is held by another user who is himself waiting for the lock held by the first user. This situation can only be resolved if one of the users releases the lock already obtained.

User Action:

In some cases, the error message contains a more detailed description of the error.

In both cases, the lock requests must be checked and modified, if necessary. Repeat the last transaction.


-913: Lock request timeout (MaxDB: Messages)

-913: Lock request timeout

Explanation:

The lock request or an implicit lock conflicts with the locks of another user. The maximum waiting time for being granted the lock has elapsed (database parameter REQUEST_TIMEOUT).

User Action:

In some cases, the error message contains a more detailed description of the error.

The lock request can be reissued. To avoid possible deadlock situations, it is advisable to roll back the transaction with a ROLLBACK statement to avoid possible deadlock situations.


-914: New volume not accessible (MaxDB: Messages)

-914: New volume not accessible

Explanation:

You tried to define an additional disk for the data area. However, you were unable to do so because there is no disk with the specified name and size which could be accessed.

User Action:

The error message contains an additional error description which must be interpreted according to the operating system being used.

Check the name and size of the disk as well as the installation. Repeat the command with changed specifications.


-915: No more memory (MaxDB: Messages)

-915: No more memory

Explanation:

...

1. The available main memory is not sufficient to open a database session. The maximum main memory available is determined by the database parameter CAT_CACHE_SUPPLY when installing the database instance.

2. The available main memory is not sufficient to execute the desired database procedure.

User Action:

...

1. You can only open a session when at least one other user has terminated his session. A check should be made as to whether the value of the database parameter CAT_CACHE_SUPPLY is large enough.

2. Try to execute the database procedure at a later time.


-917: Save/restore write process crash - I/O error (MaxDB: Messages)

-917: Save/restore write process crash - I/O error

Explanation:

  1. An I/O error occurred while attempting to write to a backup device for a save statement.
  2. An I/O error occurred while attempting to write to a volume for a restore statement.

The restore or save statement was cancelled.

User Action:

The error message contains an additional error description which must be interpreted according to the operating system being used.

To find out and remove the error cause, consult the documentation on the operating system.


-918: Stack overflow (MaxDB: Messages)

-918: Stack overflow

Explanation:

Nested calls of database procedures, triggers or subqueries or very complicated value specification resulted in the maximum stack usage allowed for a task. Further nesting is not possible. The execution of the command was cancelled.

User Action:

...

1. Further limit the nesting depth of the calls with suitable queries in the DB procedures and triggers.

2. Try to limit the nesting depth by dividing the SQL statement into several substatements.


-942: Unknown table name (MaxDB: Messages)

-942: Unknown table name

Explanation:

A table with the specified name is not known to you. This table may not exist; or this table exists but you have no privileges for it.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TABLES to find out the names of the tables for which you have privileges. Correct the table name. (It may be sufficient to place the missing owner in front of the name.) If correction is not possible, create a table with this name. Check why you have no privileges for the existing table.


-955: Duplicate name (MaxDB: Messages)

-955: Duplicate name

Explanation:

There is already a data object with the specified name.

User Action:

Repeat the SQL statement with another name.


From -1000 to -1999 (MaxDB: Messages)

From -1000 to -1999

Database Kernel Error Messages

-1000 | Too many lock requests
-1001 | Too many lock objects specified
-1002 | Too many columns
-1003 | Too many buffers requested
-1004 | Too many correlated columns
-1005 | Too many monadic operators
-1006 | Too many variables
-1007 | Parameter list too long
-1008 | Too many or too few host variables for output
-1009 | Too many named indexes for this table
-1010 | Too many volumes
-1011 | Too many correlated tables
-1012 | Too many referential constraint definitions for this table
-1013 | Too many order columns
-1014 | Too many source tables
-1015 | Too many values
-1017 | Too many joins
-1023 | Too many nested subtransactions
-1025 | Too many asynchron requests
-1026 | Too many differences between old and new view definition
-1102 | Too complicated SQL statement (Too many Subqueries)
-1103 | Too complicated SQL statement
-1104 | Too complicated SQL statement (KB-stack overflow)
-1105 | Too complicated SQL statement (Too much data)
-1106 | Too complicated SQL statement (Too much strategy data)
-1107 | Too complicated SQL statement (Too many internal commands)
-1108 | Too complicated SQL statement (Correlated row too long)
-1110 | view definition Too long
-1111 | Too many savepoints
-1112 | Constraint too complicated
-1113 | Too many nested function calls
-1114 | Communication packet too small
-1115 | Too many intern columns
-1116 | Too long trigger parameters
-1117 | Too complicated trigger qualification
-1119 | Too many constraints for this table
-1120 | Too many statements in definition
-1200 | Too few values
-1201 | Too few columns
-1400 | Input parameter cannot be NULL value
-1402 | Integrity violation
-1403 | Row not found
-1405 | Missing indicator variable, output parameter
-1406 | Output value truncated
-1452 | Duplicate secondary key
-1556 | Data space full
-1755 | SQL statement will drop further objects (use CASCADE)


-1000: Too many lock requests (MaxDB: Messages)

-1000: Too many lock requests

Explanation:

There are too many locks or lock requests.

User Action:

You can try to repeat the SQL statement at a later time or cancel the transaction. If this situation occurs frequently, then the defined database parameter MAXLOCKS is too small and should be increased.


-1001: Too many lock objects specified (MaxDB: Messages)

-1001: Too many lock objects specified

Explanation:

The LOCK statement contains too many tables or table rows that need to be locked.

User Action:

The SQL statement must be formulated using two successive LOCK statements.


-1002: Too many columns (MaxDB: Messages)

-1002: Too many columns

Explanation:

1. The maximum number of columns specified in Technical Specifications has been exceeded.

2. A named index can be created across a maximum of 16 columns of a table.

3. In a referential CONSTRAINT definition, more referencing columns were specified than referenced columns. The number of specified columns in the referencing table must correspond to the specified number of referenced columns in the referenced table.

User Action:

1. Use a QUERY-statement issued on the system table DOMAIN.COLUMNS to find out the current definition of the table. You must not define any further columns.

2. Correct the number of columns in the index definition.

3. Use a QUERY-statement issued on the system table DOMAIN.COLUMNS to find out the complete definition and the key columns of the referenced table.

...

Wenn keine Schlüsselspalte definiert wurde, beträgt die maximale Anzahl der Spalten 254, da das System automatisch eine interne Schlüsselspalte SYSKEY einfügt. Ansonsten beträgt die Anzahl 255.

n


-1003: Too many buffers requested (MaxDB: Messages)

-1003: Too many buffers requested

Explanation:

The storage requirements of the buffers and areas defined by the database parameters are larger than the maximum virtual storage space available for the database system. The execution of the SQL statement was cancelled.

User Action:

Either decrease the size or number of buffers and areas or increase the virtual storage space available to the database system. Restart the database instance.


-1004: Too many correlated columns (MaxDB: Messages)

-1004: Too many correlated columns

Explanation:

The SQL statement contains at least one correlated subquery. An attempt was made to use more than 64 correlated columns. At most 64 correlated columns can be used. Every single usage of a correlated column is counted.

User Action:

Rearrange the SQL statement in such a way that 64 correlated columns suffice. Alternatively you may want to try to achieve the effect of this SQL statement with several SQL statements.


-1005: Too many monadic operators (MaxDB: Messages)

-1005: Too many monadic operators

Explanation:

The SQL statement contains at least two monadic operators placed one after the other in an invalid manner.

User Action:

Correct the monadic operators in the SQL statement..


-1006: Too many variables (MaxDB: Messages)

-1006: Too many variables

Explanation:

A maximum of 2000 parameters may be specified per SQL statement (see Technical Specifications)..

User Action:

Reduce the number of parameters specified in the SQL statement. Some parameters must be replaced with constant values. If this is not possible, split the SQL statement into several SQL statements.


-1007: Parameter list too long (MaxDB: Messages)

-1007: Parameter list too long

Explanation:

More parameters have been specified in a statement than are permitted in the pertinent EXECUTE statement.

User Action:

Modify the number of parameters in such a way that it corresponds to the specifications made in the column list.


-1008: Too many or too few host variables for output (MaxDB: Messages)

-1008: Too many or too few host variables for output

Explanation:

The SQL statement contains variables for selected columns.

The number of variables does not match the number of selected columns.

User Action:

Check the number and data types of the variables, and correct them.

In the SELECT statement, replace ‘*’ with a sequence of column names.


-1009: Too many named indexes for this table (MaxDB: Messages)

-1009: Too many named indexes for this table

Explanation:

A maximum of 255 named indexes can be created for each table (see Technical Specifications).

User Action:

Check whether you need this many indexes.

The amount of work needed to maintain indexes for change operations, and the amount of memory needed for the indexes, is usually out of proportion to the benefits.


-1010: Too many volumes (MaxDB: Messages)

-1010: Too many volumes

Explanation

The number of data volumes is limited during installation (see Technical Specifications).. This number was exceeded.

User action

Reduce the number of data volumes.


-1011: Too many correlated tables (MaxDB: Messages)

-1011: Too many correlated tables

Explanation:

The number of correlated tables used in the correlated subqueries cannot exceed 16 (see Technical Specifications).

User Action:

Try to formulate the SQL statement in such a way that 16 correlated tables are sufficient. Should this not be possible you have to use several SQL statements to achieve the desired effect.


-1012: Too many referential constraint definitions for this tabl (MaxDB: Messages)

-1012: Too many referential constraint definitions for this table

Explanation:

An attempt was made to generate a referential CONSTRAINT definition. When doing this, the total lengths of all referring or all referred columns exceeeds the maximum row length.

User Action:

This SQL statement can only be called once an existing CONSTRAINT definition has been deleted. Otherwise, do without the new CONSTRAINT definition.


-1013: Too many order columns (MaxDB: Messages)

-1013: Too many order columns

Explanation:

The following causes of errors are possible:

  1. More than 128 columns were specified as sort criteria or group columns (see Technical Specifications).
  2. The total length of the order or group columns exceeds 1020 bytes.
  3. The length of the longest result data type of a DISTINCT function, together with the lengths of the group columns, exceeds 254 characters. The result data type is the data type which is assigned to the result of an expression.

User Action:

In the SQL statement, you must remove one or more columns specified in the ORDER clause or GROUP clause.


-1014: Too many source tables (MaxDB: Messages)

-1014: Too many source tables

Explanation:

The number of underlying tables of the FROM clause of the SQL statement exceeds 16. If a join view table was specified in the FROM clause, the number of base tables underlying the join view table is considered for the calculation.

User Action:

You can split the SQL statement into two successive SQL statements.

It is also possible to bypass this restriction by using a QUERY expression in the FROM clause.


-1015: Too many values (MaxDB: Messages)

-1015: Too many values

Explanation:

In an INSERT or UPDATE statement, the number of specified values exceeds the number of column names implicitly specified.

User Action:

Match the number of specified values in the SQL statement with the number of specified column names. Use a QUERY statement issued on the system table DOMAIN.COLUMNS for an INSERT statement without column name specification to determine the definition of the table used .


-1017: Too many joins (MaxDB: Messages)

-1017: Too many joins

Explanation:

The number of JOIN predicates in a search condition cannot exceed 64 (see Technical Specifications).

User Action:

The expected result can be achieved by issuing several QUERY statements and creating the respective result tables as temporary results. It is also possible to change the SQL statement in such a way that temporary results are implicitly created when a QUERY expression is used in a FROM clause.


-1023: Too many nested subtransactions (MaxDB: Messages)

-1023: Too many nested subtransactions

Explanation:

The maximum nesting level of subtransactions is 32767. This number was exceeded.

User Action:

Check which error in application programming generated this a nesting level of subtransactions, and correct it.


-1025: Too many asynchron requests (MaxDB: Messages)

-1025: Too many asynchron requests

Explanation

The specified SQL statement is intended to be processed asynchronously. However, there are not currently enough resources available.

User action

Execute the SQL statement later.


-1026: Too many differences between old and new view definition (MaxDB: Messages)

-1026: Too many differences between old and new view definition

Explanation:

A CREATE VIEW statement was specified with the REPLACE option. A view table with the specified name already exists. The existing view definition differs so much from the specified view definition that the definitions depending on this view table can no longer be maintained in a consistent state. The CREATE VIEW statement therefore fails.

User Action:

Do not modify the specified view table or check which of the depending definitions, e.g., view tables, privileges, and so on, do not match the new view definition. If there are some, delete them before re-executing the CREATE VIEW statement, and recreate them afterwards in an appropriate format.


-1102: Too complicated SQL statement (Too many subqueries) (MaxDB: Messages)

-1102: Too complicated SQL statement (Too many subqueries)

Explanation:

1. The SQL statement contains too many subqueries. The number of permissible subqueries depends on the kind of SQL statement.

2. Subqueries were specified in a table expression as well as in the WHERE clause and HAVING clause of an SQL statement containing at least one corresponding subquery. This is not allowed.

User Action:

Simplify the SQL statement or split it into several SQL statements.


-1103: Too complicated SQL statement (MaxDB: Messages)

-1103: Too complicated SQL statement

Explanation:

The number of operations, functions, and conditions is too large.

User Action:

Simplify the SQL statement. You may also want to try to obtain the effect of the SQL statement with several SQL statements.


-1104: Too complicated SQL statement (KB-stack overflow) (MaxDB: Messages)

-1104: Too complicated SQL statement (KB-stack overflow)

Explanation:

Within the system, more elements of an internal structure are needed to represent the SQL statement than are available.

User Action:

Simplify the SQL statement or split it into several SQL statements.

If this is not possible, check whether the database parameter PACKET_SIZE can be increased, because the size of the internal structure depends on the size of that parameter. The structure size will be adapted from a certain limit value of PACKET_SIZE.


-1105: Too complicated SQL statement (Too much data) (MaxDB: Messages)

-1105: Too complicated SQL statement (Too much data)

Explanation:

Within the system, more space is needed to represent the data of the SQL statement than is available.

User Action:

Simplify the SQL statement or split it into several SQL statements. If this is not possible, check whether the database parameter PACKET_SIZE can be increased, because the amount of storage space available depends on that parameter. An increase in excess of 32 KB will not increase the amount of space any further.


-1106: Too complicated SQL statement (Too much strategy data) (MaxDB: Messages)

-1106: Too complicated SQL statement (Too much strategy data)

Explanation

The search strategy used to process the SQL statement is greater than the space available.

User action

Delete some of the search strings containing an OR option.


-1107: Too complicated SQL statement (Too many internal commands (MaxDB: Messages)

-1107: Too complicated SQL statement (Too many internal commands)

Explanation:

The SQL statement is so complicated that more internal statements must be generated for it than can be administered for an SQL statement.

User Action:

Simplify the SQL statement or split it into several SQL statements.


-1108: Too complicated SQL statement (correlated row too long) (MaxDB: Messages)

-1108: Too complicated SQL statement (correlated row too long)

Explanation:

The processing of an SQL statement containing at least one correlated subquery requires the generation of an internal result whose rows would exceed the valid length.

User Action:

Check whether some columns within the SELECT statement can be omitted or whether the SQL statement can be reformulated in such a way that less or no corresponding columns (correlated columns) are used.


-1110: View definition too long (MaxDB: Messages)

-1110: View definition too long

Explanation:

The definition of a view table is longer than the space available for it. This error may also occur with a RENAME COLUMN statement when the view definition maintained internally exceeds the maximum length because of the extension of the name.

User Action:

Shorten the view table, for example by using short reference names instead of long table names in the SELECT statement or the search condition.


-1111: Too many savepoints (MaxDB: Messages)

-1111: Too many savepoints

Explanation:

Too many savepoints were defined within a transaction.

User Action:

Check how this uncommonly large number of savepoints occurred. Include the missing COMMIT or ROLLBACK statements in the application.


-1112: Constraint too complicated (MaxDB: Messages)

-1112: Constraint too complicated

Explanation:

The internal representation of the constraint is longer than the space available for it.

User Action:

The constraint should be simplified or split into several constraints.


-1113: Too many nested function calls (MaxDB: Messages)

-1113: Too many nested function calls

Explanation:

The SQL statement contains more nested function calls than can be processed.

User Action:

Check whether some of the functions within the nesting can be omitted. If this is not possible, check whether the desired effect can be obtained by using a QUERY expression in the FROM clause or by generating and reusing a named result set containing a part of the functions.


-1114: Communication packet too small (MaxDB: Messages)

-1114: Communication packet too small

Explanation:

The SQL statement is so long that not all pieces of information to be exchanged between client and server can be stored in the communication packet provided for this purpose.

User Action:

Simplify the SQL statement or split it into several SQL statements. If this is not possible, check whether the database parameter PACKET_SIZE can be increased. This parameter indicates the size of the communication packet.


-1115: Too many intern columns (MaxDB: Messages)

-1115: Too many intern columns

Explanation:

An ALTER TABLE statement or a CREATE VIEW statement generates a table description either containing more columns than allowed or whose rows exceed the maximum length. Under certain circumstances, this situation can occur because of columns that are invisible to the user.

User Action:

For a CREATE VIEW statement, check whether some output columns can be omitted. For an ALTER TABLE statement, check whether the specified column width can be decreased. Check also whether previous ALTER TABLE statements generated so many invisible columns that the MODIFY definition command should be used to remove invisible columns instead of the ALTER definition command. The effect would be the copying of the table, a procedure which requires considerable space and time.


-1116: Too long trigger parameters (MaxDB: Messages)

-1116: Too long trigger parameters

Explanation:

A trigger was defined with parameters whose total length exceeds the possible length.

User Action:

Try and reduce the number of parameters.


-1117: Too complicated trigger qualification (MaxDB: Messages)

-1117: Too complicated trigger qualification

Explanation:

The internal representation of the trigger qualification is longer than the space available for this purpose.

User Action:

Simplify the trigger qualification.


-1119: Too many constraints for this table (MaxDB: Messages)

-1119: Too many constraints for this table

Explanation:

More conditions have been defined for this table than is permitted. This is either because you have used a specific range of values or because you have explicitly specified certain constraints.

User Action:

Either check whether or not you really need all the constraints and get rid of any you do not need or group several constraints into one. Repeat the command using the new constraint definitions.


-1120: Too many statements in definition (MaxDB: Messages)

-1120: Too many statements in definition

Explanation:

You specified more than 255 SQL statements within a CREATE TRIGGER statement or CREATE DBPROC statement.

User Action:

Delete some of your SQL statements and try to get the same effect using fewer statements.


-1200: Too few values (MaxDB: Messages)

-1200: Too few values

Explanation:

In an INSERT or UPDATE statement, the number of specified values is less than the number of column names implicitly specified.

User Action:

Match the number of specified values in the SQL statement with the number of specified column names. You can use a QUERY statement issued on the system table DOMAIN.COLUMNS for an INSERT statement without column name specification to determine the definition of the table used.


-1201: Too few columns (MaxDB: Messages)

-1201: Too few columns

Explanation:

In a referential CONSTRAINT definition, fewer referencing columns were specified than referenced columns. The number of specified columns in the referencing table must correspond to the number of referenced columns of the referenced table specified implicitly or explicitly.

User Action:

You can use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the current definition of the key columns in the referenced table. Use a QUERY statement issued on the system table DOMAIN.IND_USES_COL to find out the indexes of the referenced table. The specification of the referencing table columns must be adapted accordingly.


-1400: Input parameter cannot be NULL value (MaxDB: Messages)

-1400: Input parameter cannot be NULL value

Explanation:

The value of an input parameter must not be a NULL value, because NULL values are not permitted for the column.

User Action:

Modify the program or change the column definition in the CREATE TABLE statement.


-1402: Integrity violation (MaxDB: Messages)

-1402: Integrity violation

Explanation:

Insertions or updates would violate integrity constraints specified in the definition of the base or the view table.

User Action:

The error message specifies the column which would violate the integrity constraints. Correct the input value for the corresponding column.


-1403: Row not found (MaxDB: Messages)

-1403: Row not found

Explanation

There is no (other) table row that meets the specified criteria.

User action

No user action is required.


-1405: Missing indicator variable, output parameter with NULL va (MaxDB: Messages)

-1405: Missing indicator variable, output parameter with NULL value

Explanation:

The indicator variable required for returning the NULL value to the SQL variable is missing.

User Action:

Specify the indicator variable with the parameter.


-1406: Output value truncated (MaxDB: Messages)

-1406: Output value truncated

Explanation:

The column's range of values is greater than that of the SQL variable. The value was truncated when being inserted into the SQL variable.

User Action:

Adapt the range of values of the SQL variable to that of the column.


-1452: Duplicate secondary key (MaxDB: Messages)

-1452: Duplicate secondary key

Explanation:

Several table rows already exist with the same values in the specified columns when a UNIQUE definition is specified, when the column attribute UNIQUE is used or when a UNIQUE definition is specified in the CREATE INDEX statement.

User Action:

Do not use the UNIQUE definition; otherwise ensure that only one table row contains a certain combination of values in the specified columns. The error message specifies the column or multiple-column index already containing the specified values.


-1556: Data space full (MaxDB: Messages)

-1556: Data space full

Explanation

The data devspace of the database instance is full.

User action

You must increase the database's data devspace by adding extra data volumes. Any SQL statements that were started beforehand will be executed.


-1755: SQL statement will drop further objects (use CASCADE) (MaxDB: Messages)

-1755: SQL statement will drop further objects (use CASCADE)

Explanation:

A DROP USER, DROP TABLE, DROP VIEW or REVOKE statement was specified for which the CASCADE option had not been specified implicitly or explicitly. Other objects depend on the object to be deleted. These objects must be deleted as well but this is only possible with an implicit or explicit specification of the CASCADE option.

User Action:

Before specifying the same SQL statement with the CASCADE option, you should check which dependent objects exist.


From -2000 to -2999 (MaxDB: Messages)

From -2000 to -2999

Database Kernel Error Messages

-2000 | Row too long
-2001 | Key too long
-2002 | One output column too long
-2003 | Output columns too long
-2004 | Numeric constant too long
-2008 | Data area too small
-2009 | Join columns too long
-2010 | Assignment impossible, char value too long
-2012 | View column list too long
-2013 | Select column list too long
-2014 | Identifier too long
-2020 | Data buffer too small
-2025 | Invalid number of backup devices
-2027 | Space for converted value too small
-2028 | Sequence <sequence name> exhausted
-2029 | <sequence name>.CURRVAL is not yet defined in this session


-2000: Row too long (MaxDB: Messages)

-2000: Row too long

Explanation:

When (re-)defining a table, the length of a table row exceeds 8088 bytes (Technical Specifications).

User Action:

1. One or more columns must be removed from a CREATE TABLE statement or their lengths must be reduced.

2. One or more columns must be removed from an ALTER TABLE statement or their lengths must be reduced. Use a QUERY-statement issued on the system table DOMAIN.COLUMNS to find out the current definition of the table.


-2001: Key too long (MaxDB: Messages)

-2001: Key too long

Explanation

1. The sum of the key column lengths must not exceed 1024 characters when using a CREATE TABLE or ALTER TABLE statement (Technical Specifications).

2. When defining a named index, the sum of the column lengths for the index must not exceed 1024 bytes.

User action

1. Correct the definition of the lengths accordingly or try to use less key columns.

3. Try to create the named index with fewer columns.


-2002: One output column too long (MaxDB: Messages)

-2002: One output column too long

Explanation:

The concatenation of values resulted in an excessively long alphanumeric value.

User Action:

Do without this kind of output. If it can be assumed that all values in a column are shorter than the maximum length defined for this column, the attempt can be made to reduce the result to fewer characters by applying the SUBSTR function. In any case, the columns and expressions involved in a concatenation can be output separately.


-2003: Output columns too long (MaxDB: Messages)

-2003: Output columns too long

Explanation:

The following reasons are possible:

...

1. The total length of the output columns exceeds 8084 bytes.

2. The total length of the output columns, together with the columns specified in the ORDER clause or GROUP clause, exceeds 8084 bytes.

3. The total length of the output columns, together with the correlated columns and the columns of predicates that contain a subquery, exceeds 8084 bytes in an SQL statement with correlated subqueries.

User Action:

...

1. The number of output columns must be reduced.

2. The attempt should be made to do without sorting or grouping, or to perform the sorting or grouping across shorter or fewer columns.

3. The attempt should be made to manage with fewer output columns or correlated columns or to achieve the desired effect using several SQL statements.


-2004: Numeric constant too long (MaxDB: Messages)

-2004: Numeric constant too long

Explanation:

...

1. The number contains more than 38 digits (Technical Specifications).

2. The number does not comply with the definition of the range of values.

User Action:

The number which was incorrectly entered may be determined from the position specification in the error message.

...

1. The number must be reduced to 38 significant digits and be specified as a floating point literal, if necessary.

2. Check the definition of the range of values and correct the specification of the number accordingly.


-2008: Data area too small (MaxDB: Messages)

-2008: Data area too small

Explanation:

· It was not possible to restore a database instance, as the database instance that is to be restored, is bigger than the target database instance specified for the restore operation.

· The installation of a database instance is not possible, as not enough space was defined for the storage of the data.

User Action:

· Reduce the size of the volume to be added.

· Raise the volume size by 2000 pages.


-2009: Join columns too long (MaxDB: Messages)

-2009: Join columns too long

Explanation:

The internal length of a table's join columns must not exceed 1020 bytes. Join columns are the columns that are contained in a JOIN predicate.

WHERE (S.A = T.V AND S.B < T.W)

The join columns of the table S are the columns S.A and S.B. The internal length of the join columns of S is the internal length of the column S.A plus the internal length of the column S.B. The internal length of the join columns of S must not exceed 1020 bytes.

User Action:

You can attempt to achieve the expected result by issuing several QUERY statements and creating tables as temporary results.


-2010: Assignment impossible, char value too long (MaxDB: Messages)

-2010: Assignment impossible, char value too long

Explanation:

In an INSERT statement with a QUERY expression or in an UPDATE statement, the attempt was made to assign a character string to a column of data type CHAR. This character string was too long. The error message is returned for the first occurring value of excess length, not while analyzing the maximum column lengths.

User Action:

Use SELECT... WHERE LENGTH (<column name>) > <unsigned_integer>to find out the rows that are too long. The length of the corresponding column can be increased by an ALTER TABLE statement.


-2012: View column list too long (MaxDB: Messages)

-2012: View column list too long

Explanation:

In a CREATE VIEW statement, the number of view table columns to be defined must be equal to the number of columns issued as the QUERY expression result. In the present case, the attempt was made to create more view table columns than columns are available in the QUERY request result.

User Action:

Reduce the number of view table columns specified in the SQL statement.


-2013: Select column list too long (MaxDB: Messages)

-2013: Select column list too long

Explanation:

The following reasons are possible:

1. In a CREATE VIEW statement, the number of view table columns to be defined must be equal to the number of columns issued as the QUERY expression result. In the present case, there are more columns in the <QUERY request> result than view table columns defined.

2. The number of subquery output columns specified in a SET UPDATE clause must be precisely one. In some SQL sessions this restriction also applies to the comparison predicate, quantity comparison prdicate and IN predicate. In the present case, the subquery produced more than one output column.

3. An SQL statement for data query was specified. The number of output columns must be less than or equal to 254. This number was exceeded.

User action

1. The number of view table columns specified in the CREATE VIEW statement must be increased or the number of output columns of the QUERY expression must be reduced.

2. The number of output columns of the subquery must be limited to one.

3. The data query statement must be corrected by removing one or more output columns.


-2014: Identifier too long (MaxDB: Messages)

-2014: Identifier too long

Explanation:

The specified identifier is too long for the SQL mode used.

User Action:

Pay attention to the restrictions in the table when specifying the identifier.

SQL mode | Length of identifier
ANSI | 18 characters maximum
DB2 | 18 characters maximum
ORACLE | 30 characters maximum
INTERNAL | 32 characters maximum


-2020: Data buffer too small (MaxDB: Messages)

-2020: Data buffer too small

Explanation:

No memory is currently available in the data cache. The execution of the SQL statement was cancelled. The database system implicitly performs a SHUTDOWN.

User Action:

Restart the database instance with an increased data cache.


-2025: Invalid number of backup devices (MaxDB: Messages)

-2025: Invalid number of backup devices

Explanation:

The number of backup devices specified for a save or restore operation does not correspond to the database parameter MAXBACKUPDEVS.

User Action:

Use the database administration tool to check the parameter and modify it, if necessary.


-2027: Space for converted value too small (MaxDB: Messages)

-2027: Space for converted value too small

Explanation

You tried to convert data in ASCII or UCS-2 format (see also UNICODE-Compliance) into another format. This attempt has failed.

User action

Check whether the target column has been defined enough space. If you cannot increase the target column, you cannot carry out an explicit conversion. You can try to avoid this error by explicitly converting the data used, for example, for comparisons.


-2028: Sequence <sequence name> exhausted (MaxDB: Messages)

-2028: Sequence <sequence name> exhausted

Explanation:

You tried to find out the next value of the specified sequence with <sequence name>.NEXTVAL. This is impossible for one of the following reasons:

...

1. The next value would not fit into the data type provided for sequences.

2. The next value would be larger than the value defined by MAXVALUE in the CREATE SEQUENCE statement, and NOCYCLE was defined implicitly or explicitly.

3. The next value would be smaller than the value defined by MINVALUE in the CREATE SEQUENCE statement, and NOCYCLE was defined implicitly or explicitly.

User Action:

...

1. Specify the desired value explicitly.

2. Delete and create the sequence again. By deleting and recreating the sequence you ensure that the values of the sequence are created cyclically or that a larger MAXVALUE or smaller MINVALUE is used. Define START WITH with the last assigned value if necessary. You may now use the SQL statement.


-2029: <sequence name>.CURRVAL is not yet defined in this sessio (MaxDB: Messages)

-2029: <sequence name>.CURRVAL is not yet defined in this session

Explanation:

You attempted to execute <sequence_name>.CURRVAL (Specification of Values (value_spec)) before using <sequence_name>.NEXTVAL in the database session.

User Action:

Execute <sequence_name>.NEXTVAL before executing <sequence_name>.CURRVAL.


From -3000 to -3999 (MaxDB: Messages)

From -3000 to -3999

Database Kernel Error Messages

-3000 | Invalid host file content
-3002 | Invalid data type
-3003 | Invalid user name
-3004 | Invalid host file sequence
-3005 | Invalid SQL statement
-3007 | Invalid sequence for DML and DDL statements
-3008 | Invalid keyword or missing delimiter
-3009 | Invalid table name
-3011 | Invalid column name
-3014 | Invalids end of SQL statement
-3016 | Invalid numeric constant
-3017 | Invalid unsigned integer
-3018 | Invalid numeric parameter
-3019 | Invalid exponent
-3020 | Invalid length for this data type
-3021 | Invalid mixture of functions and columns
-3022 | Invalid number of tables for outer join
-3024 | Invalid numeric expression
-3030 | Invalid SESSION TIMEOUT
-3035 | Invalid date time format
-3037 | Invalid Volume name
-3038 | Invalid Volume size
-3046 | Invalid char position in string function
-3047 | Invalid table for RESTORE CATALOG
-3048 | Invalid date format
-3049 | Invalid time format
-3050 | Invalid timestamp format
-3054 | Invalid block size
-3059 | Invalid day of week
-3060 | Invalid escape sequence
-3061 | Invalid escape value
-3062 | Invalid month
-3063 | Invalid format code
-3064 | Date input value out of range
-3065 | Invalid date input value
-3066 | Date input value inconsistent
-3067 | Invalid timezone
-3068 | Mismatch of parameter configuration between backup and instance
-3069 | Bad xparam page in backup
-3102 | Invalid subtrans structure
-3103 | Invalid sequence definition
-3995 | Invalid pattern
-3998 | Wrong password
-3999 | Invalid parameter


-3000: Invalid host file content (MaxDB: Messages)

-3000: Invalid host file content

Explanation:

The backup medium used or backup device does not contain any items relating to the menu command.

User Action:

Specify the backup medium or backup device. In multi-volume processing, all versions loaded by then must be reloaded.


-3002: Invalid datatype (MaxDB: Messages)

-3002: Invalid datatype

Explanation:

The specified data type is unknown in the current SQL mode.

User Action:

Use one of the permitted data types.


-3003: Invalid user name (MaxDB: Messages)

-3003: Invalid user name

Explanation:

The specified user name does not comply with the syntax for the user <IDENTIFIER>.

User Action:

Correct the user name specified in the SQL statement.


-3004: Invalid host file sequence (MaxDB: Messages)

-3004: Invalid host file sequence

Explanation:

The backup medium or backup device specified for multi-volume processing to continue the restore does not contain any items relating to the command that was previously executed.

User Action:

The error message contains an additional error description which must be interpreted according to the operating system being used.

Specify the backup medium or backup device in order to continue.


-3005: Invalid SQL statement (MaxDB: Messages)

-3005: Invalid SQL statement

Explanation:

The SQL statement either contains a typing error within the first two keywords, is unknown in the current SQL mode or is not permitted in this database version.

User Action:

Correct the typing errors, or specify another SQL statement.


-3007: Invalid sequence for DML and DDL statements (MaxDB: Messages)

-3007: Invalid sequence for DML and DDL statements

Explanation:

Modifications were made to the catalog in the time between a QUERY statement which does not generate a result table and the corresponding FETCH statements. These modifications concerned the underlying table of the QUERY statement.

User Action:

Repeat the QUERY and FETCH statement.


-3008: Invalid keyword or missing delimiter (MaxDB: Messages)

-3008: Invalid keyword or missing delimiter

Explanation:

The SQL statement contains an incorrect keyword, or a keyword unknown in the currently valid SQL mode, or a keyword or delimiter is missing.

User Action:

Correct the SQL statement according to the syntax description and the current SQL mode.


-3009: Invalid table name (MaxDB: Messages)

-3009: Invalid table name

Explanation:

The specified table name does not comply with the syntax.

User Action:

Correct the table name specified in the SQL statement.


-3011: Invalid column name (MaxDB: Messages)

-3011: Invalid column name

Explanation:

The specified column name does not comply with the syntax.

User Action:

Correct the column name specified in the SQL statement.


-3014: Invalid end of SQL statement (MaxDB: Messages)

-3014: Invalid end of SQL statement

Explanation:

According to the syntax, the specified SQL statement is not allowed in the SQL mode which is currently valid.

User Action:

The error position shows the location where the specified SQL statement deviates from the permitted syntax.


-3016: Invalid numeric constant (MaxDB: Messages)

-3016: Invalid numeric constant

Explanation:

...

The specified number does not match the column data type.

The specified length of the function's result, for example, LPAD, CHR and so on is invalid. It must be between 1 and the maximum length valid for a CHAR-type column.

User Action:

...

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the data type of the affected column.

Correct the specified length of the function’s result.


-3017: Invalid unsigned integer (MaxDB: Messages)

-3017: Invalid unsigned integer

Explanation:

No valid number was specified.

User Action:

Correct the SQL statement.


-3018: Invalid numeric parameter (MaxDB: Messages)

-3018: Invalid numeric parameter

Explanation:

The specified value is not a valid number.

User Action:

Check the numeric value entered as parameter.


-3019: Invalid exponent (MaxDB: Messages)

-3019: Invalid exponent

Explanation:

The following reasons are possible:

...

¡ A numeric final or temporary result is greater or less than the values which can be represented by a floating point number.

A numeric value is greater or less than permitted by the data type of a specified column.

User Action:

...

If a numeric intermediate result is too large or too small, the attempt can be made to prevent an overflow or underflow by rearranging the arithmetic operations.

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the data type of the affected column. Correct the parameter values accordingly.


-3020: Invalid length for this data type (MaxDB: Messages)

-3020: Invalid length for this data type

Explanation:

The specified length is not permitted for the data type.

User Action:

...

Choose a value between 1 and 254 (SQL mode ANSI) or between 1 and 8000 (SQLMODE INTERNAL and ORACLE or 1 and 4000 (SQLMODE DB2) for the length attribute of a CHAR-type column.

Choose a value between 1 and 38 for the precision of a FIXED- or FLOAT-type column.


-3021: Invalid mixture of functions and columns (MaxDB: Messages)

-3021: Invalid mixture of functions and columns

Explanation:

...

¡ When quantity functions (COUNT, MAX/ MIN, SUM, AVG, VARIANCE, STDDEV) occur in a SELECT <select_column> statement, non-group columns are not allowed in the (select_column).

Quantity functions, e.g. AVG(SUM...), must not be nested.

A corresponding subquery S contained in the WHERE clause of the QUERY specification Q must not contain quantity functions for columns of tables specified in the FROM clause of the QUERY specification Q.

User Action:

Correct the SQL statement.

Try to achieve the desired effect without nesting the quantity functions by using several QUERY statements each containing a quantity function.

Inside a QUERY statement the effect can be achieved by specifying a QUERY expression in the FROM clause.


-3022: Invalid number of tables for outer join (MaxDB: Messages)

-3022: Invalid number of tables for outer join

Explanation:

If an OUTER JOIN indicator was specified in at least one join predicate of the QUERY specification, the number of the underlying tables of the QUERY specification FROM clause must be precisely two or the following must apply:

...

¡ OUTER JOIN indicators are only specified for one of the tables specified in the FROM clause.

All join predicates of this table related to just one other table contain the OUTER JOIN INDICATOR.

All other joins do not contain an OUTER JOIN INDICATOR.

User Action:

The attempt should be made to add any missing OUTER JOIN indicators or to split the SQL statement into several SQL statements, or to achieve the desired effect by QUERY expressions in the FROM clause.


-3024: Invalid numeric expression (MaxDB: Messages)

-3024: Invalid numeric expression

Explanation:

The division by 0 does not belong to a select column of the outermost QUERY specification.

User Action:

Check whether this error can be prevented by suitable specifications (predicates).


-3030: Invalid SESSION TIMEOUT (MaxDB: Messages)

-3030: Invalid SESSION TIMEOUT

Explanation:

...

The timeout value specified for the SESSION_TIMEOUT in the CREATE USER or CREATE USERGROUP statement is invalid.

If the CONNECT statement is specified with a timeout value, this value must be less than or equal to the maximum timeout value possible for the user concerned.

User Action:

...

Choose a value between 30 and 32400 seconds for the SESSION_TIMEOUT.

If no user-specific timeout value was defined in the CREATE USER or CREATE USERGROUP statement for the current user, this maximum value is equal to the database parameter SESSION_TIMEOUT.

If a user-specific timeout value was defined in the CREATE USER or CREATE USERGROUP statement, this is the maximum value.

If 0 is specified for the timeout value in the CONNECT statement, periods of inactivity during a session are not checked.


-3035: Invalid date time format (MaxDB: Messages)

-3035: Invalid date time format

Explanation:

The DATE_TIME_FORMAT specified during installation is invalid.

User Action:

Specify EUR, INTERNAL, ISO, JIS or USA for the date and time format.


-3037: Invalid volume name (MaxDB: Messages)

-3037: Invalid volume name

Explanation

The volume name specified during installation is invalid. This name depends on the environment in which the database system is running. Usually, it is an operating system file name.

User action

The error message contains the incorrect volume name. Ensure that the name meets the conventions laid out for the environment in which the database system is running.


-3038: Invalid volume size (MaxDB: Messages)

-3038: Invalid volume size

Explanation

The value for the size of a volume specified during installation is not a valid number.

User action

Specify a valid number.


-3046: Invalid char position in string function (MaxDB: Messages)

-3046: Invalid char position in string function

Explanation:

An invalid value was specified for a position in a string function.

User Action:

In the SQL statement, a value must be specified for a position that is greater than 0 and less than or equal to the defined column width.


-3047: Invalid table for RESTORE CATALOG (MaxDB: Messages)

-3047: Invalid table for RESTORE CATALOG

Explanation:

A RESTORE CATALOG statement specified a table that contains none of the data generated by the SAVE CATALOG statement.

User Action:

Specify a table whose data was generated by the SAVE CATALOG statement.


-3048: Invalid date format (MaxDB: Messages)

-3048: Invalid date format

Explanation:

The specified value is not a valid date value or does not correspond to the date and time format chosen during installation or the current session.

User Action:

Correct the date value.


-3049: Invalid time format (MaxDB: Messages)

-3049: Invalid time format

Explanation:

The specified value is not a valid time value or does not correspond to the date and time format chosen during installation or the current session.

User Action:

Correct the time value.


-3050: Invalid timestamp format (MaxDB: Messages)

-3050: Invalid timestamp format

Explanation:

The specified value is not a valid timestamp value or does not correspond to the date and time format chosen during installation or the current session.

User Action:

Correct the timestamp value.


-3054: Invalid block size (MaxDB: Messages)

-3054: Invalid block size

Explanation

...

1. The specified block size for backing up or restoring data is invalid.

2. (liveCache) When registering a container that already exists in the database, the specified length of the object is different to the one stored in the database catalog.

User action

...

1. Set the block size to a value >= 1.

2. Register the container using the length specifications stored in the database catalog.


-3059: Invalid day of week (MaxDB: Messages)

-3059: Invalid day of week

Explanation:

An invalid day of the week was specified in the chosen language or format in the date value

User Action:

Check the chosen language and format and repeat the SQL statement with the correct day of the week. For the format element DAY, the days of the week must be written in full; for DY they must be specified with their three-letter abbreviation.


-3060: Invalid escape sequence (MaxDB: Messages)

-3060: Invalid escape sequence

Explanation:

The escape character may only be placed before a match_char, which is identical to the escape character, before a match_string or before a match_set, which is not a match_char.

User Action:

Remove the surplus escape character.


-3061: Invalid escape value (MaxDB: Messages)

-3061: Invalid escape value

Explanation:

Exactly one character is valid for an escape value.

User Action:

Reduce the escape value to one character.


-3062: Invalid month (MaxDB: Messages)

-3062: Invalid month

Explanation:

An invalid month was specified in the chosen language or format in the date value

User Action:

Check the chosen language and format and repeat the SQL statement with the correct day of the week. For the format element MONTH, the months must be written in full; for MON, they must be specified with their three-letter abbreviation.


-3063: Invalid format code (MaxDB: Messages)

-3063: Invalid format code

Explanation:

The format specification in a function for date or number conversion contains an invalid format code.

User Action:

Remove the invalid format code.


-3064: Date input value out of range (MaxDB: Messages)

-3064: Date input value out of range

Explanation:

An invalid value was specified for a format element in a function that converts a value into a date value.

Limits for format elements

Year | YYYY | 1-4713
Day of the month | DD | 1-28/29/30/31
Day of the year | DDD | 1-365/366
Day of the week | D | 1-7
Hours | HH,HH12 | 1-12
Hours | HH24 | 0-23
Minutes | MI | 0-59
Seconds | SS | 0-59
Seconds of the day | SSSSS | 0-86399
Julian calendar date | J | 1-3442447

User Action:

Correct the value.


-3065: Invalid date input value (MaxDB: Messages)

-3065: Invalid date input value

Explanation:

The value to be converted into a date value contains either an invalid element, or too many or too few elements.

User Action:

Correct the value according to the format.


-3066: Date input value inconsistent (MaxDB: Messages)

-3066: Date input value inconsistent

Explanation:

Data from two format elements was converted. The values of the data are contradictory. Perhaps a Julian calendar day was specified which does not lie within the specified year or month, or denotes another day of the month, or the seconds of the day were specified but do not correspond to the specified hours or minutes or seconds of the minute.

User Action:

...

1. One of the format elements containing contradictory values should be omitted.

2. The values of the two format elements should be matched.


-3067: Invalid timezone (MaxDB: Messages)

-3067: Invalid timezone

Explanation:

An invalid value for timezone was specified in the function NEW_TIME.

User Action:

Repeat the SQL statement with a correct timezone.


-3068: Mismatch of parameter configuration between backup and in (MaxDB: Messages)

-3068: Mismatch of parameter configuration between backup and instance

Explanation:

For a backup, the database parameters are saved. When data is restored, the database instance first checks whether the database parameters from the backup are compatible with the current database parameters of the target database instance.

A backup of a UNICODE database cannot be imported into a non-UNICODE database.

User Action:

The database parameters of the target database must be the same as the database parameters saved in the database backup. This currently only affects the special database parameter _UNICODE.


-3069: Bad xparam page in backup (MaxDB: Messages)

-3069: Bad xparam page in backup

Explanation:

The backup contains a corrupt page, in which xparam parameters are stored. As this page only occurs in the backup, this case is not as critical as a corrupt data page or log page, but the backup is still terminated.

User Action:

Please contact Support.


-3102: Invalid subtrans structure (MaxDB: Messages)

-3102: Invalid subtrans structure

Explanation:

In a database procedure, more or less subtransactions were dynamically opened than closed. The subtransactions opened but not closed until the end of the database procedure were rolled back.

User Action:

Check which error in the database procedure generated nesting of subtransactions. Correct the database procedure.


-3103: Invalid sequence definition (MaxDB: Messages)

-3103: Invalid sequence definition

Explanation:

The following reasons are possible:

...

1. In the CREATE SEQUENCE statement, the value 0 was specified for the interval between two numbers to be created by the sequence. This is not allowed.

2. In the <CREATE SEQUENCE statement>, a starting value was specified which is not within the range defined by the minimum and maximum value; or a minimum value was specified that is greater than the maximum value.

User Action:

...

1. Repeat the command with a positive or negative integer.

2. Change the starting value and/or the minimum and maximum values and repeat the command.


-3995: Invalid pattern (MaxDB: Messages)

-3995: Invalid pattern

Explanation:

The value specified in a LIKE predicate does not comply with the syntax of LIKE expressions (like_expression).

User Action:

The value must be corrected according to the syntax rules for LIKE expressions in a LIKE predicate.


-3998: Wrong password (MaxDB: Messages)

-3998: Wrong password

Explanation:

A role should be activated. The specified password is different to the one specified when the role was defined.

User Action:

Correct the password.


-3999: Invalid parameter (MaxDB: Messages)

-3999: Invalid parameter

Explanation:

...

1. An invalid database parameter was specified.

2. An invalid parameter was specified in the sequence of parameters of a CREATE TRIGGER statement. The usage of OLD is invalid in an INSERT trigger, the usage of NEW is invalid in a DELETE trigger.

User Action:

...

1. The error message contains a precise description of the error. Correct the parameter values accordingly.

2. Correct the parameters accordingly.


From -4000 to -4999 (MaxDB: Messages)

From -4000 to -4999

Database Kernel Error Messages

-4000 | Unknown result table
-4002 | Unknown password
-4003 | Unknown user name
-4004 | Unknown table name
-4005 | Unknown column name
-4006 | Unknown domain name
-4007 | Unknown synonym name
-4008 | Unknown user name/password combination
-4009 | Unknown referential constraint name
-4010 | Unknown MAPCHARSET name
-4011 | Unknown index name
-4013 | Unknown usergroup name
-4014 | Unknown SERVERDB name
-4016 | Unknown procedure name
-4017 | Unknown constraint
-4018 | Unknown default
-4019 | Unknown trigger name
-4020 | Unknown sequence name
-4023 | Unknown function name
-4024 | Unknown name
-4025 | Unknown or not loaded character set
-4027 | Unknown session


-4000: Unknown result table (MaxDB: Messages)

-4000: Unknown result table

Explanation:

There is no result table with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TABLES to find out the names of the existing result tables. Correct the name of the result table or check why the result table with the specified name was deleted already.

A COMMIT statement issued in the SQL modes ANSI and DB2 implicitly closes all result tables. This behavior can be prevented in the SQL mode DB2 by specifying "WITH HOLD".

Except for the SQL mode ORACLE, a ROLLBACK statement implicitly closes all result tables generated within this transaction.


-4002: Unknown password (MaxDB: Messages)

-4002: Unknown password

Explanation:

The specified password is unknown.

User Action:

Repeat the ALTER PASSWORD statement using the correct password.


-4003: Unknown user name (MaxDB: Messages)

-4003: Unknown user name

Explanation:

There is no user with this name.

User Action:

A DBA or the SYSDBA can use a QUERY statement issued on the system table DOMAIN.USERS to find out the known user names. Other users can use a QUERY statement issued on the system table DOMAIN.USERS to find out the users which belong to the same DBA as they do. Repeat the SQL statement with a known user name.


-4004: Unknown table name (MaxDB: Messages)

-4004: Unknown table name

Explanation:

A table with the specified name is not known to you. This table may not exist; or this table exists but you have no privileges for it.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TABLES to find out the names of the tables for which you have privileges. Then correct the table name. It may be sufficient to place the missing owner in front of it. If this does not remove the error, create a table with the desired name or check why you have no privileges for the existing table.


-4005: Unknown column name (MaxDB: Messages)

-4005: Unknown column name

Explanation:

There is no column with the specified name in any of the specified tables.

User Action:

Use QUERY statements issued on the system table DOMAIN.COLUMNS to find out the names of the columns existing in the tables. Correct the user name.


-4006: Unknown domain name (MaxDB: Messages)

-4006: Unknown domain name

Explanation:

There is no domain with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.DOMAINS to see a list of the known domains. Change the name of the domain in the SQL statement accordingly. It may be sufficient to place the missing owner in front of the statement.

A DBA can create a domain with the desired name and features.


-4007: Unknown synonym name (MaxDB: Messages)

-4007: Unknown synonym name

Explanation:

There is no synonym with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TABLES to see a list of the existing synonym names. Change the name of the domain in the SQL statement accordingly.


-4008: Unknown user name/password combination (MaxDB: Messages)

-4008: Unknown user name/password combination

Explanation:

The specified combination of user name and password is unknown. The database system can only be accessed by a combination that is known to the database instance.

User Action:

Change the user or password specification in the SQL statement.


-4009: Unknown referential constraint name (MaxDB: Messages)

-4009: Unknown referential constraint name

Explanation:

There is no referential CONSTRAINT definition with the specified name.

User Action:

Use a QUERY statement issued on the system table FOREIGNKEYS to see a list of the existing CONSTRAINT definitions. Change the name of the referential CONSTRAINT statement in the SQL statement accordingly.


-4010: Unknown MAPCHAR SET name (MaxDB: Messages)

-4010: Unknown MAPCHAR SET name

Explanation:

There is no MAPCHAR SET with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.MAPCHARSETS to see a list of the existing MAPCHAR SETS. Change the name in the SQL statement accordingly.


-4011: Unknown index name (MaxDB: Messages)

-4011: Unknown index name

Explanation:

There is no named index with the specified name for the table being used.

User Action:

Use a QUERY statement issued on the system table DOMAIN.INDEXES to see a list of the existing indexes. Change the index name in the SQL statement accordingly.


-4013: Unknown usergroup name (MaxDB: Messages)

-4013: Unknown usergroup name

Explanation:

There is no user group with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.USERS to see a list of the existing usergroup names. Change the usergroup name in the SQL statement accordingly.


-4014: Unknown SERVERDB name (MaxDB: Messages)

-4014: Unknown SERVERDB name

Explanation:

There is no database instance with the specified name.

User Action:

Correct the database name.


-4016: Unknown procedure name (MaxDB: Messages)

-4016: Unknown procedure name

Explanation:

There is no database procedure with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.DBPROCEDURES to see a list of the existing database procedures. Change the procedure name in the SQL statement accordingly.


-4017: Unknown constraint (MaxDB: Messages)

-4017: Unknown constraint

Explanation:

There is no CONSTRAINT definition for the specified column.

User Action:

No user action required.


-4018: Unknown default (MaxDB: Messages)

-4018: Unknown default

Explanation:

There is no DEFAULT specification for the specified column.

User Action:

Add a default specification.


-4019: Unknown trigger name (MaxDB: Messages)

-4019: Unknown trigger name

Explanation:

There is no trigger with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TRIGGERS to see a list of the existing trigger names.


-4020: Unknown sequence name (MaxDB: Messages)

-4020: Unknown sequence name

Explanation:

There is no sequence with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.SEQUENCES to see a list of the existing sequences.


-4023: Unknown function name (MaxDB: Messages)

-4023: Unknown function name

Explanation:

...

There is no function with the specified name.

Instead of using a valid QUERY expression, an attempt was made to use an invalid QUERY expression (named_query_expression) at this point.

User Action:

Replace the named_query_expression with query_expression. If the error message occurs although there is no named_query_expression in the SQL statement, check whether the specified function is not offered in the SQL mode being used.

...

Do without the specified function.

Open a database session using the SQL mode in which the function is available.

1. Generate a database function with the specified name and the desired functionality.


-4024: Unknown name (MaxDB: Messages)

-4024: Unknown name

Explanation:

There is no database object with the specified name.

User Action:

Use QUERY statements issued on system tables to find out which objects you are authorized to see.


-4025: Unknown or not loaded character set (MaxDB: Messages)

-4025: Unknown or not loaded character set

Explanation:

The specified CHARACTER SET is unknown.

User Action:

Check the spelling of the character set. Use a <QUERY statement> issued on the system table DOMAIN.CHARSET to find out whether the specified character set has been loaded. Replace the specification by one of the loaded character sets or ensure that the character set needed will be loaded.


-4027: Unknown session (MaxDB: Messages)

-4027: Unknown session

Explanation

You want to switch on the database trace for a special database session. The specified session number does not exist.

User action

Correct the session number.


From -5000 to -5999 (MaxDB: Messages)

From -5000 to -5999

Database Kernel Error Messages

-5001

Missing privilege

-5003

Missing key specification

-5004

Missing constant

-5005

Missing non-NULL value

-5006

Missing identifier

-5007

Missing numeric constant

-5008

Missing string constant

-5009

Missing integer

-5010

Missing value specification

-5012

Missing definite table name

-5013

Missing update column

-5014

Missing definite column name

-5015

Missing keyword

-5016

Missing delimiter


-5001: Missing privilege (MaxDB: Messages)

-5001: Missing privilege

Explanation:

...

The user is not authorized to execute the SQL statement.

The user is not authorized to execute this SQL statement for data definition. The privilege necessary for this SQL statement is only granted within a role. Such limited privileges are sufficient for other SQL statements, but not for those relating to data definitions.

User Action:

Use a query statement issued on the system table DOMAIN.TABLEPRIVILEGES or DOMAIN.COLUMNS to find out the tables or columns for which you have privileges. You cannot execute the desired SQL statement.


-5003: Missing key specification (MaxDB: Messages)

-5003: Missing key specification

Explanation:

The SQL statement requires a primary key specification. The primary key was omitted or is incomplete.

User Action:

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the key columns of the table. Correct the key specified in the SQL statement, or insert a key specification into the SQL statement.


-5004: Missing constant (MaxDB: Messages)

-5004: Missing constant

Explanation:

A constant is missing in the SQL statement.

User Action:

Insert a constant into the SQL statement.


-5005: Missing non-NULL value (MaxDB: Messages)

-5005: Missing non-NULL value

Explanation:

The INSERT- or UPDATE statement must contain non-NULL values for all mandatory columns. If a key specification is specified, non-NULL values must be specified for all key columns.

User Action:

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the mandatory and key columns of the table.


-5006: Missing identifier (MaxDB: Messages)

-5006: Missing identifier

Explanation:

An identifier is missing.

User Action:

The error position indicates the location of the missing identifier. Insert an <identifier> into the SQL statement.


-5007: Missing numeric constant (MaxDB: Messages)

-5007: Missing numeric constant

Explanation:

A number is missing.

User Action:

The error position indicates the location of the missing number. Insert a number into the SQL statement.


-5008: Missing string constant (MaxDB: Messages)

-5008: Missing string constant

Explanation:

A character string is missing in the SQL statement.

User Action:

Insert a string literal into the SQL statement.


-5009: Missing integer (MaxDB: Messages)

-5009: Missing integer

Explanation:

An integer is missing.

User Action:

Insert an integer into the SQL statement.


-5010: Missing value specification (MaxDB: Messages)

-5010: Missing value specification

Explanation:

A value is missing, or the specified value is not allowed.

User Action:

Correct the value specified in the SQL statement, or insert a value into the SQL statement.


-5012: Missing definite table name (MaxDB: Messages)

-5012: Missing definite table name

Explanation:

If a table name in a FROM clause is used several times with different owner, then the table name must always be specified with the desired owner within this SQL statement.

User Action:

Specify the owner with the table names.


-5013: Missing update column (MaxDB: Messages)

-5013: Missing update column

Explanation:

The attempt was made to update at least one column value of an updateable join view table column using an UPDATE statement. This column value can only be updated together with other column values. At least one of the required column values is missing in the <UPDATE statement>.

User Action:

Insert the missing column values into the <UPDATE statement> or execute <UPDATE statement>s for the underlying table(s) of the updateable join view table.


-5014: Missing definite column name (MaxDB: Messages)

-5014: Missing definite column name

Explanation:

The number of tables specified in a FROM clause of the SQL statement is greater than 1. A column name without preceding table name was used, and this column name occurs in more than one of the tables specified in the <FROM clause>.

User Action:

To ensure that the column name is unique, place the desired table name in front of it.


-5015: Missing keyword (MaxDB: Messages)

-5015: Missing keyword

Explanation:

The SQL statement contains a keyword that is incorrect or that is not known in the current SQL mode; or a keyword is missing.

User Action:

Correct the SQL statement according to the syntax description and the current SQL mode by using one of the specified keywords.


-5016: Missing delimiter (MaxDB: Messages)

-5016: Missing delimiter

Explanation:

The SQL statement contains an incorrect delimiter, or a delimiter is missing.

User Action:

Correct the SQL statement according to the syntax description and the current SQL mode by using one of the specified delimiters.


From -6000 to -6999 (MaxDB: Messages)

From -6000 to -6999

Database Kernel Error Messages

-6000

Duplicate table name

-6001

Duplicate column name

-6002

Duplicate privilege

-6003

Duplicate result table name

-6006

Duplicate name

-6008

Duplicate index name

-6009

Duplicate reference name

-6011

Duplicate constraint

-6012

Duplicate default

-6013

Duplicate trigger definition

-6014

Duplicate value

-6016

Duplicate format code


-6000: Duplicate table name (MaxDB: Messages)

-6000: Duplicate table name

Explanation:

There is already a table with the specified name.

User Action:

Choose another name for the new table.


-6001: Duplicate column name (MaxDB: Messages)

-6001: Duplicate column name

Explanation:

...

The column names of a table must differ from each other. Base tables without user-defined key columns and named result tables contain the implicitly created column SYSKEY.

Named result tables with columns, which have not been explicitly named and which do not inherit a column name from the underlying base table, implicitly get the column name "EXPRESSION_". "_" stands for a positive integer.

A column must not be specified more than once in an INSERT or UPDATE statement or in a sequence of key specifications.

User Action:

...

Use different column names.

In a CREATE VIEW or QUERY statement, uniqueness of the column names can be achieved by reference name specifications in the selected columns. In a <CREATE VIEW statement>, uniqueness can also be obtained by alias names specifications.

Correct the repeated specification of the same column.


-6002: Duplicate privilege (MaxDB: Messages)

-6002: Duplicate privilege

Explanation:

A privilege to be granted was listed twice in the SQL statement.

User Action:

Remove one of these privileges from the SQL statement.


-6003: Duplicate result table name (MaxDB: Messages)

-6003: Duplicate result table name

Explanation:

The SQL mode ANSI and DB2 require that a result table generated by DECLARE CURSOR is closed using a <CLOSE statement>, before the result table name can be used to open a new result table within the same transaction.

User Action:

Insert a CLOSE statement in the application.


-6006: Duplicate name (MaxDB: Messages)

-6006: Duplicate name

Explanation:

There is already a data object with the specified name.

User Action:

Repeat the SQL statement with another name.


-6008: Duplicate index name (MaxDB: Messages)

-6008: Duplicate index name

Explanation:

There is already an index with the specified name.

User Action:

Use another name for the index or delete the existing one.


-6009: Duplicate reference name (MaxDB: Messages)

-6009: Duplicate reference name

Explanation:

A reference name was selected twice in the FROM clause of a QUERY specification. This violates the requirement that each table must have a unique reference name.

User Action:

Change one of the reference names.


-6011: Duplicate constraint (MaxDB: Messages)

-6011: Duplicate constraint

Explanation:

There is already a CONSTRAINT definition for the specified column.

User Action:

Do without a CONSTRAINT definition specification, or obtain the desired effect by changing the existing CONSTRAINT definition.

Use a QUERY statement issued on the system table DOMAIN.CONSTRAINTS to check the existing CONSTRAINT definitions.


-6012: Duplicate default (MaxDB: Messages)

-6012: Duplicate default

Explanation:

There is already a DEFAULT specification for the specified column.

User Action:

Do without adding a default value, or obtain the desired effect by changing the existing default value.

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the definition of the existing default.


-6013: Duplicate trigger definition (MaxDB: Messages)

-6013: Duplicate trigger definition

Explanation:

There is already a trigger with the specified name.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TRIGGERS to find out the trigger names already used. Use another name.

Use a <QUERY statement> issued on the system table DOMAIN.TRIGGERS to find out whether the existing trigger has the desired definition and you therefore need not define another trigger.


-6014: Duplicate value (MaxDB: Messages)

-6014: Duplicate value

Explanation:

...

When defining a mapchar set, an internal value was specified more than once.

User Action:

...

Change the definition of the mapchar set in such a way that it is not necessary to specify several mappings for an internal value.


-6016: Duplicate format code (MaxDB: Messages)

-6016: Duplicate format code

Explanation:

  1. A format element was specified several times in the function TO_DATE.
  2. In the format specification of the TO_DATE function, format elements were specified which must not occur together. For example, day of year (DDD) and Julian calendar date must not occur together. There must not be several specifications denoting the year, e.g. YYYY and YY, or the month, e.g. MM and MONTH.

User Action:

  1. Remove the format elements that are specified too often.
  2. Remove one of the format elements that cannot occur together.


From -7000 to -7999 (MaxDB: Messages)

From -7000 to -7999

Database Kernel Error Messages

-7002 | KEY not allowed
-7003 | NOT NULL not allowed
-7004 | DEFAULT not allowed
-7005 | Lower bound greater than upper bound not allowed
-7006 | Reserved identifier not allowed
-7007 | Key column not allowed
-7008 | Updates of this table not allowed
-7009 | NULL value in key column not allowed
-7011 | Correlated subquery not allowed
-7012 | More than one update row not allowed
-7015 | More than one result row not allowed
-7016 | Parameter spec not allowed in this context
-7017 | User not allowed
-7018 | Variable not allowed in view definition
-7019 | Feature not allowed in view definition
-7021 | View column derived from function not allowed
-7022 | Columns from more than one table not allowed
-7023 | Dropping of all columns not allowed
-7024 | Alter column not allowed, constraint violation
-7026 | SQL statement not allowed without previous FETCH
-7029 | Function not allowed for this data type
-7032 | SQL statement not allowed for column of data type LONG
-7035 | DEFAULT specification not allowed for this column
-7036 | ROWNO specification not allowed in this context
-7037 | NULL value for NOT NULL column not allowed
-7038 | Foreign key column not allowed
-7039 | Cycle in referential constraint definition not allowed
-7040 | Referential constraint not allowed
-7041 | Result table name not allowed
-7042 | Key update not allowed
-7043 | Group member not allowed
-7045 | Parameter spec not allowed
-7046 | Column with length greater than 254 not allowed
-7048 | DROP/ALTER USER not allowed while user is connected
-7050 | Fastload with indexed table not allowed
-7051 | Read only view WITH CHECK OPTION not allowed
-7055 | Column(s) already indexed
-7056 | Subquery not allowed
-7057 | View definition contradicts new table definition
-7058 | Correlated subquery with select in from clause not allowed
-7061 | LOCK ROW for this table not allowed
-7063 | Temp table not allowed
-7064 | Feature not allowed in temp table definition
-7065 | SUBTRANS COMMIT/ROLLBACK not allowed without SUBTRANS BEGIN
-7066 | Unique index referenced by foreign key not allowed
-7067 | Update without repeated read not allowed
-7068 | Outer join not allowed in this context
-7071 | AUTOSAVE LOG must be stopped
-7072 | More than one column with default SERIAL not allowed
-7074 | Cycle in granted roles not allowed
-7075 | Current SAVE SKIPPED, next is ready to take on this tape
-7076 | No more data to read from tape
-7077 | Synonym not allowed
-7078 | No backup is running
-7079 | A backup is already running
-7080 | Query in statement not allowed
-7082 | SQL statement not allowed for this table type
-7500 | DCOM HRESULT
-7900 | Different block sizes


-7002: KEY not allowed (MaxDB: Messages)

-7002: KEY not allowed

Explanation:

...

The CREATE TABLE statement must list the key columns first if they are defined by a KEY specification in a key_or_not_null_spec.

In a CREATE TABLE statement, it is not allowed to specify KEY in a key_or_not_null_spec and a key definition.

User Action:

Specify the key columns in the SQL statement correctly.


-7003: NOT NULL not allowed (MaxDB: Messages)

-7003: NOT NULL not allowed

Explanation:

Columns with NOT NULL specification cannot be added to a table with the ALTER TABLE statement.

User Action:

Repeat the SQL statement after removing the specification NOT NULL.


-7004: DEFAULT not allowed (MaxDB: Messages)

-7004: DEFAULT not allowed

Explanation:

...

1. Columns with DEFAULT specification cannot be added to a table with the ALTER TABLE statement.

2. The specification of NOT NULL DEFAULT NULL is not allowed.

User Action:

...

1. To add a column to one with an <ALTER TABLE statement>, specify it without a DEFAULT specification. Then define the DEFAULT in another <ALTER TABLE statement>. This how this column is given the DEFAULT value in all table rows.

2. Delete the DEFAULT specification from the SQL statement and execute the statement again.


-7005: Lower bound greater than upper bound not allowed (MaxDB: Messages)

-7005: Lower bound greater than upper bound not allowed

Explanation:

In the case of an upper and lower limit specification for a range of values, the lower limit is greater than the upper limit.

User Action:

Correct the values.


-7006: Reserved identifier not allowed (MaxDB: Messages)

-7006: Reserved identifier not allowed

Explanation:

In the current SQL mode, the specified name is a reserved keyword and must not be used to identify database objects.

User Action:

Correct the SQL statement using another <identifier>.


-7007: Key column not allowed (MaxDB: Messages)

-7007: Key column not allowed

Explanation:

A key column specification is not allowed here.

User Action:

Remove the key column specification from the SQL statement.


-7008: Updates of this table not allowed (MaxDB: Messages)

-7008: Updates of this table not allowed

Explanation:

The specified table cannot be updated for the following possible reasons:

...

1. The table specified in an SQL statement with CURRENT OF and result table name is not the table indicated in the FROM clause of the QUERY statement that generated the result table.

2. The SQL statement contains a correlated subquery that uses the table to be updated.

3. The QUERY expression was specified with FOR UPDATE, The QUERY expression contains statement parts that are not permitted together with the FOR UPDATE specification (DISTINCT, GROUP CLAUSE, UNION, INTERSECT, EXCEPT, SUBQUERY).

4. In SQL mode DB2 the QUERY EXPRESSION of an SQL statement with specification of CURRENT OF <result_table_name> contains the FOR FETCH ONLY statement.

User Action:

...

1. Replace the table name with that used in the FROM clause of the QUERY statement or repeat the QUERY statement using the required table name.

2. In the case of the correlated subquery, the desired effect can be achieved by generating a named result table which is then used in the subquery.

3. You must remove the FOR UPDATE or DISTINCT specification, or similar.

4. Repeat the QUERY expression without FOR FETCH ONLY, or omit the specification of CURRENT OF <result_table_name> in the SQL statement.


-7009: NULL value in key column not allowed (MaxDB: Messages)

-7009: NULL value in key column not allowed

Explanation:

Key columns must not be set to the NULL value.

User Action:

Use non-NULL values for key columns.


-7011: Correlated subquery not allowed (MaxDB: Messages)

-7011: Correlated subquery not allowed

Explanation:

...

1. A correlated subquery was used in a <QUERY EXPRESSION> containing at least a UNION, INTERSECT, or EXCEPT. This is not yet allowed.

2. A column name was used in a selected column in a scalable subquery; this column name is not known in any FROM clause table.

User Action:

...

1. The desired effect can be achieved by splitting the <QUERY statement> into several SQL statements.

2. Correct the user name.


-7012: More than one update row not allowed (MaxDB: Messages)

-7012: More than one update row not allowed

Explanation:

The attempt was made to modify several rows with an UPDATE statement, specifying a new value for a LONG column. This is not allowed.

User Action:

Modify the <UPDATE statement> in such a way that only one row is updated, or do without the value modification for the LONG column.


-7015: More than one result row not allowed (MaxDB: Messages)

-7015: More than one result row not allowed

Explanation:

...

1. This error may occur when a SINGLE SELECT statement is executed and more than one row complies with the search condition.

2. This error can also occur when a subquery specified in a comparison predicate or a SET UPDATE clause of an UPDATE statement is executed and more than one row complies with the search condition.

User Action:

...

1. The <SINGLE SELECT statement> can be replaced with a QUERY statement and a sequence of FETCH statements; or it can be ensured that at most one row complies with the conditions by expanding the <search condition>.

2. You can replace the comparison predicate with a quantity comparison predicate. You can try to change the subquery by specifying DISTINCT or expanding the search condition so that the subquery contains one row as the result at most.


-7016: Parameter spec not allowed in this context (MaxDB: Messages)

-7016: Parameter spec not allowed in this context

Explanation:

...

1. The attempt was made to specify a parameter in a selected column.

2. A comparison predicate of type <parameter_spec> <comp_op> <parameter_spec> occurred within the search condition.

3. A comparison predicate, IN predicate or quantity comparison predicate specifies a comparison between a parameter and a subquery.

User Action:

...

1. Replace the parameter with a constant.

2. It is useful to check such a condition within the application. If this is not possible, replace one of the two parameters with a constant, a column name, or an expression which does not solely contain parameters.

3. Replace the parameter with a constant or integrate it into a function (e.g. SUBSTR) so that the data type of the parameter becomes clear.


-7017: User not allowed (MaxDB: Messages)

-7017: User not allowed

Explanation:

...

1. You cannot grant privileges to yourself.

2. The specified names must not be identical in a GRANT USER statement.

User Action:

Correct the user name.


-7018: Variable not allowed in view definition (MaxDB: Messages)

-7018: Variable not allowed in view definition

Explanation:

Parameters must not be specified in the CREATE VIEW statement.

User Action:

Use variables instead of constants.


-7019: Feature not allowed in view definition (MaxDB: Messages)

-7019: Feature not allowed in view definition

Explanation:

ROWNO specifications are not allowed in a view definition.

User Action:

Remove the ROWNO specification from the SQL statement.


-7021: View column derived from function not allowed (MaxDB: Messages)

-7021: View column derived from function not allowed

Explanation:

A view table column was specified which was the result of an arithmetic expression or of a set function. In the present case, it is not allowed to specify such a column.

User Action:

To achieve the desired effect try one or more other SQL statements.


-7022: Columns from more than one table not allowed (MaxDB: Messages)

-7022: Columns from more than one table not allowed

Explanation:

In certain cases, columns from more than one table may not be addressed within an expression.

User Action:

Consider whether issuing other SQL statements could give the desired result.


-7023: Dropping of all columns not allowed (MaxDB: Messages)

-7023: Dropping of all columns not allowed

Explanation:

You have attempted to drop all columns in a table. This is not permitted.

User Action:

...

1. Load the table with the DROP TABLE statementinstead. This deletes all view tables, privileges, indexes, referential CONSTRAINT definitions and so on that depend on the table.

2. Then use the CREATE TABLE statement to define a new table with the same name.


-7024: Alter column not allowed, constraint violation (MaxDB: Messages)

-7024: Alter column not allowed, constraint violation

Explanation:

The attempt was made to redefine a new value range for a particular column. The SQL statement fails when the table contains rows that do not meet the CONSTRAINT definition.

User Action:

...

1. Choose another CONSTRAINT definition or do not change the definition.

2. Use a QUERY statement to find out the rows which do not meet the CONSTRAINT definition. You may change or delete them.


-7026: SQL statement not allowed without previous FETCH (MaxDB: Messages)

-7026: SQL statement not allowed without previous FETCH

Explanation:

The attempt was made to issue an SQL statement with CURRENT OF for the table without having previously issued a successful FETCH statement on the specified result table.

User Action:

Issue a FETCH statement for this result table and repeat the SQL statement.


-7029: Function not allowed for this data type (MaxDB: Messages)

-7029: Function not allowed for this data type

Explanation:

...

1. The attempt was made to use one of the functions DATE, TIME, TIMESTAMP, USER, TRUE, FALSE, or STAMP for a default specification of a column having a data type not compatible with such a specification.

2. A set function with DISTINCT was called for a value whose maximum length exceeds 1024 bytes.

3. The attempt was made to call a function for a value which does not allow this function to be applied.

4. The attempt was made to form a date_or_timestamp_expression with a value having a data type that is invalid for this purpose.

User Action:

...

1. If a default is specified, another default must be chosen, or the default specification must be omitted.

2. Use function SUBSTR to reduce the value.

3. Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the data types of the specified columns. A check can be made as to whether the desired effect can be achieved by a function converting numbers into character strings or vice versa.


-7032: SQL statement not allowed for column of data type LONG (MaxDB: Messages)

-7032: SQL statement not allowed for column of data type LONG

Explanation:

The SQL statement cannot be applied to LONG columns.

User Action:

Use one of the operations allowed for the data type LONG.


-7035: DEFAULT specification not allowed for this column (MaxDB: Messages)

-7035: DEFAULT specification not allowed for this column

Explanation:

An INSERT or UPDATE statement or a DEFAULT predicate was issued with a DEFAULT specification for a column for which no DEFAULT specification had been defined in the <CREATE TABLE> or any subsequent <ALTER TABLE statement>.

User Action:

Specify the desired value instead of DEFAULT.


-7036: ROWNO- specification not allowed in this context (MaxDB: Messages)

-7036: ROWNO- specification not allowed in this context

Explanation:

One of the following conditions was violated:

...

1. The specification ROWNO may only be used in QUERY statements. The <QUERY statement> must not contain a UNION, EXCEPT or INTERSECT specification.

2. The ROWNO predicate can be used within the search condition, in the form ROWNO < <rowno_spec> or ROWNO <= <rowno_spec>.In other words, ROWNO is to the left of the operator.

3. The ROWNO predicate may occur only once in a search condition. It must be connected with other predicates by logical AND.

User Action:

...

1. In the case of UNION, EXCEPT or INTERSECT, the effect can be achieved by two successive <QUERY statement>s.

2. Correct the search condition for the SQL statement accordingly.


-7037: NULL value for NOT NULL column not allowed (MaxDB: Messages)

-7037: NULL value for NOT NULL column not allowed

Explanation:

The error message occurs when a referential CONSTRAINT definition is executed and ON DELETE SET NULL is specified in the DELETE rule if a column (referencing_column) does not permit the NULL value.

User Action:

Choose another action in the DELETE rule or admit the NULL value for the corresponding column(s) in the referencing table.


-7038: Foreign key column not allowed (MaxDB: Messages)

-7038: Foreign key column not allowed

Explanation:

A foreign key column is a column which was specified in the referencing_column of a referential CONSTRAINT definition.

...

1. The attempt was made to delete a table column which was specified as a referencing_column of a CONSTRAINT definition.

2. The attempt was made to delete the key of a table. The columns of the key were specified implicitly or explicitly as referencing_columns of a CONSTRAINT definition.

User Action:

Delete the referential CONSTRAINT definition and then the column or key.


-7039: Cycle in referential constraint definition not allowed (MaxDB: Messages)

-7039: Cycle in referential constraint definition not allowed

Explanation:

An attempt was made to create a referential CONSTRAINT definition which would produce an invalid reference cycle. This CONSTRAINT definition would lead to discrepancies so the database system has rejected it.

User Action:

Delete the cycle dependencies.


-7040: Referential constraint not allowed (MaxDB: Messages)

-7040: Referential constraint not allowed

Explanation:

There is already a referential CONSTRAINT definition with the specified referencing table. Moreover, CASCADE dependency arises. Under these conditions, all <CONSTRAINT definition>s with the indicated referencing table must specify either CASCADE or RESTRICT.

User Action:

Rethink the desired effect, because it would result in basically contesting situations. Use a QUERY statement issued on the system table DOMAIN.FOREIGNKEYCOLUMNS to see a list of the existing CONSTRAINT definitions.


-7041: Result table name not allowed (MaxDB: Messages)

-7041: Result table name not allowed

Explanation:

With the CREATE VIEW statement, the FROM clause of the QUERY expression contains a known result table. However, only base or view tables may be specified.

User Action:

Specify a base or view table in the SQL statement and expand the search condition to include conditions used when generating the result table.


-7042: Key update not allowed (MaxDB: Messages)

-7042: Key update not allowed

Explanation:

The attempt was made to change the value of a key column in a temporary table to a new value. This is not allowed. Key columns can only be changed in permanent tables.

User Action:

If another key value is wanted, delete the row with the old key value and insert a row with the new key value.


Group member not allowed (MaxDB: Messages)

Group member not allowed

Explanation:

The following reasons are possible:

...

1. The attempt was made to grant privileges to a user of a usergroup.

2. The attempt was made to alter the characteristics of a user who is a member of a usergroup using an ALTER USER statement.

User characteristics and privileges cannot be altered for members of a usergroup, but only for the usergroup itself.

User Action:

A DBA or the SYSDBA can use a QUERY statement issued on the system table DOMAIN.USERS can be used by a database administrator to display the usergroup to which the respective user belongs. Other users only see the users and usergroups which belong to the same database administrator as they do.

...

1. Grant the privileges to the usergroup to which the user belongs.

2. Replace the ALTER USER with an ALTER USERGROUP statement.


-7045: Parameter spec not allowed (MaxDB: Messages)

-7045: Parameter spec not allowed

Explanation:

A parameter was specified, although this database component or this kind of application programming only allows the use of constants.

User Action:

Replace the parameter with a constant.


-7046: Column with length greater than 254 not allowed (MaxDB: Messages)

-7046: Column with length greater than 254 not allowed

Explanation:

The attempt was made to use a CHAR-type column with a length greater than 254 in a statement part that does not allow for such a column. This could have happened, for example, if the attempt was made to change a column with a defined length less than 254 into a column with a defined length greater than 254.

User Action:

Do not use this column in the statement part. Try to achieve the desired effect by application programming. For a change in the defined length, the desired effect could be achieved by replacing the ALTER definition with a MODIFY definition. However, this is likely to take substantially more time. This depends on the number of data records in the accessed table and the indexes defined for it.


-7048: DROP/ALTER USER not allowed while user is connected (MaxDB: Messages)

-7048: DROP/ALTER USER not allowed while user is connected

Explanation:

The attempt was made to drop a user or to alter the characteristics of a user who was connected. This is only permitted for a user who is not connected.

User Action:

Repeat the SQL statement when the user to be dropped or altered is not connected.


-7050: Fastload with indexed table not allowed (MaxDB: Messages)

-7050: Fastload with indexed table not allowed

Explanation:

An index is on the table to be loaded. In this case, a fast load (FASTLOAD) is not possible.

User Action:

Delete the index or do without fast loading.


-7051: Read only view WITH CHECK OPTION not allowed (MaxDB: Messages)

-7051: Read only view WITH CHECK OPTION not allowed

Explanation:

The view table to be created is not updateable. The specification WITH CHECK OPTION is not allowed for non updateable view tables.

User Action:

Repeat the SQL statement without the WITH CHECK OPTION.


-7055: Column(s) already indexed (MaxDB: Messages)

-7055: Column(s) already indexed

Explanation:

There is already an index for the specified column(s).

User Action:

Use a QUERY statement issued on the system table DOMAIN.INDEXCOLUMNS to check whether the index values are stored in ascending or descending order. No user action is required.


-7056: Subquery not allowed (MaxDB: Messages)

-7056: Subquery not allowed

Explanation:

A subquery specification in a CONSTRAINT definition is not allowed.

User Action:

...

1. Try to reformulate the search condition so that the subquery can be omitted.

2. The attempt can be made to achieve the desired effect by defining a trigger that checks the condition.


-7057: View definition contradicts new table definition (MaxDB: Messages)

-7057: View definition contradicts new table definition

Explanation:

...

1. The attempt was made to add a column to a table or to drop a column from a table. When creating the specified view table, SELECT * was used and new names were assigned to the view table columns. After table modification, the number of names would no longer coincide with the number of table columns.

2. The attempt was made to drop a referential CONSTRAINT definition which is prerequisite for an updateable join view table.

User Action:

...

1. Delete the view table and define it again. Specify the required columns individually in the selected columns of the QUERY expression.

2. You may delete the referential CONSTRAINT definition only after the updateable view table has been deleted.


-7058: Correlated subquery with select in from clause not allowe (MaxDB: Messages)

-7058: Correlated subquery with select in from clause not allowed

Explanation:

A QUERY expression specification in the FROM clause of a correlated subquery is not allowed.

User Action:

Formulate the corresponding subquery to leave out the QUERY EXPRESSION. If this is not possible, split the SQL statement into at least two SQL statements and generate a named result table that can be used in the FROM clause.


-7061: LOCK ROW for this table not allowed (MaxDB: Messages)

-7061: LOCK ROW for this table not allowed

Explanation:

A LOCK statement giving a ROW specification may be executed for a join view table only if it is an updateable join view table. But not even updateable join view tables allow a ROW specification with OPTIMISTIC specification.

User Action:

The effect can be achieved by several ROW specifications issued on the underlying base tables.


-7063: Temp table not allowed (MaxDB: Messages)

-7063: Temp table not allowed

Explanation:

Only a subset of data definition statements is allowed for temporary tables; among them, the SQL statements for creating and deleting tables and for making the existence check.

User Action:

Decide whether the SQL data definition statement can be removed or whether a permanent table is to be created instead of the temporary table.


-7064: Feature not allowed in temp table definition (MaxDB: Messages)

-7064: Feature not allowed in temp table definition

Explanation:

You cannot specify a referential CONSTRAINT definition for a temporary table.

User Action:

Repeat the SQL statement without the invalid specification, or create a permanent table instead of the temporary table.


-7065: SUBTRANS COMMIT/ROLLBACK not allowed without SUBTRANS BEG (MaxDB: Messages)

-7065: SUBTRANS COMMIT/ROLLBACK not allowed without SUBTRANS BEGIN

Explanation:

The corresponding SQL statement SUBTRANS BEGIN statement must have been called for each subtransaction to be closed.

User Action:

Check the database application for the dynamic behavior of the UBTRANS statements.


-7066: Unique index referenced by foreign key not allowed (MaxDB: Messages)

-7066: Unique index referenced by foreign key not allowed

Explanation:

The specified index cannot be deleted, because the columns contained in it were specified as referenced columns of the referenced_table in a referential CONSTRAINT definition.

User Action:

The index can only be deleted after deleting the corresponding referential CONSTRAINT definition. Use a QUERY statement issued on the system table DOMAIN.FOREIGNKEYCOLUMNS to see which CONSTRAINT definitions were created.


-7067: Update without repeated read not allowed (MaxDB: Messages)

-7067: Update without repeated read not allowed

Explanation:

An optimistic lock was set to at least one table row by a previous SQL statement. Afterwards, another database user updated at least one of these rows. The database user who set the optimistic lock can make new changes to this row only after reading it with an (optimistic) lock.

User Action:

The row to be updated must be read again with an (optimistic) lock.


-7068: Outer Join not allowed in this context (MaxDB: Messages)

-7068: Outer Join not allowed in this context

Explanation:

An OUTER JOIN indicator was used in a comparison predicate in which no table column was specified in one of the two expressions. An OUTER JOIN indicator is only allowed in a JOIN predicate.

User Action:

You can repeat the SQL statement without the OUTER JOIN indicator.


-7071: AUTOSAVE LOG must be stopped (MaxDB: Messages)

-7071: AUTOSAVE LOG must be stopped

Explanation:

The attempt was made to perform a SHUTDOWN. This is not possible as long as the automatic log backup is active.

User Action:

Stop the automatic log backup and then perform SHUTDOWN.


-7072: More than one column with default SERIAL not allowed (MaxDB: Messages)

-7072: More than one column with default SERIAL not allowed

Explanation:

You tried to assign the DEFAULT specification DEFAULT SERIAL more than once when a base table was defined. No more than one column may exist in each base table with the DEFAULT specification DEFAULT SERIAL.

User Action:

Decide on the column in which you want to leave out this definition. Then repeat the modified SQL statement.


-7074: Cycle in granted roles not allowed (MaxDB: Messages)

-7074: Cycle in granted roles not allowed

Explanation:

The following reasons are possible:

...

1. You tried to assign a role to itself.

2. You tried to assign role definitions cyclically.

User Action:

Check whether there is a typing error. If not, check whether the roles which would result in the cycle can be combined to one role.


-7075: Current SAVE SKIPPED, next is ready to take on this tape (MaxDB: Messages)

-7075: Current SAVE SKIPPED, next is ready to take on this tape

Explanation:

You tried to restore a log backup from a no rewind tape. The given backup is older than the one required. It could still be saved on this tape.

User Action:

Try to carry out the reload with the next backup on this tape.


-7076: No more data to read from tape (MaxDB: Messages)

-7076: No more data to read from tape

Explanation:

You tried to restore a log backup from a no rewind tape. The given backup is older than the one required. There is no other backup on this tape.

User Action:

You no longer need the current tape. Insert the tape with the required backup and repeat the command.


-7077: Synonym not allowed (MaxDB: Messages)

-7077: Synonym not allowed

Explanation:

You have used an invalid synonym name within a CREATE TRIGGER or CREATE DBPROC statement. This is not allowed.

User Action:

Instead of using the synonym name, use the full name for which the synonym was originally defined.


-7078: No backup is running (MaxDB: Messages)

-7078: No backup is running

Explanation:

An attempt was made to cancel a backup but no backup was running.

User Action:

No user action required.


-7079: A backup is already running (MaxDB: Messages)

-7079: A backup is already running

Explanation:

An attempt was made to start a backup while another backup is running. You can only run one backup at a time.

User Action:

No user action is possible.


-7080: Query in statement not allowed (MaxDB: Messages)

-7080: Query in statement not allowed

Explanation:

The search condition of an IF or WHILE statement contains a QUERY statement. This is not allowed.

User Action:

Execute the QUERY statement outside of the IF or WHILE statement, and save the results in program variables. Then use these results in the IF or WHILE statement.


-7082: SQL statement not allowed for this table type (MaxDB: Messages)

-7082: SQL statement not allowed for this table type

Explanation:

SQL statements for deleting or changing table rows or for changing table definitions are not permitted for this table type.

User Action:

You cannot use this SQL statement.


-7500: DCOM HRESULT (MaxDB: Messages)

-7500: DCOM HRESULT

Explanation

An unexpected error occurred during the CREATE PACKAGE statement. The exact cause of the error is signified by a numerical value (HRESULT) in the error message.

User action

This type of error suggests that certain entries in the registration database are incorrect or missing.

Ensure that the reference to the relevant library in the programmatic ID is correct. Also make sure that this library exists in the given location and that the appropriate privileges are assigned.

If this fails to solve the problem, inform your support about the error number (HRESULT) so they can analyze the error.


-7900: Different block sizes (MaxDB: Messages)

-7900: Different block sizes

Explanation:

The block sizes specified for the restore and used for the backup differ from each other. The restore cannot be terminated successfully.

User Action:

The block size used for the corresponding save must also be used for the restore operation.


From -8000 to -9799 (MaxDB: Messages)

From -8000 to -9799

Database Kernel Error Messages

-8000 | SERVERDB must be restarted
-8001 | User must be connected
-8002 | User already connected to this user task
-8003 | Log and data must be compatible
-8004 | Constant must be compatible with column type and length
-8005 | Value expression must be parameter name
-8006 | Data types must be compatible
-8007 | Column must be key column
-8009 | DEFAULT value must be in constraint specification
-8010 | Table name must be in from list
-8013 | Order column must be output column
-8014 | Result table must be FOR REUSE
-8015 | Table must be a base table
-8016 | Table must be a view table
-8017 | Column must be group column
-8018 | Index name must be unique
-8020 | Next volume required
-8021 | Column must have DEFAULT specification
-8022 | User already connected
-8023 | COSTLIMIT must be greater than COSTWARNING
-8024 | RESTORE CATALOG failed
-8025 | Table must be temp table
-8028 | UNION columns must be compatible
-8030 | Column must be indexed
-8031 | Owner must be specified
-8033 | Imcomplete log segment
-8034 | Order column must be number
-8035 | Foreign key must exist
-8037 | DB procedure must be recompiled
-8040 | Key does not exist
-8044 | Conversion for character set value impossible
-8045 | Conversion to UNICODE impossible
-8046 | Conversion from UNICODE impossible
-8047 | Password required
-8048 | Version of component must be compatible with kernel version
-8050 | Migration error
-8888 | SERVERDB not accessible
-9000 | System error: Not yet implemented
-9001 to -9799 | System error


-8000: SERVERDB must be restarted (MaxDB: Messages)

-8000: SERVERDB must be restarted

Explanation:

It is not possible to work on the database instance because it was shut down.

User Action:

Switch the database to ONLINE mode.


-8001: User must be connected (MaxDB: Messages)

-8001: User must be connected

Explanation:

A database session can only be opened using a CONNECT statement.

User Action:

Specify a CONNECT statement.


-8002: User already connected to this user task (MaxDB: Messages)

-8002: User already connected to this user task

Explanation:

A user already connected to the database entered another CONNECT statement.

User Action:

If the user wants to continue working under another user name, he must specify first a RELEASE and then a CONNECT statement.


-8003: Log and data must be compatible (MaxDB: Messages)

-8003: Log and data must be compatible

Explanation:

...

1. When you start the database instance in the operating state ONLINE, the result of the check is that the data area and the current log area have different states.

2. When the log entries are imported, the result of the check is that the import sequence is incorrect.

User Action:

...

1. You must recover the database system by specifying the correct backup version.

2. Import all the necessary log entries in the correct order.

3. Transfer the database instance to the operating state ONLINE.


-8004: Constant must be compatible with column type and length (MaxDB: Messages)

-8004: Constant must be compatible with column type and length

Explanation:

The specified constant does not match the data type for this column.

User Action:

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the definition of the affected column. Specify a constant with the correct data type.


-8005: Value expression must be parameter name (MaxDB: Messages)

-8005: Value expression must be parameter name

Explanation:

When calling a database procedure, not a parameter but a constant value was specified for an OUT or IN/OUT parameter.

User Action:

Replace the specified constant with a parameter.


-8006: Data types must be compatible (MaxDB: Messages)

-8006: Data types must be compatible

Explanation:

...

1. A function was applied to a non-permitted argument.

2. A two-digit operation was applied to non-comparable values.

3. A predicate contains non-comparable data types.

Each data type can be compared to itself. Columns of data type CHAR with the different code attributes ASCII and UNICODE can be compared to each other; they are implicitly adapted. The columns of code attribute ASCII can be compared to date, time, and timestamp specifications.

All numbers can be compared to each other.

User Action:

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the definition of the specified columns. It may be attempted to achieve comparability by applying a conversion function.


-8007: Column must be key column (MaxDB: Messages)

-8007: Column must be key column

Explanation:

The specification of a non-key column is not allowed here.

User Action:

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the columns which belong to the table key. Only these columns can be specified at this position within the SQL statement.


-8009: DEFAULT value must be in constraint specification (MaxDB: Messages)

-8009: DEFAULT value must be in constraint specification

Explanation:

The specified DEFAULT value would violate the CONSTRAINT definition.

User Action:

...

1. The corresponding <CONSTRAINT definition> must be reconsidered and modified, if necessary.

2. Use another DEFAULT value, or do not specify a default value at all.


-8010: Table name must be in from list (MaxDB: Messages)

-8010: Table name must be in from list

Explanation:

A table name was specified in a select column, search condition or ORDER clause but this table name was not listed in the FROM clause.

User Action:

...

1. If a reference name was specified for a table name, use this reference name in the SQL statement.

2. If the FROM clause contains the specification of a table which does not belong to the current user, to this user's usergroup or to the database administrator, and which is not a system table, the owner must be specified for the table throughout the SQL statement.


-8013: Order column must be output column (MaxDB: Messages)

-8013: Order column must be output column

Explanation:

...

1. For a QUERY statement with DISTINCT specification, only those column names that were specified as select columns can be specified in the ORDER clause.

2. If a column number is specified, you must ensure that this number is not greater than the number of specified output columns.

3. The number of output columns may have decreased in case of a SELECT * as a result of an ALTER TABLE statement with DROP definition.

User Action:

...

1. Do not use the DISTINCT specification or specify the column of the ORDER clause in a select column.

2. Correct the number in the ORDER clause accordingly.


-8014: Result table must be FOR REUSE (MaxDB: Messages)

-8014: Result table must be FOR REUSE

Explanation:

A named result table which was not created with FOR REUSE was used in the FROM clause of a QUERY or SINGLE SELECT statement.

User Action:

Create the named result table with FOR REUSE and reissue the SQL statement.


-8015: Table must be a base table (MaxDB: Messages)

-8015: Table must be a base table

Explanation:

The specification of a base table is expected. This specification is missing or the specified table is not a base table.

User Action:

Use a QUERY statement issued on the system table DOMAIN.TABLES to find out whether the specified table is a view table or result table. If it is a view table, use a QUERY statement issued on the system table DOMAIN.VIEWDEFS to determine the pertinent base table. The desired SQL statement can then be issued for the base table, if you have the corresponding privileges.


-8016: Table must be a view table (MaxDB: Messages)

-8016: Table must be a view table

Explanation:

For the RENAME VIEW or DROP VIEW statement, a table was specified that is not a view table.

User Action:

Specify a view table in the SQL statement or replace the SQL statement with a RENAME TABLE or DROP TABLE statement.


-8017: Column must be group column (MaxDB: Messages)

-8017: Column must be group column

Explanation:

A column in a select column or in the HAVING clause was specified that is not a group column. In other words, it is not contained in the GROUP clause. Columns which are not group columns may only occur in arguments of the functions COUNT, SUM, AVG, MAX, MIN, STDDEV and VARIANCE.

User Action:

Insert the specified column into the <group clause> as a further group column or remove it from the select column or HAVING clause.


-8018: Index name must be unique (MaxDB: Messages)

-8018: Index name must be unique

Explanation:

...

1. This error message can occur with a DROP INDEX statement. Indexes with identical names were created for separate tables. Therefore the name of the index to be deleted is not unique.

2. There is only a named single-column index for this column. The attempt was made to delete the index for this column without specifying its name.

User Action:

...

1. Specify the name of the table to which the index to be deleted refers in the <DROP INDEX statement>.

2. Delete the index specifying its name.


-8020: Next volume required (MaxDB: Messages)

-8020: Next volume required

Explanation:

1. The current backup medium has no space left when saving.

2. Not all backup media for this backup were specified when the data backup was imported.

3. The next log backup medium is requested for the log backup import.

User Action:

...

1. Specify another backup medium.

2. Complete the list of backup media.

3. Specify the next log backup medium, if it exists, or terminate the import of the log backup manually.


-8021: Column must have DEFAULT specification (MaxDB: Messages)

-8021: Column must have DEFAULT specification

Explanation:

The attempt was made to specify the <action> SET DEFAULT as DELETE rule in a referential CONSTRAINT definition, although no DEFAULT value had been defined for at least one referencing_column.

User Action:

...

1. If the error occurred during the execution of a CREATE TABLE statement, either define a DEFAULT value for the column(s) or choose another action.

2. If the error occurred during the execution of an ALTER TABLE statement, issue another <ALTER TABLE statement> to assign a DEFAULT value to all columns (referencing_column) without a DEFAULT value and then repeat the previous ALTER TABLE statement. Alternatively, you may choose another action.


-8022: User already connected (MaxDB: Messages)

-8022: User already connected

Explanation:

A user attempts to connect to the database system under a user name which was defined with EXCLUSIVE in a CREATE USER, CREATE USERGROUP, ALTER USER or ALTER USERGROUP statement. Another user has connected to the database system using this name.

User Action:

Wait until the other user has disconnected from the database system using a RELEASE statement.

To enable a user to have various simultaneous connects, NOT EXCLUSIVE must be specified for this user with the ALTER USER or ALTER USERGROUP statement. These SQL statements may only be executed by the owner of the user or usergroup.


-8023: COSTLIMIT must be greater than COSTWARNING (MaxDB: Messages)

-8023: COSTLIMIT must be greater than COSTWARNING

Explanation:

A COSTLIMIT value was specified which was less than or equal to the specified COSTWARNING value. The COSTLIMIT value, however, must be greater than the COSTWARNING value.

User Action:

Use a QUERY statement issued on the system table DOMAIN.USERS to find out the COSTWARNING value for existing users.


-8024: RESTORE CATALOG failed (MaxDB: Messages)

-8024: RESTORE CATALOG failed

Explanation

Parts of the database catalog are deleted and then restored during certain data definition statements.

If an unexpected error occurs, error -8024 is displayed.

User action

Create a database trace of the last database activities and save it.

Send the database trace to your support so they can trace and rectify the error.


-8025: Table must be temp table (MaxDB: Messages)

-8025: Table must be temp table

Explanation:

In a CREATE TABLE statement, the option IGNORE ROLLBACK was specified for a permanent table. This is not allowed.

User Action:

You can repeat the SQL statement. To do this you either need to deselect the option IGNORE ROLLBACK or a create temporary table, by specifying TEMP as owner of the table to be created.


-8028: UNION columns must be compatible (MaxDB: Messages)

-8028: UNION columns must be compatible

Explanation:

In a QUERY expression with at least a UNION, INTERSECT or EXCEPT specification, all sequences of selected columns must designate the same number of columns. The data types of the corresponding columns must thereby comply with the conditions valid for comparability.

Each data type can be compared to itself. Columns of data type CHAR with the different code attributes ASCII and UNICODE can be compared to each other; they are implicitly adapted. The columns of code attribute ASCII can be compared to date, time, and timestamp specifications.

All numbers can be compared to each other.

In SQL mode ANSI, it is not sufficient that the data types and lengths of the specified columns are compatible; they must be equal. Moreover, only column specifications or * may be specified in the SELECT COLUMNs of the QUERY specifications connected by UNION. The specification of literals is not allowed.

User Action:

Use a QUERY statement issued on the system table DOMAIN.COLUMNS to find out the definition of the specified columns. It may be attempted to achieve comparability by applying a conversion function.

This request cannot be made in SQL mode ANSI.


-8030: Column must be indexed (MaxDB: Messages)

-8030: Column must be indexed

Explanation:

No index was created on the specified column.

In a referential CONSTRAINT definition, the columns (referenced_column) must either designate the key of the table or columns which form an index defined with UNIQUE.

User Action:

Use a QUERY statement issued on the system table DOMAIN.INDEXES to see a list of the existing indexes. Create the desired index, or do without the index.


-8031: Owner must be specified (MaxDB: Messages)

-8031: Owner must be specified

Explanation:

In a database procedure, the owner must be specified for every table name.

User Action:

Correct the database procedure accordingly.


-8033: Incomplete log segment (MaxDB: Messages)

-8033: Incomplete log segment

Explanation:

You tried to save the log area. However, the log is smaller than defined in the database parameter LOG_SEGMENT_SIZE.

User Action:

No action required.


-8034: Order column must be number (MaxDB: Messages)

-8034: Order column must be number

Explanation:

In a QUERY statement whose QUERY expression contains at least a UNION, INTERSECT or EXCEPT specification, the ORDER clause must not contain any column specifications.

User Action:

Replace the column specifications by the corresponding numbers of the output columns.


-8035: Foreign key must exist (MaxDB: Messages)

-8035: Foreign key must exist

Explanation:

An UPDATE statement was performed for an updateable join view table. This UPDATE statement leads to an internal insert into one of the underlying base tables. The specifications made in the UPDATE statement are not sufficient to form all mandatory columns which are needed for the implicit INSERT statement.

User Action:

Issue an INSERT statement on the underlying base table. This can prevent the necessity of inserting when performing the UPDATE statement on the join view table.


-8037: DB procedure must be recompiled (MaxDB: Messages)

-8037: DB procedure must be recompiled

Explanation:

SQL statements for data definition were performed which concern tables used in the database procedure. Check by compilation whether the database procedure is still executable.

User Action:

The owner of the database procedure has to perform this check by saving the database procedure again.


-8040: Key does not exist (MaxDB: Messages)

-8040: Key does not exist

Explanation:

The attempt was made to delete the key for the specified table. The specified table has no user-defined key. The key implicitly generated with the column SYSKEY cannot be deleted.

User Action:

The SQL statement is not needed because there is already the desired table definition.


-8044: Conversion for character set value impossible (MaxDB: Messages)

-8044: Conversion for character set value impossible

Explanation:

You tried to convert data in ASCII or UCS-2 format (see also Overview: UNICODE) into another format. This attempt has failed.

User Action:

You cannot perform a conversion explicitly. You can try to avoid this error by explicitly converting the data used, for example, for comparisons.


-8045: Conversion to UNICODE impossible (MaxDB: Messages)

-8045: Conversion to UNICODE impossible

Explanation:

You tried to convert data in ASCII format (see also Overview: UNICODE) into UCS-2 format. This attempt has failed.

User Action:

You cannot perform a conversion explicitly. You can try to avoid this error by explicitly converting the UCS-2 data used, for example, for comparisons.


-8046: Conversion from UNICODE impossible (MaxDB: Messages)

-8046: Conversion from UNICODE impossible

Explanation:

You tried to convert data in UCS-2 format (see also Overview: UNICODE) into an ASCII format. This is not possible because the data contains characters other than Latin1 characters.

User Action:

Check whether the data is correct.

You cannot perform a conversion explicitly. You can try to avoid this error by explicitly converting the ASCII data used, for example, for comparisons.


-8047: Password required (MaxDB: Messages)

-8047: Password required

Explanation:

With a SET statement you tried to activate a role that requires the definition of a password.

User Action:

Repeat the SQL statement and specify the password.


-8048: Version of component must be compatible with kernel versi (MaxDB: Messages)

-8048: Version of component must be compatible with kernel version

Explanation:

You tried to use a component whose version number is much smaller than that of the database kernel used. Since the interface between the components and the database kernel has changed significantly, this is not possible.

User Action:

Use a component whose version number corresponds to that of the database kernel used.


-8049: Prepare migration required (MaxDB: Messages)

-8049: Prepare migration required

Explanation:

Once you had imported SAP DB Version 7.4, you were not able to start the INPLACE migration because no preparations had been made in the original database version for migration.

User Action:

...

1. Import the original database version again.

2. Switch the database instance to ONLINE mode.

3. Shut down the database instance.

4. Run the Database Manager CLI command migrate in a utility session while the database is in ADMIN mode.

This deletes data that is no longer support in Version 7.4.

5. Import Version 7.4 again and restart the INPLACE migration.


-8050: Migration error (MaxDB: Messages)

-8050: Migration error

Explanation

An error has occurred while migrating a database instance with a database catalog stored in ASCII format (special database parameter _ = NO) to a UNICODE-enabled database instance (database parameter _UNICODE = YES). The cause of the error is logged in the file knldiag or knldiag.err.

User action

The action you need to take depends on what caused the error:

· "RESTART REQUIRED BEFORE MIGRATION"
The database instance and its current software needs to have been in ONLINE mode at least once before the migration can start.

· "UNHANDLED ENTRY TYPE: " + number of record type
The database catalog contains a record type that will not be migrated. All unhandled records are collected and an entry written for each one. Contact Support.

· "ERROR HANDLING TYPE " + number of record type
An error has occurred while processing a database catalog record of the type shown in the message. Migration is cancelled. The record is saved in the work directory under the name MIGERRORREC.BIN. Please inform the SAP DB support team.

· "ERROR WHEN RECREATING VIEW" + initial text of the defined view
An error has occurred while restoring a view table.
Depending which error has occurred, you must delete the relevant view table and, if necessary, regenerate it after the migration.

· "MIGRATION FAILED FOR TRIGGER:" or "MIGRATION FAILED FOR DBPROC:"
Database procedures or triggers have been defined based on tables. However, the tables, columns, or users have since been renamed. These cannot be recreated. The system generates a list of all the database procedures and triggers that cannot be recreated. Migration is then cancelled.
The database procedures/triggers could no longer be used at the time of migration, so have to be deleted.

· "CONSTRAINTTEXT IS TOO LONG:" + name of constraint
A constraint's definition text would exceed the maximum length if it were converted to UNICODE during migration. You must either delete or modify the constraint.

· "CATALOG IS UNICODE ALREADY"
The database instance already appears to be UNICODE-enabled.

· "_UNICODE has to be YES for migration"
The migration was started even though the database parameter _UNICODE was set as NO.


-8888: SERVERDB not accessible (MaxDB: Messages)

-8888: SERVERDB not accessible

Explanation:

The attempt was made to start a database session. This is impossible for one of the following reasons:

...

1. The database name was specified incorrectly

2. The database instance has not yet been started.

User Action:

...

1. Check the specified database name.

2. Start the database instance. Pay attention to errors that might occur.


-9000: SYSTEM ERROR: NOT YET IMPLEMENTED (MaxDB: Messages)

-9000: SYSTEM ERROR: NOT YET IMPLEMENTED

Explanation:

This SQL statement is not yet implemented. It will be available in future releases.

User Action:

To achieve the desired effect try one or more other SQL statements.


-9001 to -9799: System error (MaxDB: Messages)

-9001 to -9799: System error

Explanation:

These error messages should not occur during normal operation on a consistent database instance. With some errors, an implicit SHUTDOWN is performed.

User Action:

As a rule, the database instance should be shut down and you should contact your support. Create a trace of the last database activities and save it. Send the trace to your support organization so they can trace and rectify the error.


From -9800 to -9999 (MaxDB: Messages)

From -9800 to -9999

Precompiler error messages

-9801 | Invalid command state
-9803 | Unknown data type
-9805 | Option CHECK usage on or off error
-9806 | Invalid output value
-9807 | Too many users
-9808 | SET FORMAT error
-9809 | Option CHECK usage add error


-9801: Invalid command state (MaxDB: Messages)

-9801: Invalid command state

Explanation:

The command state is invalid.

This is a runtime error of the precompiler.

User Action:

Contact Support.


-9803: Unknown data type (MaxDB: Messages)

-9803: Unknown data type

Explanation:

The data type is not known in the database instance.

User Action:

Contact Support.


-9805: Option CHECK usage on or off error (MaxDB: Messages)

-9805: Option CHECK usage on or off error

Explanation:

When the precompiler option CHECK is specified, the SYSUSAGE entries are adapted at the end of a precompiler run. An error occurred in this case.

User Action:

For error analysis and correction, pay attention to all error messages output during the precompiler run. For further information refer to the corresponding error numbers in this manual.


-9806: Invalid output value (MaxDB: Messages)

-9806: Invalid output value

Explanation:

The define byte in the command buffer is set to an invalid value.

User Action:

Check whether the kernel and the precompiler used for translating the application have the same version number. If the version numbers agree, notify your DB administrator.


-9807: Too many volumes (MaxDB: Messages)

-9807: Too many volumes

Explanation:

All database sessions for the database instance are used.

User Action:

Wait until a database session is released. If this problem arises frequently, the configuration of the database instance must be checked and modified by the database administrator.


-9808: SET FORMAT error (MaxDB: Messages)

-9808: SET FORMAT error

Explanation:

An implicit SET FORMAT is issued to the database instance after every CONNECT statement. This determines which date and time formats are used. If an error occurs at the SET FORMAT command, the standard format is taken as the default.

User Action:

Restart the program and thereby avoid the error. If the SET FORMAT error occurs repeatedly, notify the DB administrator.


-9809: Option CHECK usage add error (MaxDB: Messages)

-9809: Option CHECK usage add error

Explanation:

When the precompiler option CHECK is specified, the SYSUSAGE entries for SQL‑PL, FORM, REPORT, PROC, QUERY, COMMAND and PREPARE are adapted at the end of a precompiler run. An error occurred in this case.

User Action:

For error analysis and correction, pay attention to all error messages output during the precompiler run. For further information refer to the corresponding error numbers in this manual.


From -22000 to -22999 (MaxDB: Messages)

From -22000 to -22999

Error messages of the ODBC program

-22000 | Null values not allowed on more than one long column
-22005 | Connection timeout occured. Session reconnected


-22000: Null values not allowed on more than one long column (MaxDB: Messages)

-22000: Null values not allowed on more than one long column

Explanation:

In an INSERT or UPDATE statement, at most one LONG column may have the value NULL if LONG columns are inserted with the functions SQLParamData and SQLPutData.

User Action:

Only include one LONG column in the statement or use empty strings instead of NULL values.


-22005: Connection timeout occurred. Session reconnected (MaxDB: Messages)

-22005: Connection timeout occurred. Session reconnected

Explanation:

The user’s transaction was cancelled and reset by a ROLLBACK statement. The database session was terminated because the user failed to carry out any operations during a certain period of time (database parameter SESSION_TIMEOUT or the timeout value specified in the CONNECT statement).

The ODBC driver recognizes the timeout in this type of instance and logs the user back on to the database instance automatically using the original parameters (user name, password, database name, database host, etc.). Each statement of the relevant session signals this with return code SQL_SUCCESS_WITH_INFO and message -22005.

User Action:

All statements having a result set (CURSOR) must be executed again in order to ensure that the result sets are built up again. If the connection is set to SQL_AUTOCOMMIT_OFF, all the other statements that were in an open transaction must also be executed again.


From -23000 to -23999 (MaxDB: Messages)

From -23000 to -23999

Error Messages of the SQL Studio Program

-23050 | Unknown error
-23051 | Could not load system tables for SQL Studio
-23052 | Could not save object data
-23053 | Cannot load suppose list
-23054 | Maximum numbers of windows reached
-23055 | Connection failed
-23056 | User is exclusive
-23057 | Reconnect failed
-23058 | No database connection
-23059 | You do not have the permission to modify this object
-23060 | You do not have the permission to delete this object
-23061 | Cannot analyze error
-23062 | Could not open connection
-23063 | Could not create Global Com Object
-23064 | Import failed
-23070 | Cannot open object created by newer SQL Studio Version
-23071 | Convert object created by older SQL Studio Version
-23072 | Representation of null value too long
-23100 | OLE Error Please restart SQL Studio
-23101 | Data in clipboard truncated
-23102 | Failed to create DBC Pool
-23103 | Failed to create DBC Handle
-23104 | Could not load table definition
-23200 | No data sources
-23201 | No ODBC driver
-23202 | Could not load object description
-23203 | Cannot show tables of users, wrong database version


-23050: Unknown error (MaxDB: Messages)

-23050: Unknown error

Explanation:

An unknown error has occurred.

User Action:

Contact the Support.


-23051: Could not load system tables for SQL Studio (MaxDB: Messages)

-23051: Could not load system tables for SQL Studio

Explanation:

The database instance does not contain the system tables needed for the SQL Studio.

User Action:

Load the system tables with the Database Manager.

If you receive the same error message again, contact Support.


-23052: Could not save object data (MaxDB: Messages)

-23052: Could not save object data

Explanation:

An SQL Studio object could not be saved.

User Action:

Load the system tables with the Database Manager.

If you receive the same error message again, contact Support.


-23053: Cannot load suppose list (MaxDB: Messages)

-23053: Cannot load suppose list

Explanation:

The SQL support could not be loaded.

User Action:

Load the system tables with the Database Manager.

If you receive the same error message again, contact Support.


-23054: Maximum numbers of windows reached (MaxDB: Messages)

-23054: Maximum numbers of windows reached

Explanation:

The maximum number of windows have been opened.

User Action:

Close some windows.


-23055: Connection failed (MaxDB: Messages)

-23055: Connection failed

Explanation:

You were unable to connect to the database instance.

User Action:

Check the state of the database instance with the Database Manager.


-23056: User is exclusive (MaxDB: Messages)

-23056: User is exclusive

Explanation:

An attempt has been made to connect to the database instance several times using an exclusive user.

User Action:

If the user really needs to connect to the database more than once, use the SQL Studio to change the user to a not-exclusive user.


-23057: Reconnect failed (MaxDB: Messages)

-23057: Reconnect failed

Explanation:

An attempt to restore an interrupted connection to the database instance has failed.

User Action:

Check the state of the database instance with the Database Manager.

End the database session and log on to the database instance again.


-23058: No database connection (MaxDB: Messages)

-23058: No database connection

Explanation:

The connection to the database instance has been broken.

User Action:

Check the state of the database instance with the Database Manager.

End the database session and log on to the database instance again.


-23059: You do not have the permission to modify this object (MaxDB: Messages)

-23059: You do not have the permission to modify this object

Explanation:

You cannot modify an object from the SQL Studio that has been released by someone else.

User Action:

Contact the owner of the object.


-23060: You do not have the permission to delete this object (MaxDB: Messages)

-23060: You do not have the permission to delete this object

Explanation:

You cannot delete an object from the SQL Studio that has been released by someone else.

User Action:

Contact the owner of the object.


-23061: Cannot analyze error (MaxDB: Messages)

-23061: Cannot analyze error

Explanation:

An ODBC error has occurred that could not be analyzed.

User Action:

Check which version of the ODBC driver you are using and install a more recent version if necessary.


-23062: Could not open connection (MaxDB: Messages)

-23062: Could not open connection

Explanation:

An attempt to connect to the database instance has failed.

User Action:

Check the state of the database instance with the Database Manager.

End the SQL Studio session and connect to the database again.


-23063: Could not create Global Com Object (MaxDB: Messages)

-23063: Could not create Global Com Object

Explanation:

An SQL Studio object could not be created.

User Action:

Exit the SQL Studio.

Check whether the system has enough memory.

Restart the SQL Studio.


-23064: Import failed (MaxDB: Messages)

-23064: Import failed

Explanation:

Could not load exported SQL Studio objects.

User Action:

Contact the Support.


-23070: Cannot open object created by newer SQL Studio Version (MaxDB: Messages)

-23070: Cannot open object created by newer SQL Studio Version

Explanation:

You attempted to open an SQL Studio object that was created with a newer version of the software.

User Action:

You can only modify this object using a newer version of the software. Install the most up-to-date version of the SQL Studio.


-23071: Convert object created by older SQL Studio Version (MaxDB: Messages)

-23071: Convert object created by older SQL Studio Version

Explanation:

You can convert the object from the SQL Studio into the format of a newer program version.

User Action:

Choose Yes if you want to convert the object. Saving the object gives it the same format as the newer version of the SQL Studio. Once the object has been converted, you can no longer process it with an older version.

Choose No if you do not want to convert the object.


-23072: Representation of null value too long (MaxDB: Messages)

-23072: Representation of null value too long

Explanation:

The NULL value display contains more than 16 characters.

User Action:

Choose a NULL value display with less than 16 characters.


-23100: OLE Error! Please restart SQL Studio (MaxDB: Messages)

-23100: OLE Error! Please restart SQL Studio

Explanation:

An automation error occurred in the Windows operating system during an OLE operation.

User Action:

End and restart SQL Studio.


-23101: Data in clipboard truncated (MaxDB: Messages)

-23101: Data in clipboard truncated

Explanation:

When the contents of a LONG column are exported into the clipboard, a maximum of 1048576 bytes are transferred. If there is more data than this in the results, it will be ignored.

User Action:

To export all contents of a LONG column, that is, even if it amounts to more than 1048576 bytes, use the export in a file.


-23102: Failed to create DBC Pool (MaxDB: Messages)

-23102: Failed to create DBC Pool

Explanation:

Could not create a database connection pool.

User Action:

Contact Support.


-23103: Failed to create DBC Handle (MaxDB: Messages)

-23103: Failed to create DBC Handle

Explanation:

Could not create a database connection pool.

User Action:

Contact Support.


-23104: Could not load table definition (MaxDB: Messages)

-23104: Could not load table definition

Explanation:

The definition of a table could not be loaded.

User Action:

Contact Support.


-23200: No data sources (MaxDB: Messages)

-23200: No data sources

Explanation:

No ODBC data sources have been installed on the operating system with the database’s ODBC driver.

User Action:

Install a data source with the ODBC administrator.


-23201: No ODBC driver (MaxDB: Messages)

-23201: No ODBC driver

Explanation:

There is no ODBC driver (sqlod32.dll, sqlsp32.dll) in the SQL Studio directory.

User Action:

Uninstall SQL Studio and reinstall it again.

If you receive the same error message again, contact Support.


-23202: Could not load object description (MaxDB: Messages)

-23202: Could not load object description

Explanation:

The SQL Studio objects could not be loaded.

User Action:

Load the system tables with the Database Manager.

If you receive the same error message again, contact Support.


-23203: Cannot show tables of users, wrong database version! (MaxDB: Messages)

-23203: Cannot show tables of users, wrong database version!

Explanation:

The system table DOMAIN.TABLES does not contain all the columns required to display the tables in the catalog tree structure.

User Action:

Use a newer version of SQL Studio.


From -24000 to -24999 (MaxDB: Messages)

From -24000 to -24999

Error Messages of the Database Manager Program

-25905 | ERR_NOEBIDLIST: no information about external backup IDs available
-25906 | ERR_EBFDIRTY: invalid format of external backup history
-24907 | ERR_DBAWRONG - wrong SYSDBA
-24908 | ERR_DOMPUNKNOWN – DOMAIN password unknown
-24909 | ERR_DBAUNKNOWN - SYSDBA unknown
-24910 | ERR_PARAMVER - wrong version of param help file (cserv.pcf) <version>
-24911 | ERR_INVDBNAME - database name <dbname> is reserved
-24912 | ERR_WRONGINST - DBM Server instroot is <instroot>
-24913 | ERR_SERVICEDB - cannot register service kernel for <instroot>
-24914 | ERR_KEYEXISTS - installation key <key> exists
-24915 | ERR_NOADDD - configuration update not allowed (param file is inactive)
-24916 | ERR_MAXDEVCNT - max device count exceeded
-24917 | ERR_MAXDATA - max data size exceeded
-24918 | ERR_MISSMIRR - missing data for mirror devspace
-24919 | ERR_CLEANUP: cannot free all operational resources after backup operation
-24920 | ERR_BACKUPOP: backup operation was unsuccessful
-24921 | ERR_POSTOP: error while finishing backup operation
-24922 | ERR_OPCHK: cannot check state of backup operation
-24923 | ERR_TOOLREQ: error while starting external backup tool
-24924 | ERR_DBREQ: cannot start database kernel request
-24925 | ERR_PREPARE: preparation of backup operation failed
-24926 | ERR_MEDIUMCHK: medium cannot be used with this external backup tool
-24927 | ERR_TOOLCHK: external backup tool not found
-24928 | ERR_NOREPLY - no reply available
-24929 | ERR_USRFRM - invalid user record format
-24930 | ERR_XPVALUESET - parameter value not in valueset
-24931 | ERR_XPMAX - parameter value higher than maximum allowed
-24932 | ERR_XPMIN - parameter value smaller than minimum allowed
-24933 | ERR_NOSERVICESESSION - no service kernel session available
-24934 | ERR_VERSION - incompatible versions (param and kernel)
-24935 | ERR_NOUSERS - no users found
-24936 | ERR_DBNORUN - database is not running
-24937 | ERR_MISSRIGHT - no server rights for this command
-24938 | ERR_NOENTRY - no entry found
-24939 | ERR_LASTREG - cannot delete last registration of instance
-24940 | ERR_NEEDSYSLOGON - system logon required
-24941 | ERR_NEEDLOGON - DBMServer logon required
-24942 | ERR_USRDELSDBA - cannot delete sysdba
-24943 | ERR_USRDELCOLD - cannot delete DBM user
-24944 | ERR_USRDELSELF - cannot delete current user
-24945 | ERR_TOFEWPARAM - too few parameters
-24946 | ERR_TOMANYPARAM - too many parameters
-24947 | ERR_DBNAME - do not use dbname
-24948 | ERR_NODBNAME - database name required
-24949 | ERR_USREXISTS - user entry already exists
-24950 | ERR_USRFAIL - user authorization failed
-24951 | ERR_USRREAD - could not read user data
-24952 | ERR_USRSAVE - could not save user data
-24953 | ERR_DBEXIST - database instance already exists
-24954 | ERR_BANOAUTOMED - no autolog medium found in media list
-24955 | ERR_BANOSAVETYPE - backup type not defined
-24956 | ERR_BASAVETYPECON – backup type conflicts with media definition
-24957 | ERR_NOUSER – required user not set
-24958 | ERR_BAOVERWRITE - file already exists, cannot overwrite
-24959 | ERR_XPOVERFLOW - value out of margin
-24960 | ERR_DBRUN – database is running
-24961 | ERR_STATE – cannot determine current db state
-24962 | ERR_DEVTYPE – wrong devspace type
-24963 | ERR_DEVCHECK – error while checking devspace
-24964 | ERR_EXECUTE – error in program execution
-24965 | ERR_SYSLOGON – logon to system failed
-24966 | ERR_LOGON – logon to DBM Server failed
-24967 | ERR_SYSTEM – system call error
-24968 | ERR_XPREADONLY – parameter is read only
-24969 | ERR_XPDIRTY – param file is dirty
-24970 | ERR_XPNOMODIFY –parameter must not be modified
-24971 | ERR_XPNOCHECK - no running parameter check
-24972 | ERR_XPINVCONF – invalid value
-24973 | ERR_XPCHECK – param check failure/request
-24974 | ERR_XPSESSION – param session active
-24975 | ERR_NOXPSESSION – param session inactive
-24976 | ERR_PARAMEXIST – param file of database already exists
-24977 | ERR_COMMAND - unknown command <command>
-24978 | ERR_XPSYNTAX – xparam syntax error
-24979 | ERR_XPNOTFOUND – parameter not found
-24980 | ERR_NOHELP - xparam help file not found
-24981 | ERR_HIENTRYNOTFOUND – backup history entry not found
-24982 | ERR_ERR_NOHISTORY - backup history file not found
-24983 | ERR_BANOVALIDTYPE - invalid backup type
-24984 | ERR_MENOVALID - invalid medium definition
-24985 | ERR_MENOTFOUND – medium not found
-24986 | ERR_NOMEDIA - media file not found
-24987 | ERR_TOSMALL – packet size too small for answer
-24988 | ERR_SQL – SQL error
-24989 | ERR_NOHISTORYSESSION – no backup history session available
-24990 | ERR_ NOBACKUPSESSION – no backup session available
-24991 | ERR_ NOSQLUSERSESSION– no SQL user session available
-24992 | ERR_NOUTILSESSION – no utility session available
-24993 | ERR_RTEEXT – runtime environment error
-24994 | ERR_RTE – runtime environment error
-24995 | ERR_MEM – memory allocation error
-24996 | ERR_PARAM – wrong parameters
-24997 | ERR_FILE – file handling error
-24998 | ERR_NOTIMPL – sorry, command not yet implemented
-24999 | ERR – common error


-24905: ERR_NOEBIDLIST: no information on external backup IDs av (MaxDB: Messages)

-24905: ERR_NOEBIDLIST: no information on external backup IDs available

Explanation:

No information on external backup IDs are available, since this information was not requested from an external backup tool.

User Action:

Execute the backup_ext_ids_get command to request this information.


-24906: ERR_EBFDIRTY: invalid format of external backup history (MaxDB: Messages)

-24906: ERR_EBFDIRTY: invalid format of external backup history

Explanation:

The External Backup History file is not in the expected format.

User Action:

Depending on whether you require the information in this file or not, either contact your support or create a backup copy of this file and replace it with an empty file with the same name.


-24907: ERR_DBAWRONG - wrong SYSDBA (MaxDB: Messages)

-24907: ERR_DBAWRONG - wrong SYSDBA

Explanation:

The user defined as SYSDBA (database system administrator) in the DBM server does not have the required rights.

User Action:

Specify the correct database system administrator.


-24908: ERR_DOMPUNKNOWN - DOMAIN password unknown (MaxDB: Messages)

-24908: ERR_DOMPUNKNOWN - DOMAIN password unknown

Explanation:

The password of the DOMAIN user required to load the system tables is not known to the DBM server.

User Action:

Specify the password for the DOMAIN user.


-24909: ERR_DBAUNKNOWN - SYSDBA unknown (MaxDB: Messages)

-24909: ERR_DBAUNKNOWN - SYSDBA unknown

Explanation:

The SYSDBA (database system administrator) required to load the system tables is not known to the DBM server.

User Action:

Specify the database system administrator.


-24910: ERR_PARAMVER - wrong version of param help file (cserv.p (MaxDB: Messages)

-24910: ERR_PARAMVER - wrong version of param help file (cserv.pcf) <version>

Explanation:

The version of the DBM server does not match the version of the parameter description file (cserv.pcf).

User Action:

Correct your installation. Remember to close all programs in your database system before starting an installation or upgrade.


-24911: ERR_INVDBNAME - database name <database_name> is reserve (MaxDB: Messages)

-24911: ERR_INVDBNAME - database name <database_name> is reserved

Explanation:

You selected an invalid name for your database instance.

User Action:

Use a different name for your database instance.


-24912: ERR_WRONGINST – DBM server instroot is <inst_path> (MaxDB: Messages)

-24912: ERR_WRONGINST – DBM server instroot is <inst_path>

Explanation:

You attempted to register an installation using a DBM server from a different installation. This is not possible.

User Action:

Use the correct DBM server. When using Database Manager CLI, you can use the Option -R to force the use of a specific DBM server.


-24913: ERR_SERVICEDB - can not register service kernel for <ins (MaxDB: Messages)

-24913: ERR_SERVICEDB - can not register service kernel for <inst_path>

Explanation:

The service database instance cannot be registered. This could be because the files were incorrectly installed or the operating system user does not have the necessary authorizations.

User Action:

Correct or repeat the installation or provide your operating system user with the required authorizations.


-24914: ERR_KEYEXISTS - installation key <key> exists (MaxDB: Messages)

-24914: ERR_KEYEXISTS - installation key <key> exists

Explanation:

You used a key in the DBM server command inst_reg that has already been used. If you did not specify a key, empty key is already used.

User Action:

Use a unique key after option -k in DBM command inst_reg ( inst_reg -k <key>).


-24915: ERR_NOADDD - configuration update not allowed (param fil (MaxDB: Messages)

-24915: ERR_NOADDD - configuration update not allowed (param file is inactive)

Explanation:

The database configuration cannot be changed as changes were made to the parameter file, but these changes are not yet activated.

User Action:

To activate the changes to the parameter file, change the database operation status to OFFLINE and then to ONLINE.

To discard the changes to the parameter file, use the DBM command param_restore.


-24916: ERR_MAXDEVCNT - max device count exceeded (MaxDB: Messages)

-24916: ERR_MAXDEVCNT - max device count exceeded

Explanation:

The number of volumes of the type used exceeds the maximum value that is currently set.

User Action:

Increase the value of database parameter MAXLOGVOLUMES for the log volumes or increase the value of MAXDATAVOLUMES for the data volumes. The database instance has to be restarted to activate the new value.


-24917: ERR_MAXDATA - max data size exceeded (MaxDB: Messages)

-24917: ERR_MAXDATA - max data size exceeded

Explanation:

The number of data volumes exceeds the maximum value that is currently set.

User Action:

Reduce the size of the volume to be added.


-24918: ERR_MISSMIRR - missing data for mirror volume (MaxDB: Messages)

-24918: ERR_MISSMIRR - missing data for mirror volume

Explanation:

The information for a mirror volume is missing.

User Action:

Correct your entry by specifying the data for the mirrored volume. Execute the command again.


-24919: ERR_CLEANUP: cannot free all operational resources after (MaxDB: Messages)

-24919: ERR_CLEANUP: cannot free all operational resources after backup operation

Explanation:

It was not possible to free all of the temporary system resources that were used for a successful backup, check, or restore.

User Action:

Check which resources were not released using the backup log. If the resources are temporary files or pipes, try to remove these manually. You should also attempt to fix the problem with the help of the extended error description. If you cannot solve the problem, contact Support.


-24920: ERR_BACKUPOP: backup operation was unsuccessful (MaxDB: Messages)

-24920: ERR_BACKUPOP: backup operation was unsuccessful

Explanation:

The backup, check or restore action failed due to problems with either the database or the backup tool. If it is a backup check that has failed, this may have been caused by errors in the relevant backup.

User Action:

Attempt to fix the problem with the help of the extended error description. If you cannot solve the problem, contact Support.


-24921: ERR_POSTOP: error while finishing backup operation (MaxDB: Messages)

-24921: ERR_POSTOP: error while finishing backup operation

Explanation:

It was not possible to perform the necessary postprocessing steps after a successful backup, check, or restore.

User Action:

Try to fix the problem with the help of the extended error description, and repeat the backup, check, or restore. If you cannot solve the problem, contact Support.


-24922: ERR_OPCHK: cannot check state of backup operation (MaxDB: Messages)

-24922: ERR_OPCHK: cannot check state of backup operation

Explanation:

You were unable to check the status of the database instance or the backup tool.

User Action:

Attempt to fix the problem with the help of the extended error description. If you cannot solve the problem, contact Support.


-24923: ERR_TOOLREQ: error while starting external backup tool (MaxDB: Messages)

-24923: ERR_TOOLREQ: error while starting external backup tool

Explanation:

It was not possible to start a backup tool correctly.

User Action:

Attempt to fix the problem with the help of the extended error description. If you cannot solve the problem, contact Support.


-24924: ERR_DBREQ: cannot start database kernel request (MaxDB: Messages)

-24924: ERR_DBREQ: cannot start database kernel request

Explanation:

The database instance was unable to start the backup, check, or restore process.

User Action:

Attempt to fix the problem with the help of the extended error description. If you cannot solve the problem, contact Support.


-24925: ERR_PREPARE: preparation of backup operation failed (MaxDB: Messages)

-24925: ERR_PREPARE: preparation of backup operation failed

Explanation:

The preparations required to implement the backup tool could not be successfully completed.

User Action:

Attempt to fix the problem with the help of the extended error description. If you cannot solve the problem, contact Support.


-24926: ERR_MEDIUMCHK: medium cannot be used with this external (MaxDB: Messages)

-24926: ERR_MEDIUMCHK: medium cannot be used with this external backup tool

Explanation:

The specified backup medium cannot be used with the backup tool defined by the name of the medium.

User Action:

Attempt to fix the problem with the help of the detailed error description, by changing the backup medium appropriately. If you cannot solve the problem, contact Support.


-24927: ERR_TOOLCHK: external backup tool not found (MaxDB: Messages)

-24927: ERR_TOOLCHK: external backup tool not found

Explanation:

The external backup tool was not found or is not correctly installed.

User Action:

Attempt to fix the problem with the help of the extended error description. If you do not want to use an external backup tool, change the backup medium definition accordingly. If you cannot solve the problem, contact Support.


-24928: ERR_NOREPLY - no reply available (MaxDB: Messages)

-24928: ERR_NOREPLY - no reply available

Explanation:

There is no response to an asynchronous request sent to the database instance.

User Action:

Repeat the statement until there is a response, and then use the statement that corresponds to the request to retrieve the response. Alternatively, you can immediately use the statement for retrieving the response. This statement waits until the response is provided.


-24929: ERR_USRFRM - invalid user record format (MaxDB: Messages)

-24929: ERR_USRFRM - invalid user record format

Explanation:

The DBM user data is inconsistent.

User Action:

If you are migrating data, check that all the migration steps have been executed correctly. If the error persists, contact Support.


-24930: ERR_XPVALUESET - parameter value not in value set (MaxDB: Messages)

-24930: ERR_XPVALUESET - parameter value not in value set

Explanation:

The entered database parameter value is not within the permitted value range.

User Action:

Correct your entry, and re-execute the DBM command.


-24931: ERR_XPMIN - parameter value smaller than minimum allowed (MaxDB: Messages)

-24931: ERR_XPMIN - parameter value smaller than minimum allowed

Explanation:

The entered database parameter value exceeds the permitted maximum value.

User Action:

Correct your entry, and re-execute the DBM command.


-24932: ERR_XPMIN - parameter value smaller than minimum allowed (MaxDB: Messages)

-24932: ERR_XPMIN - parameter value smaller than minimum allowed

Explanation:

The entered database parameter value is below the required minimum.

User Action:

Correct your entry and re-execute the DBM command.


-24933: ERR_NOSERVICESESSION - no service kernel available (MaxDB: Messages)

-24933: ERR_NOSERVICESESSION - no service kernel available

Explanation:

The DBM command requires a service session.

User Action:

Before you execute the DBM command, activate the service session with the DBM command service_connect or the option -uSRV.


-24934: ERR_VERSION - incompatible versions (param and kernel) (MaxDB: Messages)

-24934: ERR_VERSION - incompatible versions (param and kernel)

Explanation:

The version of the parameter file of the database instance does not match the executable database program.

User Action:

Update the entries in the parameter file by checking the parameters. To do this, use the DBM command param_checkall.


-24935: ERR_NOUSERS - no users found (MaxDB: Messages)

-24935: ERR_NOUSERS - no users found

Explanation:

No user entries found.

User Action:

Generate the required user entries with the DBM command db_create.


-24936: ERR_DBNORUN - database is not running (MaxDB: Messages)

-24936: ERR_DBNORUN - database is not running

Explanation:

The databank instance is not in the ADMIN or ONLINE state.

User Action:

Make sure that the database instance is in the required operation status before using this DBM command. To do this, use DBM command db_admin or db_online.


-24937: ERR_MISSRIGHT - no server rights for this command (MaxDB: Messages)

-24937: ERR_MISSRIGHT - no server rights for this command

Explanation:

The current DBM user is not authorized to execute this statement.

User Action:

Use a different DBM user, or adjust the user rights of the current DBM user appropriately. To do this, use the DBM command user_put.


-24938: ERR_NOENTRY - no entry found (MaxDB: Messages)

-24938: ERR_NOENTRY - no entry found

Explanation:

The requested registration of the database instance was not found.

User Action:

Use an existing registration to execute the DBM command.


-24939: ERR_LASTREG - cannot delete last registration of instanc (MaxDB: Messages)

-24939: ERR_LASTREG - cannot delete last registration of instance

Explanation:

The last registration of a database instance cannot be deleted using the DBM command.

User Action:

To delete the database instance, use the DBM command db_drop. When you delete a database instance, all of its data, including its configuration, is deleted.


-24940: ERR_NEEDSYSLOGON - system logon required (MaxDB: Messages)

-24940: ERR_NEEDSYSLOGON - system logon required

Explanation:

The DBM command requires that you log on to the operating system.

User Action:

Assign an operating system user to the relevant DBM user. To do this, use the DBM command user_put.

To activate the operating system user, log on to the DBM server again. To do this, use the DBM command user_logon, and note any warnings that are displayed indicating problems with the operating system logon.


-24941: ERR_NEEDLOGON - DBM server logon required (MaxDB: Messages)

-24941: ERR_NEEDLOGON - DBM server logon required

Explanation:

The DBM command requires that you log on to the DBM server.

User Action:

Log on to the DBM server. To do this, use DBM command user_logon or option -u.


-24942: ERR_USRDELSDBA - cannot delete sysdba (MaxDB: Messages)

-24942: ERR_USRDELSDBA - cannot delete sysdba

Explanation:

The specified SYSDBA user has special properties and cannot be deleted.

User Action:

You are not allowed to delete this user. If unauthorized persons know the user name and password, change the user’s password. To do this, use the DBM command user_put.


-24943: ERR_USRDELCOLD - cannot delete DBM user (MaxDB: Messages)

-24943: ERR_USRDELCOLD - cannot delete DBM user

Explanation:

The specified user has special properties and cannot be deleted.

User Action:

You are not allowed to delete this user. If unauthorized persons know the user name and password, change the user’s password. To do this, use the DBM command user_put.


-24944: ERR_USRDELSELF - cannot delete current user (MaxDB: Messages)

-24944: ERR_USRDELSELF - cannot delete current user

Explanation:

The current user cannot be deleted.

User Action:

Log on to the DBM server with another user, and execute the DBM command again.


-24945: ERR_TOFEWPARAM - to few parameters (MaxDB: Messages)

-24945: ERR_TOFEWPARAM - to few parameters

Explanation:

The DBM command has too few parameters.

User Action:

Correct your entry according to the documentation for DBM commands, and execute the statement again.


-24946: ERR_TOMANYPARAM - to many parameters (MaxDB: Messages)

-24946: ERR_TOMANYPARAM - to many parameters

Explanation:

The DBM command has too many parameters.

User Action:

Correct your entry according to the documentation for DBM commands, and execute the statement again.


-24947: ERR_DBNAME - do not use dbname (MaxDB: Messages)

-24947: ERR_DBNAME - do not use dbname

Explanation:

You cannot use this DBM command on a database instance.

User Action:

Do not specify a database name when you execute the DBM command.


-24948: ERR_NODBNAME - database name required (MaxDB: Messages)

-24948: ERR_NODBNAME - database name required

Explanation:

You can use this DBM command on a database instance only.

User Action:

Use option -d to specify the name of the database instance for the DBM server.


-24949: ERR_USREXISTS - user entry already exists (MaxDB: Messages)

-24949: ERR_USREXISTS - user entry already exists

Explanation:

This DBM command cannot be used, as the user name already exists.

User Action:

Use a name that has not already been used for a user, or delete the existing user. Only delete a user if you the user is no longer required. When you delete a user, you delete all of the saved settings for that user. To delete a user, use the DBM command user_delete.


-24950: ERR_USRFAIL - user authorization failed (MaxDB: Messages)

-24950: ERR_USRFAIL - user authorization failed

Explanation:

Authorization on the DBM server failed. The user name and/or the password used are incorrect.

User Action:

Enter the correct user/password combination and log on to the DBM server again. You can correct the user data for the database instance in the Database Manager GUI.


-24951: ERR_USRREAD - could not read user data (MaxDB: Messages)

-24951: ERR_USRREAD - could not read user data

Explanation:

The DBM user data could not be read.

User Action:

Check the file system attributes and the operating system rights of the user profile container. This file has the name <database_name>.upc. On Windows, you can find this file in the config directory of the database installation. On UNIX systems, this file is in /usr/spool/sql/config. Use the DBM command user_getall to check the existence of the user.


-24952: ERR_USRSAVE - could not save user data (MaxDB: Messages)

-24952: ERR_USRSAVE - could not save user data

Explanation:

The DBM user data could not be saved.

User Action:

Check the file system attributes and the operating system rights of the user profile container. This file has the name <database_name>.upc. On Windows, you can find this file in the config directory of the database installation. On UNIX systems, this file is in /usr/spool/sql/config. Check that there is enough memory available on the relevant hard disk.


-24953: ERR_DBEXIST - database instance already exists (MaxDB: Messages)

-24953: ERR_DBEXIST - database instance already exists

Explanation:

This DBM command cannot be used, as the database instance already exists.

User Action:

Use a name that has not already been used for a database instance, or delete the existing database instance. Only delete a database instance if you no longer need it. When you delete a database instance, all of its data, including its configuration, is deleted. To delete the database instance, use the DBM command db_drop.


-24954: ERR_BANOAUTOMED - no autolog medium found in media list (MaxDB: Messages)

-24954: ERR_BANOAUTOMED - no autolog medium found in media list

Explanation:

You have not defined a backup medium to back up the log automatically.

User Action:

Correct the medium definition, or enter the backup medium explicitly for the failed command.


-24955: ERR_BANOSAVETYPE - backup type not defined (MaxDB: Messages)

-24955: ERR_BANOSAVETYPE - backup type not defined

Explanation:

The backup medium definition contains no backup type ( LOG, DATA or PAGES) .

User Action:

Correct the medium definition, or enter the backup type explicitly for the failed command.


-24956: ERR_BASAVETYPECON - backup type conflicts with medium de (MaxDB: Messages)

-24956: ERR_BASAVETYPECON - backup type conflicts with medium definition

Explanation:

An attempt has been made to Save or Restore using the defined backup medium. However, the predefined backup type for the backup medium ( LOG, DATA or PAGES) and the backup type used for the Save or Restore clash.

User Action:

Correct your entry or the medium definition.

You may sometimes have to readjust your definition again to restore older backups.


-24957: ERR_NOUSER - required user not set (MaxDB: Messages)

-24957: ERR_NOUSER - required user not set

Explanation:

You tried to execute a DBM command relating to a set user. However, this standard user has not been set yet in the DBM server.

User Action:

First of all, save the required user with the DBM command user_set. Alternatively, you can also specify a user/password combination explicitly when you re-execute the failed statement.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24958: ERR_BAOVERWRITE - file already exists, cannot overwrite (MaxDB: Messages)

-24958: ERR_BAOVERWRITE - file already exists, cannot overwrite

Explanation:

An attempt has been made to perform a backup. However, the backup medium that you specified has already been used for a backup, and has been defined as Not overwritable.

User Action:

Use a different backup medium or delete the existing one using the operating system tools. Alternatively, you could also adjust the medium definition.

Overwriting or deleting a backup medium destroys all data stored there.


-24959: ERR_XPOVERFLOW - value out of margin (MaxDB: Messages)

-24959: ERR_XPOVERFLOW - value out of margin

Explanation:

The value used for a database parameter is invalid. You have either chosen an invalid data type (for example, you have used text for a numerical parameter) or you have exceeded the maximum values allowed for that data type (for example, you have used too large a number or too much text).

User Action:

Correct your entry.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24960: ERR_DBRUN - database is running (MaxDB: Messages)

-24960: ERR_DBRUN - database is running

Explanation:

The databank instance is in the ADMIN or ONLINE operation status. This DBM command is not valid in this operation status.

User Action:

First of all, make sure the database instance is OFFLINE and then re-execute the command.

Making the database instance OFFLINE breaks the connection to all users logged on to the database instance or to all programs that are running on it.


-24961: ERR_STATE - cannot determine current db state (MaxDB: Messages)

-24961: ERR_STATE - cannot determine current db state

Explanation:

The database instance’s operation status could not be determined. This means the validity of the DBM commands can no longer be determined.

User Action:

Check the database processes using the operating system tools. Try to connect to the database through a database instance (for example, SQL Studio). If this succeeds, the database instance has the operation status ONLINE, and is ready for (maybe limited) use.

Use some of the other options available, for example, log files, to check the status of the database instance. Please contact Support, if necessary.

If your applications or users can no longer connect to the database instance, you should make sure the database instance has a proper status by restarting it.


-24962: ERR_DEVTYPE - wrong volume type (MaxDB: Messages)

-24962: ERR_DEVTYPE - wrong volume type

Explanation:

An unknown or invalid volume type has been used.

User Action:

Correct your entry.


-24963: ERR_DEVCHECK - error while checking volume (MaxDB: Messages)

-24963: ERR_DEVCHECK - error while checking volume

Explanation:

The volume you have tried to configure is invalid. The system was unable to find/create a volume with the parameters specified.

User Action:

Check your entries and the configuration of your operating system. Make corrections as appropriate and reconfigure the volume.


-24964: ERR_EXECUTE - error in program execution (MaxDB: Messages)

-24964: ERR_EXECUTE - error in program execution

Explanation:

An error occurred when a program or operating system command was called using the DBM server. The program/command was not found or it encountered an error when it was executed.

User Action:

Remember the exit code shipped with the system as well as the programs/command documentation that was delivered. Check whether the program/command is available on the server. Use the program/command documentation to help you find the error.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24965: ERR_SYSLOGON - logon to system failed (MaxDB: Messages)

-24965: ERR_SYSLOGON - logon to system failed

Explanation:

The DBM server could not log on to the operating system or the statement used requires it to be already logged on to the operating system.

User Action:

Check you entries as well as the authorizations assigned to the respective user. In Windows, the user must have the authorization logon as batch job. The current DBM server user must also have authorization to log on under a different user account.


-24966: ERR_LOGON - logon to DBM server failed (MaxDB: Messages)

-24966: ERR_LOGON - logon to DBM server failed

Explanation:

An invalid user/password combination was used or the statement used requires you to be already logged on.

User Action:

Enter the correct user/password combination or log on to the DBM server first.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24967: ERR_SYSTEM - system call error (MaxDB: Messages)

-24967: ERR_SYSTEM - system call error

Explanation:

An attempt to use an operating system function has failed.

User Action:

Read the extended error text, which describes operating system messages in more detail.


-24968: ERR_XPREADONLY - parameter is read only (MaxDB: Messages)

-24968: ERR_XPREADONLY - parameter is read only

Explanation:

The database parameter used cannot be modified.

User Action:

Correct your entry.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact support.


-24969: ERR_XPDIRTY - param file is dirty (MaxDB: Messages)

-24969: ERR_XPDIRTY - param file is dirty

Explanation:

An attempt has been made to make a change to the database parameters without first checking whether or not a previous change works properly by restarting the database instance.

User Action:

Start the database instance and repeat the change you made to the database parameter.

Restarting the database instance breaks the connection to all users logged on to the database instance or ends all programs that are running on it.


-24970: ERR_XPNOMODIFY - parameter must not be modified (MaxDB: Messages)

-24970: ERR_XPNOMODIFY - parameter must not be modified

Explanation:

The database parameter used cannot be modified.

User Action:

Set the database parameter back to its initial value.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24971: ERR_XPNOCHECK - no running parameter check (MaxDB: Messages)

-24971: ERR_XPNOCHECK - no running parameter check

Explanation:

A restart was not possible after correcting a single database parameter because no check run was active when the parameters were checked.

User Action:

Start the database parameter check again.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24972: ERR_XPINVCONF - invalid value (MaxDB: Messages)

-24972: ERR_XPINVCONF - invalid value

Explanation:

An attempt has been made to confirm a database parameter. You have either used an invalid value or a parameter for which there was no Request available.

User Action:

Correct your entries or restart the parameter check, for example, with the DBM command param_checkall.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24973: ERR_XPCHECK - param check failure/request (MaxDB: Messages)

-24973: ERR_XPCHECK - param check failure/request

Explanation:

The system was unable to check the database parameters using the rules and processes stored in the parameter help file. You will find more information on this in the extended message text.

User Action:

Correct the database parameter value as stated in the documentation.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24974: ERR_XPSESSION - param session active (MaxDB: Messages)

-24974: ERR_XPSESSION - param session active

Explanation:

If a parameter session is already active, you will not be able to start another session.

User Action:

Check the sequence of your DBM commands. If necessary, terminate an existing parameter session using the statement param_commitsession or param_abortsession. Alternatively, you can also use the active parameter session to execute your command.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24975: ERR_NOXPSESSION - param session inactive (MaxDB: Messages)

-24975: ERR_NOXPSESSION - param session inactive

Explanation:

Some DBM commands in this application area require a parameter session. In this case, this session was inactive.

User Action:

Check the sequence of your DBM server commands. First of all, you must open a parameter session using the DBM command param_startsession before you can process a database parameter.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24976: ERR_PARAMEXIST - param file of database already exists (MaxDB: Messages)

-24976: ERR_PARAMEXIST - param file of database already exists

Explanation:

A parameter file already exists for the specified database instance. The parameter file can be initialized only if no parameter file exists. This prevents the configuration from being lost.

User Action:

Delete the parameter file explicitly either at file-system level or using the DBM command param_rmfile. Note that this will mean the current database instance configuration will be lost.


-24977: ERR_COMMAND - unknown command <command> (MaxDB: Messages)

-24977: ERR_COMMAND - unknown command <command>

Explanation:

This particular DBM command has not been recognized.

User Action:

Enter a correct command. Bear in mind that statements are case-sensitive.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24978: ERR_XPSYNTAX - xparam syntax error (MaxDB: Messages)

-24978: ERR_XPSYNTAX - xparam syntax error

Explanation:

The parameter description in the database parameter help file is incorrect.

User Action:

Read the extended error text and correct the error in the file cserv.pcf, which you will find in the database installation’s env directory.


-24979: ERR_XPNOTFOUND - parameter not found (MaxDB: Messages)

-24979: ERR_XPNOTFOUND - parameter not found

Explanation:

The database parameter specified does not exist in the parameter help file.

User Action:

Check that the parameter name is correct. Bear in mind that statements are case-sensitive.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24980: ERR_NOHELP - xparam help file not found (MaxDB: Messages)

-24980: ERR_NOHELP - xparam help file not found

Explanation:

The parameter help file that describes the database parameters could not be opened.

User Action:

Check that the cserv.pcf file in the database installation’s env directory exists and is correct. You should also check the DBM server’s access rights to this file.


-24981: ERR_HIENTRYNOTFOUND - backup history entry not found (MaxDB: Messages)

-24981: ERR_HIENTRYNOTFOUND - backup history entry not found

Explanation:

The required entry does not exist in the backup history.

User Action:

Correct the parameters of the DBM command you used to read the backup history.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24982: ERR_ERR_NOHISTORY - backup history file not found (MaxDB: Messages)

-24982: ERR_ERR_NOHISTORY - backup history file not found

Explanation:

There is no backup history available.

User Action:

A backup history only exists if backup operations have already been executed. The backup history function cannot be used before this has been done.


-24983: ERR_BANOVALIDTYPE - invalid backup type (MaxDB: Messages)

-24983: ERR_BANOVALIDTYPE - invalid backup type

Explanation:

The backup type specified is invalid.

User Action:

Specify a valid backup type in your DBM command.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24984: ERR_MENOVALID - invalid medium definition (MaxDB: Messages)

-24984: ERR_MENOVALID - invalid medium definition

Explanation:

The definition of the backup medium is invalid.

User Action:

Check the parameters you have entered.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24985: ERR_MENOTFOUND - medium not found (MaxDB: Messages)

-24985: ERR_MENOTFOUND - medium not found

Explanation:

The backup medium you have specified has not been defined.

User Action:

Check your entries. Use another backup medium or create a new one with that name.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24986: ERR_NOMEDIA - media file not found (MaxDB: Messages)

-24986: ERR_NOMEDIA - media file not found

Explanation:

No backup medium has been defined yet for the database instance.

User Action:

Create backup media before using functions that require a backup media definition.

Check that the DBM server can access its configuration files. It may be that the DBM server has the wrong user authorizations.


-24987: ERR_TOSMALL - packet size too small for answer (MaxDB: Messages)

-24987: ERR_TOSMALL - packet size too small for answer

Explanation:

The client application has provided too little memory space for the DBM server’s response.

User Action:

Change your DBM command so that the response is smaller.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24988: ERR_SQL - sql error (MaxDB: Messages)

-24988: ERR_SQL - sql error

Explanation:

An error occurred when an SQL statement was transferred to the database kernel.

User Action:

If necessary, consult the other database-kernel error message and correct your entries accordingly.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24989: ERR_NOHISTORYSESSION - no backup history session availab (MaxDB: Messages)

-24989: ERR_NOHISTORYSESSION - no backup history session available

Explanation:

The DBM server command is only possible if the backup history is open.

User Action:

First, open the backup history using this statement backup_history_open. Watch for any errors that might occur.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24990: ERR_ NOBACKUPSESSION - no backup session available (MaxDB: Messages)

-24990: ERR_ NOBACKUPSESSION - no backup session available

Explanation:

The DBM command is only permitted if the save or restore is active.

User Action:

First of all, start the backup session you require using the DBM commands backup_start or recover_start and execute further statements depending on how the save/restore runs.

Check whether the save/restore started properly.

Note that importing a database backup will override the current status of your database instance.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24991: ERR_ NOSQLUSERSESSION - no sql user session available (MaxDB: Messages)

-24991: ERR_ NOSQLUSERSESSION - no sql user session available

Explanation:

A session with a user task is required for your DBM command.

User Action:

Start the session with the DBM command sql_connect or with the Database Manager CLI option –uSQL.

Check whether a previous attempt to set up the session failed and read the error message issued for it.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24992: ERR_NOUTILSESSION - no utility session available (MaxDB: Messages)

-24992: ERR_NOUTILSESSION - no utility session available

Explanation:

A session with the utility task is required for your DBM command.

User Action:

Start the session with the DBM command util_connect or with the Database Manager CLI option –uUTL.

Check whether a previous attempt to set up the session failed and read the error message issued for it.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24993: ERR_RTEEXT - runtime environment error (MaxDB: Messages)

-24993: ERR_RTEEXT - runtime environment error

Explanation:

The database runtime environment was unable to perform a function correctly.

User Action:

Please read the additional runtime environment error message.


-24994: ERR_RTE - runtime environment error (MaxDB: Messages)

-24994: ERR_RTE - runtime environment error

Explanation:

The database runtime environment was unable to perform a function correctly.

User action:

Please read the additional runtime environment error message.


-24995: ERR_MEM - memory allocation error (MaxDB: Messages)

-24995: ERR_MEM - memory allocation error

Explanation:

The operating system was unable to provide the DBM server with enough main memory.

User Action:

Correct the limit on the DBM server’s user authorizations if one exists.

Check the overall condition of your operating system for any problems with main memory management.


-24996: ERR_PARAM - wrong parameters (MaxDB: Messages)

-24996: ERR_PARAM - wrong parameters

Explanation:

Your DBM command has been executed with incorrect parameters.

User Action:

Check your entries. You should also check whether or not the command requires a database name or a special type of session.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24997: ERR_FILE - file handling error (MaxDB: Messages)

-24997: ERR_FILE - file handling error

Explanation:

A file was not accessed properly.

User Action:

This might happen because you do not have the user authorizations required. Check the DBM server installation and its current authorizations.

You should also check whether the file is damaged.


-24998: ERR_NOTIMPL - sorry, command not yet implemented (MaxDB: Messages)

-24998: ERR_NOTIMPL - sorry, command not yet implemented

Explanation:

Your DBM command is not available in this version.

User Action:

Choose a different command.

If the error occurs in the Database Manager GUI and there is no way in which you can correct it, contact Support.


-24999: ERR - common error (MaxDB: Messages)

-24999: ERR - common error

Explanation:

An error has occurred that the Database Manager cannot analyze properly.

User Action:

Please contact Support.


From -25000 to -25999 (MaxDB: Messages)

From -25000 to -25999

SAP DB Loader error messages:

-25003 | Name of database host could not be determined
-25004 | Error when connecting to the database
-25005 | Error when logging user on to the database
-25006 | Error occurred when connecting to the database with specified userkey
-25007 | Error when executing the command; no connection to the database exists
-25008 | Error when logging on user; previous user's database connection has been restored
-25009 | Failure in db communication
-25010 | <SQL error text>
-25011 | Error when executing the internal SQL command
-25018 | Error when changing the authorizations for the log file; unable to change the file owner
-25019 | Error when opening the log file; temporary log file opened
-25020 | Memory space exhausted
-25021 | Error during user changeover
-25022 | Request to terminate operation received; processing of command terminated
-25109 | <command> not implemented
-25201 | Invalid length specification for INTEGER field
-25202 | Invalid length specification for REAL field
-25203 | Invalid length specification for DECIMAL field
-25204 | Invalid length specification for ZONED field
-25205 | Invalid specification for USAGE
-25206 | Invalid specification in lines for USAGE
-25207 | Number of lines specified for USAGE is too high
-25208 | Invalid position specification; specify a positive value
-25209 | Invalid value for FRACTION; specify a positive value
-25210 | Invalid value for SCALE; enter a value between -127 and 127
-25211 | Invalid ROUND specification; specify a value between 0 and 18
-25212 | Invalid TRUNC specification; enter a value between 0 and 18
-25213 | Invalid file format specification; FORMATTED and COMPRESSED exclude each other
-25214 | Invalid file format specification; Separator/Delimiter is not allowed together with FORMATTED
-25216 | File format specification FORMATTED required
-25218 | Invalid file format specification; no columns specified despite FORMATTED file format
-25219 | Columns must be specified in the command in ascending order according to their position
-25220 | Invalid separator/delimiter specification
-25221 | Invalid specification for representation of decimal numbers
-25222 | Invalid specification for representation of Boolean values
-25223 | Invalid specification for representation of NULL values
-25224 | Invalid specification for language of messages; specify ENG or DEU
-25225 | Invalid specification for the representation of thousand separator and decimal point in numerical values
-25226 | Maximum number of column specifications in a command has been exceeded
-25227 | Maximum number of conditions in a command has been exceeded
-25228 | Invalid specification for external representation of date or time values
-25229 | Incorrect comparison operator in condition
-25230 | Error in DATAEXTRACT command; specification for command file is missing
-25231 | Specification of ROUND, TRUNC, or SCALE not allowed for this column
-25232 | Unknown keyword
-25233 | Error in column description; file format is COMPRESSED, but some descriptions contain end positions
-25234 | Error in column description; file format is FORMATTED, but some descriptions do not contain end positions
-25235 | Error in column description; identical positions for different columns
-25236 | Error in column description; column positions overlap
-25237 | Error when executing the command; the columns that are to be updated are missing from the command
-25238 | Error when executing the command; the command does not contain any column specifications
-25239 | The value specified is not a integer number
-25281 | Syntax error at a certain position
-25301 | Invalid entry in Date or Time column
-25302 | The value entered is not a valid numerical value
-25303 | The values entered are not in the correct order
-25304 | Key field entries are missing
-25305 | The entries in the key fields are too long
-25306 | The value you have entered is not valid for hexadecimal display
-25308 | CONSTRAINT condition violated
-25309 | The value you entered was not recognized as a BOOLEAN entry
-25310 | Column does not permit NULL values
-25311 | Data missing for NOT NULL column
-25313 | Numerical value truncated
-25314 | Too few decimal places defined for column
-25315 | The data type of the column and the external data type are not compatible
-25316 | The FASTLOAD command cannot be executed; the table contains at least one column of data type LONG
-25317 | Entry for column is not compatible with the data type or the column length
-25318 | The generated system key has exceeded the maximum possible value
-25319 | Unable to find any data for the column in the data file
-25320 | The LONG value could not be loaded into column
-25321 | Error in the command; the constant you have entered is not a valid number
-25322 | Error in the command; the constant you entered was truncated during conversion
-25323 | Error in command; the data type of the constant in the column’s NULL condition is not compatible with the external column data type
-25324 | Error in the length specifications of the column descriptions; see log file for more detailed information
-25325 | Error in command; the external and internal data types are not compatible. For more detailed information, please consult the log file
-25326 | Error when executing the extract command; the number extracted was truncated during conversion
-25327 | Error when extracting data record
-25328 | Error when executing the DATAEXTRACT command; the server’s log file contains more detailed information
-25329 | Error when executing the TABLELOAD command; the data file is corrupt or was not created using TABLEEXTRACT
-25330 | Error when executing the TABLELOAD command; the page sizes of the source and target file are different
-25331 | This is a restricted statement, user must be SYSDBA
-25332 | Unable to extract table definition
-25333 | Unable to extract index definition
-25334 | The file counter exceeds the maximum of 9999 files
-25335 | Error when restoring the table; the data file specified was created with TABLEEXTRACT USER/ALL
-25336 | Error when restoring tables; the data file specified was created using TABLEEXTRACT TABLE
-25337 | Error when restoring table; the data file contains no data for the specified table
-25338 | Error when restarting the command; entry in assignment file not found
-25339 | Error when restarting the TABLELOAD command; unable to open restart
-25340 | UCS2 conversion error; character string contains invalid characters or character sequences
-25341 | Error when generating the CREATE TABLE/CREATE INDEX statement
-25342 | Error when restoring table <table name>; the structures of the source and target tables are different
-25343 | Error in command; the SELECT statement in the command does not contain the column name
-25344 | Error in command for downloading data; the output length specified is too small for the column. Minimum output length is:
-25351 | Error in command; the LONGFILE specification for the column is missing from the command
-25352 | Error when downloading data; several errors occurred when analyzing the LONGFILE specification in the command. For more information, please consult the log file
-25353 | Error when downloading data; the maximum number of LONG data files for the column has been exceeded
-25354 | Error in the command for uploading data; the LONG data file specification is missing
-25501 | Error when opening file
-25502 | Error when closing file
-25503 | Error when reading file
-25504 | Error when writing file
-25505 | Error when erasing file
-25507 | Error when shrinking file
-25801 | Internal program error


-25003: Name of database host could not be determined (MaxDB: Messages)

-25003: Name of database host could not be determined

Explanation:

In the command for creating a connection, no database host is specified. The database host could not be determined.

User Action:

In the command for setting up a connection from the database instance to the Loader, enter the name of the host on which the database instance is running. Restart the Loader.


-25004: Error when connecting to the database (MaxDB: Messages)

-25004: Error when connecting to the database

Explanation:

The system cannot open a connection to the database instance.

User Action:

Use the SQL error text to determine why the connection failed. Fix the cause of the problem, and restart the Loader.


-25005: Error when logging user on to the database (MaxDB: Messages)

-25005: Error when logging user on to the database

Explanation:

The user specified could not be logged on to the database instance.

User Action:

Use the SQL error text to determine why the log on attempt failed. Fix the cause or the error and restart the Loader.


-25006: Error occurred when connecting to the database with spec (MaxDB: Messages)

-25006: Error occurred when connecting to the database with specified user key

Explanation:

The system cannot create a connection to the database instance using the specified user data.

User Action:

Use the SQL error text to determine why the connection failed. Fix the cause or the error and restart the Loader.


-25007: Error when executing the command; no connection to the d (MaxDB: Messages)

-25007: Error when executing the command; no connection to the database exists

Explanation:

During the execution of a load or unload command, or an SQL statement, the system determined that there is no connection to the database instance. This may be because you are not logged on to the correct database instance.

User Action:

Before you execute the command or the SQL statement, log on to the database instance using the USE USER command.


-25008: Error when logging on user; previous user's database con (MaxDB: Messages)

-25008: Error when logging on user; previous user's database connection has been restored

Explanation:

An error occurred when a user attempted to log on to the database instance. The last user to have logged on has been logged on again instead.

This error message only appears if a new user is unable log on to a database instance where another user who is processing load and unload commands is already logged on. This message precedes the error message –25005.

User Action:

Since this message merely informs you that a previous connection has been restored, please proceed as described in message -25005.


-25009: Failure in db communication (MaxDB: Messages)

-25009: Failure in db communication

Explanation:

Communication between the Loader and the database instance takes place via the synchronous exchange of communication packages. The Loader sends a package containing the command that is to be processed to the database instance. This is known as a "request". While the database instance processes the command, the Loader waits for the package to be returned with the result. This is known as a "receive".

Errors may occur during this process if the connection from the Loader to the database instance is lost or if the database instance is no longer available.

User Action:

Use the error text to determine why the communication failed. Fix the cause or the error and restart the Loader.


-25010: <SQL_error_text> (MaxDB: Messages)

-25010: <SQL_error_text>

Explanation:

The database instance reports SQL errors that occur while a user's SQL statements are being processed with this error number.

User Action:

Fix the cause of the error and restart the Loader.


-25011: Error when executing the internal SQL command (MaxDB: Messages)

-25011: Error when executing the internal SQL command

Explanation:

An SQL statement generated internally by the Loader to process a load or unload command could not be executed. This message also displays the cause of the error.

User Action:

Fix the cause of the error and restart the Loader.


-25018: Error when changing the authorizations for the log file; (MaxDB: Messages)

-25018: Error when changing the authorizations for the log file; unable to change the file owner

Explanation:

This error can only occur when you execute the SET LOGOWNER <user_name> command on UNIX or Linux operating systems.

User Action:

Use the error text to determine why the modification failed. Rectify the error and re-execute the statement.


-25019: Error when opening the log file; temporary log file open (MaxDB: Messages)

-25019: Error when opening the log file; temporary log file opened

Explanation:

Attempts to open the Loader's log file failed. This may have been caused by another Loader already running on the same computer. If more than one Loader is started on one computer at the same time, only one can access the log file at a time because log files can only be opened exclusively.

So the Loader can still process the statements, it opens a temporary log file, the name of which is stated in the message.

User Action:

No user action is required.


-25020: Memory space exhausted (MaxDB: Messages)

-25020: Memory space exhausted

Explanation:

A command or a statement cannot be executed because of limited memory space.

User Action:

No user action possible.


-25021: Error during user changeover (MaxDB: Messages)

-25021: Error during user changeover

Explanation:

An error has occurred when loading or unloading data using the commands TABLEEXTRACT ALL and TABLELOAD ALL.

To load or unload data using the statement above, the Loader must switch the user internally so it can process user-specific data. This internal changeover failed.

User Action:

Rectify the cause of the error and re-execute the command.


-25022: Request to terminate operation received; processing of c (MaxDB: Messages)

-25022: Request to terminate operation received; processing of command terminated

Explanation:

Using Ctrl C, the user has sent a request to the Loader to cancel the processing of commands and statements.

User Action:

No user action is required.


-25109: <command> not implemented (MaxDB: Messages)

-25109: <command> not implemented

Explanation:

The specified statement could not be executed because the required functions have not been installed on the Loader.

User Action:

No user action is possible.


-25201: Invalid length specification for INTEGER field (MaxDB: Messages)

-25201: Invalid length specification for INTEGER field

Explanation:

The command to load or unload data contains an error.

An explicit column description contains a file field of type INTEGER whose length does not correspond to the length mentioned here.

User Action:

Correct the data and re-execute the command.


-25202: Invalid length specification for REAL field (MaxDB: Messages)

-25202: Invalid length specification for REAL field

Explanation:

The command to load or unload data contains an error.

A file field of type REAL is specified in an explicit column description. However, the length of the field does not match the length specified in the error message.

User Action:

Correct the file information and re-execute the command.


-25203: Invalid length specification for DECIMAL field (MaxDB: Messages)

-25203: Invalid length specification for DECIMAL field

Explanation:

The command to load or unload data contains an error.

A file field of type DECIMAL is specified in an explicit column description. However, the length of the field does not match the length specified in the error message.

User Action:

Correct your entries and re-execute the command.


-25204: Invalid length specification for ZONED field (MaxDB: Messages)

-25204: Invalid length specification for ZONED field

Explanation:

The command to load or unload data contains an error.

An explicit column description contains a file field of type ZONED whose length does not correspond to the length specified in the error message.

User Action:

Correct the file information and re-execute the command.


-25205: Invalid specification for USAGE (MaxDB: Messages)

-25205: Invalid specification for USAGE

Explanation:

An error has occurred in the FASTLOAD command.

The USAGE value specified in the command is not within the permitted number range, that is, between 50% and 100%.

User Action:

Correct the specified USAGE percentage and re-execute the command.


-25206: Invalid specification in lines for USAGE (MaxDB: Messages)

-25206: Invalid specification in lines for USAGE

Explanation:

An error has occurred in the FASTLOAD command.

The value that has been specified for USAGE (0 rows) is not valid.

User Action:

Correct the number of rows you specified for USAGE and re-execute the command.


-25207: Number of lines specified for USAGE is too high (MaxDB: Messages)

-25207: Number of lines specified for USAGE is too high

Explanation:

An error has occurred in the FASTLOAD command.

The row number specified for USAGE (rows per page of the database) is too large. The maximum number of lines allowed can be determined from the size of a database page and the size of a record in the table to be loaded.

User Action:

Correct your entries and re-execute the command.


-25208: Invalid position specification; specify a positive value (MaxDB: Messages)

-25208: Invalid position specification; specify a positive value

Explanation:

The command to load or unload data contains an error.

You cannot specify a negative value for a position.

User Action:

Correct the data and re-execute the command.


-25209: Invalid value for FRACTION; specify a positive value (MaxDB: Messages)

-25209: Invalid value for FRACTION; specify a positive value

Explanation:

The command to load or unload data contains an error.

The value entered for FRACTION cannot be a negative value.

User Action:

Correct the entry you made for FRACTION and re-execute the command.


-25210: Invalid value for SCALE; enter a value between -127 and (MaxDB: Messages)

-25210: Invalid value for SCALE; enter a value between -127 and 127

Explanation:

The command to load or unload data contains an error.

A number specified for SCALE must be between -127 and +127.

User Action:

Correct the entry you made for SCALE and re-execute the command.


-25211: Invalid ROUND specification; specify a value between 0 a (MaxDB: Messages)

-25211: Invalid ROUND specification; specify a value between 0 and 18

Explanation:

The command to load or unload data contains an error.

A number specified for ROUND must be between 0 and 18.

User Action:

Correct the number of rows you specified for ROUND and re-execute the command.


-25212: Invalid TRUNC specification; enter a value between 0 and (MaxDB: Messages)

-25212: Invalid TRUNC specification; enter a value between 0 and 18

Explanation:

The command to load or unload data contains an error.

A number specified for TRUNC must be between 0 and 18.

User Action:

Correct the number of rows you specified for TRUNC and re-execute the command.


-25213: Invalid file format specification; FORMATTED and COMPRES (MaxDB: Messages)

-25213: Invalid file format specification; FORMATTED and COMPRESSED exclude each other

Explanation:

The command to load or unload data contains an error.

You cannot enter both COMPRESSED and FORMATTED as the format of a data stream. These formats are mutually exclusive to one another.

User Action:

Correct the format and re-execute the command.


-25214: Invalid file format specification; Separator/Delimiter i (MaxDB: Messages)

-25214: Invalid file format specification; Separator/Delimiter is not allowed together with FORMATTED

Explanation:

The command to load or unload data contains an error.

When FORMATTED is specified as the format of a data stream in a command, you cannot also specify separators or delimiters in the statement.

User Action:

Correct the entries and re-execute the command.


-25216: File format specification FORMATTED required (MaxDB: Messages)

-25216: File format specification FORMATTED required

Explanation:

The command to load or unload data contains an error.

The formats INTEGER, REAL, DECIMAL, and ZONED for individual columns to be loaded or unloaded are only allowed if the data stream format is set to FORMATTED.

User Action:

Correct the format and re-execute the command.


-25218: Invalid file format specification; no columns specified (MaxDB: Messages)

-25218: Invalid file format specification; no columns specified despite FORMATTED file format

Explanation:

The command to load or unload data contains an error.

FORMATTED is specified as the data stream format in a command. However, no columns are specified. FORMATTED requires that every column to be loaded or unloaded be specified in the command.

User Action:

Correct the statement and re-execute it.


-25219: Columns must be specified in the command in ascending or (MaxDB: Messages)

-25219: Columns must be specified in the command in ascending order according to their position

Explanation:

Error in the command for loading data.

COMPRESSED was specified in the command as a data file format. If this is the case, the columns must be specified in the command in ascending order according to their position.

User Action:

Correct the entries and re-execute the command.


-25220: Invalid separator/delimiter specification (MaxDB: Messages)

-25220: Invalid separator/delimiter specification

Explanation:

The command to load or unload data contains an error.

Separators and delimiters must not contain more than one character.

User Action:

Correct the format and re-execute the command.


-25221: Invalid specification for representation of decimal numb (MaxDB: Messages)

-25221: Invalid specification for representation of decimal numbers

Explanation:

The command to load or unload data contains an error.

The data stream format specification in a command includes a character string to be used for decimal numbers to arrange thousands and separate whole numbers from decimal places. The syntax of the character string is incorrect.

User Action:

Correct the entries and re-execute the command.


-25222: Invalid specification for representation of Boolean valu (MaxDB: Messages)

-25222: Invalid specification for representation of Boolean values

Explanation:

The command to load or unload data contains an error.

The data stream format specification in a command includes a character string that specifies how BOOLEAN values loaded to or from the database instance are displayed. The syntax of the character string is incorrect.

User Action:

Correct the entries and re-execute the command.


-25223: Invalid specification for representation of NULL values (MaxDB: Messages)

-25223: Invalid specification for representation of NULL values

Explanation:

The command to load or unload data contains an error.

The specification of the character string with which NULL values are represented, or are to be represented, externally in a data stream does not have the correct syntax. Character strings representing NULL values can be a maximum of 20 characters long.

User Action:

Correct the file information and re-execute the command.


-25224: Invalid specification for language of messages; specify (MaxDB: Messages)

-25224: Invalid specification for language of messages; specify ENG or DEU

Explanation:

The command to load or unload data contains an error.

German (DEU) and English (ENG) are supported as languages for messages (error, status, and warning messages).

User Action:

Correct the file information and re-execute the command.


-25225: Invalid specification for the representation of thousand (MaxDB: Messages)

-25225: Invalid specification for the representation of thousand separator and decimal point in numerical values

Explanation:

The command to load or unload data contains an error.

The specification of the thousand separator and the decimal point to be used when loading or unloading numerical values from the Loader does not have the correct syntax.

User Action:

Correct the file information and re-execute the command.


-25226: Maximum number of column specifications in a command has (MaxDB: Messages)

-25226: Maximum number of column specifications in a command has been exceeded

Explanation:

The command to load or unload data contains an error.

In a command to load or unload data, you cannot specify more columns than the database instance allows per table. This value of 1024 columns was exceeded in the command to be executed.

User Action:

Correct the file information and re-execute the command.


-25227: Maximum number of conditions in a command has been excee (MaxDB: Messages)

-25227: Maximum number of conditions in a command has been exceeded

Explanation:

The command to load or unload data contains an error.

In a command to load or unload data, you cannot specify more than 254 conditions in total for all columns. This value was exceeded in the command to be executed.

User Action:

Correct the file information and re-execute the command.


-25228: Invalid specification for external representation of dat (MaxDB: Messages)

-25228: Invalid specification for external representation of date or time values

Explanation:

The command to load or unload data contains an error.

The specification for the representation of date or time values (specified template) is invalid.

User Action:

Correct the entry as specified in date_spec or time_spec and re-execute the command.


-25229: Incorrect comparison operator in condition (MaxDB: Messages)

-25229: Incorrect comparison operator in condition

Explanation:

The command to load or unload data contains an error.

The relational operator specified in the condition is not supported. Possible relational operators are specified in syntax rule compare_operator.

User Action:

Correct the file information and re-execute the command.


-25230: Error in DATAEXTRACT command; specification for command (MaxDB: Messages)

-25230: Error in DATAEXTRACT command; specification for command file is missing

Explanation:

Error when unloading data using the DATAEXTRACT command.

The command DATAEXTRACT FOR DATALOAD/FASTLOAD/DATAUPDATE must contain specifications for at least 2 output data streams – one data stream for data and one for the commands to be created. The second of these data streams is missing in the command.

User Action:

Correct the file information and re-execute the command.


-25231: Specification of ROUND, TRUNC, or SCALE not allowed for (MaxDB: Messages)

-25231: Specification of ROUND, TRUNC, or SCALE not allowed for this column

Explanation:

Error when loading or unloading data.

The ROUND, TRUNC, or SCALE specification is only possible for numerical table columns, that is, for table columns of type INTEGER, SMALLINT, FLOAT, or FIXED.

User Action:

Correct the file information and re-execute the command.


-25232: Unknown keyword (MaxDB: Messages)

-25232: Unknown keyword

Explanation:

The command to load or unload data contains an error.

The entered command contains an unknown keyword.

User Action:

Correct the statement and re-execute it.


-25233: Error in column description; file format is COMPRESSED, (MaxDB: Messages)

-25233: Error in column description; file format is COMPRESSED, but some descriptions contain end positions

Explanation:

An error has occurred in the command for loading (DATALOAD or FASTLOAD) or updating data (DATAUPDATE).

The file format for data streams is specified in the command as COMPRESSED. With this format, the positions in the column descriptions specify the number of the current field to be loaded in a data line of the data stream. End positions are not allowed in this format.

User Action:

Correct the positions you entered and re-execute the command.


-25234: Error in column description; file format is FORMATTED, b (MaxDB: Messages)

-25234: Error in column description; file format is FORMATTED, but some descriptions do not contain end positions

Explanation:

An error has occurred in the command for loading (DATALOAD or FASTLOAD) or updating data (DATAUPDATE).

The format for data streams is specified in the command as FORMATTED. With this format, position specifications in the form start position ‑ end position are required.

User Action:

Correct the positions you entered and re-execute the command.


-25235: Error in column description; identical positions for dif (MaxDB: Messages)

-25235: Error in column description; identical positions for different columns

Explanation:

Error when unloading data using the DATAEXTRACT command.

The format for data streams is specified in the command as COMPRESSED. All values to be unloaded must be specified using different position specifications. Otherwise, unloaded values will be overwritten.

User Action:

Correct the data and re-execute the command.


-25236: Error in column description; column positions overlap (MaxDB: Messages)

-25236: Error in column description; column positions overlap

Explanation:

Error when unloading data using the DATAEXTRACT command.

The format for data streams is specified in the command as FORMATTED. You must specify all the values to be unloaded using non-overlapping column position references in the command. Otherwise, any values that have already been unloaded will be overwritten.

User Action:

Correct the data and re-execute the command.


-25237: Error when executing the command; the columns that are t (MaxDB: Messages)

-25237: Error when executing the command; the columns that are to be updated are missing from the command

Explanation:

Error when updating data using the DATAUPDATE command.

The specifications required to execute the column update are missing from the command. The column specification must begin with the keyword SET.

User Action:

Correct the statement and re-execute it.


-25238: Error when executing the command; the command does not c (MaxDB: Messages)

-25238: Error when executing the command; the command does not contain any column specifications

Explanation:

Error when updating data using the DATAUPDATE command.

The column specifications required to execute the command are missing. The values specified in the columns represent the row in the target table that should be updated.

User Action:

Correct the statement and re-execute it.


-25239: The value specified is not a integer number (MaxDB: Messages)

-25239: The value specified is not a integer number

Explanation:

An error has occurred in the command for loading (DATALOAD or FASTLOAD) or updating data (DATAUPDATE).

The value specified in a command is not recognized as an integer (the range of values for integers is 0 <= 2147483647).

User Action:

Correct the statement and re-execute it.


-25281: Syntax error at a certain position (MaxDB: Messages)

-25281: Syntax error at a certain position

Explanation:

The Loader discovered a syntax error in the command when it was parsed.

User Action:

Correct the statement and re-execute it.


-25301: Invalid entry in Date or Time column (MaxDB: Messages)

-25301: Invalid entry in Date or Time column

Explanation:

An error has occurred in the command for loading ( DATALOAD or FASTLOAD) or updating data ( DATAUPDATE).

When you enter values in columns of data type DATE or TIME, there are various formats you can use: INTERNAL, EUR, ISO, USA, JIS. The Loader converts these values into the internal database format for each data type.

This error occurs if a value that you have specified is supposed to be inserted into a column of data type DATE or TIME but it cannot be converted into the correct internal database format.

User Action:

Correct the values and re-execute the command.


-25302: The value entered is not a valid numerical value (MaxDB: Messages)

-25302: The value entered is not a valid numerical value

Explanation:

The command to load or unload data contains an error.

This error can have several causes depending on the context in which it occurs.

A value that is to be loaded into a column with a numerical data type (INTEGER, FIXED (n, m), ...) cannot be converted into the internal format. The value is either too high or is not recognized as a number.

A value that is to be unloaded from a column with a numerical data type (INTEGER, FIXED (n, m), ...) cannot be converted into the external display format. The value is either too high or the data types are not compatible (for example, if you try to extract a value from a column of data type FLOAT and to display it externally as data type INTEGER BINARY).

Commands for loading or unloading data contain certain conditions, for example, for loading or unloading NULL values. If you have defined conditions for columns with a numerical data type, the values in these conditions must be recognized as a numerical value.

User Action:

Correct the values and re-execute the command.


-25303: The values entered are not in the correct order (MaxDB: Messages)

-25303: The values entered are not in the correct order

Explanation:

Error when loading data using the FASTLOAD command.

All values that are to be loaded must be saved in key sequence in the data stream. The order is disrupted either by the data record in the row (format of the data stream: COMPRESSED or FORMATTED without binary data) or the position specified (format of the data stream: FORMATTED with binary data).

User Action:

Correct the data and re-execute the command.


-25304: Key field entries are missing (MaxDB: Messages)

-25304: Key field entries are missing

Explanation:

Error when loading data using the FASTLOAD command.

No entries were made in one or more of the key fields of a table that is to be loaded. The data record affected is specified in the next message.

User Action:

Correct the data and re-execute the command.


-25305: The entries in the key fields are too long (MaxDB: Messages)

-25305: The entries in the key fields are too long

Explanation:

Error when loading data using the FASTLOAD command.

User Action:

Correct the data and re-execute the command.


-25306: The value you have entered is not valid for hexadecimal (MaxDB: Messages)

-25306: The value you have entered is not valid for hexadecimal display

Explanation:

An error has occurred in the command for loading ( DATALOAD or FASTLOAD) or updating data ( DATAUPDATE).

You have specified in the command that the values to be loaded in plain text are available in hexadecimal coding for one or more columns.

The values you have entered are not valid for hexadecimal display.

User Action:

Correct the values and re-execute the command.


-25308: CONSTRAINT condition violated (MaxDB: Messages)

-25308: CONSTRAINT condition violated

Explanation:

Error when loading data using the FASTLOAD command.

The data record specified does not meet the requirements defined in the CONSTRAINT condition for this table.

User Action:

Correct the data and re-execute the command.


-25309: The value you entered was not recognized as a BOOLEAN en (MaxDB: Messages)

-25309: The value you entered was not recognized as a BOOLEAN entry

Explanation:

An error has occurred in the command for loading ( DATALOAD or FASTLOAD) or updating data ( DATAUPDATE).

You can define how BOOLEAN values are displayed externally either in each individual command or in a command file for all commands.

The value to be loaded is not compatible with this display type.

User Action:

Correct the data and re-execute the command.


-25310: Column does not permit NULL values (MaxDB: Messages)

-25310: Column does not permit NULL values

Explanation:

An error has occurred in the command for loading ( DATALOAD or FASTLOAD) or updating data ( DATAUPDATE).

You cannot load NULL values into columns that have been defined as NOT NULL columns and that have no system default value.

User Action:

Correct the data and re-execute the command.


-25311: Data missing for NOT NULL column (MaxDB: Messages)

-25311: Data missing for NOT NULL column

Explanation:

Error when loading data using the FASTLOAD command.

This error occurs if no data is found in the data stream for a column that has been defined as NOT NULL and that has no system default value or if the column is not specified in the command.

User Action:

Correct the values or the command and re-execute the command.


-25313: Numerical value truncated (MaxDB: Messages)

-25313: Numerical value truncated

Explanation:

Error when unloading data using the DATAEXTRACT command.

A numerical value that is supposed to be unloaded and displayed in the format specified in the command cannot be unloaded. This error occurs if, for example, you try to unload the value 2147483647 from data type INTEGER into an external binary INTEGER value that is only 2 bytes long.

In this case, you will only see an error message, and instead of numerical data, the data stream will only contain the same number of asterisks (*). This error does not interrupt the data unload.

User Action:

Check the data once it has been unloaded.


-25314: Too few decimal places defined for column (MaxDB: Messages)

-25314: Too few decimal places defined for column

Explanation:

Error when unloading data using the DATAEXTRACT command.

The format you have defined for the external display of the specified column’s values (DECIMAL or ZONED format) contains too few decimal places. The number required is determined by the column definition in the database instance and/or the operations that are performed on the column values when they are unloaded.

User Action:

Correct the specifications you made for the external display of this column and re-execute the command.


-25315: The data type of the column and the external data type a (MaxDB: Messages)

-25315: The data type of the column and the external data type are not compatible

Explanation:

Error when unloading data using the DATAEXTRACT command.

User Action:

Select another external data type and re-execute the command.


-25316: The FASTLOAD command cannot be executed; the table conta (MaxDB: Messages)

-25316: The FASTLOAD command cannot be executed; the table contains at least one column of data type LONG

Explanation:

Error when loading data using the FASTLOAD command.

The table that is supposed to be loaded must not contain any columns of data type LONG. This also applies even if the column affected does not need to be loaded, that is, even if the command does not list the column in the column description.

User Action:

Load the table with the DATALOAD command instead.


-25317: Entry for column is not compatible with the data type or (MaxDB: Messages)

-25317: Entry for column is not compatible with the data type or the column length

Explanation:

An error has occurred in the command for loading ( DATALOAD or FASTLOAD) or updating data ( DATAUPDATE).

The value you have entered cannot be loaded into the column because it is either too long or the external data type and the column data type are incompatible.

User Action:

Correct the data and re-execute the command.


-25318: The generated system key has exceeded the maximum possib (MaxDB: Messages)

-25318: The generated system key has exceeded the maximum possible value

Explanation:

Error when loading data using the FASTLOAD command.

Data is being loaded into a table containing no user-defined keys. If this is the case, the database generates its own internal key.

The key that is generated exceeds the maximum possible value. However, this error only occurs if the number of data records in the table exceeds 2E48.

User Action:

No user action is possible.


-25319: Unable to find any data for the column in the data file (MaxDB: Messages)

-25319: Unable to find any data for the column in the data file

Explanation:

An error has occurred in the command for loading data ( DATALOAD or FASTLOAD).

When you load data, you must specify data in the data stream for all columns included in the command. The only exceptions to this rule are columns that permit system default or NULL value.

The Loader was unable to find any data in the data stream for the column specified.

In addition to displaying this error message, the Loader also logs which row (text data stream) or which position in the data stream (binary data stream) the error occurred in.

User Action:

Check the data in the data stream and re-execute the command.


-25320: The LONG value could not be loaded into column (MaxDB: Messages)

-25320: The LONG value could not be loaded into column

Explanation:

An error has occurred while loading (DATALOAD) or updating data (DATAUPDATE).

An error occurred when loading a value into a column of data type LONG. The error message contains extra text outlining the cause of the failed load.

User Action:

Correct the cause of the error and re-execute the command.


-25321: Error in the command; the constant you have entered is n (MaxDB: Messages)

-25321: Error in the command; the constant you have entered is not a valid number

Explanation:

An error has occurred while loading (DATALOAD or FASTLOAD) or updating data (DATAUPDATE).

You can specify conditions for individual columns in your commands, which then govern how the values are loaded/updated. The system must be able to identify the constants in conditions for numerical columns as numbers.

If you see this error message, it means that the value you have entered as a constant is not recognized as a number.

User Action:

Correct the statement and re-execute it.


-25322: Error in the command; the constant you entered was trunc (MaxDB: Messages)

-25322: Error in the command; the constant you entered was truncated during conversion

Explanation:

An error has occurred while loading (DATALOAD or FASTLOAD) or updating data (DATAUPDATE).

You can specify conditions for individual columns in your commands, which then govern how the values are loaded/updated. The system must be able to identify the constants in conditions for numerical columns as numbers.

If you see this error message, it means that the value you have entered as a constant is recognized as a number. However, it was truncated by a few decimal places during conversion and therefore can no longer be used.

User Action:

Correct the statement and re-execute it.


-25323: Error in command; the data type of the constant in the c (MaxDB: Messages)

-25323: Error in command; the data type of the constant in the column’s NULL condition is not compatible with the external column data type

Explanation:

Error when unloading data using the DATAEXTRACT command.

You can specify a NULL value for individual columns in the command. This means that if a NULL value is extracted, the constant value you entered in the command is written in the data stream.

The data type of the constant value you specified and the external data type of the column to be extracted must be compatible. If you do not specify a data type in the command, the default data type CHAR is used.

User Action:

Correct the statement and re-execute it.


-25324: Error in the length specifications of the column descrip (MaxDB: Messages)

-25324: Error in the length specifications of the column descriptions; see log file for more detailed information

Explanation:

Error when unloading data using the DATAEXTRACT command.

You can specify in your command the length of the values in the data stream for individual columns. Some of the lengths you specify may be shorter than the column lengths defined in the database. If this is the case, these values may be extracted incorrectly.

This error message is only a summary of the error. The error messages –25203, -25204, and -25315 specify which column descriptions contain errors and are listed in the log file.

User Action:

Correct the statement and re-execute it.


-25325: Error in command; the external and internal data types a (MaxDB: Messages)

-25325: Error in command; the external and internal data types are not compatible. For more detailed information, please consult the log file

Explanation:

Error when unloading data using the DATAEXTRACT command.

You can specify in your command the length of the external data type in the data stream for individual columns.

This error message is only a summary of the error. The error messages -25315 and -25323 specify which column descriptions contain errors and they are only listed in the log file.

User Action:

Correct the statement and re-execute it.


-25326: Error when executing the extract command; the number ext (MaxDB: Messages)

-25326: Error when executing the extract command; the number extracted was truncated during conversion

Explanation:

Error when unloading data using the DATAEXTRACT command.

The number that was unloaded was truncated by a few decimal places when it was converted into an external data type.

This error does not cause the command to terminate.

User Action:

No user action required.


-25327: Error when extracting data record (MaxDB: Messages)

-25327: Error when extracting data record

Explanation:

Error when unloading data using the DATAEXTRACT command.

The data record included in the error message was unloaded incorrectly.

The position specified is only relevant for binary data streams because they state the exact position of the incorrect data record in the data stream. When dealing with text data streams, the position is always 1.

This error message was preceded by other error messages which describe in more detail the error and the incorrect values in the data record.

This error does not cause the command to terminate if it was executed with error tolerance greater than 1.

User Action:

Check the incorrect data records.

If the command terminates, correct the statement and re-execute it.


-25328: Error when executing the DATAEXTRACT command; the server (MaxDB: Messages)

-25328: Error when executing the DATAEXTRACT command; the server’s log file contains more detailed information

Explanation:

Error when unloading data using the DATAEXTRACT command.

Only the client (for example, LOADERCLI) displays this error message.

User Action:

Check the problems that have occurred using the entries in the server's log file.

Correct the statement if necessary and re-execute it.


-25329: Error when executing the TABLELOAD command; the data fil (MaxDB: Messages)

-25329: Error when executing the TABLELOAD command; the data file is corrupt or was not created using TABLEEXTRACT

Explanation:

Error when loading data using the TABLELOAD command.

The data streams for the TABLELOAD command must be binary files containing the database structures and special information for executing a subsequent TABLELOAD command. These data streams are created using the TABLEEXTRACT command and must not be modified in any way.

The data stream specified in the command was modified after TABLEEXTRACT was executed or it was not created using TABLEEXTRACT. The <cause of the error> section states which information in the data stream cannot be evaluated.

User Action:

Create the data stream using the TABLEEXTRACT command and re-execute the command.


-25330: Error when executing the TABLELOAD command; the page siz (MaxDB: Messages)

-25330: Error when executing the TABLELOAD command; the page sizes of the source and target file are different

Explanation:

Error when loading data using the TABLELOAD command.

The data generated with the TABLEEXTRACT command is a binary structure of the unloaded database instance. If you want to load the data back into another database instance, it must have the same page size as the source database instance.

This error occurs when the page size of the database instance from where the table(s) were unloaded is different to the page size of the target database instance.

User Action:

No user action is possible. The data can only be loaded into a database instance with the same page size as the source database instance.


-25331: This is a restricted statement, user must be SYSDBA (MaxDB: Messages)

-25331: This is a restricted statement, user must be SYSDBA

Explanation:

The commands TABLEEXTRACT ALL, TABLELOAD ALL, CATALOGEXTRACT ALL, and CATALOGLOAD ALL affect the whole database catalog and can therefore only be executed by a database system administrator.

User Action:

Call the Loader using the correct user ID or execute a USE-USER command with the correct user ID beforehand.


-25332: Unable to extract table definition (MaxDB: Messages)

-25332: Unable to extract table definition

Explanation:

Error when unloading data using the TABLEEXTRACT command.

When you execute a TABLEEXTRACT command, all table data as well as the table’s structure is unloaded for each table. This means that the unloaded table can be completely restored when you call the TABLELOAD command.

An error occurred when the table’s structure was unloaded. You can find the cause of the error in the SQL error text.

User Action:

Analyze the cause of the error and re-execute the command.


-25333: Unable to extract index definition (MaxDB: Messages)

-25333: Unable to extract index definition

Explanation:

Error when unloading data using the TABLEEXTRACT command.

When you execute a TABLEEXTRACT command, all table data as well as the table’s indexes are unloaded for each table. This means that the unloaded table can be completely restored when you call the TABLELOAD command.

An error occurred when the table’s index definitions were unloaded. You can find the cause of the error in the SQL error text.

User Action:

Analyze the cause of the error and re-execute the command.


-25334: The file counter exceeds the maximum of 9999 files (MaxDB: Messages)

-25334: The file counter exceeds the maximum of 9999 files

Explanation:

Error when unloading data using the TABLEEXTRACT command.

To ensure that data streams generated during a TABLEEXTRACT command do not exceed the default size, a series of data files will be automatically generated on the basis of the data stream name specified in the command.

The maximum number of files that can be generated is 9999.

User Action:

Correct the default size for one single data stream in the TABLEEXTRACT command and re-execute the command.


-25335: Error when restoring the table; the data file specified (MaxDB: Messages)

-25335: Error when restoring the table; the data file specified was created with TABLEEXTRACT USER/ALL

Explanation:

Error when loading data using the TABLELOAD TABLE command.

The data generated using the TABLEEXTRACT command was created with the option USER or ALL. The tables that were unloaded in this way can only be loaded with the TABLELOAD USER or the TABLELOAD ALL command. You cannot load one particular table using this data.

User Action:

If you want to load one particular table, you must unload it using the TABLEEXTRACT command.

If you want to load the entire data stream data, correct the command and re-execute it.


-25336: Error when restoring tables; the data file specified was (MaxDB: Messages)

-25336: Error when restoring tables; the data file specified was created using TABLEEXTRACT TABLE

Explanation:

Error when uploading data using the TABLELOAD ALL or the TABLELOAD USER command.

The data generated using the TABLEEXTRACT command was created with the option TABLE. If you use this command, only one table is unloaded. This can only be loaded using the relevant TABLELOAD TABLE command.

You cannot load more than one table using this data.

User Action:

If you want to load tables, first of all you must unload them using the correct TABLEEXTRACT command (use the option ALL or USER):

Use the option ALL or USER for more than one table

Use the option TABLE for a single table


-25337: Error when restoring table; the data file contains no da (MaxDB: Messages)

-25337: Error when restoring table; the data file contains no data for the specified table

Explanation:

Error when loading data using the TABLELOAD command.

The specified data stream does not contain any data with which to load the table. Before a table can be restored, it must be unloaded using the TABLEEXTRACT command.

User Action:

Unload the table before you restore it.


-25338: Error when restarting the command; entry in assignment f (MaxDB: Messages)

-25338: Error when restarting the command; entry in assignment file not found

Explanation:

Error when re-executing the TABLELOAD command for uploading data.

You can restart cancelled uploads using the TABLELOAD command. To enable you to do this, the Loader writes a restart file containing the name of the last table to be uploaded successfully when it executes the TABLELOAD command.

This error occurs if the Loader is unable to find the name of the table written to the restart file in the assignment file. One possible cause may be that the assignment file was modified after the upload was cancelled.

User Action:

If possible, restore the assignment file to its original state. If this is not possible, you need to load and unload all the data again to ensure your data is consistent.


-25339: Error when restarting the TABLELOAD command; unable to o (MaxDB: Messages)

-25339: Error when restarting the TABLELOAD command; unable to open restart

Explanation:

Error when re-executing the TABLELOAD command for uploading data.

The system was unable to open the restart file.

User Action:

Analyze and rectify the cause of the error. Execute the command again.


-25340: UCS2 conversion error; character string contains invalid (MaxDB: Messages)

-25340: UCS2 conversion error; character string contains invalid characters or character sequences

Explanation:

Error uploading or updating data using the DATALOAD-, FASTLOAD-, or DATAUPDATE command on a UNICODE database.

If data on a UNICODE database is uploaded into columns of a character-based data type (CHAR), the Loader converts it into a format the database recognizes (UCS2). In this case, an error has occurred during the conversion. The data that is to be uploaded contains characters that cannot be converted into UCS2.

User Action:

Correct the rejected data and re-execute the command.


-25341: Error when generating the CREATE TABLE/CREATE INDEX stat (MaxDB: Messages)

-25341: Error when generating the CREATE TABLE/CREATE INDEX statement

Explanation:

Error when unloading data using the DATAEXTRACT FOR DATALOAD command.

When you execute the DATAEXTRACT FOR DATALOAD command, data is unloaded and commands for creating tables (CREATE TABLE) and indexes (CREATE INDEX) are generated.

In this case, an error has occurred during the conversion. The error is described in more detail in the error message text specified in the error message.

User Action:

Rectify the cause of the error and re-execute the command.


-25342: Error when restoring table <table name>; the structures (MaxDB: Messages)

-25342: Error when restoring table <table name>; the structures of the source and target tables are different

Explanation:

Error when loading data using the TABLELOAD command.

The specified table already exists in the database instance. The Loader has established that the structures of the source and target table are different. This means that the data cannot be uploaded.

User Action:

Change the structure of the target table so that it matches that of the source table. Execute the command again.


-25343: Error in command; the SELECT statement in the command do (MaxDB: Messages)

-25343: Error in command; the SELECT statement in the command does not contain the column name

Explanation:

Error when unloading data using the DATAEXTRACT command.

The column names are present in the column list but are missing from the SELECT command. These will not be unloaded and therefore cannot be backed up in the data stream.

User Action:

If you want to unload these columns as well, you must include them in the SELECT statement. If you do not want to unload them, delete the column names from the column list.

Execute the command again.


-25344: Error in command for downloading data; the output length (MaxDB: Messages)

-25344: Error in command for downloading data; the output length specified is too small for the column. Minimum output length is:

Explanation:

Error when unloading data using the DATAEXTRACT command.

The length specified for output is too small and not all values that are possible based on the column definition in the database instance can be output.

User Action:

Correct the output length for the column specified and re-execute the command.


-25351: Error in command; the LONGFILE specification for the col (MaxDB: Messages)

-25351: Error in command; the LONGFILE specification for the column is missing from the command

Explanation:

Error when unloading data using the DATAEXTRACT command.

The column specified in the DATAEXTRACT command's SELECT statement is data type LONG. To unload it, you must include a longfile_spec in the command for this column.

User Action:

Correct the statement and re-execute it.


-25352: Error when downloading data; several errors occurred whe (MaxDB: Messages)

-25352: Error when downloading data; several errors occurred when analyzing the LONGFILE specification in the command. For more information, please consult the log file

Explanation:

Error when unloading data using the DATAEXTRACT command.

This error message is only a summary of the error. The error messages that preceded this message are listed in the log file.

User Action:

Check the error messages. Correct the command and re-execute it.


-25353: Error when downloading data; the maximum number of LONG (MaxDB: Messages)

-25353: Error when downloading data; the maximum number of LONG data files for the column has been exceeded

Explanation:

Error when unloading data using the DATAEXTRACT command.

You can set the longfile_spec in your command for columns of data type LONG so that each value that is unloaded is written to a single data stream. Placeholders (‘#’) in the data stream name determine the maximum number of files that can be generated. For example, <name>### would mean that up to 1000 data streams can be generated.

This error occurs if the table contains more data records than the number of data streams that can be generated.

User Action:

Correct the command and re-execute it.


-25354: Error in the command for uploading data; the LONG data f (MaxDB: Messages)

-25354: Error in the command for uploading data; the LONG data file specification is missing

Explanation:

This error occurs when uploading or updating data with the DATALOAD or DATAUPDATE command if all LONG values of a column that are to be inserted are in a LONG data stream.

The Loader did not find any position specifications for the values in the LONG data stream.

User Action:

Correct the data stream and re-execute the command.


-25501: Error when opening file (MaxDB: Messages)

-25501: Error when opening file

Explanation:

An operating system-dependent text appears in the operating system error message, indicating the error that occurred. Reasons for the error may be that there is no file of this name or that the specified disk is write-protected, etc.

User Action:

Specify a different filename or correct the error (at operating system level).


-25502: Error when closing file (MaxDB: Messages)

-25502: Error when closing file

Explanation:

An operating system-dependent text appears in the operating system error message, indicating the error that occurred.

User Action:

No user action is required.


-25503: Error when reading file (MaxDB: Messages)

-25503: Error when reading file

Explanation:

An operating system-dependent text appears in the operating system error message, indicating the error that occurred.

User Action:

Fix the cause of the error and restart the Loader to process the terminated command.


-25504: Error when writing file (MaxDB: Messages)

-25504: Error when writing file

Explanation:

An operating system-dependent text appears in the operating system error message, indicating the error that occurred.

User Action:

Fix the cause of the error and restart the Loader to process the terminated command.


-25505: Error when erasing file (MaxDB: Messages)

-25505: Error when erasing file

Explanation:

An operating system-dependent text appears in the operating system error message, indicating the error that occurred.

User Action:

No user action is required.


-25507: Error when shrinking file (MaxDB: Messages)

-25507: Error when shrinking file

Explanation:

An operating system-dependent text appears in the operating system error message, indicating the error that occurred. Reasons for the error may be that there is no file of this name or that the specified disk is write-protected, and so on.

User Action:

Specify a different filename or correct the error at operating system level.


-25801: Internal program error (MaxDB: Messages)

-25801: Internal program error

Explanation:

An internal program error has occurred.

User Action:

Notify Support organization and give them the details contained in the error message.


From -27000 to -28999 (MaxDB: Messages)

From -27000 to -28999

Error Messages of the liveCache

-27000 | Unknown error
-27003 | Numeric input parameter overflow
-27006 | Incompatible data types
-27009 | Command too long
-27014 | Connect not ok
-27015 | Connection down
-27016 | DB shut down
-27017 | Too many users
-27018 | Connection error
-27019 | Conversion of UNICODE to ASCII not possible
-28001 | Access via NIL OID
-28002 | Invalid OID
-28003 | Unknown GUID
-28005 | Duplicate object
-28006 | Object not locked
-28007 | OID not compatible with given class
-28501 | Error reading OMS input stream
-28502 | Error writing OMS output stream
-28503 | Crash in DB Procedure
-28505 | No component object found
-28508 | Unsupported parameter type
-28514 | Unknown OMS version
-28515 | OMS Version already open
-28516 | Commit or Rollback required
-28517 | Already in Critical Section
-28518 | Not in Critical Section
-28521 | Already in version
-28522 | Missing before image
-28523 | Unknown schema
-28524 | Duplicate schema
-28525 | Procedure Address not found
-28527 | Directory not found
-28529 | Too small name buffer
-28530 | omsTerminate called
-28531 | OMS read only
-28532 | Version bound by transaction
-28533 | Integer out of packed range
-28534 | Package must be recreated
-28600 | Invalid request code in package
-28601 | Object data packet for read missing
-28602 | Packet size does not match object size
-28603 | Requested packet size to transfer an object is too big
-28604 | Trying to queue too many data packets when sending object data
-28605 | Invalid operation in ProcServer-Kernel communication
-28606 | Communication error
-28607 | Missing object data packet
-28608 | Invalid reply for stored procedure
-28609 | Stored procedure not found
-28801 | Wrong class id
-28802 | Wrong object version
-28803 | Wrong object state
-28804 | Too old OID
-28806 | Nil page pointer
-28808 | Hash not found
-28810 | Duplicate hash key
-28813 | Unknown consistent version
-28814 | Object not found
-28815 | Object history not found
-28817 | Wrong object length
-28818 | Wrong object position
-28819 | Object has been updated by other transactions
-28823 | Page already in use
-28826 | Pagecounter inconsistent
-28828 | Inconsistent information concerning “is container dropped”
-28902 | Too many nested try/catch statements
-28903 | DBFunction $1 must return a value
-28822 to 28999 | Internal Error


-27000: Unknown error (MaxDB: Messages)

-27000: Unknown error

Explanation:

A system error has occurred.

User Action:

Contact Support.


-27003: Numeric input parameter overflow (MaxDB: Messages)

-27003: Numeric input parameter overflow

Explanation:

An overflow occurred in one of the following situations:

With an SQL read statement
When transferring a numerical value from the database instance to a host variable

or

With an SQL write statement
When transferring a host variable’s numerical value to the database instance

User Action:

Contact Support.


-27006: Incompatible data types (MaxDB: Messages)

-27006: Incompatible data types

Explanation:

One of the following situations occurred:

An SQL read statement attempted to read a value from the database instance to an incompatible host variable.

or

An SQL write statement attempted to write the value of an incompatible host variable to the database instance.

User Action:

Contact Support.


-27009: Command too long (MaxDB: Messages)

-27009: Command too long

Explanation:

An attempt was made to prepare or execute an SQL statement that is too long.

User Action:

Contact Support.


-27014: Connect not ok (MaxDB: Messages)

-27014: Connect not ok

Explanation:

An unspecified connection error occurred.

User Action:

Contact Support.


-27015: Connection down (MaxDB: Messages)

-27015: Connection down

Explanation:

The liveCache connection has been broken.

User Action:

Contact Support.


-27016: DB shut down (MaxDB: Messages)

-27016: DB shut down

Explanation:

An external SQL class attempted to set up a connection to a database instance in the OFFLINE operating status.

User Action:

Contact Support.


-27017: Too many volumes (MaxDB: Messages)

-27017: Too many volumes

Explanation:

The maximum possible number of database instance connections has been exceeded.

User Action:

Contact Support.


-27018: Connection error (MaxDB: Messages)

-27018: Connection error

Explanation:

An unspecified error occurred when an SQL statement was executed in liveCache.

User Action:

Contact Support.


-27019: Conversion UNICODE to ASCII not possible (MaxDB: Messages)

-27019: Conversion UNICODE to ASCII not possible

Explanation:

The database instance wants to read a UNICODE character string to an ASCII variable. However, at least one character is a UNICODE character, which cannot be converted to ASCII.

This error can only occur if Unicode columns in the liveCache have been filled by native SQL, or if both Unicode and ASCII applications are using the same liveCache instance.

User Action:

If you have used native SQL to modify Unicode columns in the liveCache, check whether these changes are ASCII-compatible.

If you have not made any changes using native SQL, contact your local support.


-28001: Access via NIL OID (MaxDB: Messages)

-28001: Access via NIL OID

Explanation:

An OMS operation was attempted, such as dereferencing ( omsDeref) when specifying the NIL Oid. This is not allowed.

User Action:

Contact Support.


-28002: Invalid OID (MaxDB: Messages)

-28002: Invalid OID

Explanation:

Invalid OID specified for an OMS operation.

This is the case if the page number or position part of the OID falls outside of the permitted limits.

User Action:

Contact Support.


-28003: Unknown GUID (MaxDB: Messages)

-28003: Unknown GUID

Explanation:

A non-registered class was addressed.

A persistent class must be registered with omsRegClass before it is accessed for the first time.

User Action:

Contact Support.


-28005: Duplicate object (MaxDB: Messages)

-28005: Duplicate object

Explanation:

An attempt was made to generate a copy of a variable object ( omsLoadVarObject), even though the caller already owns a copy.

This copy must first be released with omsReleaseVarObject.

User Action:

Contact Support.


-28006: Object not locked (MaxDB: Messages)

-28006: Object not locked

Explanation:

When it attempted to change or delete an instance of a persistent class, liveCache determined that the current transaction does not have a lock for this instance.

This is not allowed.

User Action:

Contact Support.


-28007: OID not compatible with given class (MaxDB: Messages)

-28007: OID not compatible with given class

Explanation:

An attempt was made to dereference an object whose OID does not match the specified class.

The types of the OID and object are not compatible.

User Action:

Contact Support.


-28501: Error reading OMS input stream (MaxDB: Messages)

-28501: Error reading OMS input stream

Explanation:

A read error occurred in an internal ABAP table or in a stream.

For more information, see the liveCache file knldiag.

User Action:

Contact Support.


-28502: Error writing OMS output stream (MaxDB: Messages)

-28502: Error writing OMS output stream

Explanation:

A write error occurred in an internal ABAP table or in a stream. For more information, see the liveCache file knldiag.

User Action:

Contact Support.


-28503: Crash in DB-Procedure (MaxDB: Messages)

-28503: Crash in DB-Procedure

Explanation:

When a [image] database procedure was called, a non-handled exception occurred in the method code of the corresponding component instance.

For more information, see the liveCache file knldiag.

User Action:

Contact Support.


-28505: No Component Object found (MaxDB: Messages)

-28505: No Component Object found

Explanation:

The OMS library could not be loaded when liveCache was started.

liveCache cannot run.

User Action:

Contact Support.


-28508: Unsupported parameter type (MaxDB: Messages)

-28508: Unsupported parameter type

Explanation:

liveCache cannot assign an SQL data type to a parameter in a method of a component class.

User Action:

Contact Support.


-28514: Unknown OMS Version (MaxDB: Messages)

-28514: Unknown OMS Version

Explanation:

When liveCache called omsOpenVersion, OmsCloseVersion, omsDropVersion or omsRenameVersion, it established that the specified [image] OMS version does not exist.

User Action:

Contact Support.


-28515: OMS Version already open (MaxDB: Messages)

-28515: OMS Version already open

Explanation:

When liveCache called omsOpenVersion, it established that the addressed [image] OMS version has already been opened by a competing task.

The OMS version cannot be opened until the task closes this version and ends the transaction.

User Action:

Contact Support.


-28516: Commit or Rollback required (MaxDB: Messages)

-28516: Commit or Rollback required

Explanation:

When liveCache called omsCreateVersion, omsOpenVersion or omsDropVersion, it established that changes have already been made to instances in persistent classes in the current transaction.

This is not allowed, since the current transaction must already have ended.

User Action:

Contact Support.


-28517: Already in Critical Section (MaxDB: Messages)

-28517: Already in Critical Section

Explanation:

The function omsEnter was called for an instance of OmsCriticalSection although this instance is already in the critical section.

This is not allowed.

User Action:

Contact Support.


-28518: Not in Critical Section (MaxDB: Messages)

-28518: Not in Critical Section

Explanation:

The function omsLeave was called for an instance of OmsCriticalSection although this instance is not in the critical section.

This is not allowed.

User Action:

Contact Support.


-28521: Already in version (MaxDB: Messages)

-28521: Already in version

Explanation:

When liveCache called the function omsOpenVersion, it established that the caller is already in an [image] OMS version.

This is not allowed.

User Action:

Contact Support.


-28522: Missing before image (MaxDB: Messages)

-28522: Missing before image

Explanation:

The function omsStore established that no before-image exists of the object that needs to be changed.

In this case, no ForUpd pointer is requested for the object.

No changes can be made to the object.

User Action:

Contact Support.


-28523: Unknown schema (MaxDB: Messages)

-28523: Unknown schema

Explanation:

An attempt was made to access a non-existent [image] liveCache schema.

This can occur when registering or deleting a container, or when resolving a liveCache schema.

User Action:

Contact Support.


-28524: Duplicate schema (MaxDB: Messages)

-28524: Duplicate schema

Explanation:

When liveCache called the function omsCreateSchema, it established that a [image] liveCache schema with the specified name already exists.

This is not allowed.

User Action:

Contact Support.


-28525: Procedure Address not found (MaxDB: Messages)

-28525: Procedure Address not found

Explanation:

The function specified when dbpGetProcAddress was called could not be localized.

User Action:

Contact Support.


-28527: Directory not found (MaxDB: Messages)

-28527: Directory not found

Explanation:

The path name could not be retrieved for dbpGetDbrootSapPath or dbpGetWorkingDirectory.

The buffer for the name is too small.

User Action:

Contact Support.


-28529: Too small name buffer (MaxDB: Messages)

-28529: Too small name buffer

Explanation:

The buffer for the return values is too small for omsGetLiveCacheVersion, omsGetLocalDateTime, omsGetLocalDateTime or omsGetSchemaName.

User Action:

Contact Support.


-28530: omsTerminate called (MaxDB: Messages)

-28530: omsTerminate called

Explanation:

The method omsTerminate was called.

This resolved all component instances in the relevant session, and reset the current transaction.

User Action:

Contact Support.


-28531: OMS read only (MaxDB: Messages)

-28531: OMS read only

Explanation:

An attempt was made to lock an object, although the calling session is in read-only mode. This is not allowed.

User Action:

Contact Support.


-28532: Version bound by transaction (MaxDB: Messages)

-28532: Version bound by transaction

Explanation:

When liveCache called omsOpenVersion, it established that the addressed [image] OMS version is already linked to a competing task, but has not been opened.

The version cannot be opened until the task has ended its transaction.

User Action:

Contact Support.


-28533: Integer out of packed range (MaxDB: Messages)

-28533: Integer out of packed range

Explanation:

An 8 byte integer value needs to be converted into a value with the type OmsTypePacked_8_3 that is outside the permitted range.

User Action:

Contact Support.


-28534: Package must be recreated (MaxDB: Messages)

-28534: Package must be recreated

Explanation:

The library assigned to the package was changed after the package was created.

User Action:

Delete the package and create it again.


-28600: Invalid request code in packet (MaxDB: Messages)

-28600: Invalid request code in packet

Explanation:

The packet contains invalid request code.

User Action:

Contact your local support.


-28601: Object data packet for read missing (MaxDB: Messages)

-28601: Object data packet for read missing

Explanation:

A data packet is missing because an end point has sent too few data packets.

This error only occurs if you are using socket communication. In shared memory communication, data is exchanged directly using shared memory. In contrast, in socket communication, data is sent in extra packets before the request packet and after the response package.

User Action:

Contact your local support.


-28602: Packet size does not match object size (MaxDB: Messages)

-28602: Packet size does not match object size

Explanation:

This error only occurs if you are using non-shared-memory communication.

The specified object size does not match the size of the received package.

User Action:

Contact your local support.


-28603: Requested packet size to transfer an object is too big (MaxDB: Messages)

-28603: Requested packet size to transfer an object is too big

Explanation:

The packet size allowed in the communication channel is too small to accept the object.

User Action:

Increase the packet size for the communication channel.


-28604: Trying to queue too many data packets when sending objec (MaxDB: Messages)

-28604: Trying to queue too many data packets when sending object data

Explanation:

The upper limit for the length of the wait queue for non-shared memory has been reached. This error often occurs in mass operations if there are too many objects in the wait queue.

User Action:

Change the code that controls the wait queue for packets, so that fewer packets end up in the queue. Mass operations are to send a maximum of 100 packets to the wait queue.


-28605: Invalid operation in ProcServer-Kernel communication (MaxDB: Messages)

-28605: Invalid operation in ProcServer-Kernel communication

Explanation:

You have tried to use a communication channel to send object data in shared memory communication. In shared memory communication, object data is always sent using addresses in the shared memory. It is not possible to send data via a communication channel.

User Action:

Contact your local support.


-28606: Communication error (MaxDB: Messages)

-28606: Communication error

Explanation:

This error only occurs if you are using socket communication.

An unexpected data packet has been received, or the size of the data packet does not match the object size specified in the request packet.

User Action:

Contact your local support.


-28607: Missing object data packet (MaxDB: Messages)

-28607: Missing object data packet

Explanation:

A data packet is missing because an end point has sent too few data packets.

This error only occurs if you are using socket communication. In shared memory communication, data is exchanged directly using shared memory. In contrast, in socket communication, data is sent in extra packets before the request packet and after the response package.

User Action:

Contact your local support.


-28608: Invalid reply for stored procedure (MaxDB: Messages)

-28608: Invalid reply for stored procedure

Explanation:

The response packet in kernel proc-server communication does not match the request.

User Action:

Contact your local support.


-28609: Stored procedure not found (MaxDB: Messages)

-28609: Stored procedure not found

Explanation:

The user has tried to call a saved procedure. However, this procedure could not be found in the assigned DB procedure.

User Action:

Check whether the procedure is the same as your DB procedure definition in the database catalog.


-28801: Wrong class id (MaxDB: Messages)

-28801: Wrong class id

Explanation:

An incorrect container ID was used to access an object.

This is an internal liveCache error that cannot be caused by incorrect handling of the OMS API.

User Action:

Contact Support.


-28802: Wrong object version (MaxDB: Messages)

-28802: Wrong object version

Explanation:

An attempt was made to lock a deleted or reused object.

This error is translated as and OmsOutOfDate Exception, but can be logged as an error in the knldiag file.

User Action:

Contact Support.


-28803: Wrong object version (MaxDB: Messages)

-28803: Wrong object version

Explanation:

An attempt was made to access a deleted object. This error is translated as and OmsOutOfDate Exception, but can be logged as an error in the knldiag file.

User Action:

Contact Support.


-28804: Too old OID (MaxDB: Messages)

-28804: Too old OID

Explanation:

When liveCache dereferenced an OID, it could not decide whether the OID ever existed.

See also error message –28815.

This error is translated as an OmsOutOfDate Exception.

User Action:

Contact Support.


-28806: Nil page pointer (MaxDB: Messages)

-28806: Nil page pointer

Explanation:

The container directory is inconsistent.

This is an internal liveCache error that cannot be caused by incorrect handling of the OMS API.

User Action:

Contact Support.


-28808: Hash not found (MaxDB: Messages)

-28808: Hash not found

Explanation:

A B* tree of a keyed object container could not be found.

This is an internal liveCache error that cannot be caused by incorrect handling of the OMS API.

User Action:

Contact Support.


-28810: Duplicate hash key (MaxDB: Messages)

-28810: Duplicate hash key

Explanation:

A duplicate entry was found in the global container directory.

This is an internal liveCache error that cannot be caused by incorrect handling of the OMS API.

User Action:

Contact Support.


-28813: Unknown consistent version (MaxDB: Messages)

-28813: Unknown consistent version

Explanation:

An attempt was made to access an object in a [image] view that liveCache no longer recognizes.

This is an internal liveCache error that cannot be caused by incorrect handling of the OMS API.

User Action:

Contact Support.


-28814: Object not found (MaxDB: Messages)

-28814: Object not found

Explanation:

A non-existent OID was dereferenced.

User Action:

Contact Support.


-28815: Object history not found (MaxDB: Messages)

-28815: Object history not found

Explanation:

When an object is dereferenced, the liveCache data area that contains the before-images of persistent objects must satisfy the [image] consistent view of the instance.

Before-images are sorted according to their age, from old to new.

Normally, only those before-images that are no longer accessed by a consistent view are deleted.

In exceptional cases, memory problems can cause before-images that could still be accessed to be deleted.

In these cases, liveCache can no longer retrieve the requested view of the instance.

The older the consistent view, the greater the likelihood of this phenomenon-

User Action:

Contact Support.


-28817: Wrong object length (MaxDB: Messages)

-28817: Wrong object length

Explanation:

An object does not fit in the memory.

This is an internal liveCache error that cannot be caused by incorrect handling of the OMS API.

User Action:

Contact Support.


-28818: Wrong object position (MaxDB: Messages)

-28818: Wrong object position

Explanation:

An OID contains an invalid position.

User Action:

Contact Support.


-28819: Object has been updated by other transactions (MaxDB: Messages)

-28819: Object has been updated by other transactions

Explanation:

An instance with the type OmsOutOfDate was captured as a DbpError.

User Action:

Contact Support.


-28823: Page already in use (MaxDB: Messages)

-28823: Page already in use

Explanation:

The database instance has tried to use a page that is already marked as in use.

User Action:

Inform your local support.


-28826: Pagecounter inconsistent (MaxDB: Messages)

-28826: Pagecounter inconsistent

Explanation:

The specifications for the page counter on the root page of the object container file and in the object file directory are not consistent.

This error can occur if CHECK DATA is executed.

User Action:

Inform your local support.


-28828: Inconsistent information concerning “is container droppe (MaxDB: Messages)

-28828: Inconsistent information concerning “is container dropped”

Explanation:

The specifications for “is container dropped” on the root page of the object container file and in the object file directory are not consistent.

This error can occur if CHECK DATA is executed.

User Action:

Inform your local support.


-28902: Too many nested try/catch statements (MaxDB: Messages)

-28902: Too many nested try/catch statements

Explanation:

A maximum of 16 nested TRY/CATCH blocks is permitted in a database procedure.

User Action:

Do not exceed the upper limit of 16 nested TRY/CATCH blocks when you code the database procedure.


-28903: DBFunction$1 must return a value (MaxDB: Messages)

-28903: DBFunction$1 must return a value

Explanation:

A database function does not contain a RETURN statement, which means that it cannot return a result. This is not allowed.

User Action:

Add a RETURN statement to the database function.


-28822 to -28999: Internal Error (MaxDB: Messages)

-28822 to -28999: Internal Error

Explanation:

Internal liveCache system errors.

User Action:

Contact Support.


From 0 to 1999 (MaxDB: Messages)

From 0 to 1999

Database Kernel System Messages

0 | Success
100 | Row not found
200 | Duplicate key
250 | Duplicate secondary key
300 | Integrity violation
320 | View violation
350 | Referential integrity violated
360 | Foreign key integrity violated
400 | Lock collision
500 | Lock request timeout
600 | Work rolled back
650 | Work rolled back
700 | Session inactivity timeout (work rolled back)
710 | Session terminated by shutdown (work rolled back)
750 | Too many SQL statements (work rolled back)
1403 | Row not found


0: Success (MaxDB: Messages)

0: Success

Explanation:

The SQL statement was successfully executed, with the required effect.

User Action:

No user action is required.


100: Row not found (MaxDB: Messages)

100: Row not found

Explanation:

There is no (further) table row which meets the criterion.

User Action:

No user action is required.


200: Duplicate key (MaxDB: Messages)

200: Duplicate key

Explanation:

There is already a table row with the key to be inserted.

User Action:

Check whether the existing table row contains the desired values. If this is not the case, check whether values in the existing table row can be replaced with the desired values. If a new table row must be inserted, change the value of the key to be inserted in the SQL statement in order to prevent key collisions.


250: Duplicate secondary key (MaxDB: Messages)

250: Duplicate secondary key

Explanation:

There is already a table row with the specified secondary key. UNIQUE was specified for the secondary key.

User Action:

To avoid a key value collision, correct the value of the key to be inserted in the SQL statement.

The error message specifies the column or multiple-column index already containing the specified values.


300: Integrity violation (MaxDB: Messages)

300: Integrity violation

Explanation:

Insertions or updates would violate integrity constraints specified in the definition of the base or the view table.

User Action:

The error message specifies the column which would violate the integrity constraints.

Correct the input value for the corresponding column.


320: View violation (MaxDB: Messages)

320: View violation

Explanation:

An INSERT or UPDATE statement was specified for a view table. At least one of the rows specified in the SQL statement does not satisfy the search conditions of all underlying view tables defined WITH CHECK OPTION.

User Action:

You can display the definition of the view table using a QUERY statement issued on the system table DOMAIN.VIEWDEFS. Change the INSERT or UPDATE statement according to this definition.


350: Referential integrity violated (MaxDB: Messages)

350: Referential integrity violated

Explanation:

The following causes are possible:

...

1. An INSERT or UPDATE statement issued on a table that is the referencing table in a referential CONSTRAINT definition produces a row that is not a matching row of the CONSTRAINT definition.

2. When deleting rows from a referenced table (referenced_table) of a referential CONSTRAINT definition with ON DELETE RESTRICT in the DELETE rule, a matching row exists.

3. When executing a referential CONSTRAINT definition, the referenced table or referencing table contains rows that conflict with the CONSTRAINT definition.

User Action:

...

1. Display the definition of the referential CONSTRAINT definition using a QUERY statement issued on the system table DOMAIN.FOREIGNKEYCOLUMNS. Change the INSERT or UPDATE statement according to this definition.

2. You can use an appropriate QUERY statement to find out which row of the referencing table prevents the desired referenced table rows from being deleted.

3. You can use an appropriate QUERY statement to find out which row of the referenced table or referencing table conflicts with the referential CONSTRAINT definition. Change or delete this, or correct the CONSTRAINT definition.


360: Foreign key integrity violated (MaxDB: Messages)

360: Foreign key integrity violated

Explanation:

Where there is an INSER or UPDATE statement for a join view table, the column values functionally depending on the referencing columns of the referencing table conflict with the existing column values.

User Action:

Resolve this conflict by changing the statement’s column values or changing the existing values.


400: Lock collision (MaxDB: Messages)

400: Lock collision

Explanation:

When the option (NOWAIT) is specified in the LOCK statement or in the LOCK option , this confirmation signals that the lock request conflicts with the locks of other users.

User Action:

1. In interactive mode, another job can be activated which does not require the desired lock.

2. As an alternative, you can wait for the lock to be released by specifying the same SQL statement without the '(NOWAIT)' option.


500: Lock request timeout (MaxDB: Messages)

500: Lock request timeout

Explanation:

1. The lock request or an implicit lock conflicts with the locks of another user. The maximum waiting time for being granted the lock has elapsed (database parameter REQUEST_TIMEOUT).

2. The database instance could not be stopped within a certain period of time because transactions with SQL statements for data modification are still open.

User Action:

3. In some cases, the error message contains a more detailed description of the error. The lock request can be reissued. To avoid possible deadlock situations, it is advisable to roll back the transaction with a ROLLBACK statement to avoid possible deadlock situations.

4. Use the QUICK option to omit stopping or forcing the database instance to shut down.


600: Work rolled back (MaxDB: Messages)

600: Work rolled back

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement because

1. You failed to carry out any ADABAS operations within a certain period of time (installation parameter LOCK_TIMEOUT) but held locks which other users were waiting for, or because

2. the database instance was in a deadlock situation. The database server was in a situation in which two or more users are holding locks and request further locks that are being held by other users. In the simplest case of two users, one user holds one lock at least and requests another lock. But this lock is held by another user who is himself waiting for the lock held by the first user. This situation can only be resolved if one of the users releases the lock already obtained.

User Action:

In some cases, the error message contains a more detailed description of the error.

In both cases, the lock requests must be checked and modified, if necessary. The last transaction must be repeated.


650: Work rolled back (MaxDB: Messages)

650: Work rolled back

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement because the log area is full.

User Action:

The error text contains a precise description of the error.

Save the log area (log backup).


700: Session inactivity timeout (work rolled back) (MaxDB: Messages)

700: Session inactivity timeout (work rolled back)

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. The database session was implicitly terminated because the user failed to carry out any operations during a certain period of time (database parameter SESSION_TIMEOUT or the timeout value specified in the CONNECT statement).

User Action:

Repeat the CONNECT statement; it may be necessary to specify a larger timeout value.

Check and, if necessary, change the value of the SESSION_TIMEOUT database parameter.


710:Session terminated by shutdown (work rolled back) (MaxDB: Messages)

710:Session terminated by shutdown (work rolled back)

Explanation:

The user’s transaction was implicitly cancelled and reset by a ROLLBACK statement. The database session was terminated because the Database Manager shut the database instance down. To speed up a later restart, the database system tries to reset and not just terminate open transactions within a short period.

User Action:

Once the database is ready, repeat the CONNECT statement and the transaction.


750: Too many SQL statements (work rolled back) (MaxDB: Messages)

750: Too many SQL statements (work rolled back)

Explanation:

The user’s transaction was cancelled implicitly and reset by a ROLLBACK statement. The database session was terminated, since you had issued too many SQL statements or had performed too many transactions within a session.

User Action:

After a new CONNECT statement the transaction may be repeated.


1403: Row not found (MaxDB: Messages)

1403: Row not found

Explanation:

There is no (other) table row that meets the specified criteria.

User Action:

No user action is required.


From 25000 to 25999 (MaxDB: Messages)

From 25000 to 25999

Loader system messages

25601 | Warning when downloading data; character string for the value NULL in the column will be truncated
25602 | Warning when downloading data; integer values of column may become to large for output
25603 | Warning when downloading data; literal will be truncated
25604 | Warning when downloading data; supernumerary specifications for the LONG data file will be ignored
25605 | Warning when downloading data; neither the header nor the record length was found in the data file or command. The <N> value that was calculated will be used as a record length
25606 | Warning when uploading data; different byte swap of source and target computer. Check LONG values
25607 | The USAGE value is too low and will be ignored
25608 | No restart file found. Upload will restart


25601: Warning when downloading data; character string for the v (MaxDB: Messages)

25601: Warning when downloading data; character string for the value NULL in the column will be truncated

Explanation:

Warning when unloading data using the DATAEXTRACT command.

The character string for the NULL value is longer than the output length that has been defined for a column. The character string has only been partially output.

This warning does not cause the command to terminate.

User Action:

No user action is required.


25602: Warning when downloading data; integer values of column m (MaxDB: Messages)

25602: Warning when downloading data; integer values of column may become to large for output

Explanation:

Warning when unloading data using the DATAEXTRACT command.

The length specified for output is too small to output all values of data type integer that are possible based on the column definition in the database instance can be output.

This warning does not cause the command to terminate.

User Action:

No user action is required.


25603: Warning when downloading data; literal will be truncated (MaxDB: Messages)

25603: Warning when downloading data; literal will be truncated

Explanation:

Warning when unloading data using the DATAEXTRACT command.

The length of the literal exceeds the output length that has been defined. The literal will only be partially output.

This warning does not cause the command to terminate.

User Action:

No user action is required.


25604: Warning when downloading data; supernumerary specificatio (MaxDB: Messages)

25604: Warning when downloading data; supernumerary specifications for the LONG data file will be ignored

Explanation:

This warning appears if you are unloading data using the DATAEXTRACT command and you want to unload LONG columns.

In your command, you have specified LONG data streams that cannot be assigned to a column in the command's column. Any supernumerary LONG data streams will be ignored during the data unload.

This warning does not cause the command to terminate.

User Action:

No user action is required.


25605: Warning when downloading data; neither the header nor the (MaxDB: Messages)

25605: Warning when downloading data; neither the header nor the record length was found in the data file or command. The <N> value that was calculated will be used as a record length

Explanation:

Warning when uploading or updating data from binary data streams using the commands FASTLOAD, DATALOAD, or DATAUPDATE.

If the data that is to be loaded was unloaded using the Loader, the binary data stream contains a header that is the same length as an individual data record in the data stream. The system was unable to find this header. The length of an individual data record was not specified in the command either.

For this reason, the Loader calculates the record length based on the column lengths defined in the command.

This warning does not cause the command to terminate.

User Action:

No user action is required.


25606: Warning when uploading data; different byte swap of sourc (MaxDB: Messages)

25606: Warning when uploading data; different byte swap of source and target computer. Check LONG values

Explanation:

Warning when uploading data using the TABLELOAD command.

The table to be uploaded contains LONG values. The byte swap of the source and target computer is different. For this reason, LONG values may be incorrect or corrupt once they have been uploaded.

This warning does not cause the command to terminate.

User Action:

Check the LONG values in the database instance after they have been loaded:

If they have been loaded without any errors, you do not need to take any action.

If the LONG values contain any errors, they must be re-loaded.


25607: The USAGE value is too low and will be ignored (MaxDB: Messages)

25607: The USAGE value is too low and will be ignored

Explanation:

Warning when uploading data using the FASTLOAD command.

The table that is supposed to be loaded has been defined in the database instance in such a way that a single data record is greater than the value specified for USAGE. For this reason, the Loader ignores the USAGE value.

This warning does not cause the command to terminate.

User Action:

No user action required.


25608: No restart file found. Upload will restart (MaxDB: Messages)

25608: No restart file found. Upload will restart

Explanation:

Error when uploading data using the TABLELOAD ALL or the TABLELOAD USER command.

The RESTART option was specified in the command. The Loader is unable to find the restart file specified in the command. It starts the load process from the beginning.

This warning does not cause the command to terminate.

User Action:

No user action required.


Background Knowledge

This documentation contains background knowledge on the database system MySQL MaxDB. The following topics are discussed in detail:

· Logging

· Data Access

· SQL Optimizer

· High Availability (Standby Databases, Hot Standby and Creating a Homogeneous System Copy)

· Performance

For a general introduction to the MySQL MaxDB database system, refer to the Database Administration documentation.


Logging (MaxDB: Background Knowledge)

Logging

Under normal operating conditions, the database system carries out online logging. Online logging enables the database system to work consistently with transactions. It also enables the database system to undo individual SQL statements and recover them in the event of a system crash (Using Log Entries at Restart or Recovery).

With liveCache database instances, the undo log entries also ensure that transactions are able to read data consistently without locking each other.


Online Logging (MaxDB: Background Knowledge)

Online Logging

Logging during normal database operation (online operational state) is called online logging. During online logging, the database system logs all modifying SQL statements of the transactions, meaning that log entries are written.

Online logging is subdivided as follows:

· Redo Log Management

· Undo Log Management

· History Management (only for liveCache database instances)

Online logging has active components (tasks) and passive components (storage units.)

 | Active Components | Passive Components
Redo Log Management | User tasks that carry out transactions Log writer | Log queue Log area
Undo Log Management | User tasks | Undo log file
History Management | User tasks Garbage collectors | History file


Redo Log Management (MaxDB: Background Knowledge)

Redo Log Management

Redo log entries for transactions are written and managed in redo log management.

In very special situations, you can deactivate redo log management temporarily.

Redo log entries are always written when a user task carries out a modifying transaction.

1. The user task that carries out a transaction reserves main memory space in the log queue and writes the redo log entry for its transaction to a log page in this reserved area.

2. The user task releases the reserved area of the log queue for processing by the log writer. It tells the log writer if it wants to wait for the corresponding log page from the log queue to be written to the log area. This is always a requirement for COMMIT and ROLLBACKprocesses.

3. The log writer reads the redo log entries from the log queue.

4. The log writer writes the redo log entries to the log area as a log page.

5. If the user task is waiting for the redo log entry to be written, the log writer alerts the user task as soon as the redo log entry has been written and tells it the log sequence number.

In the log area, redo log management also stores and regularly updates the database parameters and other internal information that controls the logging.

Redo log management also plays a part in the following situations:

· During a log backup, redo log management ascertains if any entries from the log area have to be saved, and if so how many.

· Redo log management also displays information on waiting times and the type of access used to access the entries in the log queue.

See also:

Log Settings

Using Log Entries at Restart or Recovery


Redo Log Entry (MaxDB: Background Knowledge)

Redo Log Entry

When you REDO a transaction it means that the changes made by a transaction that has been completed successfully are redone. The status of the database is reset to the consistent status it had at the end of the transaction.

The database system stores all the information required for the REDO in the redo log entries (also known as after image entries.) Redo log entries are stored permanently in the log area only after the COMMIT for the transaction.

See also:

Using Log Entries at Restart or Recovery

Undo Log Entry


Log Queue (MaxDB: Background Knowledge)

Log Queue

The log queue is the main memory area, in which redo log entries from the transactions are stored. You use the special database parameter LOG_IO_QUEUE to configure the size of the log queue.


Log Pages (MaxDB: Background Knowledge)

Log Pages

Log pages are the main memory units used in redo log management. Log pages are 8 KB in size.

A user task writes its redo log entries to the log pages of the log queue. Each log page is assigned a log queue sequence number that specifies the time the redo log entry was written to the log queue.

Later, the log writer writes the log pages to the log area. Log pages from the log queue that were not full when they were written on, remain in the log queue and continue to be written on until the next write operation, when they are written to the log area. The log writer is configured so that it always writes the same log page to the same physical place in the log area.

When the log writer writes a log page from the log queue to the log area, it assigns a log sequence number and a timestamp to it. The log sequence numbers can be used to determine the unique sequence of the log pages in the log area. The timestamp is used to recover the database with the same status that it had at a particular point in time.


Log Writer (MaxDB: Background Knowledge)

Log Writer

The log writer is an active component of redo log management. It belongs to the user kernel thread. The log writer’s job is to write log pages from the log queue into the log area.

The log writer is activated in the following situations:

· A log page is full

· COMMIT or ROLLBACK transactions

After the log writer has written log pages to the log area, it alerts the user tasks that have been waiting to write their redo log entries.

The log writer regularly checks the status of the log area. When the log area is full, the log writer locks the log queue. This means that all the transactions that want to add redo log entries to the log queue are stopped.

When the database system is started, the log writer is initialized using permanently stored, internal configuration information. The configuration information is written to the log area at regular intervals, particularly at savepoints.

When the automatic log backup is activated, the log writer ensures that the redo log entries from the log area are backed up automatically. When a certain number of log entries have been written, the administrative information is copied to the log area, and savepoints are requested, if required. This shortens the restart time, if a restart is required.


Undo Log Management (MaxDB: Background Knowledge)

Undo Log Management

The undo log entries for transactions are written and managed in undo log management. The database system uses the undo log entries to reinstate a database with a consistent transaction status that corresponds to the status that existed at the time of the most recent savepoint.

A user task always writes undo log entries when it carries out modifying SQL statements. It stores the undo log entries in its undo log file.

See also:

Using Log Entries at Restart or Recovery


Undo Log Entry (MaxDB: Background Knowledge)

Undo Log Entry

To UNDO (rollback) a transaction means that the transaction is undone. The status of the database is reset to the consistent status it had before the transaction started.

For the UNDO, the original values of the data objects that the transaction was going to change, meaning the values from before the transaction was started, are stored for each transaction. This information is called an undo log entry or a before image entry.

Before a modifying SQL statement is carried out, the undo log entries are stored in an undo log file in the data area. Each transaction can access its undo log entries at any time.

liveCache database instances also use undo log entries to enable them to read data consistently without locking. When a transaction has finished, the liveCache database instance needs to keep all the undo log entries belonging to the transaction until all the other transactions that access the same objects have also finished. This is why, with liveCache database instances, the undo log entries are transferred to history management when the transaction that they belong to finishes.

See also:

Redo Log Entry

Using Log Entries at Restart or Recovery


Undo Log File (MaxDB: Background Knowledge)

Undo Log File

Undo log files contain the undo log entries that are created by the user tasks for modifying SQL statements. Each undo log entry in an undo log file is given an undo log sequence number, starting with 0.

Undo log files are stored in the data area.

In exceptional circumstances, storing the undo log files in the data area can cause the data area to become full. If this happens, you need to increase the size of the data area.

Undo log files are deleted as follows:

· MySQL MaxDB: At the end of a transaction, the undo log files are deleted by the user task of the transaction.

· SAP liveCache: At the end of a transaction, the undo log files are transferred to history management, because they are needed to enable data to be read consistently without any locks being applied. They are deleted later by the garbage collector.


History Management (LiveCache) (MaxDB: Background Knowledge)

History Management (liveCache)

History management is responsible for the storing undo log files and later deleting them when they are no longer required. History management also ensures that transactions are able to read data consistently without locking.

Only SAP liveCache instances have a history management. Consistent reading for OLTP instances is achieved by selecting the appropriate isolation level.

Before a user task carries out a modifying SQL statement in a transaction, it writes undo log entries into an undo log file. With OLTP database instances, undo log files are deleted at the end of the transaction. With liveCache database instances, however, the user task transfers them to history management.

...

1. At the end of a transaction, the user task writes a reference to its undo log file in a history file.

2. If no more applications need to access the data, for which details of the modifications made to it have been stored in the undo log file, the garbage collector reads the storage location of the undo log file from the history file and deletes the corresponding reference.

3. The garbage collector deletes the undo log file and any data records that the user task has marked for deletion.

See also:

Using Log Entries at Restart or Recovery

Example: Reading Data Consistently Without Locking


History File (LiveCache) (MaxDB: Background Knowledge)

History File (liveCache)

History files are internal database files containing references to the undo log files of completed transactions. The history files tell you which undo log file belongs to which completed transaction.

History files are used only by liveCache database instances.

The initial history files are generated in the data area when the database instance is created. At each savepoint, the updated history files are stored in the data area.

For performance reasons, there are always several history files open in parallel. The database system uses the MAXUSERTASKS general database parameter to calculate the number of history files.


Garbage Collector (LiveCache) (MaxDB: Background Knowledge)

Garbage Collector (liveCache)

Garbage collectors are active components of history management. They belong to the user kernel threads. The garbage collectors job is to delete undo log files that are no longer needed along with any database objects belonging to them. Garbage collectors enable data to be read consistently without locking.

Only SAP liveCache instances use garbage collectors.

When the database system starts, the garbage collectors are initialized using permanently stored, internal configuration information.

History management always starts the garbage collectors when a consistent view is completed. The required information is supplied by the lock management. A garbage collector processes sequentially the history file that history management assigned to it.

The garbage collector asks history management, which of the undo files in the history file can be deleted. History management passes the query on to the lock management, where it is checked whether the associated transactions still appear in any views.


Example: Reading Data Consistently Without Locking (Live Cache) (MaxDB: Background Knowledge)

Example: Reading Data Consistently Without Locking (Live Cache)

Undo log entries are used by liveCache database instances so that several transactions are able to access the same data record at the same time and read it consistently, without it having to be locked against one of the transactions.

...

1. Transaction T1 reads data record 4711 in a table for the first time. Transaction T1 does not lock the data record.

2. Transaction T2 modifies data record 4711 and ends with a COMMIT.

3. Transaction T1 reads data record 4711 again.

4. Transaction T1 checks the history file to see whether another transaction has modified data record 4711 since it was first read by transaction T1.

If this is the case, transaction T1 accesses the undo-log entries of transaction T2 so it can get the same result in the second reading as it did in the first. Without the undo-log entries, transaction T1 would get a different result each time it read data record 4711.

5. The garbage collectors delete the undo-log entries from transaction T2 only after transaction T1 has been ended with a COMMIT.

Only liveCache database instances can read consistently in this way, without being locked. With OLTP instances data record 4711 has to be locked until transaction T1 has ended. This is made possible by an appropriate selection of the isolation level.


Using Log Entries at Restart or Recovery (MaxDB: Background Knowledge)

Using Log Entries at Restart or Recovery

During a restart or recovery the log entries are used to reestablish the most recent consistent status of the database instance.

There are two phases to a restart or recovery:

· Evaluating the Log Information

· Redoing the Transactions

Both phases include active components (tasks) and passive components (storage units.)

 | Active Components | Passive Components
Evaluating the log information | Redo Log Manager Log Reader | Redo Log File Redo List
Redoing transactions | Redo Tasks |

See also:

Example: Restart


Determining Information for Recovering Transactions (MaxDB: Background Knowledge)

Determining Information for Redoing Transactions

If the system crashes, you need to restart or recover the database. The database system first gathers all the information it needs to redo any transactions that have been executed since the most recent savepoint.

...

1. The redo log manager starts the log reader.

2. The log reader reads the transaction file that was stored at the most recent savepoint.

3. The log reader uses the transaction file to recreate the transaction list.

4. For transactions that were started after the most recent savepoint, the log reader asks the redo log manager or the back-up manager for the relevant redo log entries and writes them from the log area into a redo log file.

5. The log reader then enters these transactions into the redo list.


Redo Log Manager (MaxDB: Background Knowledge)

Redo Log Manager

During a restart or recovery, the redo log manager ensures that the required redo log entries are available and are processed in the correct order.

The redo log manager starts the log reader and the redo tasks.


Log Reader (MaxDB: Background Knowledge)

Log Reader

The log reader is an active component of the restart or recovery process. It is a server task.

The log reader determines all the information that is required to restart or recover a system. It also generates all the files and lists that are needed to redo the transactions.


Transaction File (MaxDB: Background Knowledge)

Transaction File

A transaction file is an internal database file to which the data of all open transactions is written at the time of a savepoint. The transaction file is stored in the data area.

During a restart or a recovery, the log reader uses the transaction file to regenerate the transaction list.


Transaction List (MaxDB: Background Knowledge)

Transaction List

The transaction list is an internal database list of all open modifying transactions. The transaction list is located in the main memory.

All modifying transactions are available in the database globally from this transaction list. The transaction list contains a transaction entry for each transaction. The transaction entry contains references to redo log entries and undo log entries that may be available.

In the event of a restart or a recovery, the log reader regenerates the transaction list from the transaction file.


Redo Log File (MaxDB: Background Knowledge)

Redo Log File

Redo log files contain the redo log entries of transactions that were not completed at the point of the most recent savepoint and have to be redone if a restart or recovery is required.

Redo log files are internal database storage structures that are stored in the data area.


Redo List (MaxDB: Background Knowledge)

Redo List

The redo list is an internal database list of transactions. It is created by the redo log manager. It is stored in the main memory.

The redo list is an enhancement to the transaction list. The redo list contains information on the transactions that were started after the most recent savepoint took place. The list also contains details of the sequence in which the transactions were carried out. These transactions will need to be repeated if a restart or recovery is required.

The log reader determines the transactions that need to be entered into the redo list as follows:

· If transactions in the transaction list are marked as complete at the time of the most recent savepoint, the log reader enters these transactions immediately into the redo list.

· The log reader creates a redo log file for each further transaction found in the redo log entries. If a COMMIT or a ROLLBACK is found for the entire transaction, the log reader enters the transaction into the redo list. If a ROLLBACK is found within a transaction, the log reader removes the corresponding redo log entries from the redo log file to avoid these log entries being processed unnecessarily.

· If uncompleted transactions are found after all the redo log entries have been read, the log reader flags these transactions with a ROLLBACK and enters them into the redo list. These transactions are subsequently treated as ROLLBACK transactions.


Recovering Transactions (MaxDB: Background Knowledge)

Redoing Transactions

Once all the required information has been gathered, the transactions can be redone.

...

1. The redo log manager restarts the user tasks for the transactions in the transactions list.

2. The redo log manager starts the redo tasks. The redo tasks evaluate the redo list. They then read the required redo and undo log entries for the transactions in the redo list and execute the transactions.


Redo Task (MaxDB: Background Knowledge)

Redo Task

Redo tasks are active components during a restart or recovery. They are server tasks. The redo tasks carry out those transactions that need to be repeated in the case of a restart or recovery. They proceed as follows:

COMMIT transactions

...

1. In the redo list, the redo tasks look for transactions that were completed with a COMMIT, and are therefore ready to be redone. In the redo list, the transactions are sorted by the log sequence numbers of their COMMIT.

2. The redo task starts by processing the transaction with the lowest COMMIT log sequence number. The redo log file that belongs to this transaction is processed in sequence. If a redo log entry for this redo log file has a higher log sequence number than the lowest COMMIT log sequence number, it cannot be processed. In this case, the redo task waits for the COMMIT of the other transaction. Only then can the redo task continue processing the redo log file. This mechanism guarantees the consistency of the data.

3. When a COMMIT transaction has been processed completely, the redo task deletes the redo log file. If it is an OLTP instance, the undo log file for the transaction is also deleted. With liveCache instances, the undo log file is transferred to History Management. The transaction is removed from the redo list.

ROLLBACK transactions

...

1. In the redo list, the redo tasks look for transactions that were completed with a ROLLBACK.

2. The redo tasks delete the corresponding redo log files. This prevents the transactions being redone unnecessarily.

3. If the ROLLBACK transaction was started before the savepoint, the redo task evaluates the undo log file of the transaction in order to reset the transaction to the status it had before the savepoint. If the ROLLBACK transaction had been processed completely, the redo task deletes the undo log file of the transaction. If the ROLLBACK transaction was started after the savepoint, the redo task does not process the transaction further.

See also:

Example: Restart


Example: Restart (MaxDB: Background Knowledge)

Example: Restart

You need to restart the database because it has crashed. The database instance is recovered from the last savepoint .

The following diagram shows how different transactions are handled during a restart.

Transaction | Required recovery measures
T1 | No recovery measures required. Changes made by transaction T1 were recorded fully at the last savepoint that was carried out before the crash.
T2, T3 | No recovery measures required. However, any modifications made before the most recent savepoint must be reversed. The redo tasks therefore evaluate the relevant undo log files.
T5 | No recovery measures required. The changes made by T5 were rolled back before the crash and are not yet stored in the data area.
T4, T6 | The log reader creates the redo log files and the corresponding entries in the redo list. The redo tasks import the required redo log entries for these transactions.


Savepoint on Restart (MaxDB: Background Knowledge)

Savepoint on Restart

Savepoints are also written during a restart so that a redo can be done from a redo. The positions of the log reader and the status of all open redo transactions are stored in the data area. These savepoints enable you to continue a restart at the point at which it was cancelled.

See also:

Redo Log Management


Accessing Data (MaxDB: Background Knowledge)

Accessing Data

The database system uses the following logical structures to store data:

· Primary tables (with primary key and secondary key)

· Secondary key tables

· B* trees

B* trees are created for primary tables and secondary key tables (B* trees for tables). For tables with LONG columns (data type LONG, also known as BLOBs = Binary Large Objects), a special data processing procedure takes place using the B* trees.

The database system balances the storage automatically, making a manual reorganization of the data unnecessary. The data area can be extended online.

The database system uses the following strategies to enable it to access data efficiently:

· Table access (SELECT) using a B* tree

· Table access (INSERT) using a B* tree

· Table access (UPDATE) using a B* tree

· Table access (DELETE) using a B* tree


Terms (MaxDB: Background Knowledge)

Terms

· B* Tree

· Primary Key

· Secondary Key

· Table Access

· Table ID


B* Tree (MaxDB: Background Knowledge)

B* Tree

Most of the data in a database is stored in structures called B* trees. B* trees enable the database system to access the rows of a table far more efficiently than other methods, for example, a sequential search.

A B* tree has several levels, from the top root level through several index levels to the lowest level, the leaf level. The storage units, in which the data is stored, are called pages.

The sort criterion for building a B* tree is the primary key. All comparisons in a B* tree use ASCII code. The comparisons are performed for all values on a character-by-character basis.

See also:

· Root Page / Index Page

· Leaf Page

· Table Access

· B* Trees for Tables


Root/Index Page (MaxDB: Background Knowledge)

Root/Index Page

Entries in root pages and index pages in a B* tree contain two sections.

· First section: This section contains an initial segment of the key fields of a table row. This section is called the separator. The database system uses only that part of the primary key that is needed to differentiate the following entries. This minimizes the memory needed by these pages.

The first separator in the leftmost page of each level (including the root level) contains only the pointer to the leftmost page of the next level down.

The average length of the separators depends on the structure and the selectivity of the primary key. If a very large number of key fields have to be evaluated to enable the entries (records) to be distinguished from each other, but the characteristics in the front key fields are often the same, then this results in longer separators.

· Second section: This section contains the logical address of a page at a lower index level or at the leaf level. The number of entries in this section depends on the length of the separators.


Leaf Page (MaxDB: Background Knowledge)

Leaf Page

Leaf pages in a B* tree contain the content of table rows, that is the application data. The number of entries in a leaf page depends on the total length of the table rows.

The leaf pages in the B* tree are sorted from left to right in ascending order. In other words, each leaf page contains only the table rows that fit its sort area.

The table rows are located in the first section (data section) of the leaf page. The rows in the data section are not sorted by default. The last section of the leaf page contains a position list with addresses that point to the corresponding table rows within the leaf list. The position list is always sorted in ascending order.

The storage space required to store the entire table depends on the length of the separators and on the total length of table rows.


Primary Key (MaxDB: Background Knowledge)

Primary Key

Each database table has a primary key. The primary key is either defined by the database user or generated internally. A user-defined primary key can consist of multiple columns.


Secondary Key (MaxDB: Background Knowledge)

Secondary Key

You are able to define secondary keys for each table in order to optimize data access using SQL statements. Secondary keys can refer to any combination of columns, and they help to prevent sequential scans of the table. Like the primary key, the secondary key can consist of multiple columns.

A secondary key is often called an index (not to be confused with the B* index).


Table ID (MaxDB: Background Knowledge)

Table ID

The database user specifies a table by entering its name. The table is accessed internally using a table ID of a fixed length.

The relationship between the table name and this table ID is stored in the database catalog.

In addition, the database system has a special management structure (file directory), in which the root pages of B* trees are assigned to table IDs.

The table IDs are stored in the file directory together with a type flag and other information. The type flag specifies whether the table contains primary data, secondary key , or LONG data. The type flag specification enables one table ID to be used for all the B* trees required for the logical structures of the same table.


Table Access (MaxDB: Background Knowledge)

Table Access

The logical term table denotes primary data, including data in columns of type LONG and data in secondary key structures.

· As specified by its schema definition, a table has exactly one B* tree for the primary data, and exactly one B* tree for each secondary key.

· If the table definition contains columns of data type LONG, an additional B* tree is created to accommodate all data of this type that does not exceed a specified length (data of type short LONG). Data items of type LONG that exceed this specific length are each stored in separate B* trees (data of type long LONG).

All searches and changes in the table are executed in the computer’s main memory via SQL statements (SELECT, INSERT, UPDATE, DELETE,...), which means that they are carried out very quickly. The B* tree structure changes itself for INSERT, UPDATE and DELETE statements only when there is not enough space in the target page for the new information, or when the fill level of a page falls below the predefined fill level.

See also: B* Trees for Tables and Table Access Using a B* Tree


B* Trees for Tables (MaxDB: Background Knowledge)

B* Trees for Tables

B* trees are set up for the following kinds of table:

· Tables with primary data

· Tables with secondary keys

· Tables with LONG columns

See also: Table Access

You can find some examples for creating B* trees here:

· B* Trees for Tables with LONG Columns

· B* Trees for Tables with Secondary Keys

· B* Trees for Tables with LONG Columns and Secondary Keys


B* Trees for Tables with LONG Columns (MaxDB: Background Knowledge)

B* Trees for Tables with LONG Columns

In the following section, the B* trees for a table that has primary data and LONG type data are cited as examples of B* trees for tables.

The primary table contains a LONG column. The numerical column defines the length of the LONG field for each line. There is one B* tree for the primary data, another for short LONG type data, and multiple B* trees for other long LONG type data.

The primary table contains a fixed-length reference to the contents of the LONG field in each row. This reference points uniquely to the storage location of the contents of the LONG field, either as a key to a B* tree (short LONG) or as the table ID of one of the multiple B* trees (long LONG).


B* Trees for Tables with a Secondary Key (MaxDB: Background Knowledge)

B* Trees for Tables with a Secondary Key

One example of B* trees for tables are B* trees for a table that contains primary data and secondary keys, as described in the following.

The table has a two-column multiple secondary key. There is one B* tree for the primary data and a second B* tree for the data of the secondary key table.


B* Trees for Tables with LONG Columns and a Secondary Key (MaxDB: Background Knowledge)

B* Trees for Tables with LONG Columns and a Secondary Key

An example of B* trees for tables are B* trees for a table that has all types of structures: primary data, secondary keys, and LONG type data, as described in the following section.


Table Access Using B* Tree (MaxDB: Background Knowledge)

Table Access Using B* Tree

For all SELECT and DML (data manipulation language) statements, the database system uses the same search algorithm to determine the leaf page, in which a table entry can be found or has to be changed.

Here are some examples of how to use B* trees to access tables:

· Table access (SELECT) using a B* tree

· Table access (INSERT) using a B* tree

· Table access (DELETE) using a B* tree

· Table access (UPDATE) using a B* tree


Table Access (SELECT) Using a B* Tree (MaxDB: Background Knowledge)

Table Access (SELECT) Using a B* Tree

Table access using a B* tree is illustrated using the example of a SELECT statement.

The address table is defined by the column with the city primary key. In the table, the system searches for an entry with the value Athens for the city primary key field.

1. The search starts at the root level of the B* tree. The database system compares the value of Athens with the value of the first entry in the root page , which is Ba.

2. Since the value of Athens is smaller than Ba, the corresponding address information is evaluated. This points to an index page.

3. The search continues at the index level. The value Athens is greater than the value of the first entry in the data page, An. The next value in the page is evaluated. Since the value of Athens is smaller than Au, the corresponding address information is evaluated. This points to a leaf page.

4. The search continues at the leaf level. In the position list of the leaf page a binary search algorithm is used. The corresponding address information for the table entry with the key value Athens is evaluated.

5. The database system scans the data section in the leaf page until it has found the corresponding table entries. The search is now complete.


Table Access (INSERT) Using a B* Tree (MaxDB: Background Knowledge)

Table Access (INSERT) Using a B* Tree

Table access using a B* tree is illustrated using the example of an INSERT statement.

The address table is defined by the column with the city primary key. An INSERT statement is used to insert into the address table an entry with the value Arbon for the primary key field city.

If there is enough space for the new entry in the leaf page of the B* tree, the database system inserts the entry at the end of the data section and updates the position list. The address of the new entry is written to the correct position in the position list. In the example above, this is position 4. Position 4 points to the new table entry number 7.

When the database system adds data to a data page, the data page is filled physically from the top left with data and from the bottom right with the corresponding position entries. The position list and the data area converge when a lot of data is inserted into a data page.


Table Access (DELETE) Using a B* Tree (MaxDB: Background Knowledge)

Table Access (DELETE) Using a B* Tree

Table access using a B* tree is illustrated using the example of a DELETE statement.

The address table is defined by the column with the city primary key.

A DELETE statement is used to delete from the table an entry with the value Apach for the primary key field city.

If an entry is deleted from the table, gaps appear in the data section and in the position list of the leaf page in the B* tree. The database system closes these gaps and updates the position list to save storage space.


Table Access (UPDATE) Using B* Tree (MaxDB: Background Knowledge)

Table Access (UPDATE) Using a B* Tree

Table access using a B* tree is illustrated using the example of an UPDATE statement.

· If an UPDATE is performed and the primary key remains unchanged, only the contents of the table row are changed.

· If the data length changes, the positions of subsequent entries and their addresses in the position list of the leaf page in the B* tree are changed.

· If the key field changes, the UPDATE is executed as a DELETE (see Table Access (DELETE) Using a B* Tree) with a subsequent INSERT (see Table Access (INSERT) Using a B* Tree).


Changes in the B* Tree Structure (MaxDB: Background Knowledge)

Changes in the B* Tree Structure

The B* tree structure is changed by INSERT, UPDATE, and DELETE statements only when there is not enough space for the new information in the target page, or when the fill level of a page falls below the predefined fill level.

The address table is defined by the column with the city primary key. In the table, an entry with the value Albas has to be inserted for the city primary key field. If the new table entry is too large for the corresponding leaf page in the B* tree, the database system carries out the following actions:

· A new leaf page is created. The new row of the table is incorporated into this leaf page. In other words, the beginning of the sort area of the new leaf page is specified by this row of the table. The sort sequence of the individual leaf pages must be restored. To do this, it may be necessary to copy the table rows that belong in the new sort area from the leaf page with the next smallest sort area to the new leaf page, and then delete them from the previous leaf page. This procedure is called a page split.

· Pointers to consecutive pages are updated whenever required.

· Address and separator information on the new page is also inserted in the corresponding root or index page one level higher. If the index page is too small to accommodate this information, a new index page is inserted at this index level as well. If the root page at the uppermost level is too small to accommodate a new entry, a new index level is created.

A chain of page splits can cause the database system to balance the B* tree (storage balancing.)

See also: Non-Uniform Distribution of Data Pages


Non-Uniform Distribution of Data Pages (MaxDB: Background Knowledge)

Non-Uniform Distribution of Data Pages

Changes to the B* tree structure can lead to a non-uniform distribution of the data pages. If some branches of the B* tree have more pages than others, data page distribution is not uniform. This can affect system performance, because more accesses are generally required to find data.

Non-uniform distributions are detected by the database system when INSERT, UPDATE, or DELETE statements are performed and the tree is rebalanced when the current operation is carried out. This means that the tree is constantly maintained for optimum operation. During this procedure, page entries are moved to new locations and page pointers are redirected. As a result, data pages are used more efficiently.

Uniform distribution of data prevents individual data areas from overflowing.The only restriction on the size of tables is the storage space available in the database system.


SQL Optimizer (MaxDB: Background Knowledge)

SQL Optimizer

The SQL Optimizer is part of the kernel of the database system. It analyzes SQL queries sent to the database and selects the best search strategy for accessing the database tables with SQL.

This documentation handles the following topics:

· How the Optimizer Works

· Troubleshooting

· Terms

· Examples

For general information about the MaxDB database system, see Database Administration. For information about the syntax of the SQL statements that you can use in the database system, see the Reference Manual.


How the Optimizer Works (MaxDB: Background Knowledge)

How the Optimizer Works

SQL statements only specify the results that are required, and do not contain any information about how this data is found in the database.

The database system can often choose from multiple options for finding the data required by the SQL statement. The Optimizer has the task of determining the best search strategy for accessing the data.

The Optimizer works by running through the following steps:

...

1. The Optimizer is called when an SQL statement with a search condition is sent to the database.

2. The Optimizer converts the search condition into a standard format.

3. The Optimizer determines all search strategies that can be used to access the data specified in the SQL statement.

4. The Optimizer determines the cost of each of these search strategies and chooses the strategy that needs the fewest resources to process the SQL statement.

5. The database system uses this search strategy to execute the SQL statement.


Search Conditions (MaxDB: Background Knowledge)

Search Conditions

The Optimizer can optimize data access only for those SQL statements that contain a search condition. A search condition is defined with a WHERE clause.

SELECT name

FROM customer

WHERE city = 'Berlin' AND zip > 13000

The following SQL key words can be combined with a search condition: SELECT, UPDATE, DELETE, INSERT.

Some restrictions for search conditions apply to UPDATE statements.

The form of the search condition has a significant effect on the costs incurred by the execution of the SQL statement. When it determines costs for an SQL statement, the Optimizer only considers the following search conditions:

· Equality Condition

· Range Condition

· IN Condition

· LIKE Condition

If the search conditions in an SQL statement cannot be converted into one of the forms listed above, then the Optimizer cannot determine a search strategy for them.

If search conditions are linked using multiple identical Boolean operators, then the sequence of the search conditions does not have any influence on how the search strategy is determined by the Optimizer.


Equality Condition (MaxDB: Background Knowledge)

Equality Condition

Equality conditions are search conditions with a comparison predicate. The following applies to equality conditions:

· The only operator is the relational operator =.

· They have one of the following forms:
<column_spec>  =  <extended_value_spec>
<column_spec> =  <subquery>

The equality condition must have one of these forms before the Optimizer can use it to determine a search strategy. If the equality condition has another form, the Optimizer attempts to change it.

Expressions with the following forms are changed to conditions without NOT, with the appropriate negated operator =:

...NOT (<column_spec> <> <extended_value_spec>)

...NOT (<column_spec> <> <subquery>)

The Optimizer then continues to process the modified condition.


Range Condition (MaxDB: Background Knowledge)

Range Condition

Range conditions are search conditions with a comparison predicate or a BETWEEN predicate. The following applies to range conditions:

· The only valid operators are the relational operators < | <= | => | > and the operator BETWEEN.

· Range conditions have one of the following formats:
<column_spec> < < | <= | => | > > <extended_value_spec>

or
<column_spec> BETWEEN <extended_value_spec> AND <extended_value_spec>

To determine an optimal search strategy, the Optimizer can only use range conditions that satisfy these prerequisites.

Whether the range is defined using a BETWEEN operator or whether it is defined using a combination of the relational operators <= and => is irrelevant to the search strategy.

Conditions with the following format are converted to an expression without NOT and with the appropriate negated operator, if possible:

...NOT (<column_spec> < < | <= | => | > > <extended_value_spec>)

...NOT (<column_spec> NOT BETWEEN <extended_value_spec> AND <extended_value_spec>)

The Optimizer then continues to process the modified condition.


IN Condition (MaxDB: Background Knowledge)

IN Condition

IN conditions are search conditions with an IN predicate, to which the following rules apply:

· The operator is the operator IN.

· IN conditions have one of the following formats:
<column_spec> IN (<extended_value_spec>,...)
<column_spec> IN <subquery>

To determine an optimal search strategy, the Optimizer can only use IN conditions that satisfy these prerequisites.

Conditions with the following format are converted to an expression without NOT and with the appropriate negated operator, if possible:

...NOT (<column_spec> NOT IN (<extended_value_spec>,...))

...NOT (<column_spec> NOT IN <subquery>)

The Optimizer then continues to process the modified condition.


LIKE Condition (MaxDB: Background Knowledge)

LIKE Condition

LIKE conditions are search conditions with a LIKE predicate, to which the following applies:

· The operator is the operator LIKE.

· LIKE conditions have the following format:
<column_spec> LIKE <extended_value_spec>

· The value specification used (extended_value_spec) may not begin with the SQL syntax elements match_string or match_set.

To determine an optimal search strategy, the Optimizer can only use LIKE conditions that satisfy these prerequisites.

Conditions with the format ...NOT (<column_spec> NOT LIKE <extended_value_spec>) are, where possible, converted into an expression <column_spec> LIKE <extended_value_spec>. The Optimizer then continues to process this modified condition.


Restrictions for UPDATE Statements (MaxDB: Background Knowledge)

Restrictions for UPDATE Statements

The following restriction applies to the usage of search conditions for SQL statements that contain UPDATE: if the new value of a column is calculated in an arithmetic expression, then an inversion of this column (the corresponding index) cannot be used for a search.

UPDATE <table_name>

SET columnx = columnx + 3

WHERE columnx IN (100, 103, 106, 109, 112)

This SQL statement can lead to errors in the results if the inversion lists were processed step-by-step with the values 100, 103, 106, 109, and 112.

The same applies to SQL statements that contain FOR UPDATE in the SELECT part.


Search Strategies (MaxDB: Background Knowledge)

Search Strategies

The database system can generally use various different strategies to access data (known as search strategies).

Among other things, these search strategies differ in the costs that they incur when executed. The simplest search strategy is the sequential search, in which the entire table is scanned, row-by-row. However, for large quantities of data, the sequential search is often the most costly search strategy. For this reason, the Optimizer analyzes other search strategies that scan smaller areas of the table.

The available search strategies depend on the search condition, the structure of the SQL statement, and the design of the database (primary key and so on). This documentation describes the following cases:

· Search Conditions for Key Columns

· Search Conditions for Inverted Columns

· Search Conditions for UPDATE Statements

· Search Conditions Linked with OR

· Postponement of the Search to the FETCH Time

· Join

You can use the EXPLAIN statement to find out the search strategy chosen by the Optimizer for an SQL statement.

See also:

List of All Search Strategies

Tips on Database Design


Sequential Search (MaxDB: Background Knowledge)

Sequential Search

In principle, every search can be performed sequentially across the entire table, row by row. This is necessary in the following cases:

· No search condition has been specified.

· No search condition is specified for key columns or for inverted columns.

If the possible non-sequential search strategies would be more costly than the sequential search, the table is processed sequentially.


Search Conditions for Key Columns (MaxDB: Background Knowledge)

Search Conditions for Key Columns

If the SQL statement contains search conditions for key columns, then the following search strategies are possible:

Search Condition | Search Strategy
Equality condition for every key column | The appropriate row(s) are accessed directly.
IN condition for one key column and an equality condition for all other key columns | The appropriate row(s) are accessed directly.
Range conditions | Upper and lower limits for the valid key range are created for the key columns. All search strategies, including strategies using inversions, use the knowledge of this valid search range.


Search Conditions for Inverted Columns (MaxDB: Background Knowledge)

Search Conditions for Inverted Columns

If the SQL statement contains search conditions for inverted columns , then the following search strategies are possible:

Search Condition | Search Strategy
Equality condition for all inverted columns | Those rows whose keys are included in the associated inversion list are accessed.
IN condition for inverted columns | The system accesses those rows whose keys are included in the inversion lists.
Range conditions with one condition only ( <, £, >, ³ ) for one of the two range limits (upper or lower limit) | The system accesses those rows whose keys are included in the inversion lists that were determined by the range.
Range conditions for which both range limits are specified. It is irrelevant to the selection of the search strategy whether this specification is made using a BETWEEN operator or using two conditions (£ or ³) for the same column linked by AND. | The system accesses those rows whose keys are included in the inversion lists that were determined by the range.

In the case of the equality/IN conditions and the range conditions, there are also queries for which it is not necessary to access the rows, since all required values are already included in the inversion list(s).

See also:

Examples: Search Conditions for Inverted Columns


Examples: Search Conditions for Inverted Columns (MaxDB: Background Knowledge)

Examples: Search Conditions for Inverted Columns

The following examples show search conditions for inverted columns of the table example, as well as the corresponding search strategies that are used.

Excerpt from SQL Statement

Search Strategy

... WHERE firstkey >= 123

The table is searched sequentially from the row with the key ‘123’.

... WHERE invcolumn1 = 'Miller' AND firstkey >= 123

The whole inversion list with the value ‘Miller’ is searched from the key ‘123’ to the end of the list.

... WHERE invcolumn1 = 'Miller' AND invcolumn2 < 'C'

The system creates a logical inversion list that contains all inversion lists of invcolumn 2 that begin with a value smaller than 'C' (' ', 'A', 'B').

The intersection of the logical inversion list and the inversion list with the value ‘Miller’ is determined and the entirety of this intersection is processed.

... WHERE invcolumn1 IN ('Miller', 'Smith', 'Hawk')

The entirety of three inversion lists is processed.

... WHERE invcolumn2 > 8965 AND firstkey = 34 AND secondkey BETWEEN 12 AND 18

All inversion lists of invcolumn2 whose values are greater than 8965 are processed. However, they are only considered within the key limits ‘34, 12’ and ‘34, 18’.

... WHERE
multinvcolumn1 = 'Düsseldorf' AND
multinvcolumn2 = '40223' AND
multinvcolumn3 = 10000

The entirety of the inversion list of the named index ind with the values ‘Düsseldorf’, ‘40223’ and 10000 is processed.

... WHERE
multinvcolumn1 = 'Düsseldorf' AND
multinvcolumn2 BETWEEN '40221' AND'40238'

The inversion lists within and including the values ‘Düsseldorf’, ‘40221’ (binary zeros), and ‘Düsseldorf’, ‘40238’ (binary ones) are processed.


Search Conditions Linked with OR (MaxDB: Background Knowledge)

Search Conditions Linked with OR

For SQL statements that contain search conditions linked with OR, the Optimizer initially analyzes each search condition individually.

If the system finds an equality condition for key columns, it ignores the other search conditions linked with OR.

b1 AND b2 AND (b3 OR b4 AND b5)

The expressions b1, b2 and (b3 OR b4 AND b5) are initially analyzed individually. If an equality condition is found for key columns for b1 or b2, then (b3 OR b4 AND b5) is not considered when the search strategy is selected, since the search range cannot be effectively restricted any further.

If the system does not find any equality conditions for key columns, then the other search conditions linked with OR (not yet considered by the system) are analyzed. The Optimizer proceeds as follows:

..

1. Convert to disjunctive normal form

b1 AND b2 AND (b3 OR b4 AND b5)

is converted to the disjunctive normal form

(b1 AND b2 AND b3) OR (b1 AND b2 AND b4 AND b5)

2. Analyze the new expression
The new parenthesized expressions are analyzed separately.

3. Determine costs
The costs of the various search strategies for the parenthesized expressions of the disjunctive normal form are totaled. If this total is lower than the initial determined cost for the search strategy, without considering the search conditions linked with OR, then these various search strategies are used.

If the total costs of (b1 AND b2 AND b3) and (b1 AND b2 AND b4 AND b5) are lower than the costs for the search strategy for b1 and b2, then the strategies for (b1 AND b2 AND b3) and (b1 AND b2 AND b4 AND b5) are used.


Postponement of the Search to the FETCH Time (MaxDB: Background Knowledge)

Postponement of the Search to the FETCH Time

As far as possible, the Optimizer creates results tables only when it is absolutely necessary.

If no results table needs to be created, the search can be postponed to the FETCH time (see FETCH Statement ). In this way, no memory is used for results, and the first results can be accessed quickly.

However, you cannot always postpone the search to the FETCH time, since some situations always require a results table to be created.

· SELECT for multiple tables (Join)

· SELECT ... FOR REUSE

A results table usually needs to be created in the following cases:

· SELECT DISTINCT ...

· SELECT ... ORDER BY ...

If all of the following conditions apply, no results table needs to be created:

¡ Neither a DISTINCT specification (<distinct spec>) (with a few exceptions), nor the syntax element FOR REUSE, are specified.

¡ The columns that you are sorting by constitute an index in the specified order and with the specified sort order (ascending or descending).

You can use the EXPLAIN statement to find out whether a results table is created (RESULT IS COPIED) or not (RESULT IS NOT COPIED).


Joins (MaxDB: Background Knowledge)

Joins

Before you can understand how the Optimizer finds search strategies for joins, you need some information about how the database system processes joins.

Creating Results Tables

Joins are statements that join tables together. The tables are joined together in a series of steps:

...

1. The first table is scanned.

2. The result is stored in a temporary results table.

3. The temporary results table is sorted by the join columns of the following join step.

4. The next table that still exists is scanned.

5. The existing temporary results table is joined with the new table.

6. The result is stored in a new temporary results table.

7. This temporary results table is sorted by the join columns of the following join step.

8. The old temporary results table is deleted.

9. If there are more tables, the procedure is repeated from step 4.

The last temporary results table is the results table that the user wants.

Order of Processing for Join Tables

The aim of an optimization is to save time and memory. For joins, this means that the rows of the new tables that you want to join must be accessed as directly as possible. The temporary results tables must be as small as possible.

For this reason, the Optimizer starts to process joins for the smallest tables with the most restrictive search conditions. Initially, this keeps the temporary results tables small. This means that the Optimizer itself specifies the order in which the join tables are processed; the order in which the tables are specified in the FROM clause of the SELECT statement is not relevant here.

Search Strategies for Joins

The following search strategies can be used to access rows in the new table, starting from the join column values of the old temporary results table.

JOIN VIA INDEXED COLUMN

JOIN VIA KEY COLUMN

JOIN VIA KEY RANGE

JOIN VIA MULTIPLE INDEXED COLUMNS

JOIN VIA MULTIPLE KEY COLUMNS

JOIN VIA RANGE OF MULTIPLE INDEXED COL.

JOIN VIA RANGE OF MULTIPLE KEY COLUMNS

If the two columns that you want to compare in a join step do not have the same length, then not all of the search strategies can be used. To avoid this restriction, define the same value range for any columns that you want to join together.

You can use the EXPLAIN statement (EXPLAIN Statement for Joins) to find out the search strategy chosen by the Optimizer.


List of All Search Strategies (MaxDB: Background Knowledge)

List of All Search Strategies

The following lists all search strategies that are recognized by the Optimizer. The names match the return codes of the EXPLAIN statement. You can use this statement to query the search strategy chosen by the Optimizer for a particular SQL statement.

CATALOG KEY ACCESS

CATALOG SCAN

CATALOG SCAN USING USER EQUAL CONDITION

DIFFERENT STRATEGIES FOR OR-TERMS

EQUAL CONDITION FOR INDEX

EQUAL CONDITION FOR INDEX (SUBQ)

EQUAL CONDITION FOR KEY COLUMN

EQUAL CONDITION FOR KEY COLUMN (SUBQ)

IN CONDITION FOR INDEX

IN CONDITION FOR KEY COLUMN

JOIN VIA INDEXED COLUMN

JOIN VIA KEY COLUMN

JOIN VIA KEY RANGE

JOIN VIA MULTIPLE INDEXED COLUMNS

JOIN VIA MULTIPLE KEY COLUMNS

JOIN VIA RANGE OF MULTIPLE INDEXED COL.

JOIN VIA RANGE OF MULTIPLE KEY COLUMNS

NO RESULT SET POSSIBLE

NO STRATEGY NOW (ONLY AT EXECUTION TIME)

RANGE CONDITION FOR KEY COLUMN

RANGE CONDITION FOR KEY COLUMN (SUBQ)

RANGE CONDITION FOR INDEX

RANGE CONDITION FOR INDEX (SUBQ)

INDEX SCAN

TABLE SCAN


CATALOG KEY ACCESS (MaxDB: Background Knowledge)

CATALOG KEY ACCESS

CATALOG KEY ACCESS is a search strategy.

This search strategy can be used for search conditions that contain equality conditions. These search conditions can be processed by accessing key columns in the database catalog.

A search condition for the table DOMAIN.TABLES contains equality conditions for OWNER and TABLENAME.

See also:

List of All Search Strategies


CATALOG SCAN (MaxDB: Background Knowledge)

CATALOG SCAN

CATALOG SCAN is a search strategy. The system performs a sequential search of the database catalog.

See also:

List of All Search Strategies


CATALOG SCAN USING USER EQUAL CONDITION (MaxDB: Background Knowledge)

CATALOG SCAN USING USER EQUAL CONDITION

CATALOG SCAN USING USER EQUAL CONDITION is a search strategy. The system performs a sequential search across those database catalog entries that describe objects of the specified user.

See also:

List of All Search Strategies


DIFFERENT STRATEGIES FOR OR-TERMS (MaxDB: Background Knowledge)

DIFFERENT STRATEGIES FOR OR-TERMS

DIFFERENT STRATEGIES FOR OR-TERMS is a search strategy.

The system converted and analyzed search conditions linked with OR. If the system finds an equality condition for key columns, it ignores the other search conditions linked with OR. If the system does not find an equality condition, the system determines different search strategies for the different parts of the search conditions linked with OR.

See also:

List of All Search Strategies


EQUAL CONDITION FOR INDEX (MaxDB: Background Knowledge)

EQUAL CONDITION FOR INDEX

EQUAL CONDITION FOR INDEX is a search strategy.

This search strategy can be used for search conditions that contain an equality condition for all columns of an index.

The system uses the inversion list to access the corresponding table rows directly.

See also:

List of All Search Strategies


EQUAL CONDITION FOR INDEX (SUBQ) (MaxDB: Background Knowledge)

EQUAL CONDITION FOR INDEX (SUBQ)

EQUAL CONDITION FOR INDEX (SUBQ) is a search strategy.

This search strategy can be used for search conditions that contain an equality condition for all columns of an index.

The values for the inversion list come from a subquery.

See also:

List of All Search Strategies


EQUAL CONDITION FOR KEY COLUMN (MaxDB: Background Knowledge)

EQUAL CONDITION FOR KEY COLUMN

EQUAL CONDITION FOR KEY COLUMN is a search strategy.

This search strategy can be used if both of the following conditions are fulfilled:

· The table has only one key column.

· An equality condition is specified for this key column in the search condition.

In this search strategy, the system accesses the appropriate table rows directly.

See also:

List of All Search Strategies


EQUAL CONDITION FOR KEY COLUMN (SUBQ) (MaxDB: Background Knowledge)

EQUAL CONDITION FOR KEY COLUMN (SUBQ)

EQUAL CONDITION FOR KEY COLUMN (SUBQ) is a search strategy.

This search strategy can be used if both of the following conditions are fulfilled:

· The table has only one key column.

· An equality condition is specified for this key column in the search condition.

The values for the key column come from a subquery.

See also:

List of All Search Strategies


IN CONDITION FOR INDEX (MaxDB: Background Knowledge)

IN CONDITION FOR INDEX

IN CONDITION FOR INDEX is a search strategy.

This search strategy can be used in the following cases:

· The search condition contains an IN condition for the first column of an index that consists of multiple columns.

· The search condition contains equality conditions for the first (k-1) columns of an index of this type and an IN condition for its k-th column.

The system uses the inversion lists to access the corresponding table rows directly.

See also:

List of All Search Strategies


IN CONDITION FOR KEY COLUMN (MaxDB: Background Knowledge)

IN CONDITION FOR KEY COLUMN

IN CONDITION FOR KEY COLUMN is a search strategy.

This search strategy can be used if the following applies:

· The table has only one key column.

· The search condition contains an IN condition for this key column.

The system accesses the corresponding table rows directly.

See also:

List of All Search Strategies


JOIN VIA INDEXED COLUMN (MaxDB: Background Knowledge)

JOIN VIA INDEXED COLUMN

JOIN VIA INDEXED COLUMN is a search strategy for joins.

This search strategy can be used if an index was created for the join column, and this index only contains this one column.

The rows of the new table are accessed through the index of the join column.

See also:

List of All Search Strategies


JOIN VIA KEY COLUMN (MaxDB: Background Knowledge)

JOIN VIA KEY COLUMN

JOIN VIA KEYCOLUMN is a search strategy for joins.

This search strategy can be used if the join column is the only key column.

The system accesses the table rows in the new table directly.

See also:

List of All Search Strategies


JOIN VIA KEY RANGE (MaxDB: Background Knowledge)

JOIN VIA KEY RANGE

JOIN VIA KEY RANGE is a search strategy for joins.

This search strategy can be used if the join column is the first key column.

Within the key range, the system accesses the table rows in the new table sequentially.

See also:

List of All Search Strategies


JOIN VIA MULTIPLE INDEXED COLUMNS (MaxDB: Background Knowledge)

JOIN VIA MULTIPLE INDEXED COLUMNS

JOIN VIA MULTIPLE INDEXED COLUMNS is a search strategy for joins.

This search strategy can be used if the join columns can be combined in a complete index that includes multiple columns.

The rows of the tables that you want to join are accessed through this index.

See also:

List of All Search Strategies


JOIN VIA MULTIPLE KEY COLUMNS (MaxDB: Background Knowledge)

JOIN VIA MULTIPLE KEY COLUMNS

JOIN VIA MULTIPLE KEY COLUMNS is a search strategy for joins.

This search strategy can be used if the join columns can be combined in the key of the new table. This key consists of multiple columns.

The system accesses the table rows in the new table directly.

See also:

List of All Search Strategies


JOIN VIA RANGE OF MULTIPLE INDEXED COL. (MaxDB: Background Knowledge)

JOIN VIA RANGE OF MULTIPLE INDEXED COL.

JOIN VIA RANGE MULTIPLE INDEXED COL. is a search strategy for joins.

This search strategy can be used if the join columns can be combined in the initial part of an index that includes multiple columns.

Within the index range, the system accesses the rows of the table.

See also:

List of All Search Strategies


JOIN VIA RANGE OF MULTIPLE KEY COLUMNS (MaxDB: Background Knowledge)

JOIN VIA RANGE OF MULTIPLE KEY COLUMNS

JOIN VIA RANGE MULTIPLE KEY COLUMNS is a search strategy for joins.

This search strategy can be used if the join columns can be combined as the initial part of the key of the new table. This key consists of multiple columns.

Within the key range, the system accesses the table rows in the new table sequentially.

See also:

List of All Search Strategies


NO RESULT SET POSSIBLE (MaxDB: Background Knowledge)

NO RESULT SET POSSIBLE

The Optimizer recognizes any search conditions that can have no logical result. In this case, no search is performed.

See also:

List of All Search Strategies


NO STRATEGY NOW (ONLY AT EXECUTION TIME) (MaxDB: Background Knowledge)

NO STRATEGY NOW (ONLY AT EXECUTION TIME)

NO STRATEGY NOW (ONLY AT EXECUTION TIME) is a search strategy.

If the column values of a subquery are not known until the subquery is executed, then the most effective search strategy for accessing the table is not determined until the values are provided.

See also:

List of All Search Strategies


RANGE CONDITION FOR KEY COLUMN (MaxDB: Background Knowledge)

RANGE CONDITION FOR KEY COLUMN

RANGE CONDITION FOR KEY COLUMN is a search strategy.

This search strategy is used if a range condition exists for a key column.

The system performs a sequential search of the specified range of the table.

See also:

List of All Search Strategies


RANGE CONDITION FOR KEY COLUMN (SUBQ) (MaxDB: Background Knowledge)

RANGE CONDITION FOR KEY COLUMN (SUBQ)

RANGE CONDITION FOR KEY COLUMN (SUBQ) is a search strategy.

This search strategy is used if a range condition exists for a key column.

The values for the key column come from a subquery.

See also:

List of All Search Strategies


RANGE CONDITION FOR INDEX (MaxDB: Background Knowledge)

RANGE CONDITION FOR INDEX

RANGE CONDITION FOR INDEX is a search strategy.

This search strategy can be used if the search condition contains equality conditions or range conditions for the first k columns of an index.

The system uses the inversion lists in this range to access the corresponding table rows directly.

See also:

List of All Search Strategies


RANGE CONDITION FOR INDEX (SUBQ) (MaxDB: Background Knowledge)

RANGE CONDITION FOR INDEX (SUBQ)

RANGE CONDITION FOR INDEX (SUBQ) is a search strategy.

This search strategy can be used if the search condition contains equality conditions or range conditions for the first k columns of an index.

The values of the index columns come from a subquery.

See also:

List of All Search Strategies


INDEX SCAN (MaxDB: Background Knowledge)

INDEX SCAN

INDEX SCAN is a search strategy.

The system performs a sequential search of the entire specified index.

See also:

List of All Search Strategies


TABLE SCAN (MaxDB: Background Knowledge)

TABLE SCAN

TABLE SCAN is a search strategy.

The system performs a sequential search of the entire table.

See also:

List of All Search Strategies


Cost Determination (MaxDB: Background Knowledge)

Cost Determination

The Optimizer determines the costs of every possible search strategy.

When it determines the costs, the Optimizer only considers the expected number of I/O operations needed for the various search strategies. One I/O operation copies precisely one page. To make an estimate of the expected hit list, the Optimizer takes samples and uses the statistics provided by the database system.

The Optimizer does not consider costs incurred by resources such as CPU time or memory usage.

The cost of a search strategy is largely dependent upon the form of the search condition specified in the SQL statement. You must write your SQL statements so that they scan only those rows of the database tables that are actually needed. Results tables and temporary results tables must also be kept as small as possible.

You can use the EXPLAIN statement to examine the costs determined by the Optimizer for an SQL statement.


Troubleshooting (MaxDB: Background Knowledge)

Troubleshooting

If the database system is taking too long to process an SQL statement, perform the following steps:

..

1. Use the EXPLAIN statement to find out which search strategy the Optimizer is using for the SQL statement.

2. Check your database design.


EXPLAIN Statement (MaxDB: Background Knowledge)

EXPLAIN Statement

You can use the EXPLAIN statement to find out which search strategy the Optimizer selected for an SQL statement.

Syntax

EXPLAIN <query_statement>

EXPLAIN SELECT *

FROM example

WHERE firstkey > 30

The result of an EXPLAIN statement is a table. The STRATEGY column shows you which search strategy the Optimizer selected for this SQL statement. The PAGECOUNT column shows you the costs determined for the chosen search strategy.

The EXPLAIN statement gets the following table:

TABLE NAME | COLUMN_ OR_INDEX | STRATEGY | PAGE COUNT
EXAMPLE | FIRSTKEY | RANGE CONDITION FOR KEY COLUMN RESULT IS NOT COPIED, COSTVALUE IS | 1250 97

This means that the table example has 1250 pages; the I/O costs for executing this SQL statement are 97 pages.

For a complete syntax description for the EXPLAIN statement, see the Reference Manual, under EXPLAIN Statement (explain_statement).

See also:

· EXPLAIN Statement for Joins

· EXPLAIN Statement for Complicated SELECT Statements

· EXPLAIN Statement for SELECT Statements with Subqueries


EXPLAIN Statement for Joins (MaxDB: Background Knowledge)

EXPLAIN Statement for Joins

The following information is displayed if the EXPLAIN statement is used for joins:

· The order in which the tables are processed when the SELECT statement is executed

· Whether the rows of a new table can be accessed directly from the values in the join columns of the old temporary results table or whether they can be accessed through an inversion

· The strategy used to search the new table, if the rows of this table cannot be accessed directly or using an inversion

EXPLAIN SELECT one.key ten1.keyft1, ten2.keyft2
FROM one, ten1, ten2
WHERE ten1.keyft1 < 100
  AND ten1.ft1    = one.keyf
  AND one.indf    = ten2.keyft2
  AND ten2.keyft2 < 100;

This EXPLAIN statement gets the following result:

TABLE NAME

COLUMN_
OR_INDEX

STRATEGY

PAGE COUNT

TEN1

ONE

TEN2

KEYFT1

KEF

KEYFT2

RANGE CONDITION FOR KEY COLUMN

JOIN VIA KEY COLUMN

JOIN VIA KEY COLUMN

RESULT IS COPIED, COSTVALUE IS

1250

125

1463

97

This result is interpreted as follows:

§ The joins of the tables are performed in the order TEN1, ONE, TEN2.

§ The table TEN1 has a total size of 1250 pages, the table ONE has 125 pages, and the table TEN2 has 1463 pages.

§ The I/O costs for executing the SQL statement are 97 pages.

§ The table TEN1 is selected with the key keyft1. The table ONE is accessed with the primary key KEF. The table TEN2 is accessed with the primary key KEYFT2.

See also:

Explanations of the examples


EXPLAIN Statement for Complicated SELECT Statements (MaxDB: Background Knowledge)

EXPLAIN Statement for Complicated SELECT Statements

The Optimizer breaks down complicated SELECT statements into multiple internal SELECT steps that create temporary results.

For SELECT statements of this type, the EXPLAIN statement provides multiple search strategies. INTERNAL TEMPORARY RESULT is specified as the table name. Searches across internal temporary results of this type are only ever sequential.


EXPLAIN Statement for SELECT Statements with Subqueries (MaxDB: Background Knowledge)

EXPLAIN Statement for SELECT Statements with Subqueries

To determine the cost of search strategies where the value of a column is compared with the hit rows of a subquery, the Optimizer must know the number of hit rows. However, the number of hit rows is not known until the subquery has been processed.

For a SELECT statement with subqueries, the EXPLAIN statement determines the possible search strategies, but does not execute these subqueries. Therefore, the search strategy NO STRATEGY NOW (ONLY AT EXECUTION TIME) is usually displayed for the outer SQL statement.


Column STRATEGY (MaxDB: Background Knowledge)

STRATEGY Column

The result of the EXPLAIN statement is a table that consists of multiple columns. The STRATEGY column displays the search strategy used by the Optimizer for the SQL statement. The list of all search strategies shows you the various strategies, together with explanations.

As well as the search strategy, the Optimizer can also display the following information in the STRATEGY column:

Note | Meaning
ONLY INDEX ACCESSED | Only the specified index is used to process the SQL statement; the data in the basis table is not accessed. This is possible only if the SQL statement addresses only those columns that are included in the index structure.
DISTINCT OPTIMIZATION (A) | The complete key is included in the SELECT list/output columns. This means that the result is automatically free from duplicates.
DISTINCT OPTIMIZATION (C) | Complete secondary key After the key word DISTINCT, all columns of an index (and only these columns) are specified in a random order (DISTINCT Specification (distinct_spec)). The system accesses the values for each index column only once. No results table is created. SELECT DISTINCT <all_columns_of_index> FROM ...
DISTINCT OPTIMIZATION (P) | Partial secondary key After the key word DISTINCT, the first k (where k < total number of index columns) columns of an index are specified in a random order. The system accesses the values for each index column only once. No results table is created. SELECT DISTINCT <first_k_columns_of_index> FROM ...
DISTINCT OPTIMIZATION (K) | Primary key After the key word DISTINCT, all columns of an index and the first k (where k < total number of index columns) columns of the key are specified in a random order. The system accesses the values for the corresponding index and key columns only once. No results table is created. SELECT DISTINCT <all_columns_of_index_+_first_k_columns_of_key> FROM ...
TEMPORARY INDEX CREATED | A temporary index is created internally, in which the keys of the hit rows determined by the corresponding index columns are stored in ascending order. The system accesses the basis table using this temporary index.
ADDNL. QUALIFICATION ON INDEX | There are search conditions for index or key columns that cannot be used for the direct containment of the range for accessing an index (for example, in the case of an equality /IN condition, for the first and third columns of a multi-column index, only the first search condition of the search strategy is used for accessing the index). The usage of these search conditions for restricting access to the basis table makes them part of the corresponding index strategy

For more information on the structure of the results table, see the Reference Manual under EXPLAIN Statement.


Tips on Database Design (MaxDB: Background Knowledge)

Tips on Database Design

As well as search conditions, the following factors also affect the way SQL statements are processed, and therefore the performance of database applications.

· Type of SQL statement (SELECT, INSERT, UPDATE, DELETE)

· Elements of a SELECT statement (ORDER clause, UPDATE clause, DISTINCT specification, and specification of FOR REUSE)

· Changes that are specified in the UPDATE statement

· Type of physical storage of a table and the size of the tables (number of rows and B* tree pages)

Many performance problems can be avoided by implementing the following tips when you design your database:

· Before you define your tables, examine the structures and use the results in your table definitions. When you define the key columns, ensure that any especially selective columns, and any columns for which search conditions are specified especially often, are placed at the beginning of the key. This gives you the option of considering only a very small part of the table when processing a SELECT statement.

· Only columns that are as selective as possible should be inverted. Do not choose columns such as gender or marital status as index keys, due to their low number of different values. These columns can only be used very rarely for a non-sequential search, since these searches would usually be more costly than a sequential search.

· In the case of relatively static datasets, a large number of columns can be inverted. In doing so, you must ensure, as with the definition of the key columns, that you specify columns that are as selective as possible, and that are often used in equality conditions at the beginning of the index.

· If possible, do not invert all of the columns that are used in search conditions. The space needed for the indexes and the cost of maintaining them is considerable.

· If a large number of changes have been made in a table, you should run the UPDATE STATISTICS statement.

· You should only formulate search conditions that cannot be fulfilled by all rows. Applications are often written so that the user determines the values of a search condition. If the user does not enter any values, default values are inserted into the search condition, so that it always returns “true”. The database system must now evaluate this ineffective search condition for every row that needs to be searched. It is better to execute different SELECT statements depending on the user input

· You should place the most selective search conditions at the beginning of the condition, since it may be possible to terminate the check earlier.

· The specification
columnx IN (1,13,24,...)
can be evaluated more efficiently by the Optimizer than the semantically identical specification
columnx=1 OR columnx=13 OR columnx=24 OR ...


Terms (MaxDB: Background Knowledge)

Terms

Inverted Column

Inversion List

See also:

Documentation Database Administration, Terms


Inverted Column (MaxDB: Background Knowledge)

Inverted Column

An inverted column is a column that is part of an index.


Inversion List (MaxDB: Background Knowledge)

Inversion List

An inversion list is a list of keys that belong to an index. In each column of the index, all table rows whose keys are specified in the list contain the same value for this column.


Examples (MaxDB: Background Knowledge)

Examples

The examples used in this documentation refer to the following tables and indexes:

· Tables (example, one, ten1, ten2)

· Indexes (invcolumn1, invcolumn2, indf, ind)


example (MaxDB: Background Knowledge)

example

Definition of the table example

EXEC SQL CREATE TABLE example
  (firstkey         FIXED (3) KEY,
   secondkey        FIXED (4) KEY,
   normalcolumn     FIXED (5),
   invcolumn1       CHAR (15),
   invcolumn2       CHAR (9),
   multinvcolumn1   CHAR (22),
   multinvcolumn2   CHAR (5,
   multinvcolumn3   CHAR (8,
   PRIMARY KEY (firstkey, secondkey));

Two single-column indexes (invcolumn1 and invcolumn2), and one multi-column index ind are defined for the example table.


ind (MaxDB: Background Knowledge)

ind

Definition of the index ind

EXEC SQL CREATE INDEX ind ON example (multinvcolumn1, multinvcolumn2, multinvcolumn3);


indf (MaxDB: Background Knowledge)

indf

Definition of the index indf

EXEC SQL CREATE INDEX indf on one (indf);


invcolumn1 (MaxDB: Background Knowledge)

invcolumn1

Definition of the index invcolumn1

EXEC SQL CREATE INDEX invcolumn1 ON example (invcolumn1);


invcolumn2 (MaxDB: Background Knowledge)

invcolumn2

Definition of the index invcolumn2

EXEC SQL CREATE INDEX invcolumn2 ON example (invcolumn2);


one (MaxDB: Background Knowledge)

one

Definition of the table one

EXEC SQL CREATE TABLE one
  (keyf         FIXED (6),
   indf         FIXED (3),
   ...,
   PRIMARY KEY (keyf));   /*1000 rows*/

The index indf is created for the table one.


ten1 (MaxDB: Background Knowledge)

ten1

Definition of the table ten1

EXEC SQL CREATE TABLE ten1
  (keyft1         FIXED (6),
   ft1            FIXED (3),
   ...,
   PRIMARY KEY (keyft1));   /*10000 rows*/


ten2 (MaxDB: Background Knowledge)

ten2

Definition of the table ten2

EXEC SQL CREATE TABLE ten2
  (keyft2         FIXED (6),
   ...,
   PRIMARY KEY (keyft2));   /*10000 rows*/


High Availability (MaxDB: Background Knowledge)

High Availability

High availability means that an IT system is always operational.

A database system can fail as a result of physical errors, such as a defect with the hard drive, power failure, CPU failure, or problems with the main memory. It can also fail because of logical errors, such as the deletion of required software or data or the import of unsuitable data.

There are precautions that you can take on both a hardware level and a logical level to increase the availability of a database system.

High availability strategies exceed classic precautionary measures and are usually only necessary for large or particularly critical systems. The following high availability strategies can be used with the database system:

· Standby databases

· Hot standby with clustering

· Creating a homogeneous system copy

The method most suitable for your system depends on your specific system requirements.

See also:

Security Guide


Standby Databases (MaxDB: Background Knowledge)

Standby Databases

For a high availability of your database, MaxDB supports the setup of standby databases.

A standby instance is a copy of the active database instance (original instance). To keep the contents of your database up-to-date, the log backups of the original instance are imported at regular intervals. The standby instance always has the operational state ADMIN.

If you experience problems with the original instance, you can start operating the standby instance immediately, and carry on working without any lengthy period of downtime.

Depending on the configuration, you can also restore the standby instance to a previous status that it has had at any given point in the past.

See also:

Example


Setting Up a Standby Instance (MaxDB: Background Knowledge)

Setting Up a Standby Instance

This section describes how you set up a standby database.

Procedure

Use the Database Manager to carry out the following steps:

...

1. Create the standby instance by making a copy of your original instance. Proceed as described in Creating a Homogeneous System Copy (points 1-5). However, do not start the copy in the operational state ONLINE. Keep the copy in the operational state ADMIN instead.

You must set up the original instance and the standby instance on different computers.

2. In the standby instance, create a backup medium for importing log backups.

3. Make log backups in your active original instance at regular intervals.

4. At regular intervals, import these log backups into your standby instance with the time delay of your choice.

In the Database Manager GUI, import the backups as described under Restoring Without a Backup History.

In the Database Manager CLI, use the restore commands recover_start and recover_replace.

Notes

Keep the following points in mind:

· The data volumes and log volumes of the standby instance must be configured with enough space to be able to import the log backups of the original instance.

· The two instances cannot access the same files. This means that their run directories must be physically separate.

· You can use pipes to transport the data backup. You can transport log backups by ftp or use an exported file system (such as NFS or a shared file system) to copy them.


Starting the Standby Instance as an Active Instance (MaxDB: Background Knowledge)

Starting the Standby Instance as an Active Instance

If you experience problems with your original instance, then you can stop it, and switch the operational state of the standby instance to ONLINE. The standby instance can then take over the role of the active instance immediately.

Loss of Data

Remember that in this procedure, after you start the standby instance, it does not contain any data changes that have not yet been imported in log backups from the original instance.

If you want to start the standby instance without losing any data, or you want to start it in a state from the past, you have the following options, depending on the configuration and state of your original instance:

· Importing Log Backups up to a Specific Time

· Importing Another Manual Log Backup

· Copying the Log Volumes of the Original Instance

Prerequisites

· You have set up a standby instance.

· The standby instance has not been in the operational state ONLINE since it was last initialized.

Procedure

Use the Database Manager for the following steps:

...

1. Make sure that the original instance is in the operational state OFFLINE.

2. Start the standby instance in the operational state ONLINE.

3. In this standby instance, restore any indexes that are no longer up-to-date ( BAD INDEXES).

In the Database Manager GUI, proceed as described in Restoring the Indexes After a Database Restore.

In the Database Manager CLI, use the command sql_recreateindex to recreate a damaged index.

4. Make a complete data backup of the standby instance.

Result

You can now operate the former standby instance as an active database instance. The original instance can become the standby instance. To do this, initialize the original instance, and proceed as described in Setting Up a Standby Instance.


Importing Log Backups up to a Specific Time (MaxDB: Background Knowledge)

Importing Log Backups up to a Specific Time

You can start the standby instance in a state from the past. You may need to do this if, for example, you lose data during an operation in the original instance, and want to restore it to the state it was in before that operation.

Prerequisites

· You have set up a standby instance.

· The standby instance has not been in the operational state ONLINE since it was last initialized.

· You have imported the log backups from the original instance only up to a point in time before your chosen restore time.

Procedure

If the log backups are imported automatically from the original instance into the standby instance, then cancel the imports (recover_cancel), and import manually any log backups that are missing, up until your chosen time. Proceed as follows:

· When you import the relevant log backup in the Database Manager GUI, choose the option Restore until a specific time (see also Restoring Without a Backup History).

· When you import the relevant log backup in the Database Manager CLI, use the command recover_start with the option UNTIL <date> <time> (see also Commands for Restoring).

Result

The log entries are imported into the standby instance up to the chosen time. Any changes you have made after this time in the original instance are ignored by the standby instance.

You can now start operating the standby instance as an active instance.


Importing Another Manual Log Backup (MaxDB: Background Knowledge)

Importing Another Manual Log Backup

If it is possible to create another manual (interactive) log backup in the original instance, then you can start the standby instance without losing data, which means that it is in the same state as the original instance.

Prerequisites

· You have set up a standby instance.

· The standby instance has not been in the operational state ONLINE since it was last initialized.

· The log volumes of the original instance are not damaged.

· You can create a log backup in the original instance in the operational state ADMIN.

Procedure

...

1. Create an interactive log backup in the original instance.

2. Import this log backup into the standby instance.

Result

You can now start operating the standby instance as an active instance.


Copying the Log Volumes of the Original Instance (MaxDB: Background Knowledge)

Copying the Log Volumes of the Original Instance

If the log volumes of the original instance are not damaged, and you can use operating system tools to copy their content to the log volumes of the standby instance, then you can start the standby instance without losing data and in a state from the past.

Prerequisites

· You have set up a standby instance.

· The standby instance has not been in the operational state ONLINE since it was last initialized.

· The log volumes of the original instance are not damaged.

· The number of log volumes and their size are the same in both instances.

· The original instance is in the operational state OFFLINE.

Procedure

...

1. If the log backups are imported automatically from the original instance into the standby instance, then cancel the imports (recover_cancel).

2. Use operating system tools to copy the log volumes from the original instance to the standby instance.

3. Import any missing log backups from the original instance into the standby instance.

Result

You can now start operating the standby instance as an active instance.

You can also start the standby instance in a state from a time chosen in the past.

To do this in the Database Manager GUI, choose Instance ® Restart Until.

To do this in the Database Manager CLI, use the command db_online –u.


Example: Standby Database (MaxDB: Background Knowledge)

Example: Standby Database

This example of an input script shows you how to use the CLI Database Manager to set up a standby instance and start operating it as an active instance.

For more detailed information on working with the CLI Database Manager administration tool, and the meaning of the DBM commands, see Database Manager CLI.

Input Script

Switch an instance to ADMIN mode:
db_offline
db_admin

Creating a backup medium in the standby instance for importing a complete data backup from the original instance:
medium_put <medium_name_data> <path_data> <medium_type> DATA

Initializing the existing standby instance and importing the data backup:
util_connect
db_activate RECOVER <medium_name_data>
util_release

Creating a backup medium in the standby instance for importing the log backups from the original instance:
medium_put <medium_name_log> <path_log>\save.log FILE LOG

The log backups are numbered automatically and saved in the save.log <nnn> file at the <path_log> path. Type in the db_restartinfo command to find out which log standby has to be imported first. The Used Log Page line shows the next log page from which log entries have to be read.

The log history in the original system shows which log pages are included in the log backup. The following commands give you access to the log history: backup_history_open
backup_history_list
backup_history_close.

Importing the backup logs:
db_offline
db_admin
util_connect
recover_start <medium_name_log> LOG 001
recover_replace <medium_name_log> <path_log>\save.log 002
recover_replace <medium_name_log> <path_log>\save.log 003
...

Starting the standby instance as an active instance:
recover_ignore

In this case, the standby instance does not include the changes that have not yet been imported with the log backups from the original instance.

You can also terminate the import of the log backups without starting the standby instance in ONLINE operational state at the same time. To do this, use the command recover_cancel. The database instance is set to OFFLINE mode. Before you are able to run other commands, you must first use the db_admin command to switch the operational state of the standby instance to ADMIN.

See also:

DBM Commands: Overview


Hot Standby (MaxDB: Background Knowledge)

Hot Standby

Hot standby is a high availability strategy. If the active database instance fails, the hot standby enables you to switch immediately to a standby database instance that is running in parallel to the database instance that has failed.

A hot standby system consists of an active master instance (master component) and one or more standby components that are installed in a cluster configuration (see also Architecture of a Hot Standby System). On the outside, the hot standby system behaves like any normal database instance.

If an error occurs in the master instance, a standby component can take on the role of the master component automatically. This is faster than a standard cluster solution and means that no data is lost. The process is guaranteed by a special fail over mechanism in the cluster software.

Setting Up a Hot Standby System

To set up a hot standby system, you need to install a database instance that will take on the role of the master component. You then add as many standby components as you want to use.

When you initialize a new standby component, the memory management system takes the entire contents of the master component data area in a consistent state, for example, the state it was in at the point of the most recent savepoint, and copies it into the data area of the standby component.

See also:

System Requirements

Database Manager CLI: Setting Up a Hot Standby System

Database Manager GUI: Setting Up Master Components (Hot Standby) and Adding Standby Components (Hot Standby)


System Requirements (MaxDB: Background Knowledge)

System Requirements

If you want to set up a hot standby system, you need the database software, a cluster solution, and a memory management system.

Database software

Hot standby systems can be set up for MaxDB databases with version 7.5.08 or higher.

Cluster solution

A cluster solution enables you to combine several physical components logically, meaning not on the hardware side. A hot standby system consists of two or more computers in a cluster configuration.

The cluster software must provide a special fail over mechanism that enables the master component to switch roles with a standby component if the system crashes. The cluster software has to monitor the hot standby components constantly to enable this to happen. Since the master component and the standby components within the cluster configuration each have their own internal network address, the cluster software must support IP switching.

Setting up a hot standby system with MaxDB has been tested for the following cluster solution: IBM High Availability Cluster Multiprocessing for AIX clustering software.

Memory management system

The volumes of the master component and of the standby components have to be stored in a memory management system that fulfills the following requirements:

· The components are both able to access the log area at the same time.

· There are two different access authorizations for the log area; “read only” and “read and write”.

· Each data volume has its own physical storage area.

· The data volumes can be accessed using the same name or you can set up a corresponding symbolic link.

· You are able to create consistent copies of the data volumes (split.) When a copy is being created, the master component is able to continue to write to its data volume so that the downtime is kept to a minimum. After the split, the data volume for the master component is completely independent of the data volume for the standby components.

· When standby components are initialized, and in the case of an error, large amounts of data sometimes have to be copied. A memory management system therefore has to be set up so that data can be copied quickly and work can continue.

The following memory storage systems fulfil these requirements and support the set up of a hot standby system with MaxDB: EMC Symmetrix, IBM TotalStorage Enterprise Storage Server (ESS), IBM TotalStorage SAN Volume Controller (SVC).


Architecture of a Hot Standby System (MaxDB: Background Knowledge)

Architecture of a Hot Standby System

A hot standby system consists of a master component and one or more standby components. On the outside, the hot standby system behaves like any normal database instance. Within the cluster system, the individual components communicate with one another using internal local addresses.

If you want to access the hot standby system from outside the cluster, you need the common name of the database instance and the official name of the component, on which the database runs. If the master component is not available, this official name is transferred to the standby component, which adopts the functions of the master component.

The standby components are in STANDBY operational state , which is a status between ADMIN state and ONLINE state. In STANDBY state, standby component is not a real instance. It only becomes a real instance if the master instance is not available, in which case the standby component adopts the function of the master instance.

Master components and standby components each have their own independent data areas. However, they both access the same log area. Standby components only have read access to this log area.

You must mirror the log area to protect against hardware errors.

Unlike hot standby systems, standby databases have separate log areas for all instances.

Both master components and standby components have their own kernel, caches, X server, DBM server, and so on, but they use the same database parameters.

See also:

Synchronizing Master Components and Standby Components


Synchronizing Master Components and Standby Components (MaxDB: Background Knowledge)

Synchronizing Master Components and Standby Components

Standby components in a hot standby system are constantly being synchronized with the master component. The log entries that the master component writes to the log area are redone in the standby component automatically.

The dataset of a standby component always corresponds, albeit with a slight time delay, to the dataset of the master component. You use the special database parameter HS_DELAY_TIME to configure this time delay.

Unlike standby components, with standby instances log backups are only imported periodically.

The synchronization of standby components with the master component is triggered by the system at specific times. The master component regularly informs the standby components (special database parameter HY_SYNC_INTERVAL) of the position up to which new log entries have been written. This enables modifications that have been made since the last synchronization to be redone. The standby components report back to the master component, telling it the point up to which they have finished reading the log. The standby components then redo the log entries up to a certain point in time (HS_DELAY_TIME.)

The master component and the standby components use the same database parameter. When a new standby component is set up, it is given an exact copy of the parameter used by the master component. Any modifications to the parameter are always made to the master component and passed on to all the standby components automatically.


How a Hot Standby System Behaves when an Error Occurs (MaxDB: Background Knowledge)

How a Hot Standby System Behaves when an Error Occurs

The cluster software constantly monitors the master component of the hot standby system. If the master component fails, the cluster software notifies one of the standby components that it must take over from the master component.

The new standby component adopts the official name (that is used to address the system externally) from the master component.

The standby component is given authorization to write to the log volume and redoes the most recent log entries that have not yet been read, in particular, it redoes all of the transactions that end with a COMMIT. The standby component then switches automatically to ONLINE operational mode.

The hot standby system configuration does not protect the system against errors caused by users or an application. You therefore must make regular data and log backups in your hot standby system to protect it against these types of error.

If an error does occur, you need to import the data backups and log backups from a specific point in time in the past. For more information refer to the Database Manager GUI: Restoring Data documentation and the Database Manager CLI: Saving and Recovering Database Instances documentation.


Creating a Homogeneous System Copy (MaxDB: Background Knowledge)

Creating a Homogeneous System Copy

Use

You want to create a copy of your database instance, for example, for test or development purposes, or to set up a standby database.

Prerequisites

The prerequisites that apply depend on the type of database instance that you want to copy:

· OLTP or archive type of database instance: The processor architecture of the source computer is compatible with that of the target computer.

· liveCache type of database instance: Both the processor architectures and the operating systems of the source and target computers are identical, and you are using the same DB procedures on both computers.

Procedure

Use the Database Manager to carry out the following steps:

...

1. Make a complete data backup of the original instance.

2. Initialize an existing target instance, or install a new target instance for recovery.
The target instance must have the same database instance type as the original instance, and the same software version 7.x.

The target instance must not switch to the operational state ONLINE before you import the data backup from the original instance (step 5). If the target instance has already been ONLINE, reinitialize it.

3. Configure the data volumes of the target instance so that they have enough space for the import of the complete data backup of the original instance (10% larger than the complete data backup of the original instance, for example).

4. In the target instance, create a backup medium for importing data backups. The medium you use must be compatible with the medium that you used to create the complete data backup of the original instance.

5. Import the complete data backup of the original instance into the target instance.

If you are using the Database Manager GUI, proceed as described under Restoring Without a Backup History.

6. Start the target instance.

7. Update the system tables in the target instance.

8. In the target instance, restore any indexes that are no longer up-to-date (BAD INDEXES).

Example

Homogeneous System Copy with the Database Manager CLI


Operating System Compatibility for Homogeneous System Copies (MaxDB: Background Knowledge)

Operating System Compatibility for Homogeneous System Copies

If you want to create a homogeneous system copy of your database instance, the processor architectures of the source and target computers must be compatible. The following compatibility matrix applies to MaxDB database instances:

 | Win32 | Win64 | Linux 32 | Linux 64 | Tru64 | AIX | HP-UX | Solaris
Win32 | . | . | . | . | . |  |  |
Win64 | . | . | . | . | . |  |  |
Linux 32 | . | . | . | . | . |  |  |
Linux 64 | . | . | . | . | . |  |  |
Tru64 | . | . | . | . | . |  |  |
AIX |  |  |  |  |  | . | . | .
HP-UX |  |  |  |  |  | . | . | .
Solaris |  |  |  |  |  | . | . | .

The media that you use for creating and importing the data backup must also be compatible.


Homogeneous System Copy with the Database Manager CLI (MaxDB: Background Knowledge)

Homogeneous System Copy with the Database Manager CLI

You can generate a homogeneous system copy of your database instance by using the following DBM commands:

Creating a backup medium for complete data backups in the original instance:

dbmcli -d TST -u dbm,dbm medium_put databasecopy /usr/sapdb/dbcopy FILE DATA 0 0 NO

Creating a complete data backup of the original instance:

dbmcli -d TST -u dbm,dbm -uUTL -c backup_start databasecopy

Installing the target instance:

dbmcli -s –R <dependent_path> db_create TST1 dbm,dbm

Copying and modifying database parameters from the original instance:

dbmcli -d TST1 -u dbm,dbm -uSRV -c recover_config databasecopy
dbmcli -d TST1 -u dbm,dbm
  > param_startsession
  > param_put RUNDIRECTORY <newrundirectory>
  > param_put DIAG_HISTORY_PATH <newdiaghistorypath>
  > param_checkall
  > param_commitsession

Configuring data volumes of the target instance:

dbmcli -d TST1 -u dbm,dbm param_addvolume DATA <newdatavolume> <datatype> <datasize>
dbmcli -d TST1 -u dbm,dbm param_addvolume LOG <newlogvolume> <logtype> <logsize>

Creating the backup medium in the target instance:

dbmcli -d TST1 -u dbm,dbm medium_put databasecopy /usr/sapdb/dbcopy FILE DATA 0 0 NO

Switching the target instance to the operational state ADMIN:

dbmcli -d TST1 -u dbm,dbm db_admin

Initializing the target instance:

dbmcli -d TST1 -u dbm,dbm util_execute INIT CONFIG

Importing the data backup of the original instance into the target instance:

dbmcli -d TST1 -u dbm,dbm -uUTL -c recover_start databasecopy

Switching the target instance to the operational state ONLINE:

dbmcli -d TST1 -u dbm,dbm db_online

Loading the system tables, assigning passwords for SYSDBA and DOMAIN users:

dbmcli –d TST1 –u dbm,dbm load_systab –u <sysdba>,<password> -ud <password2>


Performance (MaxDB: Background Knowledge)

Performance

When you set up a new database instance, you make decisions that will later have an significant influence on operational performance.

· The tips on setting up a database instance show you how to obtain a good I/O performance.

· Also refer to tips on database design for information on how to achieve short access times when requesting data.

· Make sure you choose appropriate database parameters.

The database analyzer and other database tools help you to analyze operational performance.

The database system carries out internal load balancing and uses the SQL optimizer to optimize data access.


Tips on Setting Up a Database Instance (MaxDB: Background Knowledge)

Tips on Setting Up a Database Instance

The following tips on setting up a new database instance are recommendations that will help you achieve a good operational I/O performance.

· If you want to operate several database instances, install each database instance on a separate computer.

· Store data volumes and log volumes on different disks. The log volumes are the areas of the database instance that see the most write activity, because all the data modifications are logged in them.

· Even if you use RAID 5 systems, configure the database instance with several data volumes. Working with several data volumes gives you a better performance than a single one, because some parallel mechanisms used by the database system depend on the number of configured data volumes.

· Create log volumes on dedicated disks or RAID 1 systems only and not on RAID 5 systems.

· Do not swap areas or paging areas on the same disk as the log entries.

· In UNIX systems, use raw devices for the data volumes and the log volumes, because generally it is quicker to access data in raw devices than it is to access data in files.


Load Balancing (MaxDB: Background Knowledge)

Load Balancing

The load balancing concept has been developed in order to achieve an optimum distribution of tasks across the available user kernel threads. This enables the database system to use its resources more effectively, particularly on computers with multiple processors, which leads to shorter response times for individual users.

Load balancing is possible for database instances from Version 7.4.03.

The operating system cannot influence how the database system tasks are distributed across the available user kernel threads. This means that it cannot intervene if a user kernel thread is using a processor to its full capacity, while, for example, the other three processors on a computer are not being used at all.

Generally, tasks display cooperative behavior in a user kernel thread. The tasks decide when to suspend themselves and let the next waiting task run in the same user kernel thread. This behavior means that a single task can block all other tasks in the same user kernel thread for a long time.

When load balancing is activated, the timer thread coordinates the distribution of the tasks across the individual user kernel threads. At regular intervals, the timer queries how long the individual tasks have been waiting in the user kernel threads, and calculates the total waits for each user kernel thread.

If the total of the waits in a particular user kernel thread is a lot larger than in another thread, the timer ensures that the task that has been waiting the longest is moved to this other thread.

User kernel thread UKT1 contains the tasks T1, T2, T3; user kernel thread UKT2 contains the task T4. T1 is in a long-running loop, while T2 and T3 are waiting.

The total of the waits in UKT1 is 210 ms, whereas the total of the waits in UKT2 is only 10ms. T2 has been waiting the longest in UKT1, and is moved to UKT2 accordingly.

Activating Load Balancing

To activate load balancing, set the special database parameter LOAD_BALANCING_CHK to a value greater than zero.

See also:

Database Manager GUI, Displaying and Changing Database Parameters

Database Manager CLI, Changing the Value of a Database Parameter


SAP Security Guide: MySQL MaxDB

The following sections describe the security measures that you should observe for the MySQL MaxDB database system.

· Security Measures for Database Standard Users

· Measures Under UNIX

· Measures Under Microsoft Windows

For information about the MaxDB database system, see Database Administration .

Other documentation: Documentation Overview


Security Measures for Database Standard Users (MaxDB: SAP Security Guide: MySQL MaxDB)

Security Measures for Database Standard Users

To protect the database standard users, you should:

· Changing the Passwords of the Standard Users

· Changing Server Authorizations for Users

Changing the Passwords of the Standard Users

To protect the standard database system users, change their passwords.

You may also want to assign the property SECONDPASSWORD, to define a second password for a user. In this way, you can allow other people temporary access to work with a user account without needing to reveal or change the original password.

Prerequisites

The database instance is in an operational state in which it is possible to change the password of the relevant user.

User | Name | Required Operational State
<DBM_user> | First Database Manager Operator (DBM Operator) | OFFLINE
<SYSDBA_user> | Database system administrator (SYSDBA user) | ONLINE
DOMAIN | DOMAIN User | ONLINE

Procedure

Database Manager GUI: Changing a User Password

Database Manager CLI: Changing the DBM User Data

Changing Server Authorizations for Users

We recommend that zou assign the server authorizations individually to the users. In this way, you distribute the various administration tasks between several users and administrators.

Procedure

Database Manager GUI: Changing the Server Authorizations

Database Manager CLI: Changing the DBM User Data

Changing the Database Manager Operator (DBM Operator) with the Database Manager CLI

Add the following server authorization for the DBM operator DBM: Starting the database instance

Delete the following server authorization for the DBM operator DBM: Stopping the database instance

user_put DBM SERVERRIGHTS=+StartDB, -StopDB


Measures Under UNIX (MaxDB: SAP Security Guide: MySQL MaxDB)

Measures Under UNIX

The following sections describe the measures that you need to take for the database system under UNIX:

· Security Measures for Operating System Users

· Authorization Concept for Database-Related Resources


Security Measures for Operating System Users (MaxDB: SAP Security Guide: MySQL MaxDB)

Security Measures for Operating System Users

To protect the operating system users, change their passwords.

User | Type | Change the Password Using
<sid>adm | UNIX user | UNIX command passwd
sqd<sid> | UNIX user | UNIX command passwd

Changing the Passwords for <sid>adm and sqd<sid>

1. Log on using the user <sid>adm.

2. Enter the passwd command at the UNIX prompt.

3. Enter the old and new passwords.

Repeat the procedure for the user sqd<sid>.

If you use Network Information Service (NIS), you should also refer to the NIS guide and the operating system documentation, since changing the password with an activated NIS may be different from changing it with passwd.


Authorization Concept for Database-Related Resources (MaxDB: SAP Security Guide: MySQL MaxDB)

Authorization Concept for Database-Related Resources

The access rights are automatically set during installation. The authorization concept for the files and directories up to database version 7.4.03 (inclusive) is shown in the table below:

Authorization Concept for SAP System Directories and Files (up to Database Version 7.4.03)

Directories | Privilege | Owner | Group | Comment
/sapdb/<SID>/sapdata | 750 | sqd<sid> | sapsys |
/sapdb/<SID>/saplog | 750 | sqd<sid> | sapsys |
/sapdb/<SID>/sapsys | 750 | sqd<sid> | sapsys |
/sapdb/<SID>/dbsys | 750 | sqd<sid> | sapsys | No longer applies as of 7.4
/sapdb/<SID>DB | 750 | sqd<sid> | sapsys |
Files |  |  |  |
/sapdb/<SID>/sapdata/* | 660 | sqd<sid> | sapsys |
/sapdb/<SID>/saplog/* | 660 | sqd<sid> | sapsys |
/sapdb/<SID>/sapsys/* | 660 | sqd<sid> | sapsys |
/sapdb/<SID>/dbsys/sys | 660 | sqd<sid> | sapsys | No longer applies as of 7.4
Raw devices for the database system | 660 | sqd<sid> |  | Link to the raw devices used as data volumes or log volumes.

You can change the access privileges. For information about how to do this, see Assigning Access Privileges for Files and Directories beschrieben.

New Developments with Database Version 7.5

As of the database version 7.5, the access privileges for the directories and files are only set during installation and, if required, by the database tools. The owner sdb and the group sdba are assigned. For more information, see the Installation Manual: Authorization Concept for UNIX Operating Systems.

In particular, all volumes also receive these access privileges. This means that all members of the sdba group have access to the volumes. If the security of your system requires it, the administrator can restrict these access privileges by assigning the volumes to instance-specific groups with a DBM command. To provide the highest level of security, the administrator can assign an empty group to a volume, so that only the database instance itself had access to the volumes.

Version 7.5 and an Older Version Are Installed Together on One Server

You may have to change the access privileges for the directory /sapdb/<SID>DB of the database version below 7.5 to 755, so that the database processes of version 7.5 have unrestricted access to all directories.


Assigning Access Privileges for Directories and Files (MaxDB: SAP Security Guide: MySQL MaxDB)

Assigning Access Privileges for Directories and Files

Before changing the access privileges, save your current settings. This procedure is only relevant for database instances up to version 7.4 (inclusive).

Saving Current Settings

Enter the following commands:

cd /usr/sap
ls -lR > sap_perm.txt

cd /sapmnt
ls -lR > sap_sw.txt

cd /sapdb/<SID>
ls -lR > sapdb_perm.txt (as of database version 7.5, only the root user can access these directories, with either read or write accesses)

Setting Access Privileges

To change the access privileges for a file or a directory, use the chmod command as shown below:

chmod <access_privileges_in_octal_format> <file_or_directory>

chmod 750 /sapdb/<SID>/sap*

chmod 750 /sapdb/<SID>/sapdata/*

chmod 750 /sapdb/<SID>/saplog/*

.

.

Do not use chmodrecursively. It is very easy to make unintended changes to authorizations when doing so.


Measures Under Microsoft Windows (MaxDB: SAP Security Guide: MySQL MaxDB)

Measures Under Microsoft Windows

The following sections describe the measures that you need to take for the database system under Microsoft Windows operating systems:

· Security Measures for the Operating System User <SID>ADM

· Access Privileges for Database-Related Resources

Security Measures for the Operating System User <SID>ADM

To protect the operating system user <SID>ADM, change his/her password.

Access Privileges for Database-Related Resources

If you are using a Microsoft Windows operating system, the volumes of the database instance are automatically protected. Only the administrator group has full access privileges for the volumes, and all other users have no access.

However, you must protect the database directory <independent_data_path>\config, which contains the configuration files for the database instance. Set the following access privileges for the directory <independent_data_path>\config and all the files it contains:

· Full Control access privileges for the local group Administrators

· No access privileges for other groups or users

If you want to exclude all other users from access to the database instance using database tools, set the following privileges for the directory <independent_data_path> and all its subdirectories.

· Full Control access privileges for the local group Administrators

· No access privileges for other groups or users


Tools

Title of the Documentation | Explanation
Database Manager · Database Manager GUI · Web DBM · Database Manager CLI | Creating and managing database instances · Graphical user interface · Web-based user interface · Command line-oriented user interface
Database Analyzer | Analysis of the performance of database instances
Loader | Unloading and loading data
Query Tools · SQL Studio · Web SQL Studio | Data queries and data processing · Graphical user interface · Web-based user interface
WebDAV GUI | Web-based application for indexing XML documents in the MaxDB WebDAV service


Database Manager GUI

The Database Manager GUI is an application of the Database Manager, the tool for managing the database instances.

To work with the Database Manager GUI, a sound knowledge of database administration is necessary.

For information about the database system, see Database Administration.

· Calling the Database Manager GUI

· Creating or Initializing a Database Instance

· Managing Database Manager Operators

· Managing Database Instances

· Backing Up Data

· Restoring Data

· Displaying Information

· Options for Diagnosing Problems

· Updating the Database Software

· Accessing the SQL Studio Program

· Screen Areas of the Database Manager GUI


Calling the Database Manager GUI (MaxDB: Database Manager GUI)

Calling the Database Manager GUI

To call the Database Manager GUI program, we recommend that you choose Start ® Programs ® MySQL MaxDB®Database Manager or that you use an appropriate shortcut.

In exceptional cases, you can call the Database Manager GUI (dbmgui<n>.exe, where n is a program version counter) from the command line. To do this, go to the directory of the program dbmgui<n>.exe and enter the following command:

dbmgui<n> [<options>]

Options

Display all command line options | -?
Database name | -d <database_name>
Name of the database computer | -n <database_server>
Opening a database session specifying operator data (operator name and password) | -u <user_name>,[<password>]
Open the configuration file | -f <file_name>
Window for entering connection details | -prompt
Database Manager GUI version | -version
Call the Database Manager without initial screen display | -nologo
Activate database trace | -trace


Creating or Initializing a Database Instance (MaxDB: Database Manager GUI)

Creating or Initializing a Database Instance

You can use the Database Manager to create or initialize database instances on a local or remote computer.

Prerequisites

· Creating or Initializing a Local Database Instance
To create a database instance on your local computer, your operating system user must have administration rights for this computer.
To initialize an existing local database instance, you also need the administration rights for this database instance. This is guaranteed automatically if you log on as the first DBM operator.

· Creating or Initializing a Remote Database Instance
To create a database instance on a remote computer, you must specify an operating system user for this computer that has administration rights, and also the right log on as batch job, or a similar right. (For more information on the administration of operating system users, see your operating system documentation.)
To initialize an existing database instance on a remote computer, you also need the administration rights for this database instance. This is guaranteed automatically if you log on as the first DBM operator.

Predefined Configurations in Templates

To help you when you create database instances, the Database Manager GUI provides predefined configurations in templates. You can use these templates to create database instances with different sizes and properties. The Database Manager GUI includes the following templates:

· Blank: Database instance with standard settings. Here, you must create the volumes and backup media interactively.

· Demo: Fully configured demonstration database, suitable for test purposes. You can create this demonstration database in the background.

· Small: Database instance whose parameters, volumes, and backup media are configured to create a small database.

· Medium: Database instance whose parameters, volumes, and backup media are configured to create a medium-sized database.

The default settings in these templates are just recommendations. You can change them to meet your requirements. You can save the settings of your database instance in a template with a name of your choice, and add this template to the existing templates in the Database Manager GUI.

Creating a Database Instance

...

In the Database Manager GUI, choose Instance ® Create... .

Choose Next to start each of the required steps.

1. Select a template.
If you want to use default settings, choose Blank.
If you want to use a predefined configuration, select one of the available templates (Demo, Small, and so on).
If you use the Demo template to create a database instance, the instance can be created in the background. To do this, choose Unattended Installation.

2. Enter the following details:
Database instance on your local computer:
Database Server: <local>: Do not change this entry.
Database name
- When creating a database instance: Enter the name of the new database.
- Initialization of a database instance: Enter the name of the database instance that you want to initialize.

Database instance on a remote computer:
Database Server: Enter the name of the computer.
Database Name
- When creating a database instance: Enter the name of the new database.
- Initialization of a database instance: Enter the name of the database instance that you want to initialize.
Login Name: Enter the operating system user for this computer.
Password: Enter the password for this operating system user.

3. There may be more than one installation of the database software on the same computer. Select the appropriate installation.

4. Specify the Database Manager operator (DBM operator). Do not use any special characters. The default name and password is DBM. If required, change the name and password, then confirm the new password.

The Database Manager saves the name and password of the DBM operator in uppercase letters.

5. Decide how you want to give the database parameters initial values.

Initialize parameters with default values
Here, the database parameters are given the default values of the database software.

Copy parameters from existing database
Here, the initial values of the database parameters are taken from an existing database instance.
Select the database instance from which you want to copy the parameter values.

Restore parameters from a backup medium
Here, the initial values of the database parameters are taken from a complete data backup.
Select the complete data backup that you want to use.

Use current parameters
If you are initializing a database instance, you can use the current parameter values.

6. Select a database instance type.
If you chose Use current parameters, the system uses the instance type of the existing database instance.

7. Adjust the database parameters to your requirements.
Select the database parameters you want.
New Value: Enter and confirm the new value of the database parameter.
The value of the database parameter is stored in the internal data structures and becomes effective when the database instance is next restarted.

The database parameters are checked when you exit the input screen. You may be prompted to make and confirm changes before you can leave this screen.

8. Define your data volumes and log volumes.

Choose New Volume for both.
Enter the size and ID or the absolute path of the volume and confirm your entries.

9. Define any backup media that you need.

10. Choose from the following options:

Create and start instance
Specify the database system administrator (SYSDBA user). Do not use any special characters. The default name and password is DBA. If required, change the name and password, then confirm the new password.
The database instance is created or initialized and transferred to the ONLINE operational state.

Create instance for recovery
The database instance is created or initialized and transferred to the ADMIN operational state. You can use this database instance for a recovery only.
The details of the SYSDBA user are taken from the data backup.

11. Choose Start to create or initialize the database instance.

If any errors occur, the process is stopped immediately. However, the state reached when the error occurred is preserved.

12. Choose Close.

Initializing a Database Instance

You can initialize an existing database instance.

1. Select the required database instance in the list of database instances.

2. In the Database Manager GUI, choose Instance ® Initialize... .
Choose Next to start each of the required steps.

3. Select Initialize the database instance <database_name>.

4. If necessary, transfer the database instance to the ADMIN operational state.

5. Leave Use current parameters selected.
You can accept the current parameter values.

6. Now proceed as described from step 7 of Creating a Database Instance. The volumes and backup media of the previous database instance are offered as defaults.

Creating a Template

You can save the details you enter when you create or initialize a database instance in a template with a name of your choice. The system proposes a path and name for the template, and saves the template as an operating system file. In this way, you can modify the group of templates to meet your requirements.


Managing Database Manager Operators (MaxDB: Database Manager GUI)

Managing Database Manager Operators

The database system differentiates between two main user classes:

· Database Manager operators (DBM operators)

· Database users

When you create a new database instance, you create the first user in each of these classes.
The first DBM operator is known as the First Database Manager Operator. The first database user is the database system administrator (SYSDBA user).

Each of these users then has the authorization to create additional users of the specified main classes.
Use the Database Manager to create additional DBM operators.
To create additional database users, use the query tools or the Loader.

See also: User Concept in the Database Administration documentation.

Note that a Database Manager operator can manage a database instance only; this user cannot work with the database objects (for example, with the query tools or the Loader). A DBM operator is available in all operational states, to enable you to perform all required administration jobs.

The database system administrator (SYSDBA user) can work with the database objects in the ONLINE operational state and also has the authorizations of the first Database Manager operator. This administrator can also perform any Database Manager functions available in the ONLINE operational state.

You can perform the following administration tasks with the Database Manager GUI:

· Creating, Changing, or Deleting a Database Manager Operator

· Changing the User Properties

· Changing a User Password

· Changing the Server Authorizations


Creating, Changing, or Deleting a Database Manager Operator (MaxDB: Database Manager GUI)

Creating, Changing, or Deleting a Database Manager Operator

You can create a Database Manager operator (DBM operator), change the operator’s properties and server authorizations, or delete the operator. You can change the properties and server authorizations of a database system administrator (SYSDBA user).

Select the required database instance in the list of database instances.

Creating a DBM Operator

The database instance can be in any operational state.

...

1. Choose Instance ® Configuration ® Users.

2. Choose Actions ® New.

3. Choose General.
Specify the name of the Database Manager operator.
Enter and confirm the password.
If you want to lock the operator, select Disabled.
You can also specify a second password.
See also: Properties of a DBM Operator

4. Choose Server Rights.
Select the required server authorizations.
See also: List of server authorizations

Changing an Operator

You can change the properties and server authorizations of an operator. If you want to change the password of the first DBM operator, the database instance must be in the OFFLINE operational state. If you want to change the password of the database system administrator, the database instance must be in the ONLINE operational state.

To change the properties and server authorizations, proceed as described in the following sections:

· Changing the User Properties

· Changing a User Password

· Changing the Server Authorizations

Deleting a DBM Operator

You can delete any DBM operator, with the exception of the first DBM operator and the database system administrator.

Proceed as follows:

1. Choose Instance ® Configuration ® Users.

2. Select a DBM operator.

3. Choose Actions ® Delete.


Changing the User Properties (MaxDB: Database Manager GUI)

Changing the User Properties

You can change the properties of the Database Manager operator (DBM operator) and the database system administrator (SYSDBA user).

Procedure

...

1. Choose Instance ® Configuration ® Users.

2. Select a user.

3. Choose Actions ® Properties.

4. Choose General and make your changes.
See also: Properties of a DBM Operator
If you want to change passwords, you may need to transfer the database instance to the appropriate operational state.
See also: Changing a User Password

Result

You have changed the user properties.


Changing a User Password (MaxDB: Database Manager GUI)

Changing a User Password

You can use the Database Manager to change the passwords of all Database Manager operators (DBM operators) and the database system administrator (SYSDBA user) in various operational states of the database instance:

User Class | User | Operational State of Database Instance
Database Manager operator | First Database Manager operator All other DBM operators | OFFLINE Operator password can be changed in any operational state
Database user | SYSDBA user | ONLINE

Prerequisites

Starting the Database Instance , Stopping the Database Instance ).

Procedure

To change a password, proceed as described under Changing the User Properties. Make sure that the database instance is in the required operational state.

...

1. Choose Instance ® Configuration ® Users.

2. Select a user.

3. Choose Actions ® Properties.

4. Select the tab page Generaland then choose Password Change.

5. Enter the old and new passwords and save your entries.

See also:

Properties of a DBM Operator


Changing the Server Authorizations (MaxDB: Database Manager GUI)

Changing the Server Authorizations

A server authorization is an authorization that enables a user to execute certain commands in the Database Manager. A server authorization may cover more than one command and one command may have more than one server authorization assigned to it.

You can use the Database Manager to change the server authorizations of the Database Manager operator (DBM operator) and the database system administrator (SYSDBA user).

Prerequisites

You have the User Management server authorization.

Procedure

1. Choose Instance ® Configuration ® Users.

2. Select a user.

3. Choose Action ® Server Rights.

4. On the Server Rights tab page, you can now increase or limit the server authorizations of the selected user by selecting or deselecting the required authorizations.

See also:

List of server authorizations


Managing Database Instances (MaxDB: Database Manager GUI)

Managing Database Instances

The table below provides you with links to descriptions of various database management tasks:

Creating, initializing, or deleting a database instance | Creating or Initializing a Database Instance Deleting a Database Instance
Creating, changing, or deleting the list of database instances | Managing the List of Database Instances
Creating a database instance connection to the DBM Server | Connection to the DBM Server
Starting or stopping the database instance | Starting the Database Instance (Restart) Stopping the Database Instance (Shutdown)
Monitoring database sessions | Monitoring the Operational State Displaying Database Sessions Closing a Database Session Manually
Creating, displaying, changing, or deleting volumes | Creating Volumes Displaying, Changing, and Deleting Volumes Displaying Data Area Information
Displaying and changing database parameters | Displaying and Changing Database Parameters Changing Database Parameters for Volumes
Displaying and changing log settings | Displaying Log Area Information Changing Log Settings
Setting up a hot standby system | Setting Up a Master Component (Hot Standby) Adding Standby Components (Hot Standby)
Activating, deactivating, or deleting indexes | Activating, Deactivating, or Deleting Indexes
Language support (MapChar sets) | Creating Mapchar Sets Displaying, Changing, and Deleting Mapchar Sets
Updating statistics | Updating the Statistics Information


Monitoring the Operational State (MaxDB: Database Manager GUI)

Monitoring the Operational State

You can use the Database Manager GUI to monitor the operational state of each database instance.

Prerequisites

1. Make sure that the database instance has been included in the list of database instances (see Managing the List of Database Instances).

2. Set up the connection to the DBM server.

Displaying the Operational State

Check the indicator assigned to the general icon for the database instance in the list of database instances.

You can use the displays View ® Large Icons/Small Icons/List.

General icon for a database instance

Database instance is in the OFFLINE operational state.

Database instance is in the ADMIN operational state.

Database instance is in the ONLINE operational state.

Hot standby database instances have the following icons:

Master component or standby component is in the OFFLINE operational state.

Master component is in the ADMIN operational state or standby component is in the STANDBY operational state.

Master component is in the ONLINE operational state.

Changing the Operational State

Select a database instance in the list of database instances by double-clicking it.

Choose Actions ® OFFLINE/ADMIN/ONLINE to change to the required operational state.

You cannot change the operational state of standby components in a hot standby system directly. Standby components are controlled by the master component.

See also:

Starting the Database Instance (Restart)

Stopping the Database Instance (Shutdown)


Managing the List of Database Instances (MaxDB: Database Manager GUI)

Managing the List of Database Instances

Before you can use the Database Manager GUI to manage your database instances, you must include them in the list of database instances (see Screen Areas). To meet your requirements, you can change the way the database instances are displayed by choosing View ® ...

Prerequisites

If you want to access a remote database instance with the Database Manager, you have to start the X Server on the relevant database computer.

Adding an Entry to the List of Database Instances

...

1. Choose Instance ® Add.

2. Enter the name of the computer under Database Server.
Confirm this by choosing Add Server.

3. Select the database instances that you want to include in the list, and confirm.

The database instance is included in the list of database instances.

You can organize the way in which the database instances are stored and appear in the Database Manager GUI according to your requirements.

To be able to manage a database instance, you must set up a connection to the DBM server for this instance.

Deleting an Entry from the List of Database Instances

...

1. Select the database instance in the list of database instances.

2. Choose File ® Delete.

3. Confirm that you want to delete this database instance from the list.

The database instance is deleted from the list of database instance in the Database Manager.

If you want to delete a database instance, proceed as described under Deleting a Database Instance.

Synchronizing the Database Instance List in the Database Manager with the Existing Database Instances

You can make sure that the list of database instances matches the instances that actually exist on the computer.

1. Select a computer in the directory structure of the database instances.

2. Choose File ® Sync Server.

All database instances on this computer are included in the list of database instances. Any entries for database instances that no longer exist on this computer are deleted from the list.


Displaying and Changing Database Parameters (MaxDB: Database Manager GUI)

Displaying and Changing Database Parameters

You can use the Database Manager GUI to display and change the database parameters of the current database instance. You can do this in any operational state of the database instance.

The changes are stored in the parameter file but only become effective after the database has been restarted (see Starting the Database Instance (Restart)).

Procedure

1. Choose Instance ® Configuration ® Parameters. The system displays the general database parameters (General).

2. If you also want to display the special and support database parameters, choose Actions ® Show Extended and Support Parameters.

3. Select the database parameters you want.

Name | Name of the database parameter
Value | Value of the database parameter currently being used in the kernel of the database instance
New value | No entry: The database parameter has not been changed since the database instance was last started. New value entered: The database parameter has been changed since the database instance was last started. However, no changes are saved to the parameter file and none of them become active until the next time the database instance is restarted.
Description | Help text on the selected parameter

4. Choose Action ®Properties.

5. Enter the new value of the database parameter under New Value.

6. Save your entries.

The new value of the database parameter is stored in the internal data structures and becomes effective when the database instance is next restarted.

See also:

Displaying Database Parameters


Closing a Database Session Manually (MaxDB: Database Manager GUI)

Closing a Database Session Manually

In certain cases, it may be necessary to stop a specific database session. You can do this with the Database Manager GUI.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Sessions.

3. Select the database session that you want to close.

4. Choose Actions ® Kill Selected Sessions to close the database session.

See also:

Displaying Database Sessions


Activating, Deactivating, or Deleting Indexes (MaxDB: Database Manager GUI)

Activating, Deactivating, or Deleting Indexes

You can use the Database Manager GUI to determine which of the existing indexes have been used in a database instance.

You can also activate, deactivate, or delete selected indexes.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Tuning ® Index Use.

3. You can choose which indexes you want to display. To do this, enter appropriate search arguments for the owner, table name, and index name.

You can also choose between the following options:

Disabled indexes only | Only indexes that have been deactivated
Unused indexes only | Only indexes that have not been used

4. Choose Actions ® Search. The system displays a list of the indexes that match your criteria.

5. Select the indexes that you want to activate.
If you want to activate all of the indexes displayed, choose Actions ® Mark All.
Deselect the indexes that you want to deactivate.

6. Choose Actions and the action you want to perform.


Changing Log Settings (MaxDB: Database Manager GUI)

Changing Log Settings

You can use the Database Manager GUI to change log settings.

Prerequisites

Decide the level of security you need and read about the possible log settings. For more information, see the sections about log settings in the general database documentation.

Check the log area information in the Database Manager GUI.

Procedure

Select the required database instance in the list of database instances. In the Database Manager GUI, choose Instance ® Configuration ® Log Settings.

Choose Next to start each of the required steps.

Select the log settings that you want to change:

· Log Mode: Mirrors the log area

· Overwrite Mode for the Log Area: Activates and deactivates the overwrite mode for the log area

· Activating or Deactivating the Redo Log Management

You can change multiple log settings, one after the other. To do this, choose Back each time you complete your changes.

Mirroring the Log Area

If you want to mirror the log area (see Log Mode), select the log setting Log Mode.

The database instance can be in any operational state. Make sure, however, that you transfer the database instance into the operational state OFFLINE after setting the log mode, and then into the operational state ONLINE.

The Database Manager prompts you to create the required mirrors of the log volumes.

...

1. Choose Properties.

2. Specify the location of the mirror under Location.

3. Start the process.

After this operation has been completed, the database instance is transferred to the operational state OFFLINE and then to ONLINE.

If you no longer want to use the mirror, select the log setting Log Mode and follow the instructions.

Overwrite Mode for the Log Area

If your security concept allows you to overwrite the log area without backing up the log entries first (see Overwrite Mode for the Log Area), select the log setting Overwrite Mode for the Log Area and follow the instructions.

After a standard installation, normal log backups are activated, which means that the overwrite mode is deactivated. The database instance must be in the operational state ADMIN or ONLINE before you can change the overwrite mode.

Once you have activated the overwrite mode, it remains activated until the database is restarted.

To change back to normal log backups (and deactivate the overwrite mode), select Overwrite Mode for the Log Areaand follow the instructions. You are prompted to make a complete data backup to guarantee the integrity of your data.

Activating and Deactivating Redo Log Management

Under exceptional circumstances, you have the option of deactivating redo log management. To do this, select the log setting Activating or Deactivating the Redo Log Management (see Activating or Deactivating Redo Log Management) and follow the instructions.

Redo log management is activated after a standard installation. Before you can change this log setting, the database instance must be in the ADMIN operational state.

Once you have deactivated redo log management, it remains deactivated until the database is restarted.

You must reactivate redo log management as soon as possible to guarantee the integrity of your database system. To do this, select Activating or Deactivating the Redo Log Managementand follow the instructions. You are prompted to make a complete data backup to guarantee the integrity of your data.


Defining MapChar Sets (MaxDB: Database Manager GUI)

Defining MapChar Sets

You can use the Database Manager GUI to create Mapchar sets.

You cannot use this command for Unicode databases.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

...

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Configuration ® MapChar Sets.

3. Choose Actions ® New. Enter the following information:

Name | Name of the MapChar set, a maximum of 18 bytes in length
Code Type | The underlying code for the mapchar set Valid codes: ASCII codes in accordance with ISO 8859/1.2
Mapchar | Define the conversions for the characters required. Each one-byte character to be converted must be specified in its original form and also in its target form with a maximum length of two bytes. Intern: Original form in hexadecimal format Extern Hex: New form in hexadecimal format Ext. ASCII: New form in printable characters

4. Save your entries.

See also:

Displaying, Changing, and Deleting Mapchar Sets


Displaying, Changing, and Deleting MapChar Sets (MaxDB: Database Manager GUI)

Displaying, Changing, and Deleting MapChar Sets

You can use the Database Manager GUI to display, change, and delete Mapchar sets.

You do not have this option for UNICODE databases.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

...

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Configuration ® MapChar Sets.
You see all available Mapchar sets.

3. Select the MapChar set you want.

4. Choose Actions ® Properties or Delete.
You can change the following details:

Code Type | The code on which the Mapchar set is based. Valid codes: ASCII codes in accordance with ISO 8859/1.2
Mapchar | Define the conversions for the characters required. Each one-byte character to be converted must be specified in its original form and also in its target form with a maximum length of two bytes. Intern: Original form in hexadecimal format Extern Hex: New form in hexadecimal format Ext. ASCII: New form in printable characters

5. Save your entries.

See also:

Creating Mapchar Sets


Setting Up a Master Component (Hot Standby) (MaxDB: Database Manager GUI)

Setting Up a Master Component (Hot Standby)

You want to set up the master component of a hot standby system.

You require a suitable memory management system and a cluster solution. For information about setting up the memory management system and the cluster configuration, see the documentation of your vendor.

Prerequisites

· A database instance has been created and you have connected to this database instance in the Database Manager GUI.

· The database instance is in the OFFLINE operational state.

· The same version of the database software is installed on all computers of the hot standby system.

· All these computers are running.

· The X Server is running on all computers.

· The user who is setting up the hot standby system has administration rights on all computers.

Procedure

In the Database Manager GUI, choose Instance ®Configuration ®Hot Standby.

Choose Next to start each of the required steps.

...

1. Choose Enable or Disable the Hot Standby System.

2. Choose Enable Hot Standby System. Under Official Node, enter the name of the database in the cluster system. Under Storage DLL, enter the name of the library through which the memory management system is addressed.

3. Choose Start.

You have set up the master component of the hot standby system.

See also:

Adding a Standby Component (Hot Standby)


Starting the Database Instance (Restart) (MaxDB: Database Manager GUI)

Starting the Database Instance (Restart)

You can use the Database Manager GUI to start a database instance.

Prerequisites

1. Make sure that the database instance has been included in the list of database instances (see Managing the List of Database Instances).

2. Set up the connection to the DBM server.

3. Determine the operational state of the database instance (see Monitoring the Operational State).

Procedure

Select a database instance in the list of database instances by double-clicking it.

The database instance is in the OFFLINE operational state.

· Transferring the database instance to the operational state ONLINE
Choose Actions ® Online.
The database instance starts.

· Transferring the database instance to the operational state ADMIN
Choose Actions ® Admin.
The database instance is transferred to the operational state ADMIN.

The database instance is in the operational state ADMIN.

· Transferring the database instance to the operational state ONLINE
Choose Actions ® Online.
The database instance starts.

Each time you start the database instance, a copy of the log file knldiag is made under the name knldiag.old. The file knldiag is overwritten. Use this log file to analyze any errors that occurred when you started or stopped the database instance.

See also:

Stopping the Database Instance (Shutdown)


Adding a Standby Component (Hot Standby) (MaxDB: Database Manager GUI)

Adding a Standby Component (Hot Standby)

You want to add a standby component to a hot standby system.

No savepoints can be written while a new standby component is being set up.

You require a suitable memory management system and a cluster solution. For information about setting up the memory management system and the cluster configuration, see the documentation of your vendor.

Prerequisites

· You have already set up the master component of the hot standby system.

· The master and standby components use the same hardware platforms (memory size, type and number of processors).

· All data paths and files (such as the run directory, volumes, and trace files) used in the configuration are the same for the master and standby components.

· The same version of the database software is installed on all computers.

· All these computers are running.

· The X Server is running on all computers.

· The user who is setting up the hot standby system has administration rights on all computers.

Procedure

In the Database Manager GUI, choose Instance ®Configuration ®Hot Standby.

Choose Next to start each of the required steps.

...

1. Choose Add or Remove Standby Instances.

2. Choose Add Standby Instance. Enter the following information:

Node | Name of the standby computer
Login Name | Operating system user on the standby computer
Password | Password of the operating system user on the standby computer
Installation | Installation path of the database software on the standby computer
Delay | Delay (in seconds) until the standby component redoes the changes in the master component

3. Choose Start.

You have added the standby component and transferred it to the STANDBY operational state.

See also:

Setting Up a Master Component (Hot Standby)


Updating the Statistics Information (MaxDB: Database Manager GUI)

Updating the Statistics Information

Various statistics are compiled for each database instance, such as the number of table entries, the size of the tables and indexes, and the value distribution (various values) of indexes and columns. This information is required by the SQL Optimizer to define the best strategy for executing complex SQL statements. The statistics information is stored in the database catalog.

If the database size or the values it contains have changed considerably, you have to update the statistics. Do this about once a week.

The statistics values can be updated for certain tables, columns, or for all base tables.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Tuning ® Optimizer Statistics.

The database system contains an internal list of the tables whose statistics need to be updated.

· Updating statistics entries for all tables
You can update the statistics entries for all tables in this internal list. To do this, do not enter a search argument under Search; instead, just enter *.
Updating statistics entries for selected tables
You can update the statistics entries for selected tables in this internal list. To do this, enter appropriate search arguments for the owner, table name, and column name under Search.

· You can determine the size of a sample. To do this, enter appropriate information under Estimate.

Use estimate value | Select this option.
Rows | Number of rows to be checked
Percent | Percentage of rows to be checked

The update is only performed across the number of rows or the specified percentage, based on the total number of database tables. This option, therefore, is faster.

The significance of the random sample depends on the size of the tables and the physical position of the data. Measurements have shown that for large tables (more than 1 million entries), samples of more than 20000 rows produce good results.

· Independently of the internal list, you can display all tables for which statistics can be updated. To do this, select Select from tables under Advanced.

Updating Table Statistics

1. Choose Actions ® Search.

2. A list of the tables is displayed that matches your criteria under Search or Advanced. From the Update Statistics Dateand Update Statistics Time, you can tell when the statistics for this table were last updated.
If you want to update the statistics for one of the tables in the list, simply select the relevant entry. If you want to update the statistics for all of the tables, choose Actions ® Mark All.
Select Include update columns for marked tables (under Advanced) if you want to update column statistics as well as the table statistics. You can display the columns of a table by double clicking. Select the required columns.

3. Choose Actions ® Execute to update the statistics for the selected tables.
If you have not selected any tables, the statistics of those tables are updated that are in the internal list of the database system.


Stopping the Database Instance (Shutdown) (MaxDB: Database Manager GUI)

Stopping the Database Instance (Shutdown)

You can use the Database Manager GUI to start a database instance.

Prerequisites

1. Make sure that the database instance has been included in the list of database instances (see Managing the List of Database Instances).

2. Set up the connection to the DBM server.

3. The database instance is in the operational state ONLINE (see Monitoring the Operational State).

Procedure

Select a database instance in the list of database instances by double-clicking it.

· Transferring the database instance to the operational state ADMIN
Choose Actions ® Admin.
The database instance is transferred to the operational state OFFLINE and then to the operational state ADMIN. Any changes made to the database parameters take effect.

· Transferring the database instance to the operational state OFFLINE
Choose Actions ® Offline.
The database instance is stopped.

If a backup is running, the Database Manager waits until the backup is complete before stopping the database instance.

Use the log file knldiag to analyze any errors that occurred when you started or stopped the database instance.

See also:

Starting the Database Instance (Restart)


Connection to the DBM Server (MaxDB: Database Manager GUI)

Connection to the DBM Server

Before you can manage database instances using the Database Manager GUI program, a connection must be set up between the database instance to be managed and your DBM Server.

You can set up the connection to the DBM Server for one, more than one, or all database instances displayed in the list, depending on the performance of your system. Similarly, you can terminate the connection between individual database instances and your DBM Server to reduce the load on your system.

Prerequisites

The required database instance must be included in the list of the database instances. To do this, proceed as described in Managing the List of Database Instances.

Setting Up a Connection Between a Database Instance and the DBM Server

The database instance state is Not connected.

1. Select the database instance in the list of database instances.

2. Choose Instance ® Connect.

3. Enter the name and password of the Database Manager operator, if necessary. You can save this information.

The Database Manager can now determine the current operational state of the selected database instance.

Terminating a Connection Between a Database Instance and the DBM Server

1. Select the database instance in the list of database instances.

2. Choose Instance ® Disconnect.

The state of this database instance is now Not connected.

The connection to the DBM Server has been terminated. The Database Manager now no longer determines the current operational state of the database instance.


Creating Volumes (MaxDB: Database Manager GUI)

Creating Volumes

You want to user the Database Manager GUI to increase the storage capacity of your data area or log area.

· The maximum number of data volumes you can create is defined in the general database parameter MAXDATAVOLUMES.

· The maximum number of log volumes you can create is defined in the general database parameter MAXLOGVOLUMES.

Prerequisites

The database instance is in the ONLINE operational state.

The value of the database parameter MAXDATAVOLUMES or MAXLOGVOLUMES is at least as great as the total number of existing volumes plus the volumes you want to define.

The system checks that there is enough space available for at least one volume of each type before each start of the database instance. If there is not enough space available, it automatically increases the setting of the appropriate database parameter by 1.

If necessary, change the database parameter MAXDATAVOLUMES or MAXLOGVOLUMES accordingly (see Changing Database Parameters for Volumes). Later on, when the database instance is in the operational state ONLINE, this enables you to add a volume of a given type a number of times in succession without having to stop the database instance.

Procedure

...

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Configuration ® Volumes.
The system displays all existing volumes of the selected type and their data, as well as the maximum number of volumes still possible according to the parameter value.

Name | Name of the volume
Size | Size of the volume
Type | File, raw device, or symbolic link
Location | Path of the volume
M. Type | File, raw device, or symbolic link (mirrored volume)
M. Location | Path of the mirrored log volume

3. Choose one of the default volume names.

4. Choose Actions ® New. Define the new volume by entering the size and path.

You cannot increase the size of archive volumes for Archive instances at a later time; you also cannot delete data from these volumes. For this reason, set the size of these volumes to the maximum possible value.

5. Save your entries.

See also:

Displaying, Changing, and Deleting Volumes


Displaying, Changing, and Deleting Volumes (MaxDB: Database Manager GUI)

Displaying, Changing, and Deleting Volumes

You can use the Database Manager GUI to display volumes, and to change or delete their paths.

Prerequisites

The database instance is in the OFFLINE operational state.

You have copied the log or data volume to a new location and you want to inform the Database Manager GUI of the path to the new location.

Procedure

...

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Configuration ® Volumes.
You are shown all the existing volumes of the selected type.

Name | Name of the volume
Size | Size of the volume
Type | File, raw device, or symbolic link
Location | Path of the volume
M. Type | File, raw device, or symbolic link (mirrored volume)
M. Location | Path of the mirrored log volume

3. Select the log volume or data volume that you want to change.

4. Choose Action ® Properties.

5. Enter the new path of the volume under Location.

6. Save your entries.

When you now restart the database instance the database system recognizes the new path.

See also:

Creating Volumes


Changing Database Parameters for Volumes (MaxDB: Database Manager GUI)

Changing Database Parameters for Volumes

You can use the Database Manager GUI to define database parameters, including those that define the maximum number of volumes in a database instance: the general database parameters MAXDATAVOLUMES and MAXLOGVOLUMES.

You can change the settings of both database parameters at a later date regardless of which operational state the database instance is in. Like all database parameter changes, these changes take effect the next time the database instance is restarted.

Procedure

...

1. For the database parameters MAXDATAVOLUMES and MAXLOGVOLUMES, proceed as described in Displaying and Changing Database Parameters .

2. Transfer the database instance to the operational state ADMIN.

3. Start the database instance.
The Database Manager GUI transfers the database instance to the operational state OFFLINE and then to the operational state ONLINE, and saves the new value of the database parameter in the parameter file.
The Database Manager GUI reserves the memory required by this number of volumes, plus reserve memory large enough for the largest volume of this type. This reserve allows you to create an additional volume of this type while the database is running if the original number of volumes is not enough.

See also:

Creating Volumes


Backing Up Data (MaxDB: Database Manager GUI)

Backing Up Data

You can perform both data backups and log backups with the Database Manager.

· Interactive backups
Use the Backup Wizard.

· Background backups
Use the Database Manager CLI.
For more information, see Database Manager CLI, section Backing Up and Recovering Database Instances

You can manage the backup media with the Database Manager.

The Database Manager supports a range of backup procedures.

Follow the recommended backup strategies.

For SAP applications, the scheduling and automation of Database Manager backups and media management can be optimized by using the DBA Planning Calendar of the Computing Center Management System (CCMS). For more information, see Database Management in CCMS: MySQL MaxDB under [image] DBA Planning Calendar.


Backup Wizard (MaxDB: Database Manager GUI)

Backup Wizard

You can use the Backup Wizard to guide you through the entire process of backing up the data of a database instance.

You can start the Backup Wizard on a Microsoft Windows-based computer to back up data on either a local or remote computer.

Procedure

In the Database Manager GUI, choose Instance ® Backup ® Backup Wizard.

Choose Next to start each of the required backup steps.

1. You can back up the data of a database instance either locally, or on a remote computer.
Choose your database instance, or enter the following information directly:
Information about the database instance
Database Server: Enter the name of the computer.
Database Name: Enter the database name.
Information about the Database Manager operator (DBM operator)
User Name: Enter the name of the Database Manager operator.
Password: Enter the password.

2. You can switch the database instance to the operational state of your choice. When you back up data, you require the operational states ADMIN or ONLINE.

3. Choose a backup type:
Complete Data Backup
Incremental Data Backup
Log Backup: Interactive Log Backup
Activate/Deactivate Automatic Log Backup: Automatic Log Backup

Also take note of the information about completed backups in the Backup Wizard.
Inform yourself about the backup procedures, and choose a suitable backup strategy.

4. Select a backup medium.
If you do not yet have a backup medium, you can create one, or create a group of parallel backup media.
For more information on this, see Managing the Backup Media.

5. Start the backup.

6. Close the Backup Wizard.


Managing the Backup Media (MaxDB: Database Manager GUI)

Managing the Backup Media

Before you can back up data, you must define the backup media. You can create and manage backup media interactively with the Database Manager GUI or the Backup Wizard.

· Creating a Single Backup Medium

· Creating a Group of Parallel Backup Media

· Changing Backup Media

· Deleting Backup Media


Creating a Single Backup Medium (MaxDB: Database Manager GUI)

Creating a Single Backup Medium

You can change backup media interactively with the Database Manager GUI or the Backup Wizard.

Prerequisites

You have made the connection between the database instance and the DBM Server.

Procedure

· Database Manager GUI
Select the required database instance in the list of database instances.
Choose Instance ® Backup ® Backup Medium.
Choose Actions® New Medium.

· Backup Wizard
Choose New Medium in the window Media for Backup.

...

General

Choose General and enter the following information:

Name | Name of the backup medium Follow the naming conventions for backup media.
Backup Type | Choose your preferred backup type: Complete data backup Incremental data backup Log backup
Device Type | Select the type of backup medium: File: If you back up the log area to a file, the Database Manager generates version files automatically. Tape: You cannot make log backups to tape. Pipe: Pipe Always specify Pipe if you are using an external backup tool.
Location/Device | Specify the location to which you want to make the backups. With files and pipes, we recommend specifying the absolute path to the backup medium. UNIX: If you back up to a tape, you must communicate with the device driver correctly. Use a rewind tape for data backups. Microsoft Windows: The system sets the device driver automatically.

Extended

Choose Extended and enter the following information:

Size | Size of the backup medium
Overwrite | Select Overwrite if you want to use the overwrite mode for the backup medium.
Blocksize | Select Blocksize if you want to make backups in blocks of up to eight pages
Autoloader | Select Autoloader to use a tape device with autoload facilities (Backups with Automatic Tape Loaders).
OS Command | When you back up to tape, you can specify operating system commands.


Creating a Group of Parallel Backup Media (MaxDB: Database Manager GUI)

Creating a Group of Parallel Backup Media

To improve backup speed, you can back up data to multiple backup media in parallel. To do this, define a group of parallel backup media under a single medium name. A backup made to multiple media in parallel must have the name of the group of parallel media assigned to it. When you restore data, you can import the data from this type of backup in parallel.

You can change backup media interactively with the Database Manager GUI or the Backup Wizard.

Prerequisites

You have made the connection between the database instance and the DBM Server.

Procedure

· Database Manager GUI
Select the required database instance in the list of database instances.
Choose Instance ® Backup ® Backup Medium.
Choose Actions ® New Parallel Medium.

· Backup Wizard
Choose New Parallel Medium in the window Media for Backup.

General

Choose General and enter the following information:

Name | Name for the group of parallel backup media Follow the naming conventions for backup media.
Backup Type | Select your preferred backup type: Complete data backup Incremental data backup
Device Type | Select the type of backup media: File Tape Pipe Always specify Pipe if you are using an external backup tool.
Name/Location | Name and path for backup media that you want to include in the group of parallel backup media. Change the defaults, or add new locations, depending on where you want to make the backups. For files and pipes, we recommend that you specify the absolute path to the backup medium. UNIX: If you are backing up to tapes, you must communicate with the device driver correctly. Use a rewind tape for data backups. Microsoft Windows: The system sets the device driver automatically.

Extended

Choose Extended and enter the following information:

Unit | Unit of measurement for specifying the size of backup media
Overwrite | Select Overwrite if you want to use the overwrite mode for backup media
Blocksize | Select Blocksize if you want to make backups in blocks of up to eight pages
Autoloader | Select Autoloader to use a tape device with autoload facilities (Backups with Automatic Tape Loaders).
Name/Size/OS Command | You can specify the size of each backup medium in the group. When you back up to tape, you can specify operating system commands.

...


Changing Backup Media (MaxDB: Database Manager GUI)

Changing Backup Media

You can create backup media interactively with the Database Manager GUI or the Backup Wizard.

Procedure

· Database Manager GUI
Select the required database instance in the list of database instances.
Choose Instance ® Backup ® Backup Medium.
Choose a backup medium or group of parallel backup media.

· Backup Wizard
In the window Media for Backup, choose a backup medium or group of parallel backup media.

...

Changing the Name of the Backup Medium or Group of Parallel Backup Media

1. Choose Action ® Rename or Rename and make your changes.

2. Choose Enter to save your changes.

Changing the Properties of a Backup Medium

1. Choose Action ® Properties or Properties and make your changes.

2. For information on the properties that you can change under General and Extended, see Creating a Single Backup Medium.

3. To display the backup ID, choose Label.


Deleting Backup Media (MaxDB: Database Manager GUI)

Deleting Backup Media

You can delete backup media interactively with the Database Manager GUI or the Backup Wizard.

Procedure

· Database Manager GUI
Select the required database instance in the list of database instances.
Choose Instance ® Backup ® Backup Medium.
Choose a backup medium or group of parallel backup media.

· Backup Wizard
In the window Media for Backup, choose a backup medium or group of parallel backup media.

To delete the chosen backup medium, choose Action ® Delete or Delete.


Backup Procedures (MaxDB: Database Manager GUI)

Backup Procedures

You can use the Backup Wizard to back up data interactively.Depending on the technical requirements, the following backup procedures are possible:

· Backing Up to a Single Backup Medium

· Backing Up to a Group of Parallel Backup Media

If the capacity of the selected backup medium is sufficient for the total quantity of data that needs to be backed up, then the database administrator does not need to intervene during the backup process.

If the capacity of the selected backup medium is not sufficient for the backup, succeeding media must be used, meaning that when one backup medium is full, it must be automatically or manually replaced by an empty medium:

· Backups with Automatic Tape Loaders

· Backups with Manually Changed Media (Succeeding Medium)

The Backup Wizard requests additional backup media when a medium has been completely filled but the backup has not yet been completed. To allow it to do this, the media size must be stated when defining the medium, or the tape device must detect the end of the tape.

You also have the option of using an external backup tool:

· Backing Up with External Backup Tools

There is an automatic backup function for backing up the log entries:

· Activating and Deactivating the Automatic Log Backup


Backing Up to a Single Backup Medium (MaxDB: Database Manager GUI)

Backing Up to a Single Backup Medium

You can use the Backup Wizard to back up data interactively. You can save the data to a single backup medium.

If possible, we recommend that you back up data to a group of parallel backup media, rather than backing up the data to a single backup medium with succeeding media. You cannot make log backups in parallel.

Check the database structures before each complete data backup.

Prerequisites

Only one backup device is available.

You have created the required backup medium.
If you want to perform a backup using an automatic tape loader (Backups with Automatic Tape Loaders), or with the help of external backup tools (Backing Up with with External Backup Tools), then you must state this specifically when defining the backup media.

Under normal circumstances, you should back up database instances in the ONLINE operational state.
In exceptional circumstances, you can back up database instances in the ADMIN operational state.

Procedure

Use the Backup Wizard.

1. If you have not yet created a backup medium, do this now as described in Creating a Single Backup Medium. Select a backup medium in the window Media for Backup.

2. Check the details. Change them if required (Changing Backup Media).

3. Start the backup, or activate automatic log backups.
If the capacity of the specified backup medium is not large enough for the backup and you are not using an automatic tape loader, the Backup Wizard asks you to specify and insert a new backup medium as soon as the previous medium has been filled (see Backups with Manually Changed Media (Succeeding Medium)).


Backing Up to a Group of Parallel Backup Media (MaxDB: Database Manager GUI)

Backing Up to a Group of Parallel Backup Media

You can use the Backup Wizard to back up data interactively. To maximize the speed of the backup, you can back up data to a group of parallel backup media. You can use up to 32 tape devices to reduce backup times significantly.

If possible, we recommend that you back up data to a group of parallel backup media, rather than backing up the data to a single backup medium with succeeding media. You cannot make log backups in parallel.

Check the database structures before each complete data backup.

Prerequisites

There are multiple backup devices available.

You have created the required backup media.
If you want to perform a backup using an automatic tape loader (Backups with Automatic Tape Loaders), or with the help of external backup tools (Backing Up with External Backup Tools), then you must state this specifically when defining the media.

Under normal circumstances, you should back up database instances in the ONLINE operational state.
In exceptional circumstances, you can back up database instances in the ADMIN operational state.

Procedure

Use the Backup Wizard.

1. If you have not yet created a group of parallel backup media, do this now as described in Creating a Group of Parallel Backup Media. Select a group of parallel backup media in the window Media for Backup.

2. Check the details. Change them if required (Changing Backup Media).

3. Start the backup.
If the capacity of the specified group is not large enough for the backup and you are not using an automatic tape loader, the Backup Wizard asks you to specify and insert a new backup medium as soon as the previous medium has been filled (see Backups with Manually Changed Media (Succeeding Media)).


Backups with Automatic Tape Loaders (MaxDB: Database Manager GUI)

Backups with Automatic Tape Loaders

You can back up data interactively with the Backup Wizard, which also supports automatic tape loaders.

Alternatively, you can back up data with an external backup tool (Backing Up with External Backup Tools).

If you want to use an automatic tape loader, choose the following settings when you create the backup media (see Creating a Single Backup Medium, Creating a Group of Parallel Backup Media or Changing Backup Media):

· General
Choose the device type Tape.

· Extended
Select Autoloader.
On the Microsoft Windows operating system, this defines the automatic loading of tapes.
If you are using any other operating system, use the appropriate command for loading tapes. Enter the operating system command in the field OS Command.

After you insert the tape cartridge in the autoloader, the first tape must be selected manually.
When the end of this tape is reached, the autoloader will then take the next tape available.

For a backup to be successful, you will need to ensure an adequate supply of tapes.

At the end of the backup, the tape device shows the number of tapes written. The tapes should be marked with the backup ID that was displayed and confirmed at the start of the backup.

Before a backup, you must check that none of the tapes is write-protected since this terminates the entire backup.


Backups with Manually Changed Media (Succeeding Medium) (MaxDB: Database Manager GUI)

Backups with Manually Changed Media (Succeeding Medium)

You can use the Backup Wizard to back up data interactively. The Backup Wizard may prompt you to change the backup medium (use a succeeding medium).

Prerequisites

You have started a backup to a single backup medium or a backup to a group of parallel backup media.

The capacity of the backup medium or backup media inserted is not sufficient for the selected backup. The bar that shows the progress of the backup stops before reaching 100%.

The Backup Wizard prompts you to insert the succeeding medium.

Succeeding Medium is Tape

...

1. Insert the next tape.

2. Ensure that the tape that has just been written is stored in a safe place and that the right tape has been inserted.

3. Continue with the backup.

We recommend you specify the exact capacity of the medium when defining the medium. As long as the tape device driver gives a reliable indication of when the end of the tape is reached, the Database Manager GUI reacts as described even when Size = 0.
If the end of the tape is not recognized correctly, the message Writing Error is displayed. Even when this happens you can continue as described in steps 1-3.

Succeeding Medium is a File

...

1. Under New Location, enter the name and full path of the file to which you want to make the backup.

2. Continue with the backup.

Repeat the procedure until the backup has been completed.

You cannot start a new backup while another backup is running.


Backing Up with External Backup Tools (MaxDB: Database Manager GUI)

Backing Up with External Backup Tools

You can back up data interactively with the Backup Wizard, which also supports backups to tapes and continuation tapes with external backup tools.

Prerequisites

Connecting External Backup Tools

Under normal circumstances, you should back up a database instance in the ONLINE operational state. You can also back it up in the ADMIN operational state, but only in exceptional circumstances.

Procedure

If you want to use external backup tools, choose the following settings when you create the backup media (see Creating a Single Backup Medium, Creating a Group of Parallel Backup Media or Changing Backup Media):

General

· Follow the naming conventions for backup media.

· Choose the device type Pipe.

· Specify the operating system path of this pipe under Location.

When you back up the data, proceed as described under Backing Up to a Single Backup Medium or Backing Up to a Group of Parallel Backup Media.


Activating and Deactivating the Automatic Log Backup (MaxDB: Database Manager GUI)

Activating and Deactivating the Automatic Log Backup

You can activate or deactivate automatic log backups either with the Backup Wizard, or with the Database Manager GUI. These settings allow you to maximize the security of the data in production systems.

Prerequisites

The database instance is in the ONLINE operational state.

Using the Backup Wizard

You can activate and deactivate automatic log backups with the Backup Wizard.

1. Start the Backup Wizard.

2. If you have not yet created a backup medium, do this now as described in Creating a Single Backup Medium. Select a backup medium in the window Media for Backup.

3. Check the details. Change them if required (Changing Backup Media).

4. If your database is in the operational state ONLINE, you can activate or deactivate automatic log backups.

Using the Database Manager GUI

You can activate and deactivate automatic log backups with the Database Manager GUI.

Before you can make log backups, you must create the necessary backup media.

1. Start the Database Manager GUI.

2. Choose Instance.

3. If your database is in the operational state ONLINE, you can activate or deactivate automatic log backups (Set Auto Log ON/OFF).

Once you activate automatic log backups for your system, this setting remains active until you deactivate automatic log backups again. Automatic log backups also remain active when you restart the database instance.


Restoring Data (MaxDB: Database Manager GUI)

Restoring Data

The Database Manager supports the recovery of the database instance by restoring backups. You can recover either the last database state or an earlier one.

The Database Manager also supports the recovery of indexes and defective mirror log volumes.

If the automatic log backup function was not activated before the recovery of the database instance started, this function is not automatically reactivated after the recovery.

To reactivate the log backup function, proceed as described under Activating the Automatic Log Backup.

Procedure

You can usually use the Recovery Wizard to perform interactive recoveries of data. The Recovery Wizard proposes the optimal recovery strategy for your purposes. You can choose from the following procedures:

· Restoring the Last Backup in the Backup History

· Restoring a Backup from the Backup History

· Restoring Without a Backup History

· Continuing an Interrupted Recovery

· Restoring with an Automatic Tape Loader

· Restoring with External Backup Tools

If you cannot use the Recovery Wizard to restore data (for example, because the database instance has been deleted), you must initialize the database instance (see Creating or Initializing a Database Instance) and then recover it with the Recovery Wizard. The initialization process makes this a much lengthier procedure. Use it only if absolutely necessary.

· Restoring After Initializing a Database Instance

You can use the Database Manager GUI to restore indexes and mirrored volumes:

· Restoring the Indexes After a Database Recovery

· Restoring a Mirrored Log Volume


Recovery Wizard (MaxDB: Database Manager GUI)

Recovery Wizard

You can use the Recovery Wizard to guide you through the entire process of restoring the data of your database instance.

You can start the Recovery Wizard on a Windows-based server to recover data on either a local or remote server.

The Recovery Wizard always proposes the quickest procedure for recovering lost data. Any complete data backup(s) are restored first, followed by, if necessary, an incremental data backups and log backups.

To make sure that the data is recovered as quickly as possible, data backups can be retrieved from multiple backup media at the same time. The number of media in a group of parallel backup media does not have to be the same as the number of parallel backup media used for the original backup. A backup made to single medium with succeeding media can also be restored in parallel. You can use up to 32 tape drives to reduce recovery times significantly.

Log backups cannot be restored in parallel.

Procedure

In the Database Manager GUI, choose Instance ® Recovery ® Recovery Wizard.

Choose Next to start each of the required recovery steps.

1. You can recover the data of a database instance either locally, or on a remote host.
Choose your database instance, or enter the following information directly:
Information about the database instance
Database Server: Enter the server name.
Database Name: Enter the database name.
Information about the Database Manager operator (DBM operator)
User Name: Enter the name of the Database Manager operator.
Password: Enter the password.

2. You can switch the database instance to the operational state of your choice. When you recover data, you require the operational state ADMIN.

3. Choose a recovery type:
Restore last backup: Restore the last complete backup
Restore a specified backup from history: Restore a backup from the backup history
Restore a medium: Restoring without a backup history
Continue restoring pages/log: This setting is displayed if you need to continue an interrupted recovery.
Restore database until a specified time: If you only want to restore the database to a specific time, select this setting, and enter a time.

4. The recovery strategy is displayed. The system prompts you to mount the required backup media.

5. Start the recovery.

6. Close the Recovery Wizard.

Result

The database instance has been recovered to the state you specified.

If the recovery procedure offered by the Recovery Wizard does not deliver the results you need, use the procedure Restoring After Initializing a Database Instance.


Restoring the Last Backup in the Backup History (MaxDB: Database Manager GUI)

Restoring the Last Backup in the Backup History

You can use the Recovery Wizard to recover data interactively. You can perform a recovery that uses the last backup made.

Prerequisites

The log files dbm.knl and dbm.mdf exist and are not damaged. This means that the backup history is complete.

If you are performing a restore using external backup tools, the log file dbm.ebf must also have remained uncorrupted.

The database instance is in the ADMIN operational state.

Procedure

Use the Recovery Wizard.

...

1. Choose Restore last backup.
You can now choose a time up to which you want to restore data. In this case, select Restore database until a specified time and enter a time.
The system default is the current time. If you do not change the time proposed by the system, the database instance is restored completely, including all changes.

2. The last complete data backup, the corresponding incremental backup, and the required log backups are displayed.
You can remove the incremental data backup from the proposal. If you do this, the Recovery Wizard proposes the corresponding log backups, or another incremental data backup (if one exists).

3. The system prompts you to insert the specified backup medium.

4. Start the recovery.
If you are using external backup tools, the external backup IDs are displayed at this point.
The complete data backup is restored.

5. If you are restoring an incremental data backup, the Recovery Wizard prompts you to confirm this.

6. If you need to restore log backups, the Recovery Wizard prompts you to confirm that you want to restore all displayed log backups. After the log backups have been restored, the database instance is in the operational state ONLINE.
If no log backups need to be restored, the recovery is complete. You can also specify an UNTIL time. Choose Restart to start the database instance.

When you restore a series of backups, the Recovery Wizard prompts you to insert the next backup medium each time, unless you are restoring from an automatic tape loader.

If you want, you can stop the recovery and continue it at a later time (see Continuing an Interrupted Recovery).


Restoring a Backup from the Backup History (MaxDB: Database Manager GUI)

Restoring a Backup from the Backup History

You can use the Recovery Wizard to recover data interactively. You can perform a recovery with a complete data backup from the backup history.

Prerequisites

The log files of the Database Manager, dbm.knl and dbm.mdf, exist and are not damaged. This means that the backup history is complete.

If you are restoring using external backup tools, the log file dbm.ebf must also exist and not be damaged.

The database instance is in the ADMIN operational state.

Procedure

Use the Recovery Wizard.

...

1. Choose Restore a specified backup from history.
You can now choose a time up to which you want to restore data. In this case, select Restore database until a specified time and enter a time.
The system default is the current time. If you do not change the time proposed by the system, the database instance is restored completely, including all changes.

2. The backup history of the complete data backups is displayed.

3. Select the data backup you want.

4. The chosen data backup, the corresponding incremental data backup and the required log backups are displayed.
You can remove the incremental data backup from the proposal. If you do this, the Recovery Wizard proposes the corresponding log backups, or another incremental data backup (if one exists).

5. The system prompts you to insert the specified backup medium.

6. Start the recovery.
If you are using external backup tools, the external backup IDs are displayed at this point.
The complete data backup is restored.

7. If you are restoring an incremental data backup, the Recovery Wizard prompts you to confirm this.

8. If you need to restore log backups, the Recovery Wizard prompts you to confirm that you want to restore all displayed log backups. After the log backups have been restored, the database instance is in the operational state ONLINE.
If no log backups need to be restored, the recovery is complete. You can also specify an UNTIL time. Choose Restart to start the database instance.

When you restore a series of backups, the Recovery Wizard prompts you to insert the next backup medium each time, unless you are restoring with an automatic tape loader.

If you want, you can stop the recovery and continue it at a later time (see Continuing an Interrupted Recovery ).


Restoring Without a Backup History (MaxDB: Database Manager GUI)

Restoring Without a Backup History

You can use the Recovery Wizard to restore data interactively. You can also perform a restorey if the backup history is not available.

Prerequisites

The database instance is in the ADMIN operational state.

The backup history contains errors or is no longer complete.

Procedure

Use the Recovery Wizard.

...

1. Choose Restore a medium.
You can now choose a time up to which you want to restore the information from a backup medium. In this case, select Restore database until a specified time and enter a time.
The system default is the current time. If you do not change the time proposed by the system, the backups are restored completely, including all changes.

2. A list of all existing backup media is displayed.

3. Select the backup medium you want to restore.
If you are performing a recovery with external backup tools, the system displays a list of backups. Select the required external backup IDs, if necessary.

4. The system prompts you to insert the specified backup medium. If you are performing a restore using external backup tools, the external backup IDs are displayed again at this point.

5. Start the restorey.
If you then want to restore more backup media without a backup history, repeat this procedure.

6. Choose Restart to start the database instance.

If you want, you can stop the recovery and continue it at a later time (see Continuing an Interrupted Recovery).


Continuing an Interrupted Recovery (MaxDB: Database Manager GUI)

Continuing an Interrupted Recovery

You have the option of continuing an interrupted recovery of data at a later time.

Prerequisites

The database instance is in the ADMIN operational state.

One of several possible recoveries has been started but canceled before it had been completed.

· Restoring the Last Backup in the Backup History

· Restoring a Backup from the Backup History

· Restoring Without a Backup History

Procedure

Use the Recovery Wizard.

...

1. Choose Continue restoring pages/log.
You have the option of restoring the database up to a specific time. In this case, select Restore database until a specified time and enter a time.
The system default is the current time. If you do not change the time proposed by the system, the backups are restored completely, including all changes.

2. This displays a list of all relevant log backups made for data backups that have already been restored.

3. Continue with the recovery. You can follow the progress of the recovery and its completion on the screen display.

4. Choose Restart to start the database instance.

...

When you restore a series of backups, the Recovery Wizard prompts you to insert the next backup medium each time, unless you are restoring from an automatic tape loader.


Restoring from Automatic Tape Loader (MaxDB: Database Manager GUI)

Restoring with an Automatic Tape Loader

You can use the Recovery Wizard to recover data interactively. You can optimize this process by using an automatic tape loader.

Prerequisites

For the retrieval operation to be successful, all the tapes which form part of the backup must be present in the automatic tape loader.

The database instance is in the ADMIN operational state.

Procedure

Use the same media definition as for backing up (Creating a Single Backup Medium).Follow the individual steps as described for the relevant recovery procedure:

· Restoring the Last Backup in the Backup History

· Restoring a Backup from the Backup History

· Restoring Without a Backup History


Restoring with External Backup Tools (MaxDB: Database Manager GUI)

Restoring with External Backup Tools

You can use the Recovery Wizard to recover data interactively. The Recovery Wizard supports the use of external backup tools.

Prerequisites

Connecting External Backup Tools

The database instance is in the ADMIN operational state.

Procedure

Start the recovery from the Recovery Wizard. The Recovery Wizard uses the naming conventions for backup media to identify the external backup tool using the external backup IDs. The Recovery Wizard displays the external backup IDs for the operator to check, and uses these during the restore. The operator does not need to explicitly determine or specify the external backup IDs.

The number of media in a group of parallel backup media must correspond to the number of media used to create the backup.

Follow the procedure for the relevant restore process:

· Restoring the Last Backup in the Backup History

· Restoring a Backup from the Backup History

· Restoring Without a Backup History


Restoring After Initializing a Database Instance (MaxDB: Database Manager GUI)

Restoring After Initializing a Database Instance

When you restore data, you may need to initialize the database instance to delete the log entries in the log area. You can then restore the required backups to recover the database instance to a specified state.

You need to use this type of recovery in the following situations:

· You want to recover a deleted database instance from a backup.

· You want to use backups from a point in time before you made a recovery with an UNTIL time. (For example, you want to repeat a recovery with an UNTIL time so that you can specify a different time.)

Any backups made before the interruption of the backup history can only be restored with the procedure described here.

This procedure involves the initialization of the database instance. This is a very lengthy process, which is why you should use this procedure only if absolutely necessary.

Prerequisites

The log files dbm.knl and dbm.mdf exist and are not damaged. This means that the backup history is complete.

The database instance is in the OFFLINE operational state.

Procedure

The general procedure for initializing a database instance is described under Initializing a Database Instance in Creating or Initializing a Database Instance. Note the following points:

· Select the required database instance in the list of database instances in the Database Manager GUI.

· Select Initialize the database instance <database_name>. An empty database instance is created under the existing name (the database instance is initialized).

· Under Use current parameters, the Database Manager proposes the database parameters of the database instance as the parameters for the new database instance. All data from the old version is lost.

Afterwards, choose Create instance for recovery (not Create and start instance), since this is the only option that lets you recover the data.

The database instance is in the operational state ADMIN. The Database Manager opens the Recovery Wizard automatically.

The Recovery Wizard always proposes the quickest procedure for recovering lost data. You may need to choose a procedure that is adapted to your situation.

The wizard guides you through the entire process of recovering the database instance. The subsequent recovery steps are described under the relevant recovery procedure.


Restoring the Indexes After a Database Recovery (MaxDB: Database Manager GUI)

Restoring the Indexes After a Database Recovery

When you restore data, the process is optimized by not restoring the indexes in the log area. Indexes that have not been restored are marked BAD and can be restored with the Database Manager GUI.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

1. Choose Instance ® Recovery ® Index.

2. You can choose the tables for which you want to display indexes marked as BAD. To do this, enter appropriate search arguments for the owner, table name, and index name.

3. Choose Actions ® Search. The system displays a list of the indexes that match your criteria.

4. Select the indexes that you want to restore.

5. Choose Actions ® Recreate to perform the action.

We recommend that you restore the indexes during periods where the load in the system is low.


Restoring a Mirrored Log Volume (MaxDB: Database Manager GUI)

Restoring a Mirrored Log Volume

If your log volumes are mirrored, it is possible that one of the volume mirrors may fail. If there are problems accessing the log area or the mirror log area, the affected log volume is flagged as BAD, and the database instance is transferred to the OFFLINE operational state.

You can use the Database Manager GUI to restore a damaged mirror log volume. When you do this, the complete content of the relevant log volume is copied from the other log area to the faulty log volume. This ensures that, if disk errors destroy the content of a log volume, the database instance does not need to be restored, since the content of the log volume is mirrored.

Prerequisites

The database instance is in the ADMIN operational state.

Procedure

1. Choose Instance ® Recovery ® Volumes.
Select the BADvolumes that you want to recover.

2. Choose Actions ® Reintegrate to start copying the mirror volume.

See also:

Log Mode


Displaying Information (MaxDB: Database Manager GUI)

Displaying Information

For an overview of all available information and statistics for important database functions, select a database instance in the list of database instances.

If you want to view detailed information about a particular area, choose Instance ® Information and then the required area. Information is available for the following topics:

Activity | Displaying Database Activities
Caches | Displaying Cache Information
Data Area | Displaying Data Area Information
Log Area | Displaying Log Area Information
Backup History | Displaying the Backup History
Parameters | Displaying Database Parameters
Sessions | Displaying Database Sessions
System Info Tables | Displaying System Tables


Displaying Cache Information (MaxDB: Database Manager GUI)

Displaying Cache Information

You can display the hit rate of the caches in the Database Manager GUI. These hit rates show you whether the caches have been configured with enough space. The hit rates for the data cache and the converter are particularly important.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® Caches.

Type | Cache type
Accesses | Total number of accesses
Successful | Number of successful accesses
Unsuccessful | Number of unsuccessful accesses
Hit Rate (%) | Hit rate (number of hits as a percentage of the total number of accesses)

The hit rate of the data cache should be at least 99% and the converter hit rate should be at least 98%.

Lower hit rates can occur for a short time, for example when tables are read for the first time, or when the table does not fit into 10% of the data cache in the case of repeated table scans.

If the values are permanently lower than the recommended percentage, this is a sign of poor performance and the general database parameter CACHE_SIZE must be adjusted accordingly.


Displaying Database Activities (MaxDB: Database Manager GUI)

Displaying Database Activities

You can display the database activities in the Database Manager GUI.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® Activity.

You see a display of the database activities, split into the following sections:

· Commands: Information about the SQL statements

· I/O Activity: Information about the read and write activities

· Lock Activity: Information about lock activities

· Log Activity: Information about log activities

· Scan and Sort Activity: Information about table scans

Commands

The Commands section includes the following information about the SQL statements:

Command Type | Command Function
SQL Commands | Number of SQL statements sent to the database system to be executed. A direct indicator of database activity.
Prepares | Number of dynamic SQL statements
Executes | Number of executed dynamic SQL statements
Rollbacks | Unsuccessful database operations, usually caused by crashed applications
Commits | Successful database operations. The ratio between ROLLBACK actions and COMMIT actions can indicate logical inconsistencies in one or more SQL statements.
Updates, Selects and Fetches, Creates, Alters, Drops, DB procedure calls, Deletes, Inserts | Number of SQL statements, possibly with row information

I/O Activity

The I/O Activity section gives you information about I/O activities triggered by the database system. This includes details of logical and physical read and write activities.

In a physical read or write activity, the system accesses a volume directly. A logical read or write activity, on the other hand, uses data stored in the data cache or another cache.

Lock Activity

The Lock Activity section gives you information about the maximum number of available database locks (Available Entries), as well as the number of locks that have been set. If the number of locks that have been set approximates the number of available entries, you may need to increase the value of the general database parameter MAXLOCKS.

Escalations shows you the total number of rows that have been locked in a single database session. As soon as the number of locked rows exceeds a specific percentage, the database system locks the entire table. The threshold for Escalations is based on the MAXLOCKS value for this database instance.

If a locked object is requested again, a lock conflict occurs. If a large number of lock conflicts occur in your system, this means that a specific lock is being held too long, or multiple users are trying to access the same part of the database too often.

The values of Lock Owner and Lock Requestor relate to the locks that exist when the transaction is executed.

Scan and Sort Activity

The Scan and Sort Activity section shows you information about the table scans, among other things.

Keep the number of table scans to a minimum, since a high number of sequential scans can have a negative effect on database performance.


Displaying Database Parameters (MaxDB: Database Manager GUI)

Displaying Database Parameters

In the Database Manager GUI, you can display all the database parameters, as well as a chronological list of all changes made to these parameters.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® Parameters.

The display of the database parameters is divided into the following sections:

· General: Displays the general database parameters

· Extended: Displays the special database parameters

· Support: Displays the support parameters

· History: You can use the parameter history to find out when a parameter setting was changed, and the old and current values of the parameter.

See also:

Displaying and Changing Database Parameters


Displaying Database Sessions (MaxDB: Database Manager GUI)

Displaying Database Sessions

You can display all users that are currently connected to the database in the Database Manager GUI.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® Sessions.

The following information is displayed:

Name | Name of the logged on user
Terminal ID | A terminal identification specific to the particular operating system.
Task ID | Number of the task
Session ID | Number of the database session
Node | Name of the database computer
Catalog Cache Size | Size of catalog cache available for user

See also:

Closing a Database Session Manually


Displaying Data Area Information (MaxDB: Database Manager GUI)

Displaying Data Area Information

You can display information on the size and current usage of the data area in the Database Manager GUI.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® Data Area.

The display is divided into the following areas:

· Volumes: Information about the data volumes

· Settings: Value of the database MAXDATAVOLUMES

· Usage: Usage of the data area

· I/O: Reads and writes for each data volume

Volumes

Among other things, you see the following information for each data volume: name, size, type, and path in the run directory.

Settings

The maximum number of data volumes is controlled by the general database parameter MAXDATAVOLUMES. The current value of this database parameter is displayed.

Usage

If the database instance is in the ONLINE operational state, you can display the usage of the data area.

Total Size | Total size of the data area
Used Area | Used data area
Permanent Used Area | Data area used by permanent data
Temporary Used Area | Data area used by temporary data
Free Area | Free data area

You also see the fill level of each data volume.

I/O

If the database instance is in the ONLINE operational state, you can display the read and write activities for each data volume.


Displaying Log Area Information (MaxDB: Database Manager GUI)

Displaying Log Area Information

You can display information on the size and current usage of the log area in the Database Manager GUI.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® Log Area.

The display is divided into the following areas:

· Volumes: Information about the log volumes

· Settings: Information about the log settings, values of the database parameters MAXLOGVOLUMES and LOG_SEGMENT_SIZE

· Usage: Usage of the log area

· I/O: Reads and writes for each log volume

Volumes

Among other things, you see the following information for each log volume: name, size, type, and path in the run directory.

Settings

You can control redo log management by making various log settings. The following settings are displayed:

· Log Mode: See Log Mode
SINGLE: The log volumes are not mirrored.
MIRRORED: The log volumes are mirrored.

· Overwrite Mode: See Overwrite Mode for the Log Area
NORMAL: The log area cannot be overwritten until the log entries have been backed up.
OVERWRITE: The log area is overwritten when it is full.

· Redo Log Management: See Activating or Deactivating Redo Log Management
ACTIVATED: Redo log management is activated.
DEACTIVATED: Redo log management is deactivated.

See also:

Changing Log Settings

The maximum number of data volumes is controlled by the general database parameter MAXDATAVOLUMES. The general database parameter LOG_SEGMENT_SIZE controls the size of segment that is chosen when log backups are made. The current values of these database parameters are displayed.

Usage

If the database instance is in the ONLINE operational state, you can display the usage of the log area.

Total Size | Total size of the log area
Free Log Area | Free log area
Used Log Area | Used log area
Unsaved Log Area | Size of the log area that has not yet been backed up
Log since last data backup | Log entries written since the last data backup

I/O

If the database instance is in the ONLINE operational state, you can display the read and write activities for each log volume.


Displaying the Backup History (MaxDB: Database Manager GUI)

Displaying the Backup History

You can display a chronological list of all completed backup and restore operations (see also Backup History) in the Database Manager GUI.

Procedure

Select the required database instance in the list of database instances.

Choose Instance ® Information ® Backup History
or
choose Instance ® Backup ® Backup History

You see the following information for each action:

Label | Backup ID
Action | The action (backup or recover) and the mode in which it took place.
Beginning | Time when the action began
Result | Result
Media Name | Name of backup medium
Log Required | Log backups required
Size (KB) | Size (KB)
Volumes | Volumes
Next Log Page | Log page
From Page | From page number
To Page | To page number

For more information, choose Actions and one of the following functions:

· ® Show details
The system displays media information. If you are using external backup tools, the system displays the external backup IDs and the availability of the backup media.

· ® Columns
You can create your own personal display variant of the backup history here.

· ® Refresh with External Backup Info
You update the backup history and the information about the backups that were performed with external backup tools.


Displaying System Tables (MaxDB: Database Manager GUI)

Displaying System Tables

In the Database Manager GUI, you can display the system tables that contain information about the database states.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® System Info Tables.

You see a list of the system tables with information about the database states. The owner of these tables is the SYSINFO user. Click a table to display the state information stored in this table.


Options for Diagnosing Problems (MaxDB: Database Manager GUI)

Options for Diagnosing Problems

In the event of errors or performance problems, the Database Manager GUI offers you a number of options for diagnosing the problem.

Select the required database instance in the list of database instances. Choose Instance ® Check and then the required area:

Database Structure | Checking Database Structures
Database Server | Checking Database Servers
Diagnosis Files | Reading Database Files
Database Trace | Activating the Database Trace

Choose Instance and then the required area:

Command Line | Using the Command Line Version (Database Manager CLI)
OMS Caches | Displaying OMS Caches
OMS Container | Displaying OMS Class Containers
OMS Monitor | Activating the OMS Monitor

·


Reading Database Files (MaxDB: Database Manager GUI)

Reading Database Files

The database system has a number of database files. These include the Database Manager files.

You can access the existing database files from the Database Manager GUI.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Check ® Diagnosis Files.

Select the file you want.


Checking Database Servers (MaxDB: Database Manager GUI)

Checking Database Servers

The Database Manager GUI provides you with an overview of the operating system resources that the database instance is using, how the database sessions have been distributed among the threads and the status of the active database sessions.

Additional functions are available, but these are mainly reserved for support employees and developers.

Prerequisites

The database instance is the ONLINE or the ADMIN operational state.

Procedure

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Check ® Database Server.

3. Select the type of information you want.

4. To display the details, choose Actions ® View.


Checking Database Structures (MaxDB: Database Manager GUI)

Checking Database Structures

You can use the Database Manager GUI to perform a check of the database structures.

If there are serious inconsistencies, the database instance must be restored in the same way as after a disk failure.

When you check the database structures in the operational state ADMIN, any free memory pages that are wrongly recorded as used because the database has been stopped incorrectly are released to free space management.

Prerequisites

The database instance is the ONLINE or the ADMIN operational state.

Procedure

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Check ® Database Structure.

3. Choose Actions ® Execute.

The information supplied by the database kernel is written to the Database Errors file.

You can analyze this file as described in Reading Database Files.


Activating the Database Trace (MaxDB: Database Manager GUI)

Activating the Database Trace

The Database Manager GUI gives you the option of activating the database trace function if errors occur.

Use this function when asked to do so by your Support organization. Enable the database trace function only if it is really necessary, since it seriously affects the performance of the database instance.

Deactivate the database trace function as soon as the actions needed for the analysis have been logged.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Check ® Database Trace.

You can execute the log functions below either individually or in a combination that you can define yourself.

Logging Database Statements in General

1. On the Options tab page, select the required database trace options in the list. If the options support the selection of a trace level, the system default value is displayed in the column Level.

2. Choose Actions ® Selected Items ON to activate the database trace for the chosen database trace options.

If you want to change the trace level for the selected database trace options, choose Actions ® Selected Items ON with Level... You can now select a different trace level. The higher the trace level, the greater amount of detail is provided in the information collected by the database trace.

Choose Actions ® Selected Items OFF to deactivate the database trace.

Logging Database Statements in a Specific Database Session

The database trace is written for all database sessions by default. The default setting can be changed:

1. Choose the Advanced tab page and select Trace session.

2. Decide whether the database trace is to be written for the current session or for a specific database session. In this case, enter the ID of the database session (for information about finding the ID, see Displaying Database Sessions).

3. Choose Actions ® Set Advanced Options.

Logging the Occurrence of Specific Errors

1. On the Advanced tab page, select Stop on error. Enter the code of the error whose occurrence is to stop the creation of the database trace.

2. Then choose Actions ® Flush to write the information still contained in the buffer to the trace and therefore update the database trace before the log file is created.

Creating and Displaying the Database Trace Log

1. On the Protocol tab page, select the required options.

2. Then choose Actions ® Flush to write the information still contained in the buffer to the trace and therefore update the database trace before the log file is created.

3. Choose Actions ® Make Protocol. The database trace is then converted to a legible format.

To open the log, choose Instance ® Check ® Diagnosis Files. Select the Kernel Trace Protocolfile and choose Actions ® View.


Using the Command Line Version (Database Manager CLI) (MaxDB: Database Manager GUI)

Using the Command Line Version (Database Manager CLI)

You can call the command line version of the Database Manager, the Database Manager CLI, from the Database Manager GUI.

Procedure

1. Select the required database instance in the list of database instances.

2. Choose Instance ® Command Line.

3. Enter the required DBM commands in the line Command.

4. Choose Actions ® Execute.


Displaying OMS Caches (MaxDB: Database Manager GUI)

Displaying OMS Caches

This Database Manager GUI function supports performance analysis of SAP liveCache.

Prerequisites

The current database instance is a liveCache instance. You are in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® OMS Caches, to display the OMS Caches.

For more information about liveCache, see the User Manual: SAP liveCache.


Displaying OMS Class Containers (MaxDB: Database Manager GUI)

Displaying OMS Class Containers

This Database Manager GUI function supports performance analysis of SAP liveCache.

Prerequisites

The current database instance is a liveCache instance. You are in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® OMS Class Containers to display the information about the class containers.

For more information about liveCache, see the User Manual: SAP liveCache.


Activating the OMS Monitor (MaxDB: Database Manager GUI)

Activating the OMS Monitor

This Database Manager GUI function supports performance analysis of SAP liveCache.

Prerequisites

The current database instance is a liveCache instance. You are in the ONLINE operational state.

Procedure

Select the required database instance in the list of database instances. Choose Instance ® Information ® OMS Monitor to activate the OMS Monitor.

For more information about liveCache, see the User Manual: SAP liveCache.


Updating the Database Software (MaxDB: Database Manager GUI)

Updating the Database Software

After you have updated the database software, you can use the Database Manager GUI to make sure that the database instance recognizes the new software version.

Procedure

1. Update the database software.

2. Start the database instance.
The first time the Database Manager is started after update of the database software, it automatically adjusts the kernel parameters of the database instance to this new version.

3. To update the system tables, choose Instance ® Configuration ® Upgrade System Tables.

Result

The Database Manager creates a copy of the parameter file each time a parameter is changed.

UNIX: <independent_data_path>/config/<database_name>.<running_number>
Microsoft Windows: <independent_data_path>\config\<database_name>.<running_number>

<running_number>: Version of the copy, starting with 01

If parameter errors occur, the operation can be undone by restoring the original parameter file. To do this, use the Database Manager CLI program to copy the file <database_name>.<running_number> (copy of parameter file) back to <database_name> (active parameter file).


Updating the System Tables (MaxDB: Database Manager GUI)

Updating the System Tables

You can use the Database Manager GUI to update the system tables when you update the database software.

Prerequisites

The database instance is in the ONLINE operational state.

Procedure

...

1. Select the required database instance in the list of database instances.

2. Choose Instance ®Configuration ®Upgrade System Tables.

3. Start the update of the system tables. The Database Manager determines the required database users (SYSDBA and DOMAIN).If this is not possible, you are prompted to provide the users yourself.

Result

The system tables are loaded and updated. The log dbm.ins (Installation Protocol) is displayed.

If an error occurs, the ERROR status appears. In this case, analyze the Installation Protocol as described in Reading Database Files.


Accessing the SQL Studio Program (MaxDB: Database Manager GUI)

Accessing the SQL Studio Program

You can call the query tool SQL Studio from the Database Manager GUI. This program enables you to access the data of a database instance.

Prerequisites

You have the authorization of a database user of this database instance.

Procedure

Choose Tools ® SQL Studio.

For information about this tool, see SQL Studio.


Screen Areas of the Database Manager GUI (MaxDB: Database Manager GUI)

Screen Areas of the Database Manager GUI

The screen of the Database Manager GUI is structured into eight different areas. You can change the size of these screen areas.

1
2
4 | 3
5 | 6
7 |  | 8

Contents of the Screen Areas

No. | Name of the Window | Description
1 | Menu bar | Selection of functions and displays for the current database instance. The menu bar dynamically adjusts to the selected functions.
2 | Icon bar | The icon bar contains icons you can use to call up functions shown on the menu bar for the current database instance.
3 | List of the database instances | Database instances included in the Database Manager GUI's list of database instances, their logon status and operational states If a database instance has the operational state ONLINE, you also see an overview of its statistics and other important data. See also: Managing the List of Database Instances
4 | Directory structure of the database instances | Organization of the database instances included in the Database Manager GUI’s list of database instances (as in Windows Explorer) You can show or hide the directory structure. To do this, choose View ® Tree and select or deselect Tree.
5 | Menu list of the current database instance | The name of the chosen database instance is displayed. You can display or hide this menu list. To do this, choose View ® Menu and select or deselect Menu.
6 | Output area | Central screen area Contains input fields and output values.
7 | Message output area | Display of general and error messages
8 | Display of the database name | Name of the current database instance, possibly including the name of the database computer and its operational state


Web DBM

The Web DBM is a variant of the Database Manager, the tool you use for the management of database instances.

Working with the Database Manager requires a thorough knowledge of the administration of database instances, gathered through experience.

The installation of the Web DBM is described in the Web Tools Installation Guide. For general information about the database system, see the documentation Database Administration.

Documentation

The screen settings and procedures in the Web DBM largely resemble those in the Database Manager GUI. For this reason, use the Database Manager GUI documentation when you work with the Web DBM.

Monitoring Multiple Database Instances

You can use the Database Manager GUI to monitor multiple database instances at the same time. The Web DBM only allows you to connect to one database instance at a time. However, you can still monitor multiple database instances simultaneously. To do this, open as many browser windows as you need with the Web DBM, and log on to each database instance in a different window.

Wizards

The Database Manager GUI includes Wizards that guide you through the procedures for installing and registering database instances and for backups and recoveries.

If you want to install a new database instance with the Web DBM, choose New Database on the logon screen. You do not need to register the database instances with the Web DBM, since the Web DBM only refers to a single database instance.

If you want to back up or recover a database instance, choose the appropriate function, and a Backup Wizard or Recovery Wizard guides you through the procedure, without opening a new window.

Timeouts

Unlike the Database Manager GUI, you may experience timeouts when you work with the Web DBM. A timeout breaks the connection to the database instance, in which case you need to log on again.


Database Manager CLI

Purpose

The Database Manager is the administration tool for database instances. You can use this tool to create and monitor database instances on local and remote hosts. You can back up the data from database instances, and recover the data, if necessary.

Implementation Considerations

The database management tool Database Manager can be called as a graphical user interface (Database Manager GUI), as a Web-based tool (Web DBM), or as a command-line oriented tool (Database Manager CLI). All three versions of this program offer a similar range of functions.

The Database Manager CLI and the Web DBM can be installed on all supported operating systems. The Database Manager GUI can run on Microsoft Windows only.

Each version of the Database Manager can be used for the administration of database instances on all operating systems supported by the database system.

A sound knowledge of database administration is required to work with the Database Manager.

You can download the Database Manager CLI program free of charge at the address http://www.mysql.com/downloads. It is a part of the software package for the database kernel, which means it is included in the installation profiles all and Server.

For general information about the database system, see the Database Administration documentation.

You can also access the functions of the Database Manager CLI with other programming languages, and therefore automate the administration of database instances using programs. You can use the following programming interfaces to do this:

Programming Language | Module
Java | powertoys.DBM
Python | sapdb.dbm
Perl | SAP::DBtech::dbm

For more information, see the Perl and Python user manuals.

The Database Manager CLI, Version 7.5, is described in the following topics:

Functions of the Database Manager CLI

Logging On to the Database Manager

Working with the Database Manager CLI

Ending the Database Manager

Overview of All DBM Commands


Functions of the Database Manager CLI (MaxDB: Database Manager CLI)

Functions of the Database Manager CLI

The Database Manager CLI is an easy-to-use tool that can manage any number of local or remote database instances. These can be managed from the command line. The program is suitable for both interactive and background operation.

The Database Manager CLI is the client program of the Database Manager, which enables you to connect to the DBM Server and exchange data with it. It can only be called by a Database Manager operator (DBM operator).

To be able to administer a database instance, a DBM operator logs on to the Database Manager with a user name and password, and registers this database instance in the Database Manager. He or she uses DBM commands and Options , to log on to the database instance and to send requests to the Database Manager. To be able to execute DBM commands, the DBM operator must have the necessary operator authorization . The Database Manager transfers the replies to the commands and the specified options. As well as information on the state of the database instance, the reply contains formatted data ( Reply Format ).

Calling up the Database Manager CLI is equivalent to opening a session. Once the entered commands have been processed, the session with the Database Manager is closed.


Server Authorizations (MaxDB: Database Manager CLI)

Server Authorizations

To be able to execute DBM commands, the Database Manager operator (DBM operator) must have the required authorizations to be able to access the DBM server and therefore the Database Manager program. These authorizations are called server authorizations and are stored in the Database Manager under the authorization type SERVERRIGHTS. A server authorization may cover more than one DBM command and one DBM command may have more than one server authorization assigned to it.

(See also: Authorizations of a DBM Operator)

An overview of which server authorizations is required for which actions in the Database Manager is presented below.

Server Authorization | Explanation
AccessAdmin | Access to Database Session
AccessSQL | Access to SQL Session
AccessUtility | Access to Utility Session
Backup | Performing Backups
DBFileRead | Accessing Database Files (Reading Only)
DBInfoRead | Displaying Status Information
DBStart | Starting the Database Instance
DBStop | Stopping the Database Instance
ExecLoad | Executing the LOAD Program
InstallMgm | Installation Management
LoadSysTab | Loading the System Tables
ParamCheckWrite | Accessing Database Parameters (Checked Writing)
ParamFull | Accessing Database Parameters (Reading and Writing)
ParamRead | Accessing Database Parameters (Reading Only)
Recovery | Restoring Backups
SystemCmd | Executing Operating System Commands
UserMgm | Managing DBM Operators


Displaying Status Data: DBInfoRead (MaxDB: Database Manager CLI)

Displaying Status Data: DBInfoRead

Operators who have been assigned the DBInfoRead server authorization can execute the following DBM commands:

Activating an Event | event_set
Change Date of the Media Definition File | medium_date
Change Date of the Backup History | backup_history_date
Displaying the Automatic Log Backup | autolog_show
Displaying the Media Data | medium_get
Displaying the Keywords for Information About the Database Instance | show_list
Displaying the Backup History | backup_history_list
Displaying the Database Kernel Variant | db_speed
Displaying the Operational State of the Database Instance | db_state
Displaying External Backup IDs | backup_ext_ids_list
Displaying Information About the Database Instance | show
Displaying Status Information for the Database Instance | info
Terminating an Event Session | event_release
Terminating an SQL Session | sql_release
Scrolling in the External Backup IDs | backup_ext_ids_listnext
Scrolling in the Information About the Database Instance | show_next
Scrolling in the Status Information of the Database Instance | info_next
Scrolling in the Backup History | backup_history_listnext
Deactivating an Event | event_delete
Opening an SQL Session | sql_connect
Releasing the Memory Occupied by the External Backup IDs | backup_ext_ids_forget
Fetching the Backup History | backup_history_open
Fetching External Backup IDs | backup_ext_ids_get
List of All Defined Backup Media | medium_getall
Creating a List of Events and their Status | event_list
Closing the Backup History | backup_history_close
Copying an Existing Media Definition | medium_migrate
Waiting for an Event | event_wait


Executing the Program LOAD: ExecLoad (MaxDB: Database Manager CLI)

Executing the Program LOAD: ExecLoad

Operators who have been assigned the ExecLoad server authorization can execute the following DBM commands:

Loading the System Tables | load_systab
Loading SAP-Specific Tables | load_r3tab
Starting the PythonLOAD Program | exec_load


Executing Operating System Commands: SystemCmd (MaxDB: Database Manager CLI)

Executing Operating System Commands: SystemCmd

Operators who have been assigned the SystemCmd server authorization can execute the following DBM command:

Executing the liveCache Initialization Script

exec_lcinit


Performing Backups: Backup (MaxDB: Database Manager CLI)

Performing Backups: Backup

Operators who have been assigned the Backup server authorization can execute the following DBM commands:

Change Date of the Media Definition File | medium_date
Change Date of the Backup History | backup_history_date
Defining or Changing a Backup Medium | medium_put
Displaying Current Information About the Database Instance | db_restartinfo
Displaying External Backup IDs | backup_ext_ids_list
Displaying the Automatic Log Backup | autolog_show
Displaying the Media Data | medium_get
Displaying the Backup History | backup_history_list
Displaying the Backup Information in the Operational State OFFLINE | medium_labeloffline
Displaying the Backup Information in the Operational State ONLINE or ADMIN | medium_label
Displaying the Current Status of a Backup Check | recover_state_check
Displaying the Current Backup Status | backup_state
Deactivating the Automatic Log Backup | autolog_off
Terminating a Service Session | service_release
Terminating an Interrupted Automatic Log Backup | autolog_cancel
Terminating an Interrupted Backup | backup_cancel
Terminating an Interrupted Restore or Backup Check | recover_cancel
Terminating a Utility Session | util_release
Scrolling in the External Backup IDs | backup_ext_ids_listnext
Scrolling in the Backup History | backup_history_listnext
Activating the Automatic Log Backup | autolog_on
Opening a Service Session | service_connect
Opening a Utility Session | util_connect
Continuing a Parallel Restore or Backup Check | recover_ignore
Continuing the Backup Without the Medium Last Reported as Full | backup_ignore
Releasing the Memory Occupied by the External Backup IDs | backup_ext_ids_forget
Fetching the Backup History | backup_history_open
Fetching External Backup IDs | backup_ext_ids_get
List of All Defined Media | medium_getall
Deleting a Backup Medium | medium_delete
Checking a Backup | recover_check
Closing the Backup History | backup_history_close
Backing Up to a Succeeding Medium | backup_replace
Backing Up the Database Instance | backup_start
Copying an Existing Media Definition | medium_migrate
Restoring or Checking a Backup with Succeeding Medium | recover_replace


Installation Management: InstallMgm (MaxDB: Database Manager CLI)

Installation Management: InstallMgm

Operators who have been assigned the InstallMgm server authorization can execute the following DBM commands:

Updating the Registration of a Database Instance | db_reg
Changing a Configuration Parameter of the Database Manager | dbm_configset
Displaying a Configuration Parameter of the Database Manager | dbm_configget
Initializing the Database Parameter for a New Database Instance | param_init
Copying a Database Parameter File | param_copy
Deleting the Current Database Instance | db_drop
Deleting the Database Parameter File | param_rmfile


Loading the System Tables: LoadSysTab (MaxDB: Database Manager CLI)

Loading the System Tables: LoadSysTab

Operators who have been assigned the LoadSysTab server authorization can execute the following DBM commands:

Loading the System Tables | load_systab
Loading SAP-Specific Tables | load_r3tab


Starting the Database Instance: DBStart (MaxDB: Database Manager CLI)

Starting the Database Instance: DBStart

Operators who have been assigned the DBStart server authorization can execute the following DBM commands:

Starting the Database Instance | db_start
Transferring to the ONLINE Operational State | db_online


Stopping the Database Instance: DBStop (MaxDB: Database Manager CLI)

Stopping the Database Instance: DBStop

Operators who have been assigned the DBStop server authorization can execute the following DBM commands:

Using the Database Console | db_cons
Deleting Runtime Information After a Database Error | db_clear
Restarting the Database Instance | db_restart
Stopping the Database Instance | db_stop
Transferring to the ADMIN Operational State | db_admin
Transferring to the OFFLINE Operational State | db_offline


Managing DBM Operators: UserMgm (MaxDB: Database Manager CLI)

Managing DBM Operators: UserMgm

DBM operators who have been assigned the UserMgm server authorization can execute the following DBM commands:

Changing DBM Operator Data | user_put
Creating DBM Operators | user_create
Displaying the Server Authorizations | user_getrights
Displaying Operator Data | user_get
List of Registered Database Users | user_getall
Deleting DBM Operators | user_delete


Restoring Backups: Recovery (MaxDB: Database Manager CLI)

Restoring Backups: Recovery

Operators that have been assigned the Recovery server authorization can execute all of the commands listed under the Backup . They can additionally execute the following DBM commands :

Displaying the Current Restore Status | recover_state
Displaying Information About the Database Instance | db_restart_info
Restoring the Database Instance | recover_start
Restoring a Database Parameter File | recover_config


Accessing Database Files (Reading Only): DBFileRead (MaxDB: Database Manager CLI)

Accessing Database Files (Reading Only): DBFileRead

Operators who have been assigned the DBFileRead server authorization can execute the following DBM commands:

Scrolling Through the Further Contents of a Database File | file_getnext
Opening a Database File | file_getfirst
Packing Database Files | diag_pack
Backing Up a Database File | file_backup
Restoring a Database File | file_restore


Accessing Database Parameters (Checked Writing): ParamCheckWrite (MaxDB: Database Manager CLI)

Accessing Database Parameters (Checked Writing): ParamCheckWrite

Operators that have been assigned the ParamCheckWrite server authorization can execute all of the commands listed under the ParamRead . They can additionally execute the following DBM commands :

Changing the Value of a Database Parameter | param_put
Changing Volume Parameters | param_addvolume
Confirming Changes to the Database Parameter File | param_commitsession
Correcting Parameters | param_putconfirm
Deleting Volume Parameters | param_delvolume
Checking All Database Parameters | param_checkall
Resetting the Parameter File to a Previous Version | param_restore


Accessing Database Parameters (Reading and Writing): ParamFull (MaxDB: Database Manager CLI)

Accessing Database Parameters (Reading and Writing): ParamFull

Operators that have been assigned the ParamFull server authorization can execute all of the commands listed under the ParamRead and ParamCheckWrite operator authorizations. They can additionally execute the following DBM commands :

Directly Changing a Value in the Database Parameter File | param_directput
Adding a Volume | db_addvolume
Deleting a Parameter | param_directdel


Accessing Database Parameters (Reading Only): ParamRead (MaxDB: Database Manager CLI)

Accessing Database Parameters (Reading Only): ParamRead

Operators who have been assigned the ParamRead server authorization can execute the following DBM commands:

Terminating a Parameter Session | param_abortsession
Displaying All Data for a Database Parameter | param_getfull
Displaying All Properties of a Database Parameter | param_getproperties
Displaying All Parameters of the Current Database Parameter File | param_directgetall
Displaying the Data for All Database Parameters | param_extgetall
Displaying the Data for All Volume Parameters | param_getvolsall
Displaying the Data for Individual Volume Parameters | param_getvolume
Displaying the Current Value of a Database Parameter | param_getvalue
Displaying the Data Type of a Database Parameter | param_gettype
Displaying the Stored Explanatory Text | param_getexplain
Displaying the Stored Help Text | param_gethelp
Displaying the System Default Value | param_getdefault
Displaying a Value from the Database Parameter File | param_directget
Displaying Individual Data for a Database Parameter | param_extget
Scrolling in the Database Parameter History | param_gethistorynext
Opening a Parameter Session | param_startsession
List of Available Parameter Files | param_versions
Opening the Database Parameter History | param_gethistory


Access to Database Session: AccessAdmin (MaxDB: Database Manager CLI)

Access to Database Session: AccessAdmin

Operators who have been assigned the AccessAdmin server authorization can execute the following commands:

Activating a New Database Instance | db_activate
Executing a Database Statement | db_execute
Ending a Database Session | db_release
Opening a Database Session | db_connect


Access to SQL Session: AccessSQL (MaxDB: Database Manager CLI)

Access to SQL Session: AccessSQL

Operators who have been assigned the AccessSQL server authorization can execute the following commands:

Updating the Optimizer Statistics | sql_updatestat
Updating the Optimizer Statistics with the XPU Program | exec_xpu
Displaying the Structure of a Result Set | sql_info
Executing an SQL Statement | sql_execute
Scrolling in the Additional Result Data | sql_fetch
Opening an SQL Session | sql_connect
Closing an SQL Session | sql_release
Recreating a Damaged Index | sql_recreateindex


Accessing a Utility Session: AccessUtility (MaxDB: Database Manager CLI)

Accessing a Utility Session: AccessUtility

Operators who have been assigned the AccessUtility server authorization can execute the following DBM commands:

Executing a Utility or SQL Command | util_execute
Terminating a Utility Session | util_release
Opening a Utility Session | util_connect
Adding a Volume | db_addvolume


Opening a DBM Server Session (MaxDB: Database Manager CLI)

Opening a DBM Server Session

Use

You open a session with the DBM Server and define to which database instance the subsequent transferred options and commands refer. If the database instance is on a remote server, you must specify the server name <database_server> in addition to the name of the database instance <database_name>.

A DBM Server session is the prerequisite for Logging on to the Database Manager Program and the execution of most DBM Commands.

Prerequisites

You have installed the installation profile all or Server on your server. The Database Manager CLI program is contained in both installation profiles.

Syntax

dbmcli –d <database_name> [-n <database_server>]

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Calling the Database Manager CLI (MaxDB: Database Manager CLI)

Calling the Database Manager CLI

Use

DBM options with a maximum of one DBM command can be transferred when the Database Manager CLI program is called.

Additional parameters can be specified for DBM options. The description of each DBM option explains which parameters are possible.

Additional command options can be specified for the DBM command. The description of each DBM command explains which command options are possible.

There is input help available for the DBM commands.

For information about the format of the return values for DBM commands, see Reply Format.

Syntax

dbmcli [<dbm_options>] [<dbm_command> [command_options]]

If you use DBM options in conjunction with parameters, mark the beginning of the next DBM command with the option –c (Indicator as DBM Command: -c).
By doing so, you avoid the Database Manager program interpreting the beginning of the DBM command as a parameter of the previously specified DBM option.

Example

Log on to the Database Manager CLI as operator DBM with password DBM, display the contents of the customersdatabase table of the database instance HOTELDB without explicitly specifying an operator (the Database Manager uses the data of the DBM operator currently logged on):

dbmcli –d HOTELDB –u DBM,DBM –uSQL -c sql_execute SELECT * FROM customers


DBM Options (MaxDB: Database Manager CLI)

DBM Options

You can use the following DBM options in the Database Manager CLI (see also: Command Structure):

Creating or Changing XUSER Entries | -us
Logging On to the XUSER Program | -ux
Displaying XUSER Data | -ul
Opening a Service Session | -uSRV
Opening an SQL Session | -uSQL | -USQL
Opening a Utility Session | -uUTL | -UUTL
Installation Directory of the Database Instance | -R <inst_path>
Indicate as DBM Command | -c
Deleting XUSER Entries | -ud
Name of the Output File | -o <file_name>
Name of the Database Instance | -d <database_name>
Name of the Log File | -t <file_name>
Name of the Database Server | -n <database_server>
Name of the Input Script | -i <file_name> | -ic <file_name>
Version of the Database Manager | -V
XUSER Key | -uk

If you use DBM options with optional parameters, mark the beginning of the DBM command with the option –c (Indicate as DBM Command: -c).
By doing so, you prevent the Database Manager program interpreting the beginning of the DBM command as a parameter of the previously specified DBM option.


Creating or Changing XUSER Entries: -us (MaxDB: Database Manager CLI)

Creating or Changing XUSER Entries: -us

Use

From the Database Manager CLI, you can use the DBM option –us to create new XUSER entries for DBM operators or database users using program XUSER, or you can overwrite existing entries.

XUSER entries are sets of user data, which are defined by key names. They facilitate the logon process to programs that support XUSERs. You can use an XUSER key together with the DBM option –U to log on to the Database Manager. This means you do not have to specify a DBM operator name and password (DBM option –u), since the Database Manager CLI takes the required data from the relevant XUSER entry.

To create or change XUSER entries, we recommend you use the XUSER tool directly.

See also: XUSER

You can access the database instance with a user stored under an XUSER entry only if that user was actually created for this database instance. DBM operators have to be created using the Database Manager (see also Creating DBM Operators); database users have to be created using the Query Tools.

Creating XUSER Entries

You do not need to log on to the XUSER program to create new XUSER entries.

You can define a key name for an XUSER, under which the entry is to be stored.

You can also get the Database Manager CLI to generate this key name from a combination of the database name and server name. You do so by specifying the database instance and database server in addition to the user name and password.

To work in the Database Manager, we recommend you create an XUSER entry with the key name DBMUSR and the user data for the first DBM operator. If you specify the DBM option –U without a key name, the Database Manager CLI attempts to access this key implicitly when you log on to this program.

Changing XUSER Entries

To change XUSER entries, you must log on with the data of the user that you want to change, or with the data stored under the DEFAULT XUSER key.

If you log on with the data stored under the DEFAULT XUSER key, you are authorized to change all XUSER entries. To identify the XUSER entry you want to change, use the DBM option –uk or a combination of the database name and server name (DBM options -d and –n).

Syntax

-us <new_user_name>,<new_user_password>

Examples

Creating a New XUSER Entry

...

1. Call the Database Manager CLI, create a new XUSER entry (example: user MONA with password RED), save under a defined key name (example: key name MOKEY):

dbmcli –uk <user_key> –us <new_user_name>,<new_user_password> [options]

dbmcli –uk MOKEY –us MONA,RED

2. Call the Database Manager CLI, create a new XUSER entry (example: User MONA with password RED), save under the key name generated from the database name and server name (example: database instance HOTELDB, server name GENUA):

dbmcli –d <database_name> [-n <database_server>] –us <new_user_name>,<new_user_password> [options]

dbmcli –d HOTELDB –n GENUA -us MONA,RED

Changing an Existing XUSER Entry

...

1. Call the Database Manager CLI. Log on to the XUSER program with the data of the XUSER entry that is to be changed and with DBM option -u (example: change user DAVID, password BLUE to user BORIS, password PINK):

a. Specify which XUSER entry is to be changed by entering the key name (example: key name MOKEY):

dbmcli -u <user_name>,<user_password> -uk <user_key> –us <new_user_name>,<new_user_password> [options]

dbmcli –u DAVID,BLUE –uk DAKEY –us BORIS,PINK

b. Specify which XUSER entry is to be changed by entering the combination of database name and server name (example: database instance HOTELDB, server name GENUA):

dbmcli -u <user_name>,<user_password> –d <database_name> [-n <database_server>] –us <new_user_name>,<new_user_password> [options]

dbmcli –u DAVID,BLUE –d HOTELDB –n GENUA –us BORIS,PINK

2. Call the Database Manager CLI. Log on to the XUSER program with the data stored under the DEFAULT XUSER key and using the DBM option -ux (example: user MONA, password RED):

a. Specify which XUSER entry is to be changed using the DBM option –uk (example: key name: DAKEY).
Specify the new data using the DBM option –us (example: user BORIS, password PINK):

dbmcli -ux <default_user_name>,<default_user_password> -uk <user_key> –us <new_user_name>,<new_user_password> [options]

dbmcli –ux MONA,RED –uk DAKEY –us BORIS,PINK

b. Specify which XUSER entry is to be changed using a combination of the database name and server name (example: database instance HOTELDB, server name GENUA).
Specify the new data using the DBM option –us (example: user BORIS, password PINK):

dbmcli -ux <default_user_name>,<default_user_password> –d <database_name> [-n <database_server>] –us <new_user_name>,<new_user_password> [options]

dbmcli –ux MONA,RED –d HOTELDB –n GENUA –us BORIS,PINK


Logging On to the XUSER Program: -ux (MaxDB: Database Manager CLI)

Logging On to the XUSER Program: -ux

Use

You use the DBM option –ux to log on to the XUSER program from the Database Manager CLI, using the data stored under the DEFAULT XUSER key.

You can use this DBM option to change (DBM option –us) or delete (DBM option –ud) XUSER entries.

We recommend that you use the XUSER tool directly.

See also: XUSER

Syntax

-ux <default_user>,<default_user_password>

Example

Changing an Existing XUSER Entry

dbmcli -ux <default_user_name>,<default_user_password> -uk <user_key> –us <new_user_name>,<new_user_password> [options]

Call the Database Manager CLI, log on as user MONA with password RED (stored under the DEFAULT XUSER key), specify the XUSER entry to be changed with the key name DAKEY, specify the new user name and password – BORIS and PINK:

dbmcli –ux MONA,RED –uk DAKEY –us BORIS,PINK

Deleting an Existing XUSER Entry

dbmcli -ux <default_user_name>,<default_user_password> -uk <user_key> -ud

Call the Database Manager CLI, log on as user MONA with password RED (stored under the DEFAULT XUSER key), specify the XUSER entry to be deleted with the key name DAKEY, specify the DBM option –ud to delete this entry:

dbmcli –ux MONA,RED –uk DAKEY –ud


Displaying XUSER Data: -ul (MaxDB: Database Manager CLI)

Displaying XUSER Data: -ul

Use

You can use the DBM option –ul from the Database Manager CLI to display the user data stored in the XUSER program. You log on to the XUSER program as the user stored under the DEFAULT user key (DBM option -ux).

The system displays a list of the existing XUSER keys with the assigned user names.

See also: XUSER

Syntax

-ul

Example

Cal the Database Manager CLI, log on to the XUSER program with user MONA and password RED (stored under the DEFAULT key name), list all the XUSER entries stored in the XUSER program:

dbmcli -ux MONA,RED -ul

OK
DEFAULT MONA,RED
DAKEY DAVID,BLUE
DBMUSR DBM


Opening a Service Session: -uSRV (MaxDB: Database Manager CLI)

Opening a Service Session: -uSRV

Use

Certain DBM commands require a service session before they can be executed.

If, when you log on to the Database Manager CLI using the DBM options –d (name of the database instance) and –u (DBM operator), you also specify the DBM option –uSRV, the DBM command for opening a service session is executed implicitly.

You use the DBM option –uSQL to transfer the user data for the required database user. The service session is opened with this user data for the specified database instance.

When you end the Database Manager CLI, the service session is also ended.

Syntax

-uSRV

Example

Call the Database Manager CLI, log on to the database instance HOTELDB as operator DBM with password DBM, set up a service session and recover the parameter file for this database instance from the backup medium CPLBM:

dbmcli –d HOTELDB –u DBM,DBM –uSRV recover_config CPLBM

OK


Opening an SQL Session: -uSQL (MaxDB: Database Manager CLI)

Opening an SQL Session: -uSQL

Use

Certain DBM commands require an SQL session before they can be executed.

If, when you log on to the Database Manager CLI using the DBM options –d (name of the database instance) and –u (DBM operator), you also specify the DBM option –uSQL, the DBM command for opening an SQL session is executed implicitly.

You use the DBM option -uSQL to transfer the user data for the required database user. The SQL session is opened with this user data for the specified database instance.

When you end the Database Manager CLI, the service session is also ended.

Note the different meanings of the command with uppercase and lowercase specification.
-uSQL:Specification of the database user identified with the user name and password
-USQL:Logon with a user key stored in the XUSER file for a database user

See also: XUSER

If no operator is specified with -uSQL, the Database Manager CLI uses the data of the first DBM operator for the database instance specified. Opening an SQL session with the first DBM operator is successful only if the DBM operator logged on to the Database Manager CLI has the server authorization required for executing the DBM command for opening an SQL session.

The database user specified with the user name and password or with an XUSER key must have been created for the database instance specified under the DBM option -d, otherwise the command fails.

When the SQL session is opened, any database name stored under a specified XUSER key is ignored.

Syntax

Log on using name and password for a database user:

-uSQL [<database_user>,<database_user_password>]

Or log on with the XUSER key of a database user:
-USQL <user_key>

Example for -uSQL

Call the Database Manager CLI, log on to the database instance HOTELDB as operator DBM with password DBM, display the content of the database table customer for the database user MONA with password RED.

dbmcli -d HOTELDB -u DBM,DBM -uSQL MONA,RED sql_execute SELECT * FROM customer

OK
<content_of_table_customer>

Example for -USQL

Call the Database Manager CLI, log on to the database instance HOTELDB as operator DBM with password DBM, display the content of the database table customer for the database user under the MOKEY XUSER key.

dbmcli -d HOTELDB -u DBM,DBM -USQL MOKEY sql_execute SELECT * FROM customer

OK
<content_of_table_customer>


Opening a Utility Session: -uUTL (MaxDB: Database Manager CLI)

Opening a Utility Session: -uUTL

Use

A utility session for the database instance is a prerequisite for executing certain DBM commands.

If, when you log on to the Database Manager CLI using the DBM options –d (name of the database instance) and –u (DBM operator), you also specify the DBM option–uUTL, the DBM command for opening a utility session is executed implicitly.

You use the DBM option –uUTL to transfer the user data for the required database user. The utility session is opened with this user data for the specified database instance.

When you end the Database Manager CLI, the utility session for the database instance is also ended.

Note the different meanings of the command with uppercase and lowercase specification.
-uUTL:Uses the database user identified with the user name and password
-UUTL:Uses a user key stored in the XUSER file for a database user

See also: XUSER

If you do not specify a user with –uUTL, the Database Manager CLI uses the data of the first DBM operator. Opening a utility session with the first DBM operator is successful only if the DBM operator logged on to the Database Manager CLI has the server authorization required for executing the DBM command for opening a utility session.

If you do not specify a user with –UUTL, the Database Manager attempts to use the user data stored under the c XUSER key. We therefore recommend you create an XUSER entry with the key name C and the data of the first DBM operator (see also: Creating or Changing XUSER Entries).

The database user specified with the user name and password or with an XUSER key must have been created for the database instance specified under the DBM option –d, otherwise the command fails.

When the SQL session is opened, any database name stored under a specified XUSER key is ignored.

Syntax

-uUTL [<database_user>,<database_user_password>]

Or log on with the XUSER key of a database user:

-UUTL [<user_key>]

Example for -uSQL

Call the Database Manager CLI, log on to the database instance HOTELDB as operator DBM with password DBM, open a utility session as database user DAVIDwith password BLUE, and back up the database instance on the backup medium CPLBM:

dbmcli –d HOTELDB –u DBM,DBM –uUTL DAVID,BLUE backup_start CPLBM

OK
<reply_to_backup_command>

Example for -USQL

Call the Database Manager CLI, log on to the database instance HOTELDB as operator DBM with password DBM, open a utility session as the database user stored under the DAKEY XUSER key, and back up the database instance on the backup medium CPLBM:

dbmcli –d HOTELDB –u DBM,DBM –UUTL DAKEY backup_start CPLBM

OK
<reply_to_backup_command>


Installation Directory of the Database Software: -R (MaxDB: Database Manager CLI)

Installation Directory of the Database Software: -R

Use

Several versions of the database system software can be installed on a database server. If you create a new database instance or DBM command that does not refer to a particular database instance or, consequently, to a particular software version, you have to specify the software version to which the subsequent DBM command is to refer. To do so, you use the DBM option –R.

When a session is set up, the system checks whether the specified version on the server is recorded in the list of registered versions. If it is not, the session connection is refused.

When you call the Database Manager CLI with the option -R, a specified database software version can be connected only if the database software version has been registered correctly.

If you specify the option -d and the name of a database instance in addition to the option -R, option -R is ignored. In this case, the Database Manager CLI uses the database software version assigned to the specified database instance.

Syntax

-R <dependent_path>

Examples

Creating a New Database Instance

Log on to the Database Manager CLI as operator DBM with password DBM, create database instance HOTELDB with the software version stored under C:\Program Files\SDB\V75 on the remote server GENUA, identification on this server as operating system user ANNA with password MAY:

dbmcli -R "C:\Program Files\SDB\7500" –n GENUA db_create HOTELDB DBM,DBM ANNA,MAY

OK

Displaying All the Database Instances Available for a Particular Software Version

Log on to the Database Manager CLI as operator DBM with password DBM using the option –R and the installation path for software version 7.5, execute the DBM command for displaying a list of all the database instances registered for the specified version on the server GENUA:

dbmcli -R "C:\Program Files\SDB\7500" –n GENUA db_enum

OK
HOTELDB C:\Program Files\SDB\7500 7.5.0.5 fast online
HOTELDB C:\Program Files\SDB\7500 7.5.0.5 quick offline
HOTELDB C:\Program Files\SDB\7500 7.5.0.5 slow offline


Indicate as DBM Command: -c (MaxDB: Database Manager CLI)

Indicate as DBM Command: -c

Use

If you use a DBM option with optional parameters, you have to separate it logically from subsequent DBM commands. To do so, you insert the DBM option –c. The Database Manager CLI interprets all specifications following –c as a DBM command.

Syntax

-c <DBM_command>

Examples

Call the Database Manager CLI, log on to the database instance HOTELDB as operator DBM with password DBM, display the content of the database system table users without specifying a particular database user.

· If you do not specify -c between the optional parameters of the DBM option and the DBM command, the DBM command is interpreted as a user name/password combination for the option –uSQL. The system displays an error message.

dbmcli -d HOTELDB -u DBM,DBM -uSQL sql_execute SELECT * FROM users

ERR
-24988,ERR_SQL: sql error
-4008,Unknown user name/password combination

· You mark the beginning of the DBM command with the option –c. The default value (first DBM operator) is used for the –uSQL option.

dbmcli -d HOTELDB -u DBM,DBM -uSQL –c sql_execute SELECT * FROM users

OK
...


Deleting XUSER Entries: -ud (MaxDB: Database Manager CLI)

Deleting XUSER Entries: -ud

Use

Option in the Database Manager CLI.

You delete the data and the corresponding XUSER entry for a database user in the XUSER program.

To delete user data, you must log on either with the data of the database user to be deleted or with the user data registered under the DEFAULT user key.

To identify the user whose data is to be deleted, specify a combination of the name of the database instance and the database server, or an XUSER key.

We recommend that you use the XUSER tool directly.

See also: XUSER

Syntax

-ud

Log on as the user <user_name> to be deleted from the XUSER program.
To identify the user to be deleted, specify a combination of the database name and server name:

-u <user_name>,<password> -ud -d <database_name> [-n <database_server>]

Log on to the XUSER program with the user data stored under the DEFAULT XUSER key.
To identify the user to be deleted, specify a combination of the database name and server.

–ux <default_user>,<password> -ud -d <database_name> [-n <database_server>]

Log on as the user <user_name> to be deleted from the XUSER program.
To identify the user to be deleted, specify the <user_key> XUSER key.

-u <user_name>,<password> -ud -uk <user_key>

Log on to the XUSER program with the user data stored under the DEFAULT XUSER key.
To identify the user to be deleted, specify the <user_key> XUSER key.

-ux <default_user>,<password> -ud -uk <user_key>


Name of the Output File: -o (MaxDB: Database Manager CLI)

Name of the Output File: -o

Use

Option in the Database Manager CLI.

All output is written to the file specified as <file_name>.

Syntax

-o <file_name>

Store the reply to the commands for displaying the operational state of the database instance in the file state.txt:

dbmcli –d myDB –u DBM,DBM –o state.txt db_state


Name of Database Instance: -d (MaxDB: Database Manager CLI)

Name of Database Instance: -d

Use

Option in the Database Manager CLI.

The name of the database instance specified in <database_name> applies for the whole session. All database-specific DBM commands relate to this database instance.

When you set up a session there is a check whether the specified database instance on the server is recorded in the list of registered database instances. If it is not, the session connection is refused.

Prerequisites

The database instance specified in <database_name> exists (Creating a Database Instance).

Syntax

-d <database_name>

Display the operational state of the database instance myDB:

dbmcli –d myDB –u DBM,DBM db_state

OK
ONLINE


Name of the Log File: -t (MaxDB: Database Manager CLI)

Name of the Log File: -t

Use

Option in the Database Manager CLI.

The transferred DBM command is executed. All options and commands transferred to the Database Manager and the respective replies are also logged in the specified file <file_name>. The existing content of the file is retained.

Syntax

-t <file_name>

Store the call options and the DBM commands and the reply in the log file log.txt

dbmcli –d myDB –u DBM,DBM –t log.txt db_state

OK
ONLINE


Name of the Database Server: -n (MaxDB: Database Manager CLI)

Name of the Database Server: -n

Use

Option for opening a session with the Database Manager CLI.

The DBM Server program on the database server specified with <database_server> is addressed.

Prerequisites

The X-SERVER program is active on the server <database_server> (Status: Started).

Syntax

-n <database_server>

Query the operational state of the database instance myDB on the server myServer

dbmcli –n myServer –d myDB –u DBM,DBM db_state

OK
ONLINE


Name of the Input Script: -i | -ic (MaxDB: Database Manager CLI)

Name of the Input Script: -i | -ic

Use

Option in the Database Manager CLI.

If you specify the option –i or –ic the DBM command(s) listed in the file <file_name> are processed.With the –i option, processing of the DBM commands is terminated if an error occurs. With the –ic option, processing continues in the event of an error.

Syntax

-i <file_name> | -ic <file_name>

Execute DBM commands that are contained in the input script input.dbm

dbmcli–d myDB –u DBM,DBM –i input.dbm

OK
<reply_to_first_DBM_command_in_script>

OK
<reply_to_second_DBM_command_in_script>
...


Version of the Database Manager: -V (MaxDB: Database Manager CLI)

Version of the Database Manager: -V

Use

Option in the Database Manager CLI.

You request the version of the Database Manager. == _________Version

Syntax

-V

>dbmcli –V

OK
version,os,dbroot,logon,code,swap
"7.4.3","WIN32","C:\PROGRAM FILES\SAPDB\DEPEND",True,ASCII,2


XUSER Key: -uk (MaxDB: Database Manager CLI)

XUSER Key: -uk

Use

Option in the Database Manager CLI when creating new or changing existing XUSER entries in the XUSER program.

You use this option to specify the XUSER key under which the entry is to be stored in the program.

We recommend that you use the XUSER tool directly.

See also: XUSER

Syntax

-uk <user_key>

Log on to the Database Manager CLI (without explicitly specifying a user; the data for the first DBM operator is used), log on the database user SAPR3 with password SAP (stored under the DEFAULT XUSER key), enter the data for user Meyer, password secretunder the new XUSER key:

dbmcli –ux SAPR3,SAP –us Meyer,secret –uk new

OK


DBM Commands (MaxDB: Database Manager CLI)

DBM Commands

Use

DBM commands are commands in the Database Manager CLI for managing database instances.

All DBM commands during a session with the Database Manager relate to the database instance whose name was specified with the option -d when logging on to the Database Manager CLI.

See also: Command Structure

Prerequisites

The right to execute a DBM command can be linked to three prerequisites:

· Logging On to the Database Manager

· Server Authorizations

· Logging On to the Operating System

You can find out which of these prerequisites must be fulfilled for the execution of a particular DBM command from the description of the relevant action.

Syntax

<command_name> [<parameters>]

See also:

Creating a List of DBM Commands

Overview of All DBM Commands


Input Help (MaxDB: Database Manager CLI)

Input Help

The following input help is available for the script mode and the session mode :

Local System Call: !

Comment: #

Linking Lines: /

Linking Lines: <


Comment: # (MaxDB: Database Manager CLI)

Comment: #

A command which starts with a number sign is ignored.


Local System Call: ! (MaxDB: Database Manager CLI)

Local System Call: !

The command to be entered is preceded by an exclamation mark.

The command is not transferred to the Database Manager but is executed in the local command interpreter of the operating system.


Linking Lines: / (MaxDB: Database Manager CLI)

Linking Lines: /

Prerequisites

You are working in session mode or script mode .

If you end a line within a multiple line DBM Command with a slash, the system recognizes that the command is not complete. It is not executed when a line feed is inserted.

Only the entry of a line feed without a preceding slash indicates to the system that the command is complete. It is then transferred to the Database Manager.


Linking Lines: < (MaxDB: Database Manager CLI)

Linking Lines: <

Using the special character less than (<), you can transfer commands consisting of several lines to the Database Manager.

Syntax

'<'<stop-token> <command-begin>

The character string <command-begin> is linked to the continuation lines until a line is found which starts with <stop-token>.

All lines are separated from one another by a line feed.

The line with <stop-token> is not incorporated into the command.


Reply Format (MaxDB: Database Manager CLI)

Reply Format

Normally communication is in ASCII format. Only in special cases, such as binary data access, do the request and reply also contain binary data.

This ensures that the replies on the client side can be easily read. It also largely avoids dependence on the hardware architecture.

Successful Reply

If the request is successful, an OK message is given in the following format:

OK[,<description>]<NL>
[<answer>]

The character string OK is the first token of the reply. There is an optional explanatory text on the same line. The meta character <NL> stands for a line feed.

The reply data is provided after the line feed. The structure of the reply data depends on the concrete DBM command.

Error Message

ERR[,<description>]<NL>
[<errcode>,<errdescription><NL>
[<subcode>,<subdescription><NL>]
[<extended_description><NL>]]

An error always starts with the character string ERR. The same line may also contain a description.

On the first continuation line, the number of the error (<errcode>) and a relevant text (<errdescription>) can be included
(See also: Messages )

If the system has the error number and relevant text of a subcomponent (for example, runtime environment or operating system), these are transferred as <subcode> and <subdescription>.

Possible additional information follows in the <extended_description>. Special cases in which the <extended description> has a structured format are described with the relevant DBM commands.

Internal Error of the Database Manager:

ERR
-24979,ERR_XPNOTFOUND_CN00 : parameter not found

Error in the Runtime Environment:

ERR
-24994,ERR_RTE_CN00 : runtime environment error
3,cannot access PARAM file [32]

Error when analyzing the description file (see also: Configuring Database Instances):

ERR
-24978,ERR_XPSYNTAX_CN00 : xparam syntax error
16,XPERR_IVSEQ_CN21 : error in IF-ELSIF-ELSE sequence
D:\d628\usr\env\cserv.pcf(60) :     ELSE


Operating Modes (MaxDB: Database Manager CLI)

Operating Modes

The Database Manager CLI program provides three operating modes:

  • Command Mode
  • Script mode
  • Session Mode

All modes are implicitly activated by the way the Database Manager CLI is called.


Command Mode (MaxDB: Database Manager CLI)

Command Mode

The Database Manager CLI works in command mode if a DBM command is specified when the program is called.

The command is executed. The session and the Database Manager CLI program then end.

See also:

Calling the Database Manager CLI


Script Mode (MaxDB: Database Manager CLI)

Script Mode

The database manager CLI works in script mode if you call the program using option –i and specify an input script <file_name> that contains the DBM commands to be processed by the database manager. The input script is executed. The session and the database manager CLI program then end.

You can use the following input options within one script:

Local System Call: !

Comment: #

Linking Lines: /

Linking Lines: <

Syntax

dbmcli –i <file_name>


Session Mode (MaxDB: Database Manager CLI)

Session Mode

In session mode, you can execute several DBM commands individually without having to call the database manager each time.

To start the database manager CLI in session mode, call the program without a DBM command and without an input script.

Syntax

dbmcli

You have the following input options in session mode:

Local System Call: !

Comment: #

Linking Lines: /

Linking Lines: <

To end the session mode, enter exit.


Logging On to the Database Manager (MaxDB: Database Manager CLI)

Logging On to the Database Manager

Use

The specified database manager operator (DBM operator) logs on to the database manager program.

For local communication, the operator is already logged on to the operating system.

Prerequisites

Logging on to the database manager requires a session with the DBM server. You can open this session before logging on to the database manager or at the same time as logging on.

Two Step Logon

You can first open the session with the DBM server and then log on to the database manager.

Opening a DBM Server Session:

dbmcli – d <database_name> [-n <database_server>]

Logging on to the database manager:

user_logon <dbm_user>,<password>

One Step Logon

Using the DBM option –u | -U, you can perform both logon steps at the same time. The database manager implicitly executes the DBM command user_logon.

Note the different meanings of the command with uppercase and lowercase specification.

Using the DBM Option -u

dbmcli -u [<dbm_user>,<password>] –d <database_name>

· -u: explicit specification of the DBM operator identified with <dbm_user> and <password>

Calling the database manager CLI as DBM operator OLEG with password MONDAY, logging on to the database instance HOTELDB, querying the operational state of the database instance:

dbmcli –u OLEG,MONDAY –d HOTELDB db_state

Using the DBM Option –U (Logon with XUSER)

dbmcli -U [<user_key>] –d <database_name>

· -U: logon with a user stored in the XUSER file

You can use the XUSER program to store sets of user data under key names and use them when logging on. XUSER keys for DBM operators can be used successfully only if the DBM operators stored in them have actually been created for the database instance in question (see also: Creating DBM Operators).

If you do not specify a <user_key> when using –U, the database manager attempts to use the data under the DBMUSR XUSER key. We therefore recommend you create an XUSER entry with the key name DBMUSR and the data of the first DBM operator (see also: Creating or Changing XUSER Entries).

Calling the database manager CLI as the DBM operator under the key name OLKEY, logging on to the database instance HOTELDB, querying the operational state of the database instance:

dbmcli –U OLKEY –d HOTELDB db_state

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Working with the Database Manager CLI (MaxDB: Database Manager CLI)

Working with the Database Manager CLI

Use

You can perform the following tasks with the database manager CLI:

Managing DBM Operators

Storing Special Users

Configuring the Database Manager

Installation and Registration Management

Configuring Database Instances

Setting Up a Hot Standby System

Functions for Database Operation

Backing Up and Restoring Database Instances

Displaying Database Information

Analyzing a Database Instance

Accessing the Database Instance

Logging On to the Operating System

Executing the liveCache Initialization Script

Creating a List of DBM Commands


Managing the DBM Operators (MaxDB: Database Manager CLI)

Managing the DBM Operators

Use

The Database Manager CLI provides a number of DBM commands with which you can display data for DBM operators, create new DBM operators, change data for DBM operators, and delete DBM operators.

Prerequisites

You have the server authorization UserMgm.

Overview of Commands for Managing DBM Operators


Overview of the DBM Commands for Managing DBM Operators (MaxDB: Database Manager CLI)

Overview of the DBM Commands for Managing DBM Operators

Changing DBM Operator Data | user_put
Creating DBM Operators | user_create
Displaying the Server Authorizations | user_getrights
Displaying Operator Data | user_get
List of DBM Operators | user_getall
Deleting DBM Operators | user_delete


Changing DBM Operator Data (MaxDB: Database Manager CLI)

Changing DBM Operator Data

Use

You can modify the data of the DBM operator specified in <user_name>.

The new values are specified with <property>=<value>.

You can specify all Authorizations of a DBM Operator for <property>.

You can specify multiple values, separated by commas, for the SERVERRIGHTS authorization. Put a plus sign in front of the authorization to assign it and a minus sign to revoke it. For possible values, see: Server Authorizations.

The password for the SYSDBA user (special DBM operator) cannot be changed in the Database Manager.

Prerequisites

You have the server authorization UserMgm.

If you want to change the password of the first DBM operator, the database instance must be OFFLINE.

If you want to change the password of a normal DBM operator, the state of the database instance is irrelevant.

Syntax

user_put <user_name> <property>=<value>[, <property>=<value>, ...]

<property> ::= PASSWORD | COMMENT | DISABLED | SECONDPASSWORD | SERVERRIGHTS

Log on to the Database Manager CLI as the operator DBM with the password DBM, create the connection to the database instance myDB, assign the server authorization to start database instances and remove the server authorization to stop database instances for the operator with the name Meyer

dbmcli –u DBM,DBM –d myDB user_put meyer SERVERRIGHTS=+StartDB, -StopDB

OK

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Creating DBM Operators (MaxDB: Database Manager CLI)

Creating DBM Operators

Use

You create a DBM operator with the operator name and operator password specified in <user_name> and <password>.

Do not enter the character string SYSDBA as the operator name, because this is a reserved SQL keyword.

For information about the length and permitted characters for user names, see also: Database Manager Operators (DBM Operators).

At first, this operator has no server authorizations . You must explicitly assign these to the operator ( Changing the DBM Operator Data ).

Alternatively, you can also specify a <template_user>, from which all authorizations, but not operator name and operator password are then copied. (See also: Authorizations of a DBM Operator)

Prerequisites

You have the server authorization UserMgm.

Syntax

user_create <user_name>,<password> [<template_user>]

<user_name> | Name of the DBM operator to be created This may actually be a Database Manager operator <dbm_user> or the database system administrator <sysdba_user> (the only database operator with the authorizations of a DBM operator).
<password> | Operator password
<template_user> | Operator whose authorizations should be copied

Log on to the Database Manager CLI as operator DBM with the password DBM, create a connection to the database instance myDB, create the DBM operator MEYER with the password secret and the authorizations of the operator DBM

dbmcli –u DBM,DBM –d myDB user_create Meyer,secret DBM

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Displaying the Server Authorizations (MaxDB: Database Manager CLI)

Displaying the Server Authorizations

Use

You display the list of server authorizations for the operator specified in <user_name>.

Prerequisites

You have the server authorization UserMgm.

Syntax

user_getrights <user_name>

Example

Reply

OK<NL>
UserMgm                 <flag>  User management
InstallMgm              <flag>  Install management
SystemCmd               <flag>  System commands
FileFull                <flag>  File full access
FileRead                <flag>  File read access
DBFileRead              <flag>  Database file read access
AccessUtility           <flag>  Utility session access
BackupRestore           <flag>  Backup restore actions
BackupSave              <flag>  Backup save actions
ParamFull               <flag>  Parameter full access
ParamCheckWrite         <flag>  Parameter check-write access
ParamRead               <flag>  Parameter read access
AccessSQL               <flag>  SQL session access
ExecLoad                <flag>  Can execute load
LoadSysTab              <flag>  Can load system tables
DBStop                  <flag>  Can stop database
DBStart                 <flag>  Can start database
DBInfoRead              <flag>  Info functions access

A plus symbol under <flag> indicates that the relevant server authorization is assigned to the operator. A minus symbol under <flag> indicates that the relevant server authorization is not assigned to the operator.

In the event of errors, see Reply Format.


user_getrights Command: Example (MaxDB: Database Manager CLI)

user_getrights Command: Example

Log on to the Database Manager CLI as the operator DBM with the password DBM, create a connection to the database instance myDB, display the authorizations of the registered DBM operator with the name Meyer

dbmcli -u dbm,dbm -d myDB user_getrights Meyer

OK

DBInfoRead              +       Request status data
ExecLoad                +       Execute the LOAD program
SystemCmd               +       Execute operating system commands
UserMgm                 +       User management
FileFull                -       File access (read and write)
FileRead                -       File access (read only)
DBFileRead              +       Database file access (read only)
Backup                  +       Saving backups
InstallMgm              +       Installation management
LoadSysTab              +       Load the system tables
ParamCheckWrite         +       Parameter access (checked write)
ParamFull               +       Parameter access (read and write)
ParamRead               +       Parameter access (read only)
DBStart                 +       Start database instance
DBStop                  +       Stop database instance
Recovery                +       Restoring backups
AccessSQL               +       Access to SQL session
AccessUtility           +       Access to utility session

Result of the Request

The Database Manager operator DBM has all operator authorizations for the Database Manager, with the exception of FileFull and FileRead.


Displaying Operator Data (MaxDB: Database Manager CLI)

Displaying Operator Data

Use

You display the data for the Database Manager operator (DBM operator) specified in <user_name>.

The Database Manager displays a list of the server authorizations assigned to the operator. These are separated by commas.

Prerequisites

You have the server authorization UserMgm.

Syntax

user_get <user_name>

Log on to the Database Manager CLI as the operator DBM with the password DBM, create a connection to the database instance myDB, display the data of the DBM operator with the name Meyer

dbmcli -u dbm,dbm -d myDB user_get meyer

OK
SERVERRIGHTS=DBInfoRead,ExecLoad,SystemCmd,UserMgm,DBFileRead,Backup,...
SECONDPASSWORD=NO
DISABLED=NO
COMMENT=

Reply

OK<NL>
SERVERRIGHTS=<right_list><NL>
SECONDPASSWORD=[YES|NO]<NL>
DISABLED=[YES|NO]<NL>
COMMENT=<comment><NL>

In the event of errors, see Reply Format.


List of DBM Operators (MaxDB: Database Manager CLI)

List of DBM Operators

Use

You call al list of the user names of all Database Manager Operators (DBM operators) registered for the current database instance.

Prerequisites

You have the server authorization UserMgm.

Syntax

user_getall

Log on to the Database Manager CLI as the operator DBM with the password DBM, create a connection to the database instance myDB, display all DBM operators for the database instance

dbmcli -u dbm,dbm -d myDB user_getall

OK
dbm
DBA
domain

Reply

OK<NL>
<userid><NL>
<userid><NL>
...

In the event of errors, see Reply Format.


Deleting DBM Operators (MaxDB: Database Manager CLI)

Deleting DBM Operators

Use

You delete the Database Manager operator (DBM operator) specified in <user_name>.

You cannot delete the DBM operator currently logged on, or the first DBM operator that was created when creating the database instance.

Prerequisites

You have the server authorization UserMgm.

Syntax

user_delete <user_name>

Log on to the Database Manager CLI as the operator DBM with the password DBM on the database instance myDB and delete the DBM operator Meyer registered for this database instance

dbmcli -u dbm,dbm -d myDB user_delete Meyer

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Storing Special Users (MaxDB: Database Manager CLI)

Storing Special Users

Use

You store special users in the Database Manager program. This can be both DBM operators and database users.

You do not create any new users with this command; you simply store data for existing users in the Database Manager.

You can store the following users:

<user_type> | Explanation
DBM | first DBM operator
DBA | database administrator
DOMAIN | DOMAIN user
SAP | Special database user in connection with SAP applications

The Database Manager usually knows these users. If problems occur with storing the user data or after a restore of the database instance, this information can be lost in the Database Manager. You then use this command to store the users in the Database Manager again.

Prerequisites

You have the server authorization UserMgm.

Syntax

user_set user-type=<user_type> <usr>,<pwd>

<user_type> ::= DBM, DBA, DOMAIN, SAP

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Configuring the Database Manager (MaxDB: Database Manager CLI)

Configuring the Database Manager

Use

You can use the following DBM commands to configure the Database Manager:

Displaying a Configuration Parameter of the Database Manager | dbm_configget
Changing a Configuration Parameter of the Database Manager | dbm_configset

Prerequisites

You have the server authorization InstallMgm.


Displaying a Configuration Parameter of the Database Manager (MaxDB: Database Manager CLI)

Displaying a Configuration Parameter of the Database Manager

Use

You display the value of the configuration parameter of the Database Manager specified in <parameter_name>.

The parameter values are stored in the encrypted configuration file. Specify the option -raw to obtain the encrypted values. If you do not specify the option, the unencrypted value is displayed.

Note that parameter names are case sensitive when working with the Database Manager.

Prerequisites

You have the server authorization InstallMgm .

Syntax

dbm_configget [-raw] <parameter_name>

Log on to the Database Manager CLI as operator DBM with password DBM, create a connection to the database instance myDB, display the encrypted value VALUEwith the option -raw

dbmcli -u DBM,DBM -d myDB dbm_configget –raw VALUE

OK

c92ee241db0bf5632bc029bcf98f186b440bb548c0f056eb

Reply

OK<NL>
<parameter_value><NL>

In the event of errors, see Reply Format.


Changing a Configuration Parameter of the Database Manager (MaxDB: Database Manager CLI)

Changing a Configuration Parameter of the Database Manager

Use

You set the value specified for the parameter specified as <parameter_name> in the configuration of the Database Manager. The new parameter value is registered by the system, and is transferred to the configuration file as the valid value at the next restart of the database instance.

You can specify that the value is to be stored unencrypted with the option -raw.

Maximum number of characters for encrypted values: 18
A longer value is shortened to 18 characters by the Database Manager CLI.

Maximum number of characters for unencrypted values: 512

Prerequisites

You have the server authorization InstallMgm .

Syntax

dbm_configset <parameter_name> <value>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Installation and Registration Management (MaxDB: Database Manager CLI)

Installation and Registration Management

Use

You manage information on the versions of the database software and the generated database instances in Registration Management.

DBM Commands are provided for maintaining the installation(s) of the database software and for registering and deleting database instances. Many of these commands, however, do not need to be called explicitly during normal database operation, but are called by installation programs of the database software or by the database application.

Prerequisites

Note the server authorizations required for the particular DBM commands.

Overview of the Commands for Installation and Registration Management


Overview of DBM Commands for Installation and Registration Mgmt (MaxDB: Database Manager CLI)

Overview of DBM Commands for Installation and Registration Mgmt

Activating a New Database Instance | db_activate
Updating the Registration of a Database Instance | db_reg
Changing the Software Version of the Current Database Instance | db_reg -R
Creating a Database Instance | db_create
Displaying the Database Kernel Variant | db_speed
Displaying the Version Information | dbm_version
Displaying the Version-Independent Directories | dbm_getpath
List of All Registered Database Instances | db_enum
List of All Registered Versions of the Database Software | inst_enum
Deleting the Current Database Instance | db_drop
Deleting the Registration of a Version of the Database Software | inst_unreg
Registering a Version of the Database Software | inst_reg


Activating a New Database Instance (MaxDB: Database Manager CLI)

Activating a New Database Instance

Use

You start a newly registered database instance for the first time and create the first database user, the database system administrator SYSDBA.

Do not enter the character string SYSDBA as the user name, because this is a reserved SQL keyword.

Prerequisites

You have the server authorization AccessAdmin.

Syntax

db_activate <sysdba_user>,<password>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Changing the Software Version of the Current Database Instance (MaxDB: Database Manager CLI)

Changing the Software Version of the Current Database Instance

Use

You change the version of the database software for the current database instance.

You can only switch between versions of the database software that do not require migration of the database instance.

Prerequisites

The database instance is in the operational state OFFLINE (Taking the Database Instance OFFLINE).

You have called the Database Manager CLI with the option -d.

Syntax

db_reg -R

Procedure

...

1. End all sessions with the DBM Server, particularly all sessions in the Database Manager GUI.

2. Run the command db_reg -R.

3. If you are working with the Database Manager CLI in session mode, terminate the Database Manager CLI now.

Result

For every subsequent access to this database instance, the Database Manager program uses the new version of the database software.


Updating the Registration of a Database Instance (MaxDB: Database Manager CLI)

Updating the Registration of a Database Instance

Use

You update the registration of a database instance. In Microsoft Windows, the relevant entry in the registry is updated; in UNIX, the Databases.ini file is updated in directory <independent_data_path>/config.

Prerequisites

· You have the server authorization InstallMgm.

· The operational state of the database instance is OFFLINE.

· You have called the database manager CLI with the option -d.

Syntax

db_reg <database_name>

The first registration of a database instance takes place implicitly when the database instance is created. Use the command db_reg only when told to do so by support.


Creating a Database Instance (MaxDB: Database Manager CLI)

Creating a Database Instance

Use

You create a new database instance on a local or remote server. All kernel variant (fast and slow) are always created for this.

Prerequisites

You have the authorizations of an operating system user for the server on which the database instance is to be created.

To create a database instance on a remote server under Microsoft Windows, you must also have administrator authorizations for the database server and the authorization log on as batch job. For information about maintaining operating system users, see your operating system documentation.

If several versions of the database software are available on the database server, you must specify the path of the version to which this database instance is to be assigned when registering the database instance. To do this, use the option -R (installation directory of the database software) when calling the Database Manager CLI.

Syntax

db_create [-a|-auto] <database_name> <dbm_user>,<dbm_user_password> [<os_user>,< os_user_password>]

-a | -auto | If you use this option, under Microsoft Windows NT the service entry Start-up-type in the Control Panel is set to automatic. Under the UNIX operating system this parameter is ignored.
database_name | Name of database instance, maximum length eight characters
dbm_user | Database Manager Operators (DBM Operators) This operator is stored on the database server when you start to create the database. Subsequent access to the database instance is possible only with this operator.
dbm_user_password | The DBM operator’s password
os_user | Operating system user If you want to create the database instance on a remote server, you must also specify the operating system user for this server. If the logon to the operating system fails, the database instance cannot be installed.
os_user_password | The operating system user’s password

From now on, to access the new database instance, you need the data specified in <dbm_user> and<password>.

Example

In Microsoft Windows:

Log on to the Database Manager CLI, create a local database instance called HOTELDB, define the DBM operator DAVID with password BLUE:
dbmcli db_create HOTELDB DAVID,BLUE

Log on to the Database Manager CLI, create a local database instance called HOTELDB with the software stored under C:\Program Files\SDB\V75, define the DBM operator DAVID with password BLUE:

dbmcli -R "C:\Program Files\SDB\V75" db_create HOTELDB DAVID,BLUE

Log on to the Database Manager CLI, create a database instance called HOTELDB on the remote server GENUA, define the DBM operator DAVID with password BLUE, log on to the remote server as operating system user ANNA with password BLACK:
dbmcli –n GENUA db_create HOTELDB DAVID,BLUE ANNA,BLACK

In UNIX:

Log on to the Database Manager CLI, create a local database instance called HOTELDB, define the DBM operator DAVID with password BLUE, use option –s to avoid being identified as the operating system user

dbmcli -s db_create HOTELDB DAVID,BLUE

Reply

There is an OK message after the command has been executed successfully.

In the event of errors, see Reply Format.

Example: How to Create a Database Instance

Example: How to Create an Archive Type Database Instance


db_create Command: Example (MaxDB: Database Manager CLI)

db_create Command: Example

To create a new database instance with the Database Manager CLI, you only need a few DBMCLI commands.

First execute the command db_create and define the first Database Manager operator (DBM operator).

dbmcli db_create <database_name> <dbm_user>,<dbm_user_password>

· If you can choose between multiple versions of the database software, make your choice by specifying the option -R:
dbmcli -R <dependent_path> db_create <database_name> <dbm_user>,<dbm_user_password>.

· If you want to install a new database instance on a remote computer, also specify the option -n. You must also log on to the operating system of this computer:

dbmcli -n <database_server> db_create <database_name> <dbm_user>,<dbm_user_password> <os_user>,<os_user_password>

For the other steps need to create the database instance, use a DBMCLI script:

dbmcli -d <database_name> -u <dbm_user>,<dbm_user_password> -i <script_file>

Example of a script:

param_startsession
param_init
param_put MAXUSERTASKS 5
 param_checkall
param_commitsession
param_addvolume 1 LOG LOG_001 F 2000
param_addvolume 1 DATA DAT_001 F 10000
 db_admin
db_activate <sysdba>,<password>
 load_systab -ud <domain_password>

Modify the values of the database parameters according to your requirements.


Example: How to Create an Archive Type Database Instance (MaxDB: Database Manager CLI)

Example: How to Create an Archive Type Database Instance

To create an archive type database instance with a log volume, a normal data volume, and an archive data volume, use the following commands in the Database Manager CLI:

dbmcli db_create HOTELDB DBM,DBM

dbmcli –d HOTELDB –u DBM,DBM

param_startsession

param_init ARCHIVE

param_put MAXUSERTASKS 5

param_checkall

param_commitsession

param_addvolume 1 LOG LOG_001 F 2000

param_addvolume 1 DATA DAT_001 F 10000

param_addvolume 2 DATA ARCH_001 A 10000

db_admin

db_activate DBA,DBA

load_systab -ud DBA

Modify the values of the database parameters according to your requirements. When you have correctly set all the parameters, the message Installation successfully finished appears after the final step.


Displaying the Database Kernel Variant (MaxDB: Database Manager CLI)

Displaying the Database Kernel Variant

Use

You display the variant of the database kernel of the current database instance.

Prerequisites

You have the server authorization DBInfoRead.

The database instance is in operational state ONLINE or ADMIN.

Syntax

db_speed

Reply

OK<NL>
Speed<NL>
(FAST|QUICK|SLOW|UNKNOWN|)

FAST | Fastest database kernel variant, with minimum logging and runtime checks.
QUICK | Variant of the database kernel with various logs and runtime checks.
SLOW | Variant of the database kernel with extensive logs and runtime checks.
UNKNOWN | The kernel variant cannot be determined.

If the database is in the OFFLINE operational state, the system answers this command with an error message.

See also: Reply Format


Displaying the Version Information (MaxDB: Database Manager CLI)

Displaying the Version Information

Use

You display the version information of the Database Manager. Since the version of the DBM Server is always the same as the version of the database software, this is how you can also determine the version of the database software.

Prerequisites

You do not need to log on to the Database Manager to execute this DBM command.

Nor do you require any server authorization.

Syntax

dbm_version

Reply

OK
VERSION    = <version> <NL>
BUILD      = <build_number> <NL>
OS         = <os> <NL>
INSTROOT   = <dependent_path> <NL>
LOGON      = <logon_state> <NL>
 CODE       = <code><NL>
SWAP       = <swap><NL>
UNICODE    = (YES|NO)<NL>
INSTANCE   = (OLTP|LVC|CS|BW|unknown)<NL>
SYSNAME    = <os><NL>

Values of the reply lines

VERSION | Version number of the Database Manager
BUILD | Identification number of the Database Manager
OS | Name of the operating system
INSTROOT | Installation directory of the version-dependent components
LOGON | Displays whether a logon to the operating system has been performed: True logged on False not logged on
CODE | Display of the character set used in the Database Manager: ASCII or EBCDIC
SWAP | Displays of the swap type (internal representation of numerical values) used in the Database Manager : no hihi-hilo-lohi-lolo full lolo-lohi-hilo-hihi half lohi-lolo-hihi-hilo
UNICODE | Configuration of the current database instance as a UNICODE database
INSTANCE | Database instance type
SYSNAME | Name of the operating system

In the event of errors, see Reply Format.


Displaying the Version-Independent Directories (MaxDB: Database Manager CLI)

Displaying the Version-Independent Directories

Use

You display the version-independent directories configured on the database server.
If more than one version of the database software is installed on your computer, version-independent data or programs are stored and found in these directories.

Prerequisites

You do not need to log on to the Database Manager to execute this DBM command. Nor do you require any server authorization.

Syntax

dbm_getpath IndepDataPath | IndepProgPath

See also Variables


List of All Registered Database Instances (MaxDB: Database Manager CLI)

List of All Registered Database Instances

Use

You call up a list of all the database instances registered on the server.

If you specify the option [-s], the service database instances for each version of the database software are also listed (Access Using a Service Session).

Prerequisites

You do not need to log on to the database manager to execute this DBM command.

You do not require a server authorization .

Syntax

db_enum [-s]

Reply

The system displays an OK message. Then a table is displayed, listing all of the registered database instances in tabular format.

OK<NL>
<database_name><TAB><dependent_path><TAB><database_version><TAB><kernel_version><TAB><operational_state><NL>
<database_name><TAB><dependent_path><TAB><database_version><TAB><kernel_version><TAB><operational_state><NL>
...

Reply values

<database_name> | Name of the database instance
<dependent_path> | Directory that contains the server software dependent on the database version.
<database_version> | Version of the database software
<kernel_version> | Kernel variant
<operational_state> | Operational state of the database instance

Example

Logging on to the database manager CLI as operator DBM with password DBM using the option –R and the installation path for software version 7.5, executing the DBM command for displaying a list of all the database instances registered for the specified version on the server GENUA:

dbmcli -R "C:\Program Files\SDB\7500" –n GENUA db_enum

OK
HOTELDB C:\Program Files\SDB\7500 7.5.0.5 fast online
HOTELDB C:\Program Files\SDB\7500 7.5.0.5 quick offline
HOTELDB C:\Program Files\SDB\7500 7.5.0.5 slow offline


List of All Registered Versions of the Database Software (MaxDB: Database Manager CLI)

List of All Registered Versions of the Database Software

Use

You can call up the list of all registered versions of the database software on the database server.

Prerequisites

You do not need to log on to the Database Manager to execute this DBM command.

Nor do you require an server authorization.

Syntax

inst_enum

Reply

The system displays an OK message. The system then displays a table of the registered versions <version> and their installation paths < dependent_path >.

OK<NL>
<version><TAB><dependent_path><NL>
<version><TAB><dependent_path><NL>
...

OK
7.4.0.3 "C:\Program Files\SAPDB\depend"
7.5.0.3 "C:\Program Files\SDB\7500"


Deleting the Current Database Instance (MaxDB: Database Manager CLI)

Deleting the Current Database Instance

Use

With this command you delete a database instance.

If you specify the option WITHOUTFILES for this command, the database files on the DBM Server are retained. If you do not specify this option, the files for the database instance are also deleted.

Prerequisites

The database instance is in the operational state OFFLINE (Taking the Database Instance OFFLINE ).

You have the server authorization InstallMgm.

Syntax

db_drop [WITHOUTFILES]

Example

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


db_drop Command: Example (MaxDB: Database Manager CLI)

db_drop Command: Example

1. Database instance stop:

dbmcli –d<database_name> -u<user_name>,<password> db_stop

or

dbmcli -d <database_name> -u <user_name>,<password> db_offline

2. Delete the current database instance from the database server:

dbmcli -d <database_ name> -u <user_name>,<password> db_drop

This deletes the files of the database instance.


Deleting Registration of a Database Software Version (MaxDB: Database Manager CLI)

Deleting Registration of a Database Software Version

Use

You delete a version entry and the path under which the server software that is dependent on the database version is stored in the system, from the list of registered versions of the database software. You can then no longer run database software that requires this information.

Specify the installation path <dependent_path> as a parameter.

Prerequisites

You have called the Database Manager CLI with the -R option.

You are logged on to the operating system (Logging On to the Operating System).

You do not require any server authorization.

Syntax

inst_unreg <dependent_path>

Log on to the Database Manager CLI with the user DBM and password DBM, create a connection to the database instance myDB,

delete the registration of the software version 7.5 (default installation path)

dbmcli –u DBM,DBM –d myDB instunreg C:Program Files\SDB\7500

or

delete the registration of the software version 7.4 (default installation path)

dbmcli –u DBM,DBM –d myDB instunreg C:Program Files\SAPDB\depend

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Registering a Version of the Database Software (MaxDB: Database Manager CLI)

Registering a Version of the Database Software

Use

You enter the software version of the database manager from the current database installation in the list of registered versions of the database software.

The version is registered once only, upon installation of the relevant database software. The installation must be registered for this software to function correctly.

Prerequisites

You are logged on to the operating system (Logging On to the Operating System).

You have executed the command inst_enum to display all the registered versions of the database software and their possible keys.

Syntax

inst_reg [-k <key>][-c]

Options

If you have installed the same version of the database software more than once, you must specify a unique key -k <key>.

If only the client programs of the database software have been installed on a server, register the client by specifying the option –c.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Configuring Database Instances (MaxDB: Database Manager CLI)

Configuring Database Instances

Use

The database parameters are stored in the description file and the parameter file.

The default values, value areas, calculation rules, and parameter properties the Database Manager needs to process parameters correctly are all stored in the description file.

The description file and a parameter file that has default values assigned to it are installed with the database instance. With the commands for the configuration of database instances you change the entries in the parameter file of the database instance.

Prerequisites

For some of the commands for configuring database instances you require a parameter session.

Note the server authorizations required for the particular DBM commands.

Procedure

When logging on to the Database Manager, use the -d option to specify the name of the database instance for which you want to edit the parameters. On entering the param_* commands, a search is made in the parameter file belonging to this database instance for the value of the respective parameters.

If you do not specify a name or you specify the name of a non-existent database, the required parameter cannot be found.

Overview of the Commands for Configuring Database Instances


Overview of the DBM Commands for Configuring Database Instances (MaxDB: Database Manager CLI)

Overview of the DBM Commands for Configuring Database Instances

Terminating a Parameter Session | param_abortsession
Changing the Value of a Database Parameter | param_put
Changing Volume Parameters | param_addvolume
Displaying All Data for Database Parameter | param_getfull
Displaying All Properties of a Database Parameter | param_getproperties
Displaying All Parameters of the Current Database Parameter File | param_directgetall
Displaying the Data for All Database Parameters | param_extgetall
Displaying the Data for All Volume Parameters | param_getvolsall
Displaying the Data for Individual Volume Parameters | para_getvolume
Displaying the Current Value of a Database Parameter | param_getvalue
Displaying the Data Type of a Database Parameter | param_gettype
Displaying the Stored Explanatory Text | param_getexplain
Displaying the Stored Help Text | param_gethelp
Displaying the System Default Value | param_getdefault
Displaying a Value from the Database Parameter File | param_directget
Displaying Individual Data for a Database Parameter | param_extget
Confirming Changes to the Database Parameter File | param_commitsession
Scrolling in the Database Parameter History | param_gethistorynext
Directly Changing a Value in the Database Parameter File | param_directput
Opening a Parameter Session | param_startsession
Adding a Volume | db_addvolume
Initializing the Database Parameter for a New Database Instance | param_init
Copying a Database Parameter File | param_copy
Correcting Database Parameters | param_putconfirm
List of Available Parameter Files | param_versions
Deleting the Database Parameter File | param_rmfile
Deleting a Database Parameter | param_directdel
Changing Volume Parameters | param_delvolume
Opening the Database Parameter History | param_gethistory
Checking All Database Parameters | param_checkall
Resetting the Parameter File to a Previous Version | param_restore

The commands of the class param_direct* access the parameter file of the database instance directly. These commands do not require a parameter session, and it is therefore not possible to ROLLBACK.


Terminating a Parameter Session (MaxDB: Database Manager CLI)

Terminating a Parameter Session

Use

You terminate the parameter session. All of the changes and corrections made to database parameters in this session are rejected. The internal data structures in which the contents of the description file and the parameter file were stored are removed (see also: Configuring Database Instances).

If you change values without a parameter session, that is, directly in the parameter file (Make direct changes with param_directput and delete directly with param_directdel ), the changes are immediately written to the parameter file, that is, they cannot be rejected.

Prerequisites

You have opened a parameter session.

You have the server authorization ParamRead .

Syntax

param_abortsession

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Changing the Value of a Database Parameter (MaxDB: Database Manager CLI)

Changing the Value of a Database Parameter

Use

You can use this command to change the value of a database parameter in the internal data structures and to store it in the Database Manager.

In contrast to the function for changing a value directly in the database parameter file, the parameter is not written straight to the parameter file and you can still reject it by not confirming the parameter change or by terminating the parameter session.

The change of this parameter is rejected, if the entered value or the change is impermissible due to the parameter properties.

After changing the database parameter, you must also execute the command to check all database parameters.

Prerequisites

You have opened a parameter session.

You have the server authorization ParamCheckWrite.

Syntax

param_put <parameter_name> <user_value>

Example

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


param_put Command: Example (MaxDB: Database Manager CLI)

param_put Command: Example

You change the value of the database parameter MAXUSERTASKS to the value 5.

param_startsession
param_init
param_put MAXUSERTASKS 5
param_checkall
param_commitsession


Changing Volume Parameters (MaxDB: Database Manager CLI)

Changing Volume Parameters

Use

Use the command param_addvolume described here only for Creating a New Database Instance, when creating a first mirror volume for a database instance, or in consultation with Support.

Inconsistencies in the volume settings can lead to damage to the database instance.

Extend an existing database instance using the command db_addvolume (Adding a Volume).

Use db_addvolume to create mirror volumes only if the database instance is already mirrored; that is, if mirror volumes already exist.

To mirror the log volume, see also: Log Mode

Use this command to enter the volume parameters in the parameter file of the database instance. The new parameter value is registered by the system, and is transferred to the parameter file as the valid value at the next restart of the database instance.

You change volume parameters in two steps:

...

1. Change the entries for the parameters in the parameter file

2. Transfer the corresponding information to the database kernel with an administrative command (See: Executing a Database Command)

If this command fails, you must also remove the entries in the parameter file of the database instance.

No check is made of whether there is sufficient disk capacity available to add the volume.

If you create a mirror volumes with this command, you must then also set the general database parameter LOG_MIRRORED to the value YES.
To change the database parameter, see: Changing the Value of a Database Parameter

Volumes of type archive cannot be extended later. Therefore, select the maximum value allowed by the storage system when you specify the size of such volumes.

Prerequisites

You have the server authorization ParamFull.

Syntax

param_addvolume <vol_no> <vol_mode> <vol_name> <vol_type> <vol_size>

Options

<vol_no> | Number of the volume
<vol_mode> | Mode of the volume
<vol_name> | Name of volume/file of the volume
<vol_type> | Type of volume
<vol_size> | Size of the volume in pages
<vol_mode>
DATA | Data volume; the number of the data volume is assigned by the system as a four-digit number with leading zeros when creating the volume
LOG | Log volume; the number of the log volume is assigned by the system as a three-digit number with leading zeros when creating the volume
MLOG | Mirrored log volume
<vol_type>
F | File
L | Link
R | Raw device
A: | Archive

Reply

The system displays an OK message.

In the event of errors, see Reply Format.

Example

To define the first data volume of type file, execute the following command:

param_addvolume 1 DATA DAT_001 F 10000


Displaying All Data for a Database Parameter (MaxDB: Database Manager CLI)

Displaying All Data for a Database Parameter

Use

You request all of the data stored for the database parameter identified as <parameter_name>.

Prerequisites

You have the server authorization ParamRead .

Syntax

param_getfull <parameter_name>

Example

Reply

The system outputs an OK message followed by all of the data for the parameter concerned.

OK<NL>
<type><NL>
<default><NL>
<value><NL>
<property> <value><NL>
<property> <value><NL>
...
HELP
<help_line><NL>
<help_line><NL>
...
EXPLAIN
<explain_line><NL>
<explain_line><NL>
...

Reply values

<type> | Data type of the parameter
<default> | System default value
<value> | Current value, taken from the parameter file at the start of the session
<property> | Property of the Parameter
<help_line> | Help text
<explain_line> | Explanatory text

In the event of errors, see Reply Format.


param_getfull Command: Example (MaxDB: Database Manager CLI)

param_getfull Command: Example

Displaying the data for the parameter RUNDIRECTORY

dbmcli -d DB -u dbm,dbm param_getfull RUNDIRECTORY

OK
c64
d:\sapdb\usr\wrk\DB
CHANGE YES
INTERN NO
MANDATORY YES
CLEAR YES
DYNAMIC NO
CASESENSITIVE YES
OVERRIDE NO
DEVSPACE NO
MODIFY YES
GROUP GENERAL
DISPLAYNAME
VALUESET
MAX
MIN
INSTANCES
LASTKNOWNGOOD d:\sapdb\usr\wrk\DB
HELP
Path where context and diagnosis information is stored
EXPLAIN
Path where context and diagnosis information is stored for this database instance.
(char(64))


Displaying All Properties for a Database Parameter (MaxDB: Database Manager CLI)

Displaying All Properties for a Database Parameter

Use

You request all properties of the database parameter identified as <parameter_name>. All properties <property> are listed with their values <value>.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_getproperties <parameter_name>

Reply

OK<NL>
<property> <value><NL>
<property> <value><NL>
...

In the event of errors, see Reply Format.


Displaying All Parameters of the Current Database Parameter File (MaxDB: Database Manager CLI)

Displaying All Parameters of the Current Database Parameter File

Use

You display all database parameters of the current database instance with their values. One parameter with name < parameter_name>and value <value> is displayed per line.

The command accesses the database instance parameter file directly. It does not require a parameter session and so it is also not possible to ROLLBACK.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_directgetall

Reply

OK<NL>
<parameter_name> <value><NL>
 <parameter_name> <value><NL>
...

In the event of errors, see Reply Format.


Displaying the Data for All Database Parameters (MaxDB: Database Manager CLI)

Displaying the Data for All Database Parameters

Use

You request all database parameters from the description file and the parameter file of the database instance (see also: Configuring Database Instances).

If the reply is successful, the name of each database parameter <parameter_name>, its data type <type> and its current value <value> are displayed. This is the value that is copied from the parameter file at the start of the session. If the parameter is not in it, the default value from the description file is displayed.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_extgetall [<property>=<value>]

<property> Option

By specifying properties you can restrict what is displayed. However, each property can only be specified once. If the same property is entered more than once, the value of the last entry is used.

A parameter must correspond to the specified value in all specified properties (AND link). Several values for one property separated by commas are treated as OR-linked.

Property | Possible values
CASESENSITIVE | YES | NO
CHANGE | YES | NO
CLEAR | YES | NO
VOLUME | YES | NO
DISPLAYNAME | Character string (may include spaces) displayed in place of the parameter name in the D atabase Manager GUI
DYNAMIC | YES | NO
GROUP | GENERAL | EXTENDED | SUPPORT | NO
INFO | YES | NO
INSTANCES | Database instance type, for which the parameter is relevant: LVC | OLTP | ARCHIVE No entry: Parameter is generally valid
INTERN | YES | NO
MANDATORY | YES | NO
MAX | Maximum parameter value
MIN | Minimum parameter value
MODIFY | YES | NO
OVERRIDE | YES | NO | HIGHER
VALUESET | Permitted parameter value set

Log on to the Database Manager CLI as the operator DBM with the password DBM, create a connection to the database instance myDB, and display all parameters that can be changed and which are assigned to the group General - General Database Parameters

dbmcli –u DBM,DBM –d myDB param_getextall CHANGE=YES GROUP=GENERAL

Log on to the Database Manager CLI as the operator DBM with the password DBM, create a connection to the database instance myDB, and display all parameters that are assigned to the group General – General Database Parameters or to the group Extended – Special Database Parameters.

dbmcli –u DBM,DBM –d myDB param_getextall GROUP=GENERAL,EXTENDED

Reply

OK<NL>
< parameter_name><type> <value><NL>
< parameter_name> <type> <value><NL>
...

In the event of errors, see Reply Format.


Displaying the Data for All Volume Parameters (MaxDB: Database Manager CLI)

Displaying the Data for All Volume Parameters

Use

You display the data for all volumes of a database instance.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_getvolsall [<vol_mode>]

Options

<vol_mode>

Type of the volume
Option <vol_mode>
DATA | Data Volume; the number of the data volume is assigned by the system as a four-digit number with leading zeros when creating the volume
LOG | Log Volume; the number of the log volume is assigned by the system as a three-digit number with leading zeros when creating the volume
MLOG | Mirrored log volume (see also: Log Mode)

Log on to the Database Manager CLI as the operator DBM with the password DBM, create a connection to the database instance myDB, display the data for all volumes of the type DATA

dbmcli -u dbm,dbm -d myDB param_getvolsall DATA

OK
MAXDATAVOLUMES   3
DATAVOL_0001       10000      F  DAT_001
DATAVOL_0002       11000      F  DAT_002

Reply

The system displays a list the data for the volumes.

OK<NL>
<parameter_name> <value>
<parameter_name> <value>
...
<volume> <vol_size> <vol_type> <vol_name>
<volume> <vol_size> <vol_type> <vol_name>
...

Values for the Fields of the Reply

<parameter_name> | Name of a database parameter relevant for volumes
<value> | Value of the parameter
<volume> | Volume ID
<vol_name> | Name of volume/file of the volume
<vol_type> | Type of volume (such as file, raw device)
<vol_size> | Size of the volume

In the event of errors, see Reply Format.


Displaying the Data of an Individual Volume Parameter (MaxDB: Database Manager CLI)

Displaying the Data of an Individual Volume Parameter

Use

You display the data of an individual volume parameter of the current database instance.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_getvolume <vol_no> <vol_mode>

Options

<vol_no> | Number of the volume
<vol_mode> | Type of the volume
Option <vol_mode>
DATA | Data Volume; the number of the data volume is assigned by the system as a four-digit number with leading zeros when creating the volume
LOG | Log Volume; the number of the log volume is assigned by the system as a three-digit number with leading zeros when creating the volume
MLOG | Mirrored log volume (see also: Log Mode)

Log on to the Database Manager CLI as operator DBM with password DBM, create a connection to the database instance myDB, and display the data for volume number 1 of type DATA

dbmcli -u dbm,dbm -d myDB param_getvolume 1 DATA

OK
DAT_001
F
10000

Reply

OK<NL>
<vol_name>
<vol_type>
<vol_size>

Values for the Fields of the Reply

<vol_name> | Name of volume/file of the volume
<vol_type> | Type of volume (such as file, raw device)
<vol_size> | Size of the volume

In the event of errors, see Reply Format.


Displaying the Current Value of a Database Parameter (MaxDB: Database Manager CLI)

Displaying the Current Value of a Database Parameter

Use

You display the current value of the database parameter specified in <parameter_name>.

The system outputs the value of the parameter as saved in the database parameter file the last time the database instance was started.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_getvalue <parameter_name>

Reply

OK<NL>
<value>

In the event of errors, see Reply Format.


Displaying the Data Type of a Database Parameter (MaxDB: Database Manager CLI)

Displaying the Data Type of a Database Parameter

Use

You display the current value of the parameter specified as <parameter_name>.

There is an OK message after the command has been executed successfully. This is followed by the data type <type> of the specified parameter. The following output values for < type> are possible:
 int2 | int4 | c8 | c18 | c24 | c40 | c64

Prerequisites

You have the server authorization ParamRead .

Syntax

param_gettype <parameter_name>

Reply

OK<NL>
<type>

In the event of errors, see Reply Format.


Displaying the Stored Explanatory Text (MaxDB: Database Manager CLI)

Displaying the Stored Explanatory Text

Use

You display the stored explanatory text for the database parameter <parameter_name>.

The system outputs an OK message followed by the explanatory text < explanation_line>. The line is empty, if no explanatory text is stored.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_getexplain <parameter_name>

Reply

OK<NL>
<explanation_line><NL>
<explanation_line><NL>
...

In the event of errors, see Reply Format.


Displaying the Stored Help Text (MaxDB: Database Manager CLI)

Displaying the Stored Help Text

Use

You display the stored help text for the database parameter <parameter_name>.

The system outputs an OK message followed by the help text <helpline>. The line is empty, if no help text is stored.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_gethelp <parameter_name>

Reply

OK<NL>
<help_line><NL>
<help_line><NL>
...

In the event of errors, see Reply Format.


Displaying the System Default Value (MaxDB: Database Manager CLI)

Displaying the System Default Value

Use

You display the system default value of the database parameter specified in <parameter_name>.

The system outputs an OK message and a line showing the system <default> value. The line is empty if no default value exists for the database parameter.

Prerequisites

You have the server authorization ParamRead .

Syntax

param_getdefault <parameter_name>

Reply

OK<NL>
<default>

In the event of errors, see Reply Format.


Displaying a Value from the Database Parameter File (MaxDB: Database Manager CLI)

Displaying a Value from the Database Parameter File

Use

The parameter file of the database instance is searched for the value of the database parameter specified in <parameter_name>.

After a successful search an OK message is displayed. The name of the database parameter <parameter_name> and its value <value> are displayed in the following line. The message output if the specified parameter is not in the parameter file is not found.

The command accesses the database instance parameter file directly. It does not require a parameter session and so it is also not possible to ROLLBACK.

Prerequisites

You have the server authorization ParamRead .

Syntax

param_directget <parameter_name>

Reply

OK<NL>
<parameter_name> <value><NL>

In the event of errors, see Reply Format.


Displaying Individual Data for a Database Parameter (MaxDB: Database Manager CLI)

Displaying Individual Data for a Database Parameter

Use

You display the name, data type, and current value of the database parameter specified in < parameter_name>. The parameter help file and the current database instance parameter file are searched (see also: Database Instance Configuration).

Prerequisites

You have the server authorization ParamRead.

Syntax

param_extget < parameter_name>

Reply

OK<NL>
< parameter_name> <type> <value><NL>

< parameter_name> | Name of the database parameter
<type> | Data type of the database parameter
<value> | Current value This is the value that is copied from the parameter file at the start of the session. If the parameter is not in it, the default value from the description file is displayed here.

In the event of errors, see Reply Format.


Confirming Changes to the Database Parameter File (MaxDB: Database Manager CLI)

Confirming Changes to the Database Parameter File

Use

You confirm all changes to the database parameters and transfer these to the parameter file of the database instance. Before storing them the check status of all parameters is verified.

If you specify the NOCLOSE option, the parameter session remains open after the database parameters have been stored. If you do not specify this option, the parameter session is closed after the database parameters have been stored.

The changed values in the parameter file are only effective after a restart of the database instance.

Prerequisites

You have changed parameter values in a parameter session.

You have the server authorization ParamCheckWrite.

Syntax

param_commitsession [NOCLOSE]

Successful Reply

The system displays an OK message.

Error Message

Execution of the command is refused:

ERR
14,ERR_XPCHECK_CN00 : param check failure/request
<identifier>      <check_status>
<user_value>
<computed_value>

Values for the Individual Fields of the Reply

<check_status>

The following check status may occur:

Mandatory: An obligatory database parameter has been assigned an empty value.

Constraint: A condition defined in the description file could not be fulfilled (Configuring Database Instances).

Request: The user input deviates both from the value transferred to the system and confirmed by it earlier, as well as from the system default value.

<user_value>

Value that the operator entered with param_put (Changing the value of a database parameter).

<computed_value>

Default value calculated by the system

Check status request is displayed only if the user entry varies from the value of the database parameter in the parameter file.

Continuation of Procedure

If the check status is a request, you can correct the error as follows:

Specify the valid value with param_putconfirm (Correcting Database Parameters). Otherwise the system default <computed_value> is used this for parameter for all further calculations of other parameters.

In the following cases, the parameter change is refused:

- The parameter has the value NOBODY for the CHANGEproperty

- The parameter has the value NOfor the property MODIFY and the parameter file was already checked by the kernel (parameter __PARAM_CHANGED___ exists)

- You are dealing with a volume parameter (VOLUME property = Yes) and there are changed kernel parameters in the parameter file (VOLUME property = No) that have not yet been checked by the kernel
(Exception: You are creating a new database instance)

- The parameter is a kernel parameter and volume parameters have already been changed, but not yet checked by the kernel.


Scrolling in the Database Parameter History (MaxDB: Database Manager CLI)

Scrolling in the Database Parameter History

Use

You call up the rest of the contents of the database parameter history.

If you have set selection criteria in the options on opening the database parameter history, then these also apply while you are scrolling through the parameter history.

Prerequisites

You have opened the database parameter history (Opening the Database Parameter History).

You have the server authorization ParamRead .

Syntax

param_gethistorynext

Reply

OK
<header_line><NL>
<param_line><NL>
<param_line><NL>
...

If you receive a reply of only:

OK
<header_line><NL>

then all specified entries have already been displayed.

Values for the Individual Fields of the Reply

<header_line> | contains the names of the fields displayed S stands for STATE and describes the database parameter's change state
<param_line> | contains the values for the fields described in the <header _ line>, the values are in the same column position as the field description in the <header _ line> Field S for STATE can contain any of the following entries: c: changed d: deleted a: active


Changing a Value Directly in the Database Parameter File (MaxDB: Database Manager CLI)

Changing a Value Directly in the Database Parameter File

Use

With this command you change the parameters of the database instance. Unlike the function changing the value of a database parameter, the value <value> for the parameter identified as <parameter_name> is written straight to the parameter file. An entry is only made if the parameter is already contained in the parameter file.

In the following cases the parameter change is refused:

· The parameter has the value NOBODYfor the CHANGEproperty

· The parameter has the value NO for the property MODIFY and the parameter file was already checked by the kernel (parameter __PARAM_CHANGED___ exists)

· You are dealing with a volume parameter (property VOLUME = Yes) and there are changed kernel parameters in the parameter file (property VOLUME = No) that have not yet been checked by the kernel
(Exception: You are creating a new database instance)

· The parameter is a kernel parameter and volume parameters have already been changed, but not yet checked by the kernel.

The entered value for the parameter is not checked for consistency. Therefore unqualified changes to parameters are also possible using the command param_directput. These can then not be rejected by param_abortsession because the changes are written directly to the parameter file.

Prerequisites

You have the server authorization ParamFull.

Syntax

param_directput <parameter_name> <value>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Opening a Parameter Session (MaxDB: Database Manager CLI)

Opening a Parameter Session

Use

You open a parameter session to check or change the parameters of a database instance.

The DBM Server loads the description file and parameter file of the database instance (see also: Configuring Database Instances) and stores the contents in internal data structures. All access operations to this internal data take place within a parameter session.

In case of syntax error an error message is displayed which contains the file name, line number and line text.

Prerequisites

You have the server authorization ParamRead .

Syntax

param_startsession

Reply

The system displays an OK message.

In case of syntax error an error message is displayed which contains the file name, line number and line text.


Adding a Volume (MaxDB: Database Manager CLI)

Adding a Volume

Use

You define additional Volumes to extend the disk space for the database instance. You can also use this command for creating additional mirror volumes, if the database is already mirrored.

If the database instance is not yet mirrored, create the first mirror volume with the command param_addvolume (Changing Volume Parameters).

Volumes of type archive cannot be added after the database has been set up.

To mirror the log volume, see also: Log Mode

Prerequisites

You have the server authorization ParamFull or AccessUtility.

Syntax

db_addvolume <vol_mode> <vol_name> <vol_type> <size>

<vol_mode> | Type of volume that is to be added Possible values are: DATA (Data Volume) LOG (Log Volume) MLOG (Mirrored log volume)
<vol_name> | Name of device/file
<vol_type> | Type of device or file that is to be added. Possible values are: F (File) L (Link) R (Raw Device) Option A (archive device) is not allowed. Archive volumes can be defined only during the database setup. The command for this is param_addvolume. They cannot be added afterward.
<size> | Size of the volume to be added in pages

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Initializing the Database Parameters for a New Database Instance (MaxDB: Database Manager CLI)

Initializing the Database Parameters for a New Database Instance

Use

You initialize all of the database parameters needed to generate a new database instance.

This procedure uses the name of the database instance from the session with the database manager. There must be no database parameter file for this database instance.

All database parameters are first assigned their default values from the description file (see also: Configuring Database Instances). Then a complete calculation run is carried out. The values from the calculation run overwrite the default values.

The new parameter values in the database parameter file are checked for correct syntax. The system does not display a message about conditions that are not fulfilled or missing obligatory values.

The initialization is performed only within the database manager. The parameters are not saved to the database parameter file until you confirm changes to the database parameter file.

Prerequisites

You have opened a parameter session.

You have the server authorization InstallMgm.

Syntax

param_init [<db_instance_type>]

db_instance_type

Database instance type

Permitted values are:
OLTP (OLTP)
LVC (liveCache)
ARCHIVE (Archive)

If you do not enter a database parameter, the system uses OLTP.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Copying a Database Parameter File (MaxDB: Database Manager CLI)

Copying a Database Parameter File

Use

You copy the parameter file of an existing database instance as the initial configuration for a new database instance. You can only copy a source parameter file if the new database instance does not yet have one.

All parameter changes made during the current parameter session up to this point are overwritten by the copied parameter file. Parameters that cannot be changed because of their properties retain their system default values copied from the description file. This applies to the following parameters:

· RUNDIRECTORY contains a directory name
<independent_data_path>/wrk/<database_name>

· KERNELVERSION is initialized with the version number stored in the DBM Server

Specify the name of the source database in <source_db>.

(See also: Configuring Database Instances)

Prerequisites

You have opened a parameter session.

You have the server authorization InstallMgm.

Syntax

param_copy <source_db>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Correcting Parameters (MaxDB: Database Manager CLI)

Correcting Parameters

Use

You correct the value of a parameter. In doing so, you have the choice of assigning either the user input <user_value> or the system default value <computed_value> to the parameter <parameter_name>registered with request.

The value is stored in the parameter manager and becomes effective after a Restart of the Database Instance. Parameters that you correct with this command are only queried if both the current user input and the system default value do not match the confirmed value.

You can only use this command for database systems up to version 7.3.

Prerequisites

You have the server authorization ParamCheckWrite.

You have opened a parameter session and checked parameters.

The check status Request for a parameter was indicated.

Syntax

param_putconfirm <parameter_name> <user_value>|<computed_value>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


List of the Available Parameter Files (MaxDB: Database Manager CLI)

List of the Available Parameter Files

Use

You request a list of all available parameter files.

Prerequisites

You have the server authorization ParamRead .

Syntax

param_versions

Reply

OK<NL>
<file><NL>
<file><NL>
...

<file>

Name of the parameter file

In the event of errors, see Reply Format.


Deleting the Database Parameter File (MaxDB: Database Manager CLI)

Deleting the Database Parameter File

Use

You can delete the parameter file.

Use this command with great care.

With the command param_restore (Resetting the Parameter File to a Previous Version), you can restore the version of the parameter file that was valid before the deletion.

Prerequisites

You have the server authorization InstallMgm.

Syntax

param_rmfile

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Deleting a Database Parameter (MaxDB: Database Manager CLI)

Deleting a Database Parameter

Use

You delete the parameter specified as <parameter_name> from the database parameter file.

The changed values are transferred to the parameter file and are effective after the next restart of the database instance.

Use this command with great care.

The param_directdel command accesses the database instance parameter file directly. It does not require a parameter session and so it is not possible to ROLLBACK.

Prerequisites

You have the server authorization ParamFull.

Syntax

param_directdel <parameter_name>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Deleting Volume Parameters (MaxDB: Database Manager CLI)

Deleting Volume Parameters

Use

You delete the parameters for the specified volume from the database parameter file. This command deletes only the parameters of the volumes; you cannot fully delete a volume that has been used.

Use this command with great care. Inconsistencies in the volume settings can lead to damage to the database instance.

Prerequisites

You have the server authorization ParamCheckWrite.

Syntax

param_delvolume <vol_no> <vol_mode>

Options

<vol_no> | Number of the volume
<vol_mode> | Mode of the volume
Option <vol_mode>
DATA | Data volume: the number of the data volume is assigned by the system as a four-digit number with leading zeros when creating the volume
LOG | Log volume: the number of the log volume is assigned by the system as a three-digit number with leading zeros when creating the volume
MLOG | Mirrored log volume (see also: Log Mode)

Log on to the Database Manager CLI as operator DBM with password DBM, create a connection to the database instance hoteldb, delete volume number 3 of type DATA

dbmcli –u DBM,DBM –d hoteldb param_delvolume 3 DATA

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Opening the Database Parameter History (MaxDB: Database Manager CLI)

Opening the Database Parameter History

Use

You open the database parameter history and transfer the first block of the contents. The entries are output in reverse chronological sequence, that is, starting with the most recent and ending with the oldest.

You can limit the output by specifying options. If you enter several selection criteria, then only those parameter changes that correspond to all the criteria are output.

If the parameter history entries have been incompletely transferred, you can call up the rest of the contents using the command for scrolling through the database parameter history.

Prerequisites

You have the server authorization ParamRead.

Syntax

param_gethistory [fields=<field_list>] [name=<parameter_name>]

[date=<yyyymmdd>] [group=<group_list>]

[state=<state_list>]

Example

Options

<field_list>

You can restrict the quantity of history fields supplied by the Database Manager by specifying a field list.
Enter the fields that you want display here using a comma as a separator.
The fields you select will always be output in the following sequence:

Possible entries:

DATE Date when parameter was changed (YYYYMMDD)
TIME Time when parameter was changed (00HHMMSS)
NAME Name of parameter
NEWVALUE New value of parameter
OLDVALUE Old value of parameter
STATE Change state of parameter
GROUP Group to which the parameter is assigned

If you do not specify a field list, then all fields are displayed.

<parameter_name>

You can display the history of one specific parameter by specifying the parameter name.
If you do not specify a parameter name, the entries for all parameters in the history are displayed.

<yyyymmdd>

If you specify a date, then only those parameter changes that have taken place since this date are displayed.
If you do not specify a date, all entries in the history are displayed.

<group_list>

You can restrict the database parameters for which the changes are displayed by specifying a parameter group. Use a comma to separate entries.

Possible values are:
GENERAL: General database parameters
EXTENDED: Special database parameters
SUPPORT: Support database parameters

If you do not specify a parameter group, then the parameter changes for all groups are displayed.

<state_list>

You can specify the change state to determine whether active, changed or deleted database parameters are displayed. Use a comma to separate entries.

Possible values are: A (active), C (changed), D (deleted)

if you do not specify a state, then all parameter changes are displayed.

Reply

OK
<header_line><NL>
<param_line><NL>
<param_line><NL>
...

Values for the Individual Fields of the Reply

<header_line> | contains the names of the fields displayed S stands for STATE and describes the parameter's stat us
<param_line> | contains the values for the fields described in the <header _ line>, the values are in the same column position as the field description in the <header _ line> Field S for STATE (change status of the database parameters) can contain any of the following entries: c: changed d: deleted a: active


param_gethistory Command: Example (MaxDB: Database Manager CLI)

param_gethistory Command: Example

Opening the parameter history for the parameter _MAXDATAVOLUMES

dbmcli -d myDB -u dbm,dbmp param_gethistory name=_MAXDATAVOLUMES

OK
DATE TIME NAME  NEWVALUE OLDVALUE S GROUP
20010613 00152700 _MAXDATAVOLUMES 5 4 A SUPPORT
20010613 00152700 _MAXDATAVOLUMES 4 3 C SUPPORT
20010613 00152659 _MAXDATAVOLUMES 3 C SUPPORT


Checking All Database Parameters (MaxDB: Database Manager CLI)

Checking All Database Parameters

Use

You check all database parameters using the properties, calculation formulas, and conditions stored in the description file (Configuring Database Instances).

Prerequisites

You have opened a parameter session.

You have the server authorization ParamCheckWrite.

Syntax

param_checkall [<mode>]

Option <mode>

Using the parameter <mode>, you can control the behavior of the Database Manager for parameters with the check status request.

Possible values of <mode>:

No entry | The system default values are used for all parameters (necessary for background processing).
GENERAL | Only the parameters from the group General - General Database Parameters are requested during the check status request.
EXTENDED | Only the parameters from the groups General Database Parameters and Special Database Parameters (Extended) are checked.
SUPPORT | This option is only relevant for Support. All parameters (from the groups General, Extended, and Support) are checked.

Reply

If an error occurs the database parameter check is canceled with an error message.

ERR
14,ERR_XPCHECK_CN00 : param check failure/request
<parameter_name>      <check_status>
<user_value>
<computed_value>

<parameter_name> | Name of the database parameter
<check_status> | The following are possible values for the check status: Mandatory – An obligatory parameter has been assigned a blank value. Constraint – a constraint could not be fulfilled. Request – the operator input deviates both from the value transferred to the system and confirmed by it earlier, as well as from the system default value.
<user_value> | Value that the operator entered with param_put.
<computed_value> | Default value calculated by the system

For open requests the parameter changes cannot be confirmed (Confirming Changes to the Database Parameter File).

Continuation of Procedure

Correct the parameter in question using param_putconfirm (parameter correction) or param_put (change a parameter value)and carry out a new check with the command param_checkall [<mode>].

The new parameter value is registered by the system, and is transferred to the parameter file as the valid value at the next restart of the database instance.


Resetting the Parameter File to a Previous Version (MaxDB: Database Manager CLI)

Resetting the Parameter File to a Previous Version

Use

The parameter file is reset to the version specified by <version_number>.

This parameter file will be used when the database instance is next started.

Prerequisites

You have the server authorization ParamCheckWrite.

Syntax

param_restore <version_number>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Parameter Properties (MaxDB: Database Manager CLI)

Parameter Properties

Property | Explanation | Possible values
CASESENSITIVE | Upper/lower case distinctions are relevant (for example, file names under UNIX) | YES | NO
CHANGE | Parameter can be changed | YES | NO
CLEAR | In a new installation, the parameter must not be copied from another database instance (examples: database instance name, volumes) | YES | NO
VOLUME | Type of parameter (Yes: volume parameter, NO: kernel parameter) | YES | NO
DISPLAYNAME | Character string (may include spaces) displayed in place of the parameter name in the Database Manager GUI |
DYNAMIC | Parameter has a position indicator in the description file, such as DATAVOL_? In the parameter file, it becomes DATAVOL_00, DATAVOL_01 and so on. | YES | NO
GROUP | Assignment to a group for display in the Database Manager GUI GENERAL: General Database Parameters, visible EXTENDED: Special Database Parameters, visible SUPPORT: Support Database Parameters, visible NO: The parameter is not accessible using the Database Manager GUI INFO: The parameter contains special information for users | GENERAL | EXTENDED | SUPPORT | NO | INFO
INSTANCES | Instance type for which the parameter is relevant No entry: Parameter is generally valid | LVC | OLTP | ARCHIVE
INTERN | The value is only in the description file, not in the parameter file (Configuring Database Instances) | YES | NO
LASTKNOWNGOOD | Valid value of the parameter with which the database instance was last started |
MANDATORY | Mandatory parameter | YES | NO
MAX | Maximum parameter value |
MIN | Minimum parameter value |
MODIFY | You can still change the parameter after the database instance has been generated (for example: RUNDIRECTORY: NO) | YES | NO
OVERRIDE | You can overwrite the DBM Server default value | YES | NO | HIGHER
VALUESET | Permitted value set for a parameter The individual values must be separated by spaces or tabs. Permitted string constants in character string parameters must be set off in quotation marks. |


Setting Up a Hot Standby System (MaxDB: Database Manager CLI)

Setting Up a Hot Standby System

Use

You set up a hot standby system to improve the availability of your database system. You require a suitable memory management system and a cluster solution. For information about setting up a memory management system and cluster configuration, see the manufacturer documentation.

Prerequisites

· Master and standby components use the same hardware platforms (memory space, type and number of processors).

· All the data paths and files (run directory, volumes, trace files, and so on) used in the configuration are the same in the master and standby components.

· The same version of the database software is installed on all the servers.

· All the servers are switched on.

· The X Server is running on all the servers.

· The user setting up the hot standby system has administration rights on all the servers.

Procedure

...

1. Creating the Database Instance.

2. Transferring the Database Instance to the Operational State OFFLINE.

3. Configuring a Master Component.

4. Transferring the Database Instance to the Operational State ONLINE.

5. Defining an Additional Standby Component.

While a new standby component is being set up, savepoints must not be written.

6. Transferring the Standby Component to the Operational State STANDBY.

Result

The hot standby system is set up. To add additional standby components, repeat the procedure from step 5.

To change database parameters, use the usual commands to address the master component of the hot standby system. The changes are transferred automatically to all the standby components.

See also:

Example

Database Administration documentation: Special Database Parameters.


Overview of the DBM Commands for Setting Up a Hot Standby System (MaxDB: Database Manager CLI)

Overview of the DBM Commands for Setting Up a Hot Standby System

Querying Hot Standby Parameters | hss_getnodes
Addressing a Standby Component | hss_execute
Defining an Additional Standby Component | hss_addstandby
Removing a Standby Component | hss_removestandby
Configuring a Master Component | hss_enable


Querying Hot Standby Parameters (MaxDB: Database Manager CLI)

Querying Hot Standby Parameters

Use

You query the values of the hot standby parameters. You can also find out which server within the cluster is currently defined as the master component (CURRENT_NODE).

Prerequisites

You have the server authorization ParamRead, ParamCheckWrite, or ParamFull.

Syntax

hss_getnodes

Reply

You receive information about the hot standby system.

Example

hss_getnodes

OK

HS_STORAGE_DLL libhsscopy

OFFICIAL_NODE hotel_official

CURRENT_NODE genua

HS_NODE_001 genua

HS_NODE_002 parma

See also:

Example: How to Set Up a Hot Standby System

Database Administration documentation: Special Database Parameters.


Addressing a Standby Component (MaxDB: Database Manager CLI)

Addressing a Standby Component

Use

You send a Database Manager (DBM) command to a standby component via the master component.

DBM commands should usually be sent to the cluster and not directly to standby components. The cluster software forwards the commands to the master component. The master component executes the commands and synchronizes the standby components if necessary.

Prerequisites

You have the required server authorizations.

Syntax

hss_execute <hs_node_nnn> <dbm_command>

hs_node_nnn | Server name/standby component address nnn.
dbm_command | DBM command

Reply

The system displays an OK message.

Example

To query the status of the standby component parma, use the following command:

hss_execute parma db_state


Defining an Additional Standby Component (MaxDB: Database Manager CLI)

Defining an Additional Standby Component

Use

You define an additional standby component for the hot standby system.

Prerequisites

· In the Database Manager CLI, you are connected to the hot standby system via the master component.

· The operational state of the hot standby system is ONLINE.

· All the data paths and files (run directory, volumes, trace files, and so on) of the standby component to be added match those of the master component.

· You have the server authorization ParamFull.

Syntax

hss_addstandby <hs_node_nnn> login=<user>,<password> [path=<dependent _path>] [delay=<hs_delay_time_nnn>]

hs_node_nnn | Server name/standby component address nnn.
user | Operating system user on the standby server; must have administration rights for the server.
dependent_path | Installation path of the database software on the standby server. If you do not enter a path, the database software is used that has the same version as the database software on the master component.
hs_delay_time_nnn | Time delay (in seconds) for the standby component nnn to restore log entries.

Reply

The system displays an OK message.


Removing a Standby Component (MaxDB: Database Manager CLI)

Removing a Standby Component

Use

You remove a standby component from the hot standby system.

Prerequisites

· In the Database Manager CLI, you are connected to the hot standby system via the master component.

· You have the server authorization ParamFull .

Syntax

hss_removestandby <hs_node_nnn>

hs_node_nnn

Server name/standby component address nnn.

Reply

The system displays an OK message.


Configuring a Master Component (MaxDB: Database Manager CLI)

Configuring a Master Component

Use

You configure the master component for a hot standby system.

Prerequisites

· The operational state of the database instance is OFFLINE.

· You have the server authorization ParamFull.

Syntax

hss_enable lib=<hs_storage_dll> node=<official_node>

hs_storage_dll | Name of the library required for controlling the memory management system.
official_node | Official name of the database within the cluster system. This name is defined by the system administrator.

Reply

The system displays an OK message.


Example: How to Set Up a Hot Standby System (MaxDB: Database Manager CLI)

Example: How to Set Up a Hot Standby System

You want to set up a hot standby system called HOTELDB with a master component GENUA and a standby component PARMA. The GENUA server recognizes the operating system user DAVID with password BLUE. The hot standby system is to be addressed using the official name HOTEL_OFFICIAL. The PARMA server recognizes the operating system user ANNA with password MAY. The installation path for the database software on this server is C:\Program Files\sdb\7500.

Open a connection to the official node HOTEL_OFFICIAL:

dbmcli -n HOTEL_OFFICIAL

Generate the database instance HOTELDB:

db_create HOTELDB DBM,DBM DAVID,BLUE
...
Set up the hot standby system:

db_offline
hss_enable node=HOTEL_OFFICIAL lib=LIBHSSCOPY
db_online
hss_addstandby PARMA login=ANNA,MAY path="C:\Program Files\sdb\7500"
db_standby PARMA


Functions for Database Operation (MaxDB: Database Manager CLI)

Functions for Database Operation

Use

You can use the commands for database operation to perform important functions for starting and stopping the database instance and to load the system tables.

Prerequisites

Note the operator authorizations required for the particular DBM commands.

Overview of the Commands for Database Operation


Overview of the DBM Commands for Database Operation (MaxDB: Database Manager CLI)

Overview of the DBM Commands for Database Operation

Updating the Optimizer Statistics with the XPU Program | exec_xpu
Using the Database Console | db_cons
Loading the System Tables | load_systab
Loading SAP-Specific Tables | load_r3tab
Deleting Runtime Information After a Database Error | db_clear
Restarting the Database Instance | db_restart
Starting the Database Instance | db_start
Starting the PythonLOAD Program | exec_load
Stopping the Database Instance | db_stop
Transferring to the ADMIN Operational State | db_admin
Transferring to the OFFLINE Operational State | db_offline
Transferring to the ONLINE Operational State | db_online
Transferring to the STANDBY Operational State | db_standby


Updating Optimizer Statistics with the XPU Program (MaxDB: Database Manager CLI)

Updating Optimizer Statistics with the XPU Program

Use

The SQL optimizer is part of the database instance and provides the fastest possible means of processing database accesses. To do this, it accesses the statistics about the contents of database tables. See also: SQL Optimizer

You update the statistics about the contents of the tables of the database instance using the XPU program.

You use the parameters for the XPU program as parameters.

Prerequisites

You have the DBM operator authorization AccessSQL.

The status of the database instance is ONLINE.

Syntax

exec_xpu <xpu_params>

Reply

You receive the reply of the XPU program.

OK<NL>
<xpu_output>

In the event of errors, see Reply Format.


Using the Database Console (MaxDB: Database Manager CLI)

Using the Database Console

Use

You use the database console to analyze and influence the runtime behavior of the database instance.

As parameters, you use a command for the database console, <cons_cmd>, and additional parameters for the database console <cons_param>.

Only use the database console when told to do by Support.

Prerequisites

You have the DBM operator authorization DBStop.

The database instance is in the operational state ADMIN or ONLINE.

Syntax

db_cons <cons_cmd> [<cons_param>]

Reply

You receive the database console reply.

OK<NL>
<console_output>

In the event of errors, see Reply Format.


Loading the System Tables (MaxDB: Database Manager CLI)

Loading the System Tables

Use

System tables are internal tables for the system that users do not define or change.

You have to reload the system tables after a change of database software version.

You do not need to reload system tables when restoring a database instance.

In order to load the system tables, the DBM server program must know the name and password of the SYSDBA user and the password of the DOMAIN user. If this is not already the case, enter the name and password of the SYSDBA user under -u <sysdba>,<password>, and the DOMAIN user's password under -ud <domain_password>.

See also: Database Administration

Prerequisites

You have the DBM operator authorization ExecLoad or LoadSysTab.

Syntax

load_systab [-u <sysdba>,<password>] [-ud <domain_password>]

Reply

OK<NL>
<errcode>,<err_description><NL>
<pgmcode>,<command><NL>
<xload_output_lines><NL>
<xload_protocol_lines><NL>

Values for the Individual Fields of the Reply

<errcode> | Error number of the DBM server program. If successful, the error number is 0
<err_description> | Description of the error
<pgmcode> | Return value of the executed program
<command> | Command line executed by the DBM server program
<xload_output_lines> | Output text of the program
<xload_protocol_lines> | Lines of the LOAD log
<NL> | Line feed


Loading SAP-Specific Tables (MaxDB: Database Manager CLI)

Loading SAP-Specific Tables

Use

The SAP-specific tables contain information for the SAP application on the status of the database instance.

You maintain the contents of the SAP-specific tables. Normally, these tables are maintained by the SAP application on a regular basis.

Prerequisites

You have the DBM operator authorization ExecLoad or LoadSysTab.

Syntax

load_r3tab

Reply

OK<NL>
<errcode>,<err_description><NL>
<pgmcode>,<command><NL>
<xload_output_lines><NL>
<xload_protocol_lines><NL>

Values for the Individual Fields of the Reply

<errcode> | Error number of the DBM server. If successful, the error number is 0
<err_description> | Description of the error
<pgmcode> | Return value of the executed program
<command> | Command line executed by the DBM Server
<xload_output_lines> | Output text of the program
<xload_protocol_lines> | Lines of the LOAD log
<NL> | Line feed


Deleting Runtime Information After a Database Error (MaxDB: Database Manager CLI)

Deleting Runtime Information After a Database Error

Use

If runtime information is still present in the operating system after a database error, it is not possible to restart the database instance.

Using this command, you remove this runtime information from the operating system and therefore allow the restart of the database instance.

Prerequisites

You have the DBM operator authorization DBStop.

Syntax

db_clear

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Restarting the Database Instance (MaxDB: Database Manager CLI)

Restarting the Database Instance

Use

You first transfer the database instance from the ADMIN or ONLINE operational state into the OFFLINEoperational state and then into the ONLINE operational state.

Prerequisites

You have the DBM operator authorization DBStop.

Syntax

db_restart [<option>]

Options

You can use the following options <option> for the command:

-f | -fast | The kernel variant fast is started.
-q | -quick | The kernel variant quick is started.
-s | -slow | The kernel variant slow is started.
-d | -dump | A dump is generated on transferring from ADMIN or ONLINE to OFFLINE.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Starting the Database Instance (MaxDB: Database Manager CLI)

Starting the Database Instance

Use

You change the database instance from the OFFLINE operational state to ADMIN (Transferring to the ADMIN Operational State ).

Prerequisites

You have the DBM operator authorization DBStart.

If you are using the Microsoft Windows operating system, this database instance must be registered as a service under the name SAP DB: <database_name>. This is done implicitly when you create a database instance with the database manager.

Syntax

db_start [<option>]

option

Kernel variant with which the database instance is to be started:
-f | -fast

-q | –quick

-s | –slow

If you do not specify an option, the fast variant of the database kernel is started.

The -q | -quick and -s | -slow options should only be used in case of error and in consultation with support.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Starting the PythonLOAD Program (MaxDB: Database Manager CLI)

Starting the PythonLOAD Program

Use

PythonLOAD is an environment programmed in the script language Python that allows load operations to be executed. As a response to the execution of this script, the system displays information about the execution status of the program as a reply.

With this command, the PythonLOAD program is executed on the current database instance with the user specified in <userid> <password>. Specify a PythonLOAD script file <file>. If you specify a relative file name, it is used relative to the directory <dependent_path>\env.

PythonLOAD options in double quotation marks are transferred uninterpreted to the PythonLOAD program.

Prerequisites

You have the DBM operator authorization ExecLoad.

Syntax

exec_load <userid> <password> <file> ["<option>"]

Reply

OK<NL>
<errcode>,<errdescription><NL>
<pgmcode>,<command><NL>
<pythonload output lines><NL>

Values for the Individual Fields of the Reply

<errcode> | Error number of the DBM server program. If successful, the error number is 0
<errdescription> | Description of the error
<pgmcode> | Return value of the executed program
<command> | Command executed by the DBM Server program
<pythonload output lines> | Output text of the program
<NL> | Line feed


Stopping the Database Instance (MaxDB: Database Manager CLI)

Stopping the Database Instance

Use

With this command, you transfer the database instance from the operational state ADMIN or ONLINE to the operational state OFFLINE.

Prerequisites

You have the DBM operator authorization DBStop.

Syntax

db_stop [<option>]

Option

If you specify the value -d | -dump as an <option>, a dump is created when the database instance transfers from the ADMIN to the OFFLINE operational state.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Transferring to the ADMIN Operational State (MaxDB: Database Manager CLI)

Transferring to the ADMIN Operational State

Use

The database instance is transferred to the ADMIN operational state.

If the database instance is in the ONLINE operational state, it is first transferred to the OFFLINE operational state and then to the ADMIN operational state.

Prerequisites

You have the user authorization DBStop.

Syntax

db_admin [<option>]

Options

You can enter the command with the following options <option>:

-f | -fast | When you change from the OFFLINE operational state to ADMIN, the kernel variant fast is started.
-q | -quick | When you change from the OFFLINE operational state to ADMIN, the kernel variant quick is started.
-s | -slow | When you change from the OFFLINE operational state to ADMIN, the kernel variant slow is started.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Transferring to the OFFLINE Operational State (MaxDB: Database Manager CLI)

Transferring to the OFFLINE Operational State

Use

The database instance is transferred to the operational state OFFLINE.

Prerequisites

You have the DBM operator authorization DBStop.

Syntax

db_offline [<option>]

Options

You can enter the command with the following option <option>:

-d | –dump

A dump is generated when transferring from the operational states ADMIN or ONLINE to OFFLINE.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Transferring to the ONLINE Operational State (MaxDB: Database Manager CLI)

Transferring to the ONLINE Operational State

Use

You transfer the database instance in normal database operation to the ONLINE operational state.

You use this command after a database error where the log backups remained intact but the data had to be restored using a complete data backup. To do so, you must have imported the complete data backup already (see also: Restoring the Database Instance). If you specify the option –u | -until and a time, you define the time up to which the log entries still available in the database instance are to be restored.

Prerequisites

You have the server authorization DBStart.

Syntax

db_online [<option>]

Options

You can enter the command with the following options <option>:

-f | -fast

The kernel variant fast is started.

-q | -quick

The kernel variant quick is started.

-s | -slow

The kernel variant slow is started.

[-u | -until] <date> <time>
<date> ::= <yyyymmdd>
<time> ::= <hhmmss>

Time (year, month, day, hour, minutes, seconds) up to which the log entries still available in the database instance are to be restored.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Transferring to the STANDBY Operational State (MaxDB: Database Manager CLI)

Transferring to the STANDBY Operational State

Use

A standby component is transferred to the STANDBY operational state and added to the hot standby system. The standby component receives an exact copy of the configuration of the master component.

Prerequisites

· The operational state of the hot standby system is ONLINE.

· All the data paths and files (run directory, volumes, trace files, and so on) are the same in the master component and the standby component.

· You have the server authorization DBStart.

Syntax

db_standby <hs_node_nnn>

hs_node_nnn

Server name/standby component address nnn.

Reply

The system displays an OK message.


Backing Up and Recovering Database Instances (MaxDB: Database Manager CLI)

Backing Up and Recovering Database Instances

Use

You can use the Database Manager CLI to carry out complete and incremental data backups and log backups, and to import these backups if hardware errors occur, thereby restoring the database to a consistent state.

Prerequisites

Note the operator authorizations required for the particular DBM commands.

Commands for Backup Media

Commands for Backing Up and Archiving

Commands for the Backup History

Commands for External Backup IDs

Commands for Backup Information

Commands for Restoring


Commands for Backup Media (MaxDB: Database Manager CLI)

Commands for Backup Media

Use

A backup medium is assigned to every backup action. Backup media can be files, tapes, and pipes.

The path specifications and properties of the tape device, tapes, or files are grouped together in the media definition under a freely selectable, practical name. Under these names, the backup media can be re-used for all possible backup operations.

Prerequisites

Note the operator authorizations required for the particular DBM commands.

Syntax

Change Date of the Media Definition File | medium_date
Defining or Changing a Backup Medium | medium_put
Displaying the Media Data | medium_get
List of All Defined Backup Media | medium_getall
Deleting a Backup Medium | medium_delete
Copying an Existing Media Definition | medium_migrate


Displaying the Change Date of the Media Definition File (MaxDB: Database Manager CLI)

Displaying the Change Date of the Media Definition File

Use

You display the date and time when the current media definiton file was last changed (see also: Database Manager Files).

Prerequisites

You have the server authorization Backup and DBInfoRead.

Syntax

medium_date

Reply

OK<NL>
<yyyymmdd><HHMMSS><NL>

In the event of errors, see Reply Format.


Creating or Changing a Backup Medium (MaxDB: Database Manager CLI)

Creating or Changing a Backup Medium

Use

You create a new backup medium or change the data for a backup medium that already exists.

Prerequisites

You have the server authorization Backup.

Syntax

medium_put <name> <location> <type> <backup_type> <size> <block_size> <overwrite> <autoloader> <os_command> <tool_type>

<name>

The backup medium specified in <name> is created or updated. The name of the medium may comprise a group name and a member name. These are separated by a slash.

<name> ::= [<group_name>/]<member_name>

Groups of parallel backup media of this type are used for parallel backups and restores. To create a group of parallel backup media, execute the command for creating one backup medium as many times as you need. Create the group by assigning each different <member_name> to the same <group_name>.

<location>

The name of the device/file with which it can be addressed through operating system functions.

When you change an existing backup medium with the <backup_type> LOG and the <type> FILE, note that the system adds a serial number after the successful backup of the <location> originally defined. You must enter this serial number here too.

<type>

Type of the backup medium. Possible values are:

AUTO | TAPE | FILE | PIPE

The media type AUTO is the default value for the command for activating the automatic log backup. There can only be one backup medium of this type. If there is already a backup medium of type AUTO, and you create a backup medium of type AUTO again, the system changes the media type of the existing backup medium to FILE.

Specify TAPE for backup to a non-rewindable tape, FILE for backup to a file, and PIPE for backup to a pipe.

In Microsoft Windows: The name of a backup medium of type PIPE must adhere to the following convention: \\.\pipe\<pipe_name>. For a backup medium of type TAPE, the path must adhere to the following convention: \\.\tape<running_number>. If you specify a relative path for a backup medium of type FILE, the backup medium is stored in the run directory of the database instance.

In UNIX, any path can be used for backup media of type FILE and PIPE. If you specify relative paths, the backup media are stored in the run directory of the database instance. You must specify absolute paths for backup media of type TAPE.

<backup_type>

Type of save for which the backup medium is to be used:

DATA | PAGES | LOG

Specify DATA for a complete data backup , PAGES for an incremental data backup and LOG for a log backup.

<size>

Maximum number of pages that can be written to the backup medium. This entry is necessary to change the tape correctly, for example. If the backup media are of a sufficient size, you can enter a zero here.

<block_size>

Number of pages that are transferred when accessing the medium (default: 8).

<overwrite>

This option is only relevant for the medium type FILE and defines the behavior if the file is already present. Possible values are:

YES | NO

If you specify YES and the file already exists, it will be overwritten with the new backup. If you specify NO and the file already exists, the backup will fail.

<autoloader>

Details of whether the device changes the backup medium automatically

are only relevant in Microsoft Windows.
Possible values are:

YES | NO

<os_command>

Operating system command to be executed before backing up to a succeeding medium or restoring from a succeeding medium.

<tool_type>

Backup tool to be used.

Possible values are:

NONE | BACK | NSR | TSM

If you specify the value NONE and <type> PIPE, in UNIX the pipe must already have been created before the start of the backup, and in Microsoft Windows it cannot exist yet.

If you specify a value other than NONE, you must enter PIPE as the <type> and 0 as the <size>. The pipe cannot exist in either UNIX or Microsoft Windows before the backup starts.

Examples: Creating Backup Media

Reply

OK

In the event of errors, see Reply Format.


medium_put Command: Examples (MaxDB: Database Manager CLI)

medium_put Command: Examples

Defining a file as a backup medium for an interactive log backup:

dbmcli -d <database_name> -u <dbm_user>,<password> medium_put logsave /usr/maxdb/log FILE LOG

Defining a file as a backup medium for an automatic log backup:

dbmcli -d <database_name> -u <dbm_user>,<password> medium_put autosave /usr/maxdb/auto FILE AUTO

Defining a file as an overwritable backup medium for a complete data backup:

dbmcli -d <database_name> -u <dbm_user>,<password> medium_put completeF /usr/maxdb/complete FILE DATA 0 0 YES

Defining a tape device as a backup medium for a complete data backup:

dbmcli -d <database_name> -u <dbm_user>,<password> medium_put completeT /dev/rft0 TAPE DATA 64000 8 NO

Defining a File as a backup medium for an incremental data backup:

dbmcli -d <database_name> -u <dbm_user>,<password> medium_put incrF /usr/maxdb/incr FILE PAGES

Defining a pipe as an external backup medium for an incremental data backup with an external backup tool on Microsoft Windows:

dbmcli -d <database_name> -u <dbm_user>,<password> medium_put ADSM123 \\.\pipe\example PIPE PAGES


Displaying the Media Data (MaxDB: Database Manager CLI)

Displaying the Media Data

Use

You display the media data for the backup medium specified in <name>.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

Syntax

medium_get <name>

Reply

OK<NL>
<name> <location> <type> <backup_type> <size> <block_size> <overwrite> <autoldr> <oscmd> <date_created> <date_modified> <NL>

The fields of the one-line output are separated by tabs.

Values for the Individual Fields of the Reply

<name>

Name to identify the backup medium. The name of the backup medium may comprise a group name and a member name. These are separated by a slash.

<name> ::= [<group_name>/]<member_name>

This type of group is used with parallel backup or restore operations.

<location>

The name of the device/file with which it can be addressed through operating system functions.

<type>

Type of the backup medium, possible values are:
 TAPE
FILE
NO-REWIND
PIPE
AUTOLOADER
UNKNOWN

<backup_type>

Type of backup for which the backup medium is to be used: Possible values are:
 DATA for a complete data backup
PAGES for an incremental data backup
LOG for a log backup

<size>

Maximum number of pages which can be written to the backup medium. This is necessary to change the tape correctly, for example. If the media are of sufficient size, a zero can be specified.

<block_size>

Number of pages that are transferred when accessing the medium (default: 8).

<overwrite>

This option is only relevant for the medium type FILE and describes the behavior if the file is already present. Permitted values are:
 NO
YES
VERSION

<autoldr>

Specifies whether the device changes the backup medium automatically:
 YES
NO

<oscmd>

Operating system command to be executed before backing up to a succeeding medium or restoring from a succeeding medium.

<date_created>

Date on which the backup medium was created

<date_modified>

Date on which the backup medium was changed

In the event of errors, see Reply Format.


List of All Defined Backup Media (MaxDB: Database Manager CLI)

List of All Defined Backup Media

Use

You can call up a list of all defined backup media.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

Syntax

medium_getall

Reply

OK<NL>
 <name> <location> <type> <backup_type> <size> <block_size> <overwrite> <autoldr> <oscmd> <date_created> <date_modified> <NL>

<name> <location> <type> <backup_type> <size> <block_size> <overwrite> <autoldr> <oscmd> <date_created> <date_modified> <NL>

...

Values for the Individual Fields of the Reply

<name>

Name to identify the backup medium. The name of the medium may comprise a group name and a member name. These are separated by a slash.

<name> ::= [<grpname>/]<membername>

This type of group is used with parallel data backups or parallel restore operations.

<location>

The name of the device/file
Used for operating system functions.

<type>

Type of the backup medium Possible values are:
 TAPE
FILE
NO-REWIND
PIPE
AUTOLOADER
UNKNOWN

<backup_type>

The type of backup for which the backup medium is to be used:
 DATA (complete data backup)
 PAGES (incremental data backup)
 LOG (log backups)

<size>

Maximum number of pages which can be written to the medium. This is necessary to change the tape correctly, for example. If the backup media is of sufficient size, a zero can be specified.

<block_size>

Number of pages that are transferred when accessing the medium (default value: 8).

<overwrite>

This option is only relevant for the media type FILE and describes the behavior if the file is already present. Possible values are:
 NO
YES
VERSION

<autoldr>

Specifies whether the device changes the backup medium automatically:
 YES
NO

<oscmd>

Operating system to be executed before backing up to a succeeding medium or restoring from a succeeding medium.

In the event of errors, see Reply Format.


Deleting a Backup Medium (MaxDB: Database Manager CLI)

Deleting a Backup Medium

Use

You delete the backup medium specified as <name>.

Prerequisites

You have the DBM operator authorization Backup.

Syntax

medium_delete <name>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Transferring an Existing Media Definition (MaxDB: Database Manager CLI)

Transferring an Existing Media Definition

Use

You can transfer existing definitions for backup media from the media definition file control.med(database version 6.2) to the new media definition file dbm.mmm (as of database version 7.2.4.2).

See also: Database Manager Files

The media definition from the old file is not transferred if there is an identical media name in the old and new media definition files.

As the old definitions for backup media do not contain a backup type (incremental data backup, complete data backup, or log backup), you should define this afterwards using the command medium_put (Defining or Changing a Backup Medium). Otherwise you must specify this when starting the backup process.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

Syntax

medium_migrate

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Commands for Backing Up and Archiving (MaxDB: Database Manager CLI)

Commands for Backing Up and Archiving

Use

You can carry out full and incremental data backups and log backups with the Database Manager. For log backups, we recommend that you enable automatic log backup. The option of interactive log backups is also available to you, however.

Prerequisites

Note the operator authorizations required for the particular DBM commands.

The prerequisite for executing all other backup commands is to execute the command to backup the database instance first.

Syntax

Canceling the Automatic Log Backup | autolog_cancel
Displaying the Automatic Log Backup | autolog_show
Displaying the Current Backup Status | backup_state
Deactivating the Automatic Log Backup | autolog_off
Terminating an Interrupted Backup | backup_cancel
Creating a Single Archive of the Version Files | archive_stage
Activating the Automatic Log Backup | autolog_on
Continuing the Backup Without the Medium Last Reported as Full | backup_ignore
Creating Multiple Archives of the Version Files | archive_stage_repeat
Backing Up to a Succeeding Medium | backup_replace
Backing Up the Database Instance | backup_start
Backing Up with External Backup Tools | ---


Canceling the Automatic Log Backup (MaxDB: Database Manager CLI)

Canceling the Automatic Log Backup

Use

You can cancel an automatic log backup while it is running. This deactivates the automatic log backup function. Use this command to prevent technical problems with the backup medium, for example.

If you want the log to be backed up automatically again later, then you have to explicitly enable the log backup again (Activating the Automatic Log Backup).

Prerequisites

You have the DBM operator authorization Backup.

Syntax

autolog_cancel

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Displaying the Automatic Log Backup Function (MaxDB: Database Manager CLI)

Displaying the Automatic Log Backup Function

Use

You determine whether the automatic log backup function is enabled or disabled.

Prerequisites

You have the DBM operator authorization DBFileRead or DBInfoRead..

Syntax

autolog_show

dbmcli -d <database_name> -u <userid>,<password> autolog_show

OK<NL>
AUTOLOG IS OFF <NL>

Reply

OK<NL>
AUTOLOG IS (OFF | ON)<NL>

AUTOLOG IS ON | Automatic log backup is enabled
AUTOLOG IS OFF | Automatic log backup is disabled

In the event of errors, see Reply Format.


Displaying the Current Backup Status (MaxDB: Database Manager CLI)

Displaying the Current Backup Status

Use

You display the current status of the backup operation.

You can use this request while backing up the database instance.

Prerequisites

You have the DBM operator authorization Backup.

You have started a backup (Backing Up the Database Instance).

Syntax

backup_state

Reply

OK<NL>
Returncode <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volume Count [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Errortext [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Version of the database software
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Archiving the Version Files of the Log Area (MaxDB: Database Manager CLI)

Archiving the Version Files of the Log Area

To increase the security of your database system, we recommend that you archive the version files created during the Log Backup and stored on the hard disk of your system at regular intervals (Version Files). To do this, copy the version files to another backup medium.

You can perform this process manually or use external backup tools. For information about which external backup tools are supported by the MaxDB database system, see the Database Administration documentation.

There are DBM commands available for archiving with external backup tools, with which you can copy the version files once or several times to external backup media.

The commands for archiving the version files to external backup media are supported from database version 7.04.03.

Creating a Single Archive of the Version Files

Creating Multiple Archives of the Version Files


Creating a Single Archive of the Version Files (MaxDB: Database Manager CLI)

Creating a Single Archive of the Version Files

Use

You archive the original Version Files for the Log Backups. To do this, you copy the version files using an external backup tool to an external backup medium.

The command for archiving the version files once to external backup media is supported from database version 7.04.03.

If you want to backup the same version files more than once to different external backup media, first use the archive_stage command described here and then the command for creating multiple archives of the version files of the log area.

Prerequisites

Your database instance has at least Version 7.04.03.

You have the DBM operator authorization Backup.

You have backed up the log (Log Backup).

The external backup medium is defined for the backup type LOG (Defining or Changing a Backup Medium).

Syntax

archive_stage <ext_backup_medium> <log_medium> [VERIFY | NOVERIFY] [REMOVE | KEEP] [FNL <list>]

<ext_backup_medium> | Name of the external backup medium
<log_medium> | Name of the backup medium that was used for the log backup
VERIFY | System default value The archived files are compared with the original files.
NOVERIFY | Only the usual checks as to whether the backup was successful are performed by the system. The system displays error messages and the output of the backup tools.
REMOVE | System default value The original files are deleted after they have been successfully archived to the external backup medium.
KEEP | The original files are archived, but not then deleted.
FNL | File Number List: Keyword of the list of files to be archived
<list> | File name or area or file names: you can leave out leading zeros. Separate multiple specifications using commas. If you do not specify a file list, all version files on the backup medium that are also in the backup history are copied.

In most cases, it is not necessary to specify a file number list, as all completed version files are archived with the command archive_stage. The system obtains the information about which files are complete from the backup history.
Only specify the keyword FNL and the file number list if version files that you are sure were created are not in the backup history due to an error. This would be the case, for example, if the version files with the number 10 and 12 are in the backup history, but number 11 is missing.

Archiving the originals of the version files 1 and 3-10
These are on the backup medium LOGMEDIUM and are archived to the external backup medium EXTMEDIUM. Only the usual system checks are to be performed. The version files are not then to be deleted.

archive_stage EXTMEDIUM LOGMEDIUM NOVERIFY KEEP FNL 1,3-10

Reply:

OK
Processed Stage Files  9
Bytes Processed     12845056
Deleted Stage Files    0
Remaining Stage Files  2

Result

The system displays an OK message and information about the archived version files.

The archived version files are assigned their own external backup IDs and are entered in the backup history.

Processed Stage Files | Processed version files
Bytes Processed | Processed bytes
Deleted Stage Files | Deleted version files
Remaining Stage Files | Remaining version files


Creating Multiple Archives of the Version Files (MaxDB: Database Manager CLI)

Creating Multiple Archives of the Version Files

Use

You archive the original version files for log backups more than once on to different external backup media. You can also use different external backup tools to do this.

Exactly the same version files are processed as were copied to the first external backup medium using the command to archive the version files once, which must be executed once.

The command for archiving the version files to external backup media is supported from database version 7.04.03.

It can be executed only in the same session as the DBM server, just like the command for archiving the version files once, which must be executed first (Opening a DBM Server Session).

Prerequisites

Your database instance has at least Version 7.04.03.

You have the DBM operator authorization Backup.

You have first executed the command to archive the version files once, specifying the KEEPoption.

The external backup media are defined for the backup type LOG (Defining or Changing a Backup Medium).

Syntax

archive_stage_repeat <ext_backup_medium> [VERIFY | NOVERIFY] [REMOVE | KEEP]

<ext_backup_medium> | Name of the external backup medium
VERIFY | System default value The archived files are compared with the original files.
NOVERIFY | Only the usual checks as to whether the backup was successful are performed by the system. The system displays error messages and the output of the backup tools.
REMOVE | System default value The original files are deleted after they have been successfully archived to the external backup medium.
KEEP | The original files are archived, but not then deleted.

Multiple archiving of the original version files 1 and 3-10
These are on the backup medium LOGMEDIUM, and are first archived to the external backup medium EXTMEDIUM_1 and then to the medium EXTMEDIUM_2. Only the usual system checks are to be performed. The version files are not then to be deleted.

archive_stage EXTMEDIUM_1 LOGMEDIUM NOVERIFY KEEP FNL 1,3-10

Reply:

OK
Processed Stage Files  9
Bytes Processed     12845056
Deleted Stage Files    0
Remaining Stage Files  2

archive_stage_repeat EXTMEDIUM_2

Reply:

OK
Processed Stage Files  9
Bytes Processed     12845056
Deleted Stage Files    9
Remaining Stage Files  0

Result

The system displays an OK message and information about the archived version files.

The archived version files are assigned their own external backup IDs and are entered in the backup history.

Processed Stage Files | Processed version files
Bytes Processed | Processed bytes
Deleted Stage Files | Deleted version files
Remaining Stage Files | Remaining version files


Deactivating the Automatic Log Backup (MaxDB: Database Manager CLI)

Deactivating the Automatic Log Backup

Use

You deactivate the automatic log backup.

Prerequisites

You have the DBM operator authorization Backup.

Syntax

autolog_off

dbmcli -d <database_name> -u <userid>,<password> autolog_off

OK

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Terminating an Interrupted Backup (MaxDB: Database Manager CLI)

Terminating an Interrupted Backup

Use

You can exit an interrupted backup process completely.

Prerequisites

You have the DBM operator authorization Backup .

You have begun backing up the database instance . The backup operation was interrupted.

Syntax

backup_cancel

Reply

In the reply to this command only the field Return code is assigned a value.

OK<NL>
Return code <value>

In the event of errors, see Reply Format .


Activating the Automatic Log Backup (MaxDB: Database Manager CLI)

Activating the Automatic Log Backup

Use

You enable automatic log backup. For <medium>, specify the backup medium on which the log is to be automatically backed up.

Prerequisites

You have the DBM operator authorization Backup.

Syntax

autolog_on <medium>

You must specify a suitable medium when you activate automatic log backups for the first time. The Database Manager then uses the medium last used for the automatic log backup, if you do not specify another medium.

dbmcli -d <database_name> -u <dbm_user>,<password> autolog_on [<medium>]

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Continuing the Backup Without the Medium Last Reported as Full (MaxDB: Database Manager CLI)

Continuing the Backup Without the Medium Last Reported as Full

Use

Use this command to continue a backup without the last medium that was reported full.

Prerequisites

You have the DBM operator authorization Backup.

You have started backing up the database instance. The backup operation was interrupted because the backup medium was reported full.

Syntax

backup_ignore

Reply

The reply to this command provides information about the backup supplied by the kernel.

This information is only given when the backup has been ended or interrupted. This command may, therefore, take a long time to execute.

OK<NL>
Returncode              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volume Count            [<value>]<NL>
Medianame               [<value>]<NL>
Location                [<value>]<NL>
Errortext               [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>

In particular, analyze the Returncode reply field, which contains a numeric value supplied by the kernel.

See also: Messages

If it is clear from the message number that the backup was only interrupted, the session must be continued with the continuation command: (backup_replace, backup_ignore), or terminated with backup_cancel.

In the event of errors, see Reply Format.


Backing Up to a Succeeding Medium (MaxDB: Database Manager CLI)

Backing Up to a Succeeding Medium

Use

You have started a backup. This was interrupted because the system reported that the backup medium is full.

You define a new backup medium. The backup continues to the medium you defined.

Prerequisites

You have the DBM operator authorization Backup.

Syntax

backup_replace <medium>

Reply

The reply to this command provides information about the backup supplied by the kernel.

This information is only given when the backup has been ended or interrupted. This command may, therefore, take a long time to execute.

OK<NL>
Returncode              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volume Count            [<value>]<NL>
Medianame               [<value>]<NL>
Location                [<value>]<NL>
Errortext               [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>
Database ID             [<value>]<NL>
Max Used Data Page      [<value>]<NL>

In particular, analyze the Returncodereply field, which contains a numeric value supplied by the kernel.

See also: Messages

If it is clear from the message number that the backup was only interrupted, the session must be continued with the continuation command: (backup_replace, backup_ignore), or terminated with backup_cancel.

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Backing Up the Database Instance (MaxDB: Database Manager CLI)

Backing Up the Database Instance

Use

You save the database instance.

If you want to use an external backup tool to do this, proceed as described in the section Backing Up with External Backup Tools. Otherwise, use the command backup_start, described below.

Prerequisites

You have the DBM operator authorization Backup.

You have started a utility session.

Syntax

backup_start <medium> [<type>] [AUTOIGNORE]

<medium> | Name of the backup medium; for a backup to a group of parallel backup media), specify the name of the media group here. This must first be defined (Defining or Changing a Backup Medium).
<type> | Type of Backup: DATA (Complete data backup), PAGES (Incremental data backup), or LOG (Log Backup)
AUTOIGNORE | The backup is to be automatically continued without the last backup medium reported as full (Continuing the Backup Without the Medium Last Reported as Full)

If you are using backup media that is already defined, it is vital you follow the current naming conventions for backup media (see Defining or Changing a Backup Medium ) to avoid error messages.

Reply

The reply to this command provides information about the backup supplied by the kernel.

This information is only given when the backup has been ended or interrupted. This command may, therefore, take a long time to execute.

OK<NL>
Returncode <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volumes [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Error text [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

Reply in the Event of an Error

If an error occurs while you are using an external backup tool, you will receive a reply in the following format:

ERR<NL>
<errcode>, <err_description><NL>
[<extended_description><NL>]

<errcode> | Error message number See also: Messages
<err_description> | Description of the error
<extended_description> | Cause of the error

The following errors may occur:

<errcode> | <err_description> | Explanation
-24927 | ERR_TOOLCHK: the external backup tool was not found | The external backup tool could not be found or has been installed incorrectly.
-24926 | ERR_MEDIUMCHK: the medium cannot be used with an external backup tool | The specified backup medium cannot be used with the backup tool referred to by the medium name (Creating or Changing a Backup Medium).
-24925 | ERR_PREPARE: prepare of the backup operation failed | The preparations necessary to use the backup tool were not made correctly.
-24924 | ERR_DBREQ: cannot start database kernel request | The database instance was unable to start the backup.
-24923 | ERR_TOOLREQ: cannot start external backup tool correctly | The backup tool could not be started correctly.
-24922 | ERR_OPCHK: cannot check state of backup operation | Unable to check the status of the database instance or the backup tool.
-24921 | ERR_POSTOP: cannot finish backup operation correctly | Although the backup was successful, the post-processing steps required could not be performed.
-24920 | ERR_BACKUPOP: backup operation was unsuccessful | The backup failed due to a problem with the database or the backup tool.
-24919 | ERR_CLEANUP: cannot clean up correctly after backup operation | Although the backup was successful, the temporary system resources that were used could not be freed up again.

If it is clear from the message number that the backup was only interrupted, the session must be continued with the continuation command: (backup_replace, backup_ignore), or terminated with backup_cancel.


Backing Up with External Backup Tools (MaxDB: Database Manager CLI)

Backing Up with External Backup Tools

The Database Manager supports the use of external backup tools for complete and incremental data backups, as well as for the archiving of log backups.

For information on which external backup tools are supported by MaxDB, External Backup Tool in the Database Administration documentation.

You can also use scripts to perform backups with external backup tools. However, if you do this, the Database Manager does not write a backup history. It therefore cannot check whether the backup procedure was successful.

Using the Backup Tools

Start the backup operation directly from the Database Manager CLI. The naming conventions for backup media enable the program to recognize the external backup tool and start it. The pipes for transferring the backup data are implicitly created by the Database Manager CLI during the backup process. They must not exist beforehand.

Prerequisites

· You have the DBM operator authorization Backup.

· The database instance is in the operational state ADMIN or ONLINE.

· You have defined the backup media in accordance with the naming conventions for external backup media (Defining or Changing a Backup Medium).

· You have configured the MaxDB software installation for the backup tool you want to use (see Integration of External Backup Tools).

· You have inserted the required backup media in the external backup tool.

Procedure

Proceed as described under Backing Up the Database Instance or Archiving the Version Files of the Log Area.

Backups with TSM:

dbmcli –u dbm,dbm –uUTL –d mydb backup_start ADSMData DATA

ADSMData | Backup medium for the external backup tool TSM
DATA | Complete data backup


Commands for the Backup History (MaxDB: Database Manager CLI)

Commands for the Backup History

Use

Information on all the backup and restore actions that have been performed is recorded chronologically in the backup history.

The Database Manager CLI provides you with a number of DBM commands, with which you can work with the backup history.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead .

Syntax

Change Date of the Backup History | backup_history_date
Displaying the Backup History | backup_history_list
Scrolling in the Backup History | backup_history_listnext
Fetching the Backup History | backup_history_open
Closing a Backup History | backup_history_close


Displaying the Change Date of the Backup History (MaxDB: Database Manager CLI)

Displaying the Change Date of the Backup History

Use

You display the date and time when the current backup history was last changed.

Prerequisites

You have the server authorization Backup or DBInfoRead .

Syntax

backup_history_date

Reply

OK<NL>
<yyyymmdd><HHMMSS><NL>

In the event of errors, see Reply Format.


Displaying the Backup History (MaxDB: Database Manager CLI)

Displaying the Backup History

Use

The system displays the content of the backup history. You can restrict or extend what is displayed using options.

To save time, we recommend that you execute the DBM command for fetching the backup history first. If you do not do so, it will be executed implicitly with the DBM command for displaying the backup history.

Prerequisites

You have the server authorization Backup or DBInfoRead .

Syntax

backup_history_list [-c <columns>] [-k <key>] [-l <label>] [-a <action>] [-r <restore_flag>] –u <yyyymmddHHMMSS>] –m] [-e] [-Inverted]

-c <columns>

You determine which columns should be displayed. If several columns are specified, you separate them by commas. The keywords for the individual columns are:
KEY Key value of the backup

LABEL Label of the backup

ACTION   Action of the backup

STAMP1 First time stamp of the backup

STAMP2 Second time stamp of the backup

START Start of the backup

STOP End of the backup

FIRSTLOG First log IO sequence number of backup

LASTLOG Last log IO sequence number of backup

LOG Specifies whether log backups must additionally be imported after the data backup import.

MEDIA Name of the backup medium used

PAGES Size of the backup in pages

VOLUMES Number of parts comprising the backup

RC Return value of the database instance for the backup

ERROR Error text of the backup

-k <key>

Only the line of the backup history that contains the keyword specified under <key> is displayed.

This option cannot be used with the -r option.

-l <label>

Only the lines of the backup history that contain the specified backup ID are displayed.

This option cannot be used with the -r option.

-a <action>

Only the lines of the backup history that correspond to the specified backup type are displayed.

This option cannot be used with the -r option.

-r <restore_flag>

Only backups that are required to restore the database instance are displayed. The following values for <restore_flag> are possible:

* | LAST | <key>

If you specify *, all data backups required to restore the database instance are displayed. If the log volume is intact, only the data backups that match the available log are displayed.

If you specify LAST, starting with the last complete backup all backups required to restore the database instance are displayed.

If you specify <key> for the complete data backup, all backups that are required to restore the database instance are displayed. The key value for the data backup is found in the first column of the entry for this backup in the backup history.

-u <yyyymmddHHMMSS>

Only those lines in the backup history that contain data that was saved in the database instance before the specified time are displayed.

This option cannot be used with the -r option.

-m

For each line that relates to a backup, information is supplied on the backup medium used.

-e

For each line that relates to a backup, information is supplied on the relevant external backup ID.

-Inverted

The backup history is displayed in reverse sequence (most recent backup first).

Reply

OK<NL>
(END|CONTINUE)<NL>
<history_line><NL>
[<media_line><NL>]
[<external_backup_id-line><NL>]
<history_line><NL>
[<media_line><NL>]
[<external_backup_id-line><NL>]
....

Values for the Individual Fields of the Reply

END | The contents of the backup history have been transferred in full. The file is closed automatically.
CONTINUE | The backup history contains further entries that were not transferred due to the limited storage available for replies. You can display this data by entering the above command or close the backup history.
<history_line> | Information on the completed backups. The individual columns are separated by |. A separate line is displayed for each backup.
<media_line> | Information on the medium used for the backup The line is prefixed with an M: and is followed by columns separated by |.
<external_backup_id_line> | If the backup was created using an external backup tool, information on the external backup ID is provided here. You have to specify this information when restoring a database instance from an external backup tool. The line is prefixed with E: which, in turn, is followed by columns separated with |.

In the event of errors, see Reply Format.


Scrolling in the Backup History (MaxDB: Database Manager CLI)

Scrolling in the Backup History

Use

You read more of the backup history. Options you specified for displaying the backup history remain active.

Prerequisites

You have the server authorization Backup or DBInfoRead .

You have fetched the backup history (Fetching the Backup History) and executed the DBM command for displaying the backup history. The keyword CONTINUE in the reply shows that you have not yet read the whole file.

Syntax

backup_history_listnext

Reply

OK<NL>
[END|CONTINUE]<NL>
<history_line><NL>
[<media_line><NL>]
[<external_backup_id-line><NL>]
<history_line><NL>
[<media_line><NL>]
[<external_backup_id-line><NL>]
....

Values for the Individual Fields of the Reply

END | The content of the backup history was transferred completely to the database manager.
CONTINUE | The backup history contains further entries that were not transferred due to the limited storage available for replies. You can display this data by entering the above command or close the backup history.
<history_line> | Information about the completed backups. The individual columns are separated by |. A separate line is displayed for each backup.
<media_line> | Information about the backup medium used for the backup. The line is prefixed with an M: and is followed by columns separated by |.
<external_backup_id_line> | If the backup was created using an external backup tool, the external backup ID is provided here. You have to specify this ID when restoring a database instance from an external backup tool. The line is prefixed with E:, followed by columns separated with |.

In the event of errors, see Reply Format.


Fetching the Backup History (MaxDB: Database Manager CLI)

Fetching the Backup History

Use

You use this DBM command to fetch the current backup history from the main memory. If you also specify the option –e, current information about the backup tools used is added to the backup history.

To display the content, execute the DBM command for displaying the backup history.

Prerequisites

You have the server authorization Backup or DBInfoRead.

Syntax

backup_history_open [-e]

-e

The availability status of each backup in the external backup tools is determined.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Closing the Backup History (MaxDB: Database Manager CLI)

Closing the Backup History

Use

You close a backup session. The backup history information buffered in the Database Manager is deleted.

Prerequisites

You have the server authorization Backup or DBInfoRead.

You have already opened a backup session either explicitly with the DBM command for Fetching the Backup History or implicitly with the DBM command for Displaying the Backup History.

Syntax

backup_history_close

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Commands for External Backup IDs (MaxDB: Database Manager CLI)

Commands for External Backup IDs

Use

Backups created with external backup tools can be identified uniquely by means of an external backup ID. These IDs are logged in the backup history. They can be called up using the commands for the backup history and must be entered when restoring using external backup tools.

To enable restores without a backup history, the external backup IDs of the backups currently in the backup tool can, however, also be determined using the DBM commands.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

Syntax

Displaying External Backup IDs | backup_ext_ids_list
Scrolling in the External Backup IDs | backup_ext_ids_listnext
Releasing the Memory Occupied by the External Backup IDs | backup_ext_ids_forget
Fetching External Backup IDs | backup_ext_ids_get


Displaying External Backup IDs (MaxDB: Database Manager CLI)

Displaying External Backup IDs

Use

You display the information requested by a backup tool. This information comprises, for each backup, the availability status, the external backup ID, the backup type, and the creation date/time.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

You have fetched a backup tool’s external backup IDs ( Fetching External Backup IDs ).

Syntax

backup_ext_ids_list

Reply

OK<NL>
(END|CONTINUE)<NL>
[<external_backup_id_line><NL>]
[<external_backup_id_line><NL>]
....

Values for the Individual Fields of the Reply

END | All of the information requested by the backup tool was transferred in full.
CONTINUE | Information on further backups is available. This was not transferred because of the limited storage available for replies. You can scroll through this information or release the memory occupied by it.
<external_backup_id_line> | A line containing information on one of the backups registered in the backup tool. The individual columns are separated by a |.

In the event of errors, see Reply Format.


Scrolling in the External Backup IDs (MaxDB: Database Manager CLI)

Scrolling in the External Backup IDs

Use

You display the external backup IDs of the individual backup media of a backup. In addition, the system displays the availability status, the backup type, and the creation time of the backup for each backup medium.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

You have fetched the external backup IDs of a backup tool ( Fetching External Backup IDs ) and executed the command for displaying the external backup IDs . The keyword CONTINUE in the reply shows that you have not yet read the whole file.

Syntax

backup_ext_ids_listnext

Reply

OK<NL>
(END|CONTINUE)<NL>
[<external_backup_id_line><NL>]
[<external_backup_id_line><NL>]
....

Values for the Individual Fields of the Reply

END | All of the requested information has been transferred in full.
CONTINUE | Information on further backups is available. This was not transferred because of the limited storage available for replies. You can call up this information by entering the above command again or release the occupied memory.
<external_backup_id_line> | A line containing information on one of the backups still registered in the backup tool. The individual columns are separated by a line ( | ).

In the event of errors, see Reply Format.


Releasing the Memory Occupied by the External Backup IDs (MaxDB: Database Manager CLI)

Releasing the Memory Occupied by the External Backup IDs

Use

You release the memory in which the external backup IDs requested by a backup tool are stored.

Prerequisites

You have the DBM operator authorization Backup or DBInfoRead.

Syntax

backup_ext_ids_forget

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Fetching External Backup IDs (MaxDB: Database Manager CLI)

Fetching External Backup IDs

Use

The external backup IDs and information currently available to the external backup tool specified by <medium> are written to a file. This information concerns the availability status, backup type, and creation time of the backups for a database instance. To display the file content, use the DBM command for displaying external backup IDs.

Prerequisites

You have the server authorization Backup or DBInfoRead.

Syntax

backup_ext_ids_get <medium> [<database_name>] [<database_server>]

<medium> | Name of the backup medium
<database_name> | Name of the database instance from which the backups were created
<database_server> | Name of the database server

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Commands for Backup Information (MaxDB: Database Manager CLI)

Commands for Backup Information

Use

Whatever operational state the database instance is in, you can request the information held on the backup media about backups. You can use various DBM commands to do this.

Prerequisites

You have the operator authorization Backup.

Syntax

Displaying the Backup Information in the Operational State OFFLINE | medium_labeloffline
Displaying the Backup Information in the Operational State ONLINE or ADMIN | medium_label
Displaying the Current Status of a Backup Check | recover_state_check
Checking a Backup | recover_check


Displaying the Backup Information in the Operational State OFFLI (MaxDB: Database Manager CLI)

Displaying the Backup Information in the Operational State OFFLINE

Use

You display the information stored on the backup medium <medium> about the backup. The system accesses the backup medium directly so that this function can be executed, if the database instance is in the operational state OFFLINE. If the database instance is in operational state ONLINE or ADMIN, use the command for displaying the backup information in the operational state ONLINE or ADMIN.

Prerequisites

You have the DBM operator authorization Backup.

Syntax

medium_labeloffline <medium>

Reply

OK<NL>
Returncode              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volume Count            [<value>]<NL>
Medianame               [<value>]<NL>
Location                [<value>]<NL>
Errortext               [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>
Database ID             [<value>]<NL>
Max Used Data Page      [<value>]<NL>

In particular, analyze the Returncode reply field, which contains a numeric value supplied by the kernel.

See also: Messages

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Displaying the Backup Information in the Operational State ONLIN (MaxDB: Database Manager CLI)

Displaying the Backup Information in the Operational State ONLINE or ADMIN

Use

You display the information stored on a backup medium about the backup.

Prerequisites

You have the DBM operator authorization Backup.

You have started a utility session (Opening a utility session). The database instance is in operational state ONLINE or ADMIN.

Syntax

medium_label <medium>

Specify the backup medium from which the information is to be read under <medium>.

For parallel backup media, specify only the name of the group of parallel backup media. You must first define this group (Defining or Changing a Backup Medium).

Reply

OK<NL>
Returncode              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volumes                 [<value>]<NL>
Medianame               [<value>]<NL>
Location                [<value>]<NL>
Errortext               [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>
Database ID             [<value>]<NL>
Max Used Data Page      [<value>]<NL>

In particular, analyze the Returncode reply field, which contains a numeric value supplied by the kernel.

See also: Messages

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Displaying the Current Status of a Backup Check (MaxDB: Database Manager CLI)

Displaying the Current Status of a Backup Check

Use

You display information about the current status of a backup check. You can run this command while a backup is being checked.

Prerequisites

You have the DBM operator authorization Backup.

You have opened a service session (Opening a Service Session).

Syntax

recover_state_check

Reply

OK<NL>
Return code <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volumes [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Error text [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Version of the database software
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | Only for data backup: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | Only for log backup: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Highest page number assigned (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Checking a Backup (MaxDB: Database Manager CLI)

Checking a Backup

Use

You check that the backup is consistent and complete. This command is executed independently of the current database instance functions but can adversely impact database instance performance temporarily.

Prerequisites

You have the DBM operator authorization Backup.

You have opened a service session.

Syntax

recover_check <medium> <type> [ExternalBackupID <external_backup_ID>] [<nnn>] [UNTIL <date> <time>]

<medium> | Name of the backup medium; this must be defined beforehand (Defining or Changing a Backup Medium)
<type> | Type of Backup: DATA (Complete data backup), PAGES (Incremental data backup) or LOG (Log Backup)

Options

ExternalBackupID <external_backup_ID> | To check a backup created with an external backup tool, enter a backup ID name that the external tool will recognize.
<nnn> | Actual backup version on the backup media that is being checked; relevant only for media of type FILE
UNTIL <date> <time> | For log backups you can enter an exact time up to which the log backups are to be checked.

The backup specified is just checked, not restored.

Reply

OK<NL>
Returncode              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volume Count            [<value>]<NL>
Mediumname              [<value>]<NL>
Location                [<value>]<NL>
Errortext               [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>
Database ID             [<value>]<NL>
Max Used Data Page      [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

Reply in the Event of an Error

If an error occurs during the process, you will receive a reply in the following format:

ERR<NL>
<errcode>, <err_description><NL>
[<extended_description><NL>]

<errcode> | Error message number See also: Messages
<err_description> | Description of the error
<extended_description> | Cause of the error

The following errors may occur:

<errcode> | <err_description> | Explanation
-24927 | ERR_TOOLCHK: the external backup tool was not found | The external backup tool could not be found or has been installed incorrectly.
-24926 | ERR_MEDIUMCHK: the medium cannot be used with an external backup tool | The medium specified cannot be used with the backup tool the medium name refers to (Defining and Changing a Backup Medium).
-24925 | ERR_PREPARE: prepare of the backup operation failed | The preparations necessary to use the backup tool were not made correctly.
-24924 | ERR_DBREQ: cannot start database kernel request | The database instance was unable to start the check.
-24923 | ERR_TOOLREQ: cannot start external backup tool correctly | The backup tool could not be started correctly.
-24922 | ERR_OPCHK: cannot check state of backup operation | Unable to check the status of the database instance or the backup tool.
-24921 | ERR_POSTOP: cannot finish backup operation correctly | Although the backup was successful, the post-processing steps required could not be performed.
-24920 | ERR_BACKUPOP: backup operation was unsuccessful | The check failed due to a problem with the database or the backup tool.
-24919 | ERR_CLEANUP: cannot clean up correctly after backup operation | Although the check was successful, the temporary system resources that were used could not be freed up again.


Commands for Restoring (MaxDB: Database Manager CLI)

Commands for Restoring

Use

The Database Manager supports the restoring of the database instance after hardware errors. The last state of the database is restored. A prerequisite for this is that all the data specified in the backup history is available.

To obtain the highest possible throughput of data, full and incremental data backups can be imported from a number of backup media simultaneously. The number of parallel backup media used for the restore does not depend on the number of parallel backup media used to make the backup originally. Even a backup made to single medium plus continuation media can be imported in parallel.

You define the maximum number of backup media that can be imported concurrently using the parameter MAX_BACKUP_DEVS. The use of up to 32 tape devices allows you to reduce restore times considerably.

Prerequisites

Note the operator authorizations required for the particular DBM commands.

The prerequisite for executing all other restore commands is to execute the command to restore the database instance first.

Syntax

Displaying Current Information About the Database Instance | db_restartinfo
Displaying the Current Restore Status | recover_state
Terminating an Interrupted Restore or Backup Check | recover_cancel
Continuing a Parallel Restore or Backup Check | recover_ignore
Restoring the Database Instance | recover_start
Restoring the Parameter File from a Data Backup | recover_config
Restoring a Database Instance with Initialization | db_activate RECOVER
Recreating a Damaged Index | sql_recreateindex
Restoring with External Backup Tools | ---
Restoring or Checking a Backup with Succeeding Medium | recover_replace


Displaying Current Information About the Database Instance (MaxDB: Database Manager CLI)

Displaying Current Information About the Database Instance

Use

You can display the current status of the database instance after importing a backup. Information is output on the state of the log and the ability of the database instance to Restart.

Prerequisites

You have the DBM operator authorization Recovery.

You have executed the command for restoring a database instance.

Syntax

db_restartinfo

dbmcli -d myDB -u dbm,dbm db_restartinfo

OK
Used LOG Page           10636
First LOG Page          8640
Restartable             1
Id Restart Record       P46643:DB_20010629_115558
Id LOG Info             P46643:DB_20010629_115558
Consistent              1

Reply

OK<NL>
Used LOG Page           <number><NL>
First LOG Page          <number><NL>
Restartable             (1|0)<NL>
Id Restart Record       <id><NL>
Id LOG Info             <id><NL>
Consistent              (1|0)<NL>

Values for the Individual Fields of the Reply

Used LOG Page | Next log page to be used after restarting
First LOG Page | Oldest available log page
Restartable | Restartable (1 = yes, 0 = no)
Id Restart Record | Identifier of the restart record for the database instance
Id LOG Info | Identifier for the database instance log
Consistent | Consistency of the database instance, that is, can be restarted without log ( 1 = yes, 0 = no)

In the event of errors, see Reply Format.


Displaying the Current Restore Status (MaxDB: Database Manager CLI)

Displaying the Current Restore Status

Use

You display information about the current status of the restore. You can execute this command while a backup of a database instance is being restored.

Prerequisites

You have the DBM operator authorization Recovery.

You have executed the command for restoring a database instance. The operation was interrupted.

Syntax

recover_state

Reply

OK<NL>
Return code <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volumes [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Error text [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | Only for data backup: backup is internally consistent
First LOG Page | For data backup: First page of the log backup to be read For log backup: first page saved in log
Last LOG Page | Only for log backup: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Highest page number assigned (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Terminating an Interrupted Restore or a Backup Check (MaxDB: Database Manager CLI)

Terminating an Interrupted Restore or a Backup Check

Use

You definitively terminate an interrupted restore or a backup check.

Prerequisites

You have the DBM operator authorization Backup.

You have executed the command for Restoring the Database Instance or for Checking a Backup. The operation was interrupted.

Syntax

recover_cancel

Reply

In the reply to this command only the field Returncode is assigned a value.

OK<NL>
Returncode <value>

See also: Messages

In the event of errors, see Reply Format.


Continuing the Parallel Restore or Backup Check (MaxDB: Database Manager CLI)

Continuing the Parallel Restore or Backup Check

Use

You continue reading in from the other backup media. The reply to this command gives you information about the import of the backup.

However, you see this information only if the backup has been imported completely, or if the backup was interrupted. This command may, therefore, take a long time to execute.

Prerequisites

You have the DBM operator authorization Backup.

You have started restoring a database instance by reading data from several media simultaneously. The procedure was interrupted because at least one medium no longer has a succeeding backup medium.

Syntax

recover_ignore

Reply

OK<NL>
Returncode              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volumes                 [<value>]<NL>
Medianame               [<value>]<NL>
Location                [<value>]<NL>
Errortext               [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>
Database ID             [<value>]<NL>
Max Used Data Page      [<value>]<NL>

In particular, analyze the Returncode reply field, which contains a numeric value supplied by the kernel.

See also: Messages

If it is clear from the message number that the recovery was only interrupted, the session must be continued with the continuation command (recover_ignore) or terminated (recover_cancel).

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the Database Instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | Only for log backup: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Recovering a Database Instance (MaxDB: Database Manager CLI)

Recovering a Database Instance

Use

When you recover a database instance, you import backups and recover the database status that they contain. To do so, you first import a complete data backup, followed by the related log backups. You can use the option UNTIL to specify the time up to which the log backups are to be imported from the backup medium.

If the log volumes for the database instance are available and undamaged and still contain the log from the time of the complete data backup, use the command recover_start only to import the complete data backup. Then start the database instance and create the database instance from the log volume of the database instance (see also: Transferring to the ONLINE Operational State). If you specify the option -u | -until, you recover the database instance up to the specified time.

If you used an external backup tool to make these backups, use that tool to recover the database instance. Proceed as described in Restoring with External Backup Tools. Otherwise, use the description of the command recover_start, below.

The reply to this command gives you information about the import of the backup. However, you see this information only if the backup has been imported completely, or if the backup was interrupted. This command may, therefore, take a long time to execute.

If automatic log backups were activated before the recovery was started, they are not reactivated automatically after the recovery.

To reactivate the log backups, execute the command for activating automatic log backups.

Prerequisites

You have the DBM operator authorization Recovery.

You have opened a database session (Opening a Database Session).

Syntax

recover_start <medium> <type> [ExternalBackupID <external_backup_ID>] [<nnn>] [UNTIL <date> <time>] [AUTOIGNORE]

<medium> | Backup medium from which you want to import the backup. When you restore a backup made on multiple parallel backup media (a parallel backup), enter the name of the media group here.
<type> | Type of backup to be imported: DATA (complete data backup), PAGES (incremental data backup), or LOG (log backup)

Options

ExternalBackupID <external_backup_ID>

To restore a backup created with an external backup tool, enter a backup ID here that the external backup tool can recognize as the backup.

<nnn>

Actual backup version on the backup medium that you want to read; relevant only for media of type FILE.

UNTIL <date> <time>
<date> ::= <yyyymmdd>
<time> ::= <hhmmss>

You can specify a time (year, month, day, hour, minutes, seconds) up to which you want to import log backups.

AUTOIGNORE

In the case of a parallel restore, the process is automatically continued by the system (Continuing a Parallel Restore).

To avoid receiving error messages, note the media naming conventions (see Defining or Changing a Backup Medium).

Logging on to the database manager CLI as operator DBM with password DBM, opening a database session with the database instance myDB, recovering the database instance from the backup created with Networker on the backup medium NSRPages (complete data backup type with the external backup ID 9025):

dbmcli –u dbm,dbm –uDBS –d myDB recover_start NSRPages DATA ExternalBackupID 9025

Reply

OK<NL>
Return code <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volumes [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Error text [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | Only for data backup: backup is internally consistent
First LOG Page | For data backup: First page of the log backup to be read For log backup: first page saved in log
Last LOG Page | Only for log backup: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

Reply in the Event of an Error

If an error occurs while you are using an external backup tool, you receive a reply in the following format:

ERR<NL>
<errcode>, <err_description><NL>
[<extended_description><NL>]

<errcode> | Error message number See also: Messages
<err_description> | Description of the error
<extended_description> | Cause of the error

The following errors may occur:

<errcode> | <err_description> | Explanation
-24927 | ERR_TOOLCHK: the external backup tool was not found | The external backup tool could not be found or has been installed incorrectly.
-24926 | ERR_MEDIUMCHK: the medium cannot be used with an external backup tool | The specified backup medium cannot be used with the backup tool to which the medium name refers (Defining and Changing a Backup Medium ).
-24925 | ERR_PREPARE: prepare of the backup operation failed | The preparations necessary to use the backup tool were not made correctly.
-24924 | ERR_DBREQ: cannot start database kernel request | The database instance was unable to start the restore operation.
-24923 | ERR_TOOLREQ: cannot start external backup tool correctly | The backup tool could not be started correctly.
-24922 | ERR_OPCHK: cannot check state of backup operation | Unable to check the status of the database instance or the backup tool.
-24921 | ERR_POSTOP: cannot finish backup operation correctly | Although the recovery was successful, the post-processing steps required could not be performed.
-24920 | ERR_BACKUPOP: backup operation was unsuccessful | The recovery failed due to a problem with the database or the backup tool.
-24919 | ERR_CLEANUP: cannot clean up correctly after backup operation | Although the recovery was successful, the temporary system resources used could not be freed up again.


Restoring the Parameter File from a Data Backup (MaxDB: Database Manager CLI)

Restoring the Parameter File from a Data Backup

Use

You recover the parameter file from the data backup stored on a backup medium.

All parameters except for SERVERDB are taken over. The parameter SERVERDB is converted to the value of the current database instance.

The parameter file is stored under the name of the current database instance.

Prerequisites

You have the DBM operator authorization Recovery.

You have opened a service session.

You have executed the command for restoring a database instance.

Syntax

recover_config <medium>

Reply

OK<NL>
Return code              <value><NL>
Date                    [<value>]<NL>
Time                    [<value>]<NL>
Server                  [<value>]<NL>
Database                [<value>]<NL>
Kernel Version          [<value>]<NL>
Pages Transferred       [<value>]<NL>
Pages Left              [<value>]<NL>
Volume Count            [<value>]<NL>
Medianame               [<value>]<NL>
Location                [<value>]<NL>
Error text              [<value>]<NL>
Label                   [<value>]<NL>
Is Consistent           [<value>]<NL>
First LOG Page          [<value>]<NL>
Last LOG Page           [<value>]<NL>
DB Stamp 1 Date         [<value>]<NL>
DB Stamp 1 Time         [<value>]<NL>
DB Stamp 2 Date         [<value>]<NL>
DB Stamp 2 Time         [<value>]<NL>
Page Count              [<value>]<NL>
Devices Used            [<value>]<NL>
Database ID             [<value>]<NL>
Max Used Data Page      [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Recovering a Database Instance with Initialization (MaxDB: Database Manager CLI)

Recovering a Database Instance with Initialization

Use

When you recover a database instance, you import backups and recover the database status that they contain. To do so, you first import a complete data backup, followed by the related log backups. You can use the option UNTIL to specify the time up to which the log backups are to be imported from the backup medium.

In contrast to the command recover_start (Recovering the Database Instance), the database instance is initialized, which means the volumes configured in the parameter file are created (if they are not available) and the data in the existing log volume is deleted. Note that if you have not backed up this log data explicitly on a backup medium, this log data is deleted permanently.

If automatic log backups were activated before the restoration was started, they are not reactivated automatically after the recovery.

To reactivate the log backups, execute the command for activating automatic log backups.

If you used an external backup tool to make these backups, use that tool to recover the database instance. Proceed as described in Restoring with External Backup Tools. Otherwise, use the description below for the command recover_start.

The reply to this command gives you information about the import of the backup. However, you see this information only if the backup has been imported completely, or if the backup was interrupted. This command may, therefore, take a long time to execute.

Prerequisites

You have the server authorization Recovery.

You have opened a database session (Opening a Database Session).

Syntax

db_activate RECOVER <medium> <type> [ExternalBackupID <external_backup_ID>] [<nnn>] [UNTIL <date> <time>] [AUTOIGNORE]

<medium> | Backup medium from which you want to import the backup. When you restore a backup made on multiple parallel backup media (a parallel backup), enter the name of the media group here.
<type> | Type of backup to be imported: DATA (complete data backup), PAGES (incremental data backup), or LOG (log backup)

Options

ExternalBackupID <external_backup_ID>

To restore a backup created with an external backup tool, enter a backup ID here that the external backup tool can recognize as the backup.

<nnn>

Actual backup version on the backup medium that you want to read; relevant only for media of type FILE.

UNTIL <date> <time>
<date> ::= <yyyymmdd>
<time> ::= <hhmmss>

You can specify a time (year, month, day, hour, minutes, seconds) up to which you want to import log backups.

AUTOIGNORE

If you are restoring data in parallel, the process is automatically continued by the system (Continuing a Parallel Restore).

To avoid receiving error messages, follow the media naming conventions (see also: Defining or Changing a Backup Medium).

Logging on to the database manager CLI as operator DBM with password DBM, opening a database session with the database instance myDB, creating the database instance from a backup created with NetWorker on the backup medium NSRPages (complete data backup type with the external backup ID 9025):

dbmcli –u dbm,dbm –uDBS –d myDB db_activate RECOVER NSRPages DATA ExternalBackupID 9025

Reply

OK<NL>
Return code <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volumes [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Error text [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database instance
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | Only for data backup: backup is internally consistent
First LOG Page | For data backup: First page of the log backup to be read For log backup: first page saved in log
Last LOG Page | Only for log backup: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

Reply in the Event of an Error

If an error occurs while you are using an external backup tool, you receive a reply in the following format:

ERR<NL>
<errcode>, <err_description><NL>
[<extended_description><NL>]

<errcode> | Error message number See also: Messages
<err_description> | Description of the error
<extended_description> | Cause of the error

The following errors may occur:

<errcode> | <err_description> | Explanation
-24927 | ERR_TOOLCHK: the external backup tool was not found | The external backup tool could not be found or has been installed incorrectly.
-24926 | ERR_MEDIUMCHK: the medium cannot be used with an external backup tool | The specified backup medium cannot be used with the backup tool to which the medium name refers ( Creating or Changing a Backup Medium ).
-24925 | ERR_PREPARE: prepare of the backup operation failed | The preparations necessary to use the backup tool were not made correctly.
-24924 | ERR_DBREQ: cannot start database kernel request | The database instance was unable to start the restore operation.
-24923 | ERR_TOOLREQ: cannot start external backup tool correctly | The backup tool could not be started correctly.
-24922 | ERR_OPCHK: cannot check state of backup operation | Unable to check the status of the database instance or the backup tool.
-24921 | ERR_POSTOP: cannot finish backup operation correctly | Although the recovery was successful, the post-processing steps required could not be performed.
-24920 | ERR_BACKUPOP: backup operation was unsuccessful | The recovery failed due to a problem with the database or the backup tool.
-24919 | ERR_CLEANUP: cannot clean up correctly after backup operation | Although the recovery was successful, the temporary system resources used could not be freed up again.


Recreating a Damaged Index (MaxDB: Database Manager CLI)

Recreating a Damaged Index

Use

You use this command to recover the specified indexes.

Indexes can become damaged for various reasons. To save time, indexes are not maintained when a database instance is restored and are given the attribute bad. They must be recovered explicitly.

Indexes can be damaged by hardware or software problems. If the database kernel identifies a defect index, the index is marked as bad. It is then no longer available to the optimizer during the strategy determination process.

The database software ignores damaged indexes. For this reason, they cannot cause errors, but do impair the performance of the database instance.

Prerequisites

You have the DBM operator authorization AccessSQL.

You have opened an SQL session.

Syntax

sql_recreateindex <scheme>.<table>.<index>

<scheme> | Scheme
<table> | Table name
<index> | Index name or field name

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Recovering a Damaged Volume (MaxDB: Database Manager CLI)

Recovering a Damaged Volume

Use

If you are running the log volumes of a database instance in mirrored form, and a single log volume fails while the database is running, there are functions available that enable you to recover the failed volume.

Entries that were written to the intact volume only while the damaged volume was out of action are not copied.

Note that the mirrored log volume is only secure once the recovered volume is operating again. You should therefore backup the log entries that only exist once using a log backup (Backing up the Database Instance).

Prerequisites

You have the DBM operator authorization Recovery.

You are operating the database instance with mirrored log volumes. ( LOG_MODE: DUAL).

You have opened a utility session.

You have executed the command for restoring a database instance.

Syntax

recover_volume <volno> [<volmode>]

<volno> | Number of the volume
<volmode> | Here, LOG is the only possible entry.

With this command, you return a damaged volume of a volume pair to operation.

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Restoring with External Backup Tools (MaxDB: Database Manager CLI)

Restoring with External Backup Tools

The Database Manager supports the use of external backup tools for complete and incremental data backups, as well as for the archiving of log backups.

For information on which external backup tools are supported by MaxDB, see External Backup Tool in the Database Administration documentation.

Using the Backup Tools

Start the operation for restoring the database instance from the Database Manager CLI. The naming conventions for external backup media enable the program to recognize the external backup tool and start it.

Prerequisites

You have configured your SAP DB software installation for the external backup tool you want to use (see Integration of External Backup Tools).

When you restore data, NetWorker requires the exact name of the relevant backup pipe. This means that the media group must be configured in exactly the same way it was when you backed up the data. The backup media must also be in the same order in the media group.

Procedure

First determine the external backup ID for the required backup (Fetching External Backup IDs, Displaying External Backup IDs). The Database Manager uses this ID to identify the backup that is to be restored.

The number of media in a group of parallel backup media must correspond to the number of media used to create the backup.

If a deadlock occurs when you restore parallel media, you must use the Database Manager to import the backup in sequence (that is, each individual medium in the media group).

Proceed as described in Restoring the Database Instance.


Restoring or Checking a Backup with a Succeeding Medium (MaxDB: Database Manager CLI)

Restoring or Checking a Backup with a Succeeding Medium

Use

You specify the next medium from which reading in the backup is to continue. The reply to this command gives you information about the import of the backup. However, you see this information only if the backup has been imported completely, or if the backup was interrupted. This command may, therefore, take a long time to execute.

Prerequisites

You have the DBM operator authorization Backup.

You have executed the command for restoring a database instance. The procedure was interrupted, because all backup data has been read from one backup medium.

Syntax

recover_replace <medium> [ExternalBackupID <ext_backup_ID>] [<loc> [<nnn>]]

<medium>

Medium from which the backup is to be read.
When restoring a backup made on several media at the same time, you must enter the name of the group of parallel backup media here.

Options

ExternalBackupID <external_backup_ID> | To restore a backup created with an external backup tool, enter a backup ID name here that the external backup tool can recognize as the backup.
<loc> | Name of the device/the file in which the backup to be restored is stored. Operating system functions must be able to address the device/file using <loc>.
<nnn> | Actual backup version on the backup medium that is to be read; relevant only for a backup medium of the type FILE.

It is vital you follow the current media naming conventions (see Defining or Changing a Backup Medium) to avoid error messages.

Reply

OK<NL>
Returncode <value><NL>
Date [<value>]<NL>
Time [<value>]<NL>
Server [<value>]<NL>
Database [<value>]<NL>
Kernel Version [<value>]<NL>
Pages Transferred [<value>]<NL>
Pages Left [<value>]<NL>
Volumes [<value>]<NL>
Medianame [<value>]<NL>
Location [<value>]<NL>
Errortext [<value>]<NL>
Label [<value>]<NL>
Is Consistent [<value>]<NL>
First LOG Page [<value>]<NL>
Last LOG Page [<value>]<NL>
DB Stamp 1 Date [<value>]<NL>
DB Stamp 1 Time [<value>]<NL>
DB Stamp 2 Date [<value>]<NL>
DB Stamp 2 Time [<value>]<NL>
Page Count [<value>]<NL>
Devices Used [<value>]<NL>
Database ID [<value>]<NL>
Max Used Data Page [<value>]<NL>

In particular, analyze the Returncode reply field, which contains a numeric value supplied by the kernel.

See also: Messages: SAP

If it is clear from the message number that the recovery was only interrupted, the session must be continued with the continuation command (recover_replace) or terminated (recover_cancel).

Values for the Individual Fields of the Reply

Date | Date
Time | Time
Server | Name of the database server
Database | Name of the database
Kernel Version | Database kernel version
Pages Transferred | Number of pages transferred
Pages Left | Number of pages still to be transferred
Volumes | Number of backup media used
Medianame | Name of the backup medium
Location | File or device name
Errortext | Error message text
Label | Backup ID
Is Consistent | For data backup only: backup is internally consistent
First LOG Page | For data backup: first page of log backup to be read For log backup: first page saved in log
Last LOG Page | For log backup only: last page saved in log
DB Stamp 1 Date DB Stamp 1 Time | Time stamp for first page of log backup
DB Stamp 2 Date DB Stamp 2 Time | Time stamp for last page of log backup
Page Count | Total number of pages saved
Devices Used | Number of backup devices used
Database ID | Database ID used to identify data and log backups that belong together
Max Used Data Page | Maximum page number (indication of minimum database size when backup is imported)

In the event of errors, see Reply Format.


Displaying Database Information (MaxDB: Database Manager CLI)

Displaying Database Information

Use

For the daily operation of the database instance, there are commands available to you with which you can display current information about the database instance.

Prerequisites

Note the operator authorizations required for the particular DBM commands.

Overview of the Commands to Display Database Information


Overview of the DBM Commands for Displaying Database Information (MaxDB: Database Manager CLI)

Overview of the DBM Commands for Displaying Database Information

Displaying the Keywords for Information About the Database Instance | show_list
Displaying the Operational State of the Database Instance | db_state
Displaying Information About the Database Instance | show
Scrolling in the Information About the Database Instance | show_next


Displaying the Keywords for Information About the Database Insta (MaxDB: Database Manager CLI)

Displaying the Keywords for Information About the Database Instance

Use

You display the list of all keywords <keyword> for information about the database instance. You then use the command show <keyword> (Displaying Information About the Database Instance) to display the desired information.

Prerequisites

You have the DBM operator authorization DBInfoRead.

Syntax

show_list


Displaying the Operational State of the Database Instance (MaxDB: Database Manager CLI)

Displaying the Operational State of the Database Instance

Use

You display the operational state of the database instance.

Prerequisites

You have the DBM operator authorization DBInfoRead.

Syntax

db_state

Reply

OK<NL>
State<NL>
(ONLINE|ADMIN|OFFLINE|UNKNOWN|STOPPED INCORRECTLY)

State | Description
ONLINE | The database instance is ready.
ADMIN | The database instance has been shutdown to the ADMIN operational state. Only special administrative tasks can be performed.
OFFLINE | The database instance has not been started.
STOPPED INCORRECTLY | Only with a UNIX operating system: The database stopped after an error.
UNKNOWN | The operational state cannot be determined.


Displaying Information About the Database Instance (MaxDB: Database Manager CLI)

Displaying Information About the Database Instance

Use

You display information about the database instance; about statistics, the operational state, tasks, and so on. To do this, the show command obtains and outputs information from program x_cons.

Prerequisites

You have the DBM operator authorization DBInfoRead.

Syntax

show <command>

Possible values for <command>

IO | Input/output activities in regular database operation
AIO | Input/output activities for data backups
STORAGE | Configuration and current status of the various storage areas
TASKS | List of available tasks
ACTIVE [DW|SV|US] | Active tasks for [Datawriter-Task|Server-Task|User-Task]
RUNNABLE [DW|SV|US] | Runnable tasks (waiting for CPU)
T_C [DW|SV|US|Tx] | Task-specific information on [Datawriter_Task | Server Task | User Task | Task No.x}
VERSIONS | Current variant of the database kernel and the runtime environment
REGIONS | Information about the critical regions used in the kernel
STATE | Operational state of the database instance
RTE | Runtime environment
QUEUES | Queues of runnable tasks (waiting for CPU)
SUSPENDS | Information about suspend states anywhere in the overall system
SLEEP | The CPU load from user kernel threads measured by the database kernel.
THRD_TIMES | Information from the system about the CPU load from user kernel threads (Microsoft Windows NT operating system only)
ALL | All of the information provided by the database console

Reply

OK<NL>
[CONTINUE]<NL>
<info_record><NL>
<info_record><NL>

Continue | More result data ready
<info_record> | Information


Scrolling in the Information About the Database Instance (MaxDB: Database Manager CLI)

Scrolling in the Information About the Database Instance

Use

You display additional information about the database instance.

Prerequisites

You have the DBM operator authorization DBInfoRead.

You have entered a command to display information about the database instance. The keyword CONTINUE in the reply indicates that further information is available; this information has not yet been output because of the limited size of the reply memory.

Syntax

show_next

Reply

OK<NL>
[CONTINUE | END]<NL>
<info_record><NL>
<info_record><NL>

Values in the individual fields of the reply

END | The requested information on the database instance has been transferred in full. The file is closed automatically.
Continue | More result data is available but was not transferred due to the limited size of the reply memory. You can call up this data by entering the show_next command again.
<info_record> | Information


Analyzing the Database Instance (MaxDB: Database Manager CLI)

Analyzing the Database Instance

Use

You have the option of performing various analyses of the database instance.

The Database Manager gives you the following options:

Database Trace Functions

Accessing the Database Analyzer Program

Accessing Database Files Accessing Events

Prerequisites

Note the server authorizations required for the particular DBM commands.

See also:

Overview of DBM Commands for Analyzing the Database Instance


Overview of DBM Commands for Analyzing the Database Instance (MaxDB: Database Manager CLI)

Overview of DBM Commands for Analyzing the Database Instance

Activating an Event | event_set
Displaying the Diagnosis History | diag_histlist
Displaying Options for the Text Version of the Database Trace | trace_protopt
Displaying the Logged Activities of the Database Trace | trace_show
Calling the Database Analyzer | dban_start
Deactivating the Database Trace | trace_off
Editing Log Files of the Database Instance | file_operation
Ending an Event Session | event_release
Ending the Database Analyzer | dban_stop
Scrolling Through a Database File | file_getnext
Deactivating an Event | event_delete
Activating the Database Trace | trace_on
Determining the Status of the Database Analyzer | dban_state
Creating the Text Version of the Database Trace | trace_prot
Creating a List of Events and Statuses | event_list
Creating a List of the Database Files | file_getlist
Deleting the Content of the Database Trace | trace_clear
Opening a Database File | file_getfirst
Packing Database Files | diag_pack
Backing Up a Database File | file_backup
Waiting for an Event | event_wait
Restoring a Database File | file_restore


Database Trace Functions (MaxDB: Database Manager CLI)

Database Trace Functions

Use

Use this function only when told to do so by Support. The database trace is not required for normal database operation.

Using the database trace, you log selected activities of the database instance in detail. You can use the DBM commands for database trace functions to activate, deactivate and evaluate the database trace.

The following commands are available:

Displaying Options for the Text Version of the Database Trace | trace_protopt
Displaying the Logged Activities of the Database Trace | trace_show
Deactivating the Database Trace | trace_off
Activating the Database Trace | trace_on
Creating the Text Version of the Database Trace | trace_prot
Deleting the Contents of the Database Trace | trace_clear

Prerequisites

Note the server authorizations required for the particular DBM commands.


Displaying Command Options for Database Trace Text Version (MaxDB: Database Manager CLI)

Displaying Command Options for Database Trace Text Version

Use

Use this DBM command for the database trace function only when told to do so by Support. The database trace is not required for normal database operation.

You display which command options are permitted for creating the text version of the current database trace to restrict the trace output of the internal database components. You receive a list with the names and description of these command options.

Prerequisites

You have the server authorization DBInfoRead or DBFileRead.

Syntax

trace_protopt

dbmcli -d DB -u dbm,dbm trace_protopt

OK
name,option
a Order Interface (AK)
b Record Interface (BD)
k Show Message Block (KB)
m Message Block
e No Entrypos Output
s Strategy
t Time
x Switch Output (Slow Kernel)

a | The trace output of the internal database component order interface is copied to the text file
b | The trace output of the internal database component record interface is copied to the text file
k | The trace output of the internal database component table interface is copied to the text file
m | The internal data structure with the name message block is transferred to the text file
e | The numbers of the trace page and the buffer's position in the page are copied to the text file for the order interface and the message block
s | Information about the processing strategy is copied to the text file
t | The results of the internal time measurement are copied to the text file
x | Additional trace output is copied to the text file

Reply

OK<NL>
name,option<NL>
<name>,<option><NL>
<name>,<option><NL>
...


Displaying the Logged Activities of the Database Trace (MaxDB: Database Manager CLI)

Displaying the Logged Activities of the Database Trace

Use

Use this DBM command for the database trace function only when told to do so by Support. The database trace is not required for normal database operation.

You display which activities of the database instance are currently logged.

All activities that can be logged are displayed under the column name Description. The word ON appears in the State column for activities that are actually currently being logged.

If you specify the option verbose, the system displays an extended description of the database trace.

Prerequisites

You have the server authorization DBInfoRead or DBFileRead.

Syntax

trace_show [verbose]

dbmcli -d DB -u dbm,dbm trace_show

OK
Name State Level Description
DEFAULT OFF - Default
INDEX OFF - Index
LOCK ON - Lock
LONG OFF - Long
PAGES OFF - Pages
STANDARD OFF - Standard
TABLE OFF - Table
OBJECT OFF - Objects
OBJECTADD OFF - Objects add
OBJECTGET OFF - Objects get
OBJECTALTER OFF - Objects alter
OBJECTFREE OFF - Objects free
SELECT OFF - Select
INSERT OFF - Insert
UPDATE OFF - Update
DELETE OFF - Delete
ORDER OFF - Order
OPTIMIZER OFF - Optimize
TIME OFF - Time
CHECK OFF - Check
COMMANDS ON - Commands
TOPICCONVERTER OFF 0 Topic Converter
TOPICDATA OFF 0 Topic Data
TOPICFRAMECTRL OFF 0 Topic Framecontrol
TOPICLOG OFF 0 Topic Log
TOPICIOMAN ON 7 Topic I/O manager
TOPICMEMORY OFF 0 Topic Memory
TOPICVOLUME OFF 0 Topic Devspace
TOPICRUNTIME OFF 0 Topic Runtime
TOPICALLOCATOR OFF 0 Topic Allocator
CHECKCONVERTER OFF 0 Check Converter
CHECKDATA OFF 0 Check Data
CHECKFRAMECTRL OFF 0 Check Framecontrol
CHECKLOG OFF 0 Check Log
CHECKIOMAN OFF 0 Check I/O manager
CHECKMEMORY OFF 0 Check Memory
CHECKVOLUME ON 3 Check Devspace
CHECKRUNTIME OFF 0 Check Runtime
CHECKALLOCATOR OFF 0 Check Allocator

...

Reply

OK<NL>
name State Level Description<NL>
<name> (ON|OFF) (-|<level>) <short description>[,<long description>]<NL>
<name> (ON|OFF) (-|<level>) <short description>[,<long description>]<NL>
...


Deactivating the Database Trace (MaxDB: Database Manager CLI)

Deactivating the Database Trace

Use

The database trace is not required for normal database operation. Therefore you should activate and then deactivate it only when told to do so by Support, because the writing of a database trace has a detrimental effect on the performance of your database system.

You determine which activities of the database instance should no longer be logged or completely deactivate the database trace.

You specify which activities should no longer be logged using the command option activity_list. Separate multiple activities by a space.

By specifying ALL, you deactivate the log function for all activities, and therefore completely deactivate the database trace.

You can view the command options currently active with a description using the command trace_show verbose (Displaying the Logged Activities of the Database Trace).

Prerequisites

You have the server authorization DBInfoRead or DBFileRead.

Syntax

trace_off <activity_list> | ALL
<activity_list> :: = <activity> | <activity> <activity_list>

Deactivate the database trace for the areas LOCK and TOPICIOMAN

dbmcli -d a74 -u dbm,dbm trace_off LOCK TOPICIOMAN

OK

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Activating the Database Trace (MaxDB: Database Manager CLI)

Activating the Database Trace

Use

Use this command only when told to do so by Support. The database trace is not required for normal database operation.

Follow Support’s instructions about which activities should be logged.

You activate the database trace with this command. In this way, selected database kernel activities are logged.

The database trace is stored in the binary file knltrace in the run directory of the database instance. To evaluate the file, you first create the text version of the database trace (Creating the Text Version of the Database Trace).

The file_id (see also: Opening a Database File ) for opening this binary version is KNLTRC.

You specify which activities are to be logged using the option activity_list. Separate multiple activities by spaces.
The special option ALLactivates the logging of all activities.

Some activities allow you to set a logging level between 1 and 9. This is optional. The Database Manager CLI default is Level 5.

Prerequisites

You have the server authorization DBInfoRead or DBFileRead.

Syntax

trace_on <activity_list> | ALL [<level>]

Activating the database trace for the areas
LOCK
COMMANDS
TOPICIOMAN Level 7
CHECKVOLUME Level 3

dbmcli -d a74 -u dbm,dbm trace_on LOCK COMMANDS TOPICIOMAN 7 CHECKVOLUME 3

OK

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Creating the Text Version of the Database Trace (MaxDB: Database Manager CLI)

Creating the Text Version of the Database Trace

Use

Use this command only when told to do so by Support. The database trace is not required for normal database operation.

You transfer the binary version of the database trace to the text version. You can use all values and combinations of values for option command options that you received as a reply when displaying the option for the text version of the database trace.

The binary version of the database trace has the file name knltrace and is stored in the run directory of the database instance (see also: Database Files).

Prerequisites

· You have the server authorization DBInfoRead or DBFileRead

· You have generated the database trace (Activating the Database Trace).

· You have determined the file ID of the database trace file (Creating a List of Database Files).

Syntax

trace_prot <option> | <option>...

Create the text version of the database trace for the areas
a - Order Interface and b - Record Interface:

dbmcli -d DB -u dbm,dbm trace_prot ab

OK

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Deleting the Contents of the Database Trace (MaxDB: Database Manager CLI)

Deleting the Contents of the Database Trace

Use

You delete the current contents of the database trace.

Use this DBM command to delete data that you no longer require from the database trace before you perform targeted logging of the database instance activities by activating the database trace.

Prerequisites

You have the server authorization DBInfoRead or DBFileRead.

Syntax

trace_clear

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Accessing the Database Analyzer Program (MaxDB: Database Manager CLI)

Accessing the Database Analyzer Program

Use

The Database Analyzer program is a tool for analyzing the database instance. It replaces the previous tools XWIZARD and XWIZTRC, and makes it easier to find out the causes of performance problems.

You can use the Database Analyzer irrespective of database instance type and the version of the database software.

It is possible to access the database instance from a remote server with this program.

You can use the following DBM commands to access the Database Analyzer:

Calling the Database Analyzer | dban_start
Ending the Database Analyzer | dban_stop
Determining the Status of the Database Analyzer | dban_state


Calling the Database Analyzer (MaxDB: Database Manager CLI)

Calling the Database Analyzer

Use

You call the Database Analyzer program in the Database Manager. The Database Manager then transfers the following to the Database Analyzer: the database names, the user data for the SYSDBA user, and any call options transferred with the DBM command.

If the Database Analyzer is already active, only its status is determined.

Syntax

dban_start [<options>]

Example

Call the Database Manager, log on to the database instance HOTELDB as the operator DBM with password DBM, call the Database Analyzer.

dbmcli -d HOTELDB -u DBM,DBM dban_start

Reply

You receive the output of the Database Analyzer.

Example of a Successful Call of the Database Analyzer

Example of an Error when Calling the Database Analyzer


Example of a Successful Call of the Database Analyzer (MaxDB: Database Manager CLI)

Example of a Successful Call of the Database Analyzer

Name of the database instance: a74

Name and operator password of the DBM operator: dbm,dbm

d:\v74>dbmcli -d a74 -u dbm,dbm dban_start

Reply:

OK
0,OK: everything works fine
0, Database Analyzer -d A74 -u *,* -state

SAP DB Database Analyzer, The Performance Analysis Tool, Version 7.4
Copyright (c) 1998-2002 by SAP AG

Used protocol directory: D:\V74\USR\wrk\A74\analyzer
Used configuration file: D:\V74\USR\env\dbanalyzer74.cfg

INFO 13: Database Analyzer active in directory "D:\V74\USR\wrk\A74\analyzer".

Database = A74
Node =
Rundirectory = D:\V74\USR\wrk\A74
Configfile = D:\V74\USR\env\dbanalyzer74.cfg
Protocoldirectory = D:\V74\USR\wrk\A74\analyzer
Interval = 900
Reconnect = false
ProcessID = 1884
SessionID = 657
Started = 2002-09-11 09:16:29

The Database Analyzer was successfully started or was already active.


Example of an Error when Calling the Database Analyzer (MaxDB: Database Manager CLI)

Example of an Error when Calling the Database Analyzer

Name of the database instance: a74

Name and operator password of the DBM operator: dbm,dbm

d:\v74>dbmcli -d a74 -u dbm,dbm dban_start

Reply:

ERR
-24964,ERR_EXECUTE: error in program execution
1,Database Analyzer -d A74 -u *,* -state

SAP DB Database Analyzer, The Performance Analysis Tool, Version 7.4
Copyright (c) 1998-2002 by SAP AG

ERROR 4: Cannot connect to database.

-709 [SAP AG][SQLOD32 DLL][SAP DB]Unable to connect to data source;-709 CONNECT:(database not running).

The Database Analyzer could not be started.
The system displays a description of the cause of the error.


Ending the Database Analyzer (MaxDB: Database Manager CLI)

Ending the Database Analyzer

Use

You exit the Database Analyzer program from the Database Manager. If it is not active, only its status is output.

Syntax

dban_stop

Example

Call the Database Manager, log on to the database instance HOTELDB as the operator DBM with password DBM, end the Database Analyzer.

dbmcli -d HOTELDB -u DBM,DBM dban_stop

Reply

You receive the output of the Database Analyzer.

Example of Ending the Database Analyzer Successfully

Example of Errors when Ending the Database Analyzer


Example of Ending the Database Analyzer Successfully (MaxDB: Database Manager CLI)

Example of Ending the Database Analyzer Successfully

Name of the database instance: a74

Name and operator password of the DBM operator: dbm,dbm

d:\v74>dbmcli -d a74 -u dbm,dbm dban_stop

Reply:

OK
0,OK: everything works fine
0, Database Analyzer -d A74 -u *,* -stop

SAP DB Database Analyzer, The Performance Analysis Tool, Version 7.4
Copyright (c) 1998-2002 by SAP AG

Used protocol directory: D:\V74\USR\wrk\A74\analyzer
Used configuration file: D:\V74\USR\env\dbanalyzer74.cfg

The Database Analyzer was successfully ended.


Examples of Errors when Ending the Database Analyzer (MaxDB: Database Manager CLI)

Examples of Errors when Ending the Database Analyzer

Name of the database instance: a74

Name and operator password of the DBM operator: dbm,dbm

d:\v74>dbmcli -d a74 -u dbm,dbm dban_stop

Response Example 1:

ERR
-24964,ERR_EXECUTE: error in program execution
1, Database Analyzer -d A74 -u *,* -stop

SAP DB Database Analyzer, The Performance Analysis, Version 7.4
Copyright (c) 1998-2002 by SAP AG

Used protocol directory: D:\V74\USR\wrk\A74\analyzer
Used configuration file: D:\V74\USR\env\dbanalyzer74.cfg

ERROR 20: Database Analyzer not active in directory "D:\V74\USR\wrk\A74\analyzer".

The Database Analyzer could not be ended.
ERROR 20 means that the Database Analyzer is not active.

Response Example 2:

ERR
-24964,ERR_EXECUTE: error in program execution
1,dbanalyzer -d A74 -u *,* -stop

SAP DB Database Analyzer, The Performance Analysis Tool, Version 7.4
Copyright (c) 1998-2002 by SAP AG

ERROR 4: Cannot connect to database.

-709 [SAP AG][SQLOD32 DLL][SAP DB]Unable to connect to data source;-709 CONNECT: (database not running).

The Database Analyzer could not be ended.
The system displays a description of the cause of the error.


Determining the Status of the Database Analyzer (MaxDB: Database Manager CLI)

Determining the Status of the Database Analyzer

Use

You determine whether the Database Analyzer is active.

Syntax

dban_state

Example

Call the Database Manager, log on to the database instance HOTELDB as the operator DBM with password DBM, request the status of the Database Analyzer.

dbmcli -d HOTELDB -u DBM,DBM dban_state

Reply

You receive the output of the Database Analyzer with the current status.

Example of Determining the Status Successfully

Example of an Error when Determining the Status


Example of Determining the Status Successfully (MaxDB: Database Manager CLI)

Example of Determining the Status Successfully

Name of the database instance: a74

Name and operator password of the DBM operator: dbm,dbm

d:\v74>dbmcli -d a74 -u dbm,dbm dban_state

Response Example 1:

OK
0,OK: everything works fine
0, Database Analyzer -d A74 -u *,* -state

SAP DB Database Analyzer, The Performance Analysis Tool, Version 7.4
Copyright (c) 1998-2002 by SAP AG

Used protocol directory: D:\V74\USR\wrk\A74\analyzer
Used configuration file: D:\V74\USR\env\dbanalyzer74.cfg

INFO 20: Database Analyzer not active in directory "D:\V74\USR\wrk\A74\analyzer".

The status was successfully determined. INFO 20 means that the Database Analyzer is not active.

Response Example 2:

OK
0,OK: everything works fine
0,dbanalyzer -d A74 -u *,* -state

SAP DB Database Analyzer, The Performance Analysis Tool, Version 7.4
Copyright (c) 1998-2002 by SAP AG

Used protocol directory: D:\V74\USR\wrk\A74\analyzer
Used configuration file: D:\V74\USR\env\dbanalyzer74.cfg

INFO 13: Database Analyzer active in directory "D:\V74\USR\wrk\A74\analyzer".

Database = A74
Node =
Rundirectory = D:\V74\USR\wrk\A74
Configfile = D:\V74\USR\env\dbanalyzer74.cfg
Protocoldirectory = D:\V74\USR\wrk\A74\analyzer
Interval = 900
Reconnect = false
ProcessID = 1896
SessionID = 639
Started = 2002-09-10 16:51:40

The status was successfully determined. INFO 13 means that the Database Analyzer is active. The system displays additional information.


Example of an Error when Determining the Status (MaxDB: Database Manager CLI)

Example of an Error when Determining the Status

Name of the database instance: a74

Name and operator password of the DBM operator: dbm,dbm

d:\v74>dbmcli -d a74 -u dbm,dbm dban_stop

Reply

ERR
-24964,ERR_EXECUTE: error in program execution
1, Database Analyzer -d A74 -u *,* -state

SAP DB Database Analyzer, The Performance Analysis, Version 7.4
Copyright (c) 1998-2002 by SAP AG

ERROR 4: Cannot connect to database.

-709 [SAP AG][SQLOD32 DLL][SAP DB]Unable to connect to data source;-709 CONNECT:(database not running).

The state could not be determined.
The system displays a description of the cause of the error.


Accessing Database Files (MaxDB: Database Manager CLI)

Accessing Database Files

Use

You can access the database files of the current database instance.

You can use the following DBM commands to do this.

Displaying the Diagnosis History | diag_histlist
Editing Log Files of the Database Instance | file_operation
Scrolling Through a Database File | file_getnext
Creating a List of the Database Files | file_getlist
Opening a Database File | file_getfirst
Packing Database Files | diag_pack
Backing Up a Database File | file_backup
Restoring a Database File | file_restore

Prerequisites

Take account of the server authorizations required for the respective DBM commands.


Displaying the Diagnosis History (MaxDB: Database Manager CLI)

Displaying the Diagnosis History

Use

You display the available diagnosis history.

If a database instance was not properly stopped, the system backs up certain database files when restarting the database instance. These files are required for the diagnosis of problems that occurred previously. The files are backed up by the system in a diagnosis backup and stored in the directory DIAGHISTORY in the run directory of the database instance (Database Manager default value). You can define this path using the parameter DIAG_HISTORY_PATH.

If you run the command without specifying the option <YYYYMMDDHHMMSS>, the system displays a list of all available diagnosis backups. These are listed with their time stamps and the paths under which the backups are stored. This means that you can also access the diagnosis backup using operating system resources.

If you enter the command again with the option <YYYYMMDDHHMMSS> (timestamp), the system displays the file IDs of the files belonging to the diagnosis backup. Using the file ID, you can display the contents of a database file (Opening a Database File).

Prerequisites

You have the DBM operator authorization DBFileRead.

Syntax

diag_histlist [<YYYYMMDDHHMMSS>]

Command without option specified

dbmcli -d DB -u dbm,dbmp diag_histlist

OK
20010706140709  d:\sapdb\usr\wrk\DB\DIAGHISTORY\A74_20010706_14-07-09
20010706162223  d:\sapdb\usr\wrk\DB\DIAGHISTORY\A74_20010706_16-22-23

Command with option specified

dbmcli -d DB -u dbm,dbmp diag_histlist 20010706162223

OK
DIAGHIST#20010706_16-22-23\knldiag
DIAGHIST#20010706_16-22-23\knldump
DIAGHIST#20010706_16-22-23\knltrace
DIAGHIST#20010706_16-22-23\rtedump

Reply

The result of the request depends on whether you specify the option <YYYYMMDDHHMMSS> (time stamp).

After Entering a Command Without an Option

If you do not specify a time stamp, the system displays a list of all available diagnosis backups.

OK<NL>
<YYYYMMDDHHMMSS> <directory><NL>

<YYYYMMDDHHMMSS> <directory><NL>

...

After Entering a Command with an Option

If you specify a time stamp, the system displays a list of the files that belong to the diagnosis backup.

OK<NL>
<file_id><NL>

<file_id><NL>

...

In the event of errors, see Reply Format.


Editing Log Files of the Database Instance (MaxDB: Database Manager CLI)

Editing Log Files of the Database Instance

Use

You are deleting part of the content of the log files of the database instance or complete files.

This command can be used for log files only and not for other database files. If you use the command on a file for which it is not valid, you generate the error
 -24996 ERR_PARAM - wrong parameters.

You specify the operation that you want to perform with the parameter OP.

Prerequisites

You have the DBM operator authorization DBFileRead.

You have used the command for creating the list of database files to find out the file ID of the file or group of files that you want to edit.

Syntax

file_operation <file_id> OP=DELETE [DATE=<yyyymmddhhmmss>] | OP=SHRINK DATE=<yyyymmddhhmmss>|LINE=<n>

<file_id>

Log file(s) of the database instance

OP=DELETE

The file(s) is/are deleted.

You can specify that all files that have not been changed since the specified date, DATE=<yyyymmddhhmmss>, are to be deleted.

OP=SHRINK

Part of the content of the file is deleted.

If you also specify the parameter DATE=<yyyymmddhhmmss>, all lines that were written before the specified date are deleted.

If, instead, you specify the parameter LINE=<n>, the contents of the file are reduced to <n> lines. The <n> lines that were written most recently are retained.

Reply

The system outputs an OK message.

In the event of errors, see Reply Format.


Scrolling Through a Database File (MaxDB: Database Manager CLI)

Scrolling Through a Database File

Use

You are requesting the rest of the content of an opened database file. Use the <file_handle> displayed by the system when you open the database file.

Prerequisites

You have opened a database file. The keyword CONTINUE in the reply shows that you have not yet read the whole file.

You have the DBM operator authorization DBFileRead.

You have determined the file ID of the file (Creating a List of the Database Files).

Syntax

file_getnext <file_id> <file_handle>

Reply

Output in ASCII Mode

OK<NL>
[CONTINUE|END]<NL>
<file_length>:20<data_length>:20<NL>
<data><NL>
<data><NL>
...

Output in Binary Mode

OK<NL>
[CONTINUE|END]<NL>
<file_length><data_length><NL>
<data> <NL>

Values for the Individual Fields of the Reply

END | Contents of the file have been completely transferred, file is automatically closed
CONTINUE | File has additional entries that have not been transferred due to the limited size of the reply memory. Call these by entering the command used above again
<file_length> | File length
<data_length> | Data length
<data> | Data value

The total length of file is not determined again and is, therefore, set to 0.


Creating a List of the Database Files (MaxDB: Database Manager CLI)

Creating a List of the Database Files

Use

You request a list of the database files of the current database instance.

You determine the scope of the displayed file list by using the parameter <list_level>.

Possible values for <list_level>:

0 | Default value of the Database Manager CLI, display the most important files
1 | Display all files

Prerequisites

You have the DBM operator authorization DBFileRead.

Syntax

file_getlist <list_level>

Only those files are listed that are actually available. The list may therefore vary with the state of the database instance.

Reply

The system displays an OK message. Then it lists the database files currently available.

OK
key_name,mode,size,date,time,comment,file_name
<file_id> (ASCII|BINARY) <file_lengthe> <date> <time> <comment> <file_name>
<file_id> (ASCII|BINARY) <file_length> <date> <time> <comment> <file_name>
...

Values for the Individual Fields of the Reply

file_id | Key identifying name of a database file
file_length | Size of database file
date | Date last changed
time | Time last changed
comment | Additional information
file_name | File name


Opening a Database File (MaxDB: Database Manager CLI)

Opening a Database File

Use

You open the database file specified under <file_id> and transfer the first block. Using the <file_id>, the Database Manager determines the actual name of the file and whether it is a binary or text file.

File access using this command is limited to the database files. For this reason this command does not necessitate logging on to the operating system.

You can request the files that are currently available and their <file_id> with the command file_getlist (Creating a List of the Database Files).

Prerequisites

You have the DBM operator authorization DBFileRead.

Syntax

file_getfirst <file_id>

Options for <file_id>

See: Database Files

Reply

Output in ASCII Mode

OK<NL>
<file_handle><NL>
[CONTINUE|END]<NL>
<file_length>:20<data_length>:20<NL>
<data><NL>
<data><NL>
...

Output in Binary Mode

OK<NL>
file_handle><NL>
[CONTINUE|END]<NL>
<file_length><data_length><NL>
<data ><NL>

Values for the Individual Fields of the Reply

<file_handle> | Numeric value that can be used for subsequent access to this file.
END | The contents of the file have been transferred in full. The file is closed automatically.
CONTINUE | The file contains further entries that were not transferred due to the limited storage available for replies. Interrogate this data by entering the above command or close the file.
<file_length> | File length
<data_length> | Data length
<data> | Data

In ASCII mode the data is read from the file line by line. Each line is extended by a line feed (0x0D,0x0A) in the output area.

On a UNIX server, the line feed only consists of one character. This is why the value initially output for the file length may be smaller than the data length.

In the event of errors, see Reply Format.


Packing Database Files (MaxDB: Database Manager CLI)

Packing Database Files

Use

To be able to comprehensively diagnose a database problem, Support requires a significant number of database instance files.

Use this command to collect all of the required database files in a compressed archive file.

Default values of the Database Manager for the archive file:

File name | diagpack.tgz
Directory | Run directory for the database instance
<file_id> | DIAGTGZ

When opening the file, note that it is stored in binary format (Opening a Database File).

Prerequisites

You have the DBM operator authorization DBFileRead.

Syntax

diag_pack [file=<archive>] [class=<class_spec> | <class_spec>,...] [date=<time_stamp>]

<archive> | Name and path of the archive file that you want to create
<class_spec> | Class of files that you want to include in the package The default value of the Database Manager is the class protocol Separate multiple classes with commas.
<time_stamp> | Time stamp of the diagnosis backup Additional parameter when class hist specified Determine this by Displaying the Diagnosis History

Options for <class_spec>

Class | Description
protocol | General log files
backup | Log files from backups and restores
config | Configuration files
lvc | Additional log files for a database of instance type liveCache


Backing Up a Database File (MaxDB: Database Manager CLI)

Backing Up a Database File

Use

Use this command to create a backup copy of the specified database file. Specify the name of the database file in <file_id>.

Normally, you do not have to create backup copies of internal Database Manager files because the program creates backups automatically every time it writes to the configuration files.

Prerequisites

You have the DBM operator authorization DBFileRead.

You have determined the file ID of the relevant database file (Creating a List of the Database Files).

Syntax

file_backup <file_id>

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Restoring a Database File (MaxDB: Database Manager CLI)

Restoring a Database File

Use

Use this command to copy the backup copy of the database file specified using <file_id> back to its original position. If a file already exists there, it will be overwritten.

Normally, you do not have to copy backups of internal Database Manager files to their original position manually because the Database Manager will automatically use the backups if it is unable to access the original file.

Prerequisites

You have the DBM operator authorization DBFileRead.

You have determined the file ID of the file that you want to copy (List of Database Files).

Syntax

file_restore <file_id>

Reply

There is an OK message after the command has been executed successfully.

In the event of errors, see Reply Format.


Accessing Events (MaxDB: Database Manager CLI)

Accessing Events

Use

Statuses are defined for every database instance. Their occurrence triggers an event.

Certain events are always triggered and cannot be disabled. The time proposed by the system as to when the event should be triggered cannot be changed.

Other events can be disabled or the time proposed by the system as to when the event should be triggered can be changed. More than one value can be defined for certain statuses, and an event should be output for each value.
You can use these events, for example, to display warnings of potential performance problems when a certain usage level is reached, or to issue a note when the optimizer statistics need to be updated.

The following events can be triggered:

Name | Can it be disabled? | Description
ALIVE | No | Database instance is running
AUTO_SAVE | No | Automatic log backup has started
BACKUP_PAGES | Yes System default not active | Number of pages written in the backup
DB_ABOVE_LIMIT | Yes System default: active (usage level 5-95%: message output in increments of 5%. After 96%: message output with each increase of 1%) | Defined database usage level (in percent) is exceeded
DB_BELOW_LIMIT | Yes System default: active (message output in increments of 5%) | Defined database usage level (in percent) is not reached
EVENT | No | Event configuration has been changed
LOG_ABOVE_LIMIT | Yes System default: active (message output at 50%, 75%, 90%, 95% of defined usage level and thereafter with every increase of 1%) | Defined log usage level (in percent) is exceeded
RESTART_SHUTDOWN | No | Database instance has been transferred to another operation status
UPDATE_STATISTICS | No | SQL optimizer statistics need to be updated
WARNING | No | A warning has been entered in the knldiag log file
ERROR | No | An error has been entered in the knldiag log file

You can use the following DBM commands to access events of the database instance:

Activating an Event | event_set
Terminating an Event Session | event_release
Deactivating an Event | event_delete
Creating a List of Events and their Status | event_list
Waiting for an Event | event_wait

Prerequisites

You have the server authorization DBInfoRead.


Activating an Event (MaxDB: Database Manager CLI)

Activating an Event

Use

You activate an event. In accordance with the set parameters, you can display messages about the occurrence of the activated events in the Database Manager CLI using the commands for waiting for an event.

Prerequisites

You have the server authorization DBInfoRead.

Syntax

event_set <event_name> [<priority>] [[<value1>] <value2>]

event_name | Description of the event
priority | Priority of the event NIL: No priority defined MEDIUM: Medium priority HIGH: High priority
value | Additional value whose meaning depends on the event

Reply

The system displays an OK message.

In the event of errors, see Reply Format.

Example

Call the Database Manager CLI, log on to the database instance HOTELDB as the operator DBM with password DBM, open a utility session (without specifying the user and therefore with the stored default first DBM operator), activate the event BACKUP_PAGES with the value 1000.

dbmcli -d HOTELDB -u DBM,DBM –uUTL -c event_set BACKUP_PAGES 1000

Result:

OK

From now on, during the current backup process, the database instance will generate a message after every thousand pages that are backed up.


Ending an Event Session (MaxDB: Database Manager CLI)

Ending an Event Session

Use

When an event is being waited for, a database instance session is created implicitly. You use this DBM command to end that session.

Prerequisites

You have the server authorization DBInfoRead.

Syntax

event_release

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Deactivating an Event (MaxDB: Database Manager CLI)

Deactivating an Event

Use

You deactivate an event. The occurrence of the event will now no longer be logged by the Database Manager.

Prerequisites

You have the server authorization DBInfoRead.

Syntax

event_delete <event_name> [<priority>] [[<value1>] <value2>]

event_name | Description of the event
priority | Priority of the event NIL: No priority defined MEDIUM: Medium priority HIGH: High priority
value | Additional value whose meaning depends on the event

Reply

The system displays an OK message.

In the event of errors, see Reply Format.

Example

Call the Database Manager CLI, log on to the database instance HOTELDB as the operator DBM with password DBM, open a utility session (without specifying the user and therefore with the stored default first DBM operator), deactivate the event BACKUP_PAGES for which the value 1000 was defined:

dbmcli -d HOTELDB -u DBM,DBM -uUTL -c event_delete BACKUP_PAGES 1000

OK


Creating a List of Events and Statuses (MaxDB: Database Manager CLI)

Creating a List of Events and Statuses

Use

You display a list of all the events. The state status indicates whether the event is active (ON) or inactive (OFF).

Prerequisites

You have the server authorization DBInfoRead.

Syntax

event_list

Reply

OK<NL>
Name State Prio 1st 2nd Description<NL>

<name> <state> <prio> <value> <value> <description><NL>

<name> <state> <prio> <value> <value> <description><NL>

...

Values in the Individual Fields of the Reply

name | Event description
state | Status of the event ON: Event is active OFF: Event is inactive When the system is waiting for an event, a signal is output as soon as the event occurs.
prio | Priority of the event NIL: No priority defined MEDIUM: Medium priority HIGH: High priority
value | Additional value whose meaning depends on the event
description | Description of the event

In the event of errors, see Reply Format.

Example

Calling the database manager CLI, logging on to the database instance HOTELDB as operator DBM with password DBM, displaying a list of all the events and their statuses:

dbmcli -d HOTELDB -u DBM,DBM event_list

OK
Name State Prio 1st 2nd Description
BACKUP_PAGES OFF NIL 0 Next <n> pages moved
DB_ABOVE_LIMIT ON MEDIUM 90 Database above limit
DB_ABOVE_LIMIT ON HIGH 95 Database above limit
DB_ABOVE_LIMIT ON HIGH 96 Database above limit
DB_ABOVE_LIMIT ON HIGH 97 Database above limit
DB_ABOVE_LIMIT ON HIGH 98 Database above limit
DB_ABOVE_LIMIT ON HIGH 99 Database above limit
DB_BELOW_LIMIT OFF NIL 0 Database below limit


Waiting for an Event (MaxDB: Database Manager CLI)

Waiting for an Event

Use

You display the notification from the database manager about the occurrence of an activated event and the associated data.

Once you have received the notification, you evaluate it, enter the command again, and wait for the next notification from the database manager about the occurrence of the activated event.

You do not receive a reply to this DBM command until the activated event occurs.

Use this DBM command via a database manager programming interface.

If you want to use the DBM command with the database manager CLI, work in session mode.

Prerequisites

· You have the server authorization DBInfoRead.

· You have activated an event (Activating an Event).

Syntax

event_wait

Example

1. Generating the session mode:
Calling the database manager CLI, logging on to the database instance HOTELDB as operator DBM with password DBM:

dbmcli -d HOTELDB -u DBM,DBM

dbmcli on HOTELDB>

2. Entering the DBM command for waiting for an event:

dbmcli on HOTELDB>event_wait

Result:

You receive notification about the occurrence of the event BACKUP_PAGES.

OK
NAME=BACKUP_PAGES
PRIORITY=LOW
DATE=20030712
TIME=00151725
VALUE1=99
COUNT=188
DESCRIPTION=Next <n> pages moved


Accessing the Database Instance (MaxDB: Database Manager CLI)

Accessing the Database Instance

UseThis group of DBM commands allows you to communicate with the database instance. If you do not specify a database user for a command for accessing the database instance, the first DBM operator will become the default user. PrerequisitesTake account of the server authorizations required for the respective DBM commands.To use these DBM commands you must open and work in a utility session, an SQL session, a service session or a database session. For more information see the documentation for the particular DBM commands.

Overview of Commands for Accessing the Database Instance:

· Access Using a Database Session

· Access Using a Utility Session

· Access Using an SQL Session

· Access Usng a Service Session


Overview of DBM Commands for Accessing the Database Instance (MaxDB: Database Manager CLI)

Overview of DBM Commands for Accessing the Database Instance

Updating the Optimizer Statistics | sql_updatestat
Updating the Optimizer Statistics with the XPU Program | exec_xpu
Displaying the Structure of a Result Set | sql_info
Displaying Status Information for the Database Instance | info
Executing a Database Statement | db_execute
Executing an SQL Statement | sql_execute
Executing a Utility or SQL Command | util_execute
Ending a Database Session | db_release
Ending a Service Session | service_release
Terminating an SQL Session | sql_release
Ending a Utility Session | util_release
Scrolling in the Result Data | sql_fetch
Scrolling in the Status Information of the Database Instance | info_next
Opening a Database Session | db_connect
Opening a Service Session | service_connect
Opening an SQL Session | sql_connect
Opening a Utility Session | util_connect


Access Using a Database Session (MaxDB: Database Manager CLI)

Access Using a Database Session

Use

You can use the following DBM commands during a database session:

Executing a Database Statement | db_execute
Ending a Database Session | db_release
Opening a Database Session | db_connect

Prerequisites

Take account of the server authorizations required for the respective DBM commands.


Executing a Database Statement (MaxDB: Database Manager CLI)

Executing a Database Statement

Use

You transfer the specified administration command or SQL statement to the database instance.

When you enter a SELECT statement, the system displays the results. The system outputs an OK message for other statements.

Prerequisites

You have the server authorization AccessAdmin or AccessSQL.

You have opened a database session. (See: Opening a Database Session)

Syntax

db_execute <statement>

Reply

After executing an administration command, the system displays an OK message, or the specific reply for the administration command.

If an error occurs, an error message number is displayed.

See also: Messages

After successfully executing an SQL statement, the following is displayed:

OK<NL>
END|CONTINUE)<NL>
<record><NL>
<record><NL>

The fields in an answer record are separated by semicolons.

Character strings are displayed in single quotation marks.

END | Result set output complete
Continue | More result data ready

In the event of errors, see Reply Format.


Ending a Database Session (MaxDB: Database Manager CLI)

Ending a Database Session

Use

You end the active database session. All assigned resources are released.

Prerequisites

You have the server authorizations AccessAdmin, AccessSQL, or DBInfoRead.

Syntax

db_release

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Opening a Database Session (MaxDB: Database Manager CLI)

Opening a Database Session

Use

You open a session with the database instance as a database user in which you can transfer both administrative commands and SQL statements to the database instance.

The database session is linked with a user task of the database instance.

You can specify the user to be logged on by entering <user_name>,<password> or the user type <user-type>. If you do not specify a database user, the first DBM operator registered on the database server will be logged on.

Prerequisites

You have the server authorizations required to execute the commands and statements.

You are working in script mode or session mode.

Syntax

db_connect [<user_name>,<password> | user-type=<value>]

<value> ::= DBM | DBA | DOMAIN | SAP

<user_type> | Explanation
DBM | first DBM operator
DBA | database administrator
DOMAIN | DOMAIN user
SAP | Special database user in connection with SAP applications

Log on to the database instance myDB in session mode as the database user SAPR3

dbmcli –d myDB –u DBM,DBM

dbmcli on myDB> db_connect SAPR3,SAP

OK

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Access Using a Utility Session (MaxDB: Database Manager CLI)

Access Using a Utility Session

Use

For a utility session with the database instance, you can use the following DBM commands:

Executing a Utility or SQL Command | util_execute
Terminating a Utility Session | util_release
Opening a Utility Session | util_connect

Prerequisites

You have the server authorization AccessUtility.


Ending a Utility Session (MaxDB: Database Manager CLI)

Ending a Utility Session

Use

You end the active utility session. All assigned resources are released.

Prerequisites

You have the server authorization AccessUtility or Backup.

You have started a utility session.

Syntax

util_release

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Opening a Utility Session (MaxDB: Database Manager CLI)

Opening a Utility Session

Use

You open a session with the database instance, using the utility task of the database kernel. This task is reserved solely for database administration.

Only one utility task exists for each database instance. Administrative operations cannot therefore be performed in parallel.

If you do not specify a user, the system default (the first DBM operator) is used to log on.

Prerequisites

You have the server authorization AccessUtility or Backup.

You are working in script mode or session mode.

Syntax

util_connect

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Executing a Utility or SQL Command (MaxDB: Database Manager CLI)

Executing a Utility or SQL Command

Use

You transfer the specified utility command or SQL statement to the database instance.

Prerequisites

You have the server authorization AccessUtility.

You have opened a utility session.

Syntax

util_execute <statement>

Reply

The system displays an OK message.

If an error occurs, an error message number is displayed.

See also the documentation on Messages.


Access Using an SQL Session (MaxDB: Database Manager CLI)

Access Using an SQL Session

Use

For an SQL session with the database instance, you can use the following DBM commands:

Updating the Optimizer Statistics | sql_updatestat
Displaying the Structure of a Result Set | sql_info
Displaying Status Information for the Database Instance | info
Executing an SQL Statement | sql_execute
Terminating an SQL Session | sql_release
Scrolling in the Result Data | sql_fetch
Scrolling in the Status Information of the Database Instance | info_next
Opening an SQL Session | sql_connect

Prerequisites

Take account of the server authorizations required for the respective DBM commands.


Updating the Optimizer Statistics (MaxDB: Database Manager CLI)

Updating the Optimizer Statistics

Use

You update the statistics for the Optimizer.

These statistics enable the Optimizer to choose the best strategy for retrieving data. Obsolete statistics impair the performance of the database instance.

You can update all the statistics or restrict the update function to a set of statistics using a table specification <tablespec>.

See also: Optimizer

Prerequisites

You have the DBM operator authorization AccessSQL.

You have started an SQL session.

Syntax

sql_updatestat [<tablespec>]

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Displaying the Structure of a Result Set (MaxDB: Database Manager CLI)

Displaying the Structure of a Result Set

Use

You display the structure of the result set for an SQL statement.

Prerequisites

You have the DBM operator authorization AccessSQL .

You have started an SQL session .

Syntax

sql_info <statement>

sql_info select username,connectmode,templimit, user_id from users

OK
USERNAME;CONNECTMODE;TEMPLIMIT;USER_ID

Reply

The names of all columns are output separated by semicolons.

OK<NL>
<col_1>;<col_2>;...;<col_n><NL>q


Displaying Status Information for the Database Instance (MaxDB: Database Manager CLI)

Displaying Status Information for the Database Instance

Use

You display the information given under <info_id>.

Prerequisites

You have the DBM operator authorization DBInfoRead.

You have started an SQL session.

Syntax

info <info_id>

Option <info_id>

BADVOLUMES | Damaged volumes
BADIDX | Damaged indexes
CACHES | Accesses to the caches
CLSCON | SAP liveCache class container (only for database instance type liveCache)
COLUMNS | Columns of database instance tables
DATA | Data volumes
VOLUMES | Volumes
DISABLEDIDX | Deactivated indexes
EVENTS | Active events
INDEXES | Database instance indexes
INFOS | Available information
IO | Read and write operations
LOCKS | Locks
LOG | Log status (see also Logging)
OMSCACHES | liveCache caches (only for liveCache instance type)
OMSMON | liveCache monitors (only for liveCache instance type)
PARAMS | Database Parameters
STATE | Short description of the status of the database instance
SYSDDCONFIG | Internal configuration
SYSDDMONITOR | Internal monitors
SYSDDSRVDB | Internal database status
TABLES | Database instance tables
UNUSEDIDX | Unused indexes
UPDSTAT | Update of the statistics for the Optimizer is possible (see also: Optimizer)
UPDSTATW | Statistics must be updated for the Optimizer
USERS | Logged on database users
VERSIONS | Version of the database software

Reply

OK<NL>
(END|CONTINUE)<NL>
<description_record><NL>
<info_record><NL>
<info_record><NL>

END | Result set output complete
Continue | More result data ready

The description line <description_record> contains the names of the fields of the following information lines <info_record>.


Terminating an SQL Session (MaxDB: Database Manager CLI)

Terminating an SQL Session

Use

You exit the active SQL session. All assigned resources are released.

Prerequisites

You have the DBM operator authorization AccessSQL or DBInfoRead .

You have opened an SQL session .

Syntax

sql_release

Reply

The system outputs an OK message.

In the event of errors, see Reply Format .


Scrolling in the Result Data (MaxDB: Database Manager CLI)

Scrolling in the Result Data

Use

You request the output of additional result data.

Prerequisites

You have the server authorization AccessSQL.

You have opened an SQL session and transferred an SQL statement. In the response, CONTINUE indicated that additional result data was available.

Syntax

sql_fetch

Reply

The fields in a record are separated by semicolons.

Character strings are displayed in single quotation marks.

OK<NL>
(END|CONTINUE)<NL>
<record><NL>
<record><NL>

Values for the Individual Fields of the Reply

END | The contents of the file have been transferred in full. The file is closed automatically.
CONTINUE | The file contains further entries that were not transferred due to the limited storage available for replies. You can display these by entering the above command again.


Scrolling in the Status Information of the Database Instance (MaxDB: Database Manager CLI)

Scrolling in the Status Information of the Database Instance

Use

You can output further information on the state of the database instance.

Prerequisites

You have the DBM operator authorization DBInfoRead.

When displaying status information for the database instance or scrolling in the status information for the database instance, the system informs you that you can request more information using the keyword CONTINUE.

Syntax

info_next

Reply

OK<NL>
(END|CONTINUE)<NL>
<description_record><NL>
<info_record><NL>
<info_record><NL>

Values for the Individual Fields of the Reply

END | Result set output complete
Continue | More result data ready
<description_record> | Name of the fields of the subsequent information lines
<info_record> | Information


Opening an SQL Session (MaxDB: Database Manager CLI)

Opening an SQL Session

Use

You create an SQL session for the specified DBM operator with the database kernel. The operator of an SQL session shares the performance of the database instance with up to n additional operators.

If you have not specified an operator, the DBM operator registered on the server is logged on.

Prerequisites

You have the DBM operator authorization DBInfoRead or AccessSQL.

You are working in script mode or session mode.

Syntax

sql_connect [<userid>,<password>]

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Executing an SQL Statement (MaxDB: Database Manager CLI)

Executing an SQL Statement

Use

You can transfer an SQL statement to the database instance by entering a DBM command.

When the <statement> that you enter is a SELECT statement, the system displays the results. If you enter other SQL statements, the execution of the statement is confirmed with an OK message.

Prerequisites

You have the server authorization AccessSQL.

You have started an SQL session.

Syntax

sql_execute <statement>

sql_execute SELECT username,connectmode,templimit,user_id from users

OK
END
'PUBLIC';'SINGLE';(null);3
'DBA';'SINGLE';(null);10
'DOMAIN';'SINGLE';(null);11
'SYS';'SINGLE';(null);12
'CONTROL';'MULTIPLE';(null);0

Reply

OK<NL>
(END|CONTINUE)<NL>
<record><NL>
<record><NL>

The fields in an answer record are separated by semicolons.

Character strings are displayed in single quotation marks.

END | Result set output complete
Continue | More result data ready

In the event of errors, see Reply Format.


Access Using a Service Session (MaxDB: Database Manager CLI)

Access Using a Service Session

Use

To use the DBM Server commands for checking backups and restoring parameter files from the data backup, you must have a service session running with the database instance.

For a service session, you can use the following DBM commands:

Terminating a Service Session | service_release
Opening a Service Session | service_connect

Prerequisites

You have the server authorization Backup.


Ending a Service Session (MaxDB: Database Manager CLI)

Ending a Service Session

Use

You use this DBM command to end the active service session. All assigned resources are released. When you end the database manager, this command is executed implicitly.

Prerequisites

You have the server authorization Backup.

You have started a service session.

Syntax

service_release

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Opening a Service Session (MaxDB: Database Manager CLI)

Opening a Service Session

Use

You start the appropriate service kernel for the version of the database software and open a session with the utility task.

The service kernel is a specially configured database instance without a dataset of its own. You can use it to carry out tasks for other database instances, such as Checking a Backup, or Restoring the Parameter File from a Data Backup.

Prerequisites

You have the server authorization Backup.

You are working in script mode or session mode.

Syntax

service_connect

Reply

The system displays an OK message.

In the event of errors, see Reply Format.


Logging On to the Operating System (MaxDB: Database Manager CLI)

Logging On to the Operating System

Use

So that the Database Manager can access a remote server once with operating system rights, log on to the operating system with a DBM command in session mode or script mode.

This logon is needed for executing the following DBM Server commands.

Creating a Database Instance | db_create
Deleting the Registration of a Version of the Database Software | inst_unreg
Registering a Version of the Database Software | inst_reg

Prerequisites

No special operator authorization is required for this command.

Syntax

user_system <dbm_user>,<password>

Reply

An OK message.

In the event of errors, see Reply Format.


Executing the liveCache Initialization Script (MaxDB: Database Manager CLI)

Executing the liveCache Initialization Script

This command is only relevant in connection with SAP applications.

Use

You are logged on to the Database Manager CLI and start the liveCache initialization script stored on the database server from this program.

You can specify parameters with this DBM command that are passed to the liveCache initialization script by the Database Manager. The output from the liveCache initialization script is supplied by the Database Manager CLI.

Prerequisites

You have the operator authorization SystemCmd .

Syntax

exec_lcinit [<lcinitparams>]

Successful Reply

OK<NL>
0,<err_description><NL>
<pgmcode>,<command><NL>
<command_output_lines><NL>

Error Message

ERR<NL>
<err_code>,<err_description><NL>
<pgm_code>,<command><NL>
<command_output_lines><NL>

Values for the individual fields of the reply

<err_code> | Error number of the Database Manager, if successful the error number is 0.
<err_description> | Description of the error
<pgm_code> | Return value of the executed program
<command> | Command line executed by the Database Manager
<command_output_lines> | Output text of the program
<NL> | Line feed


Creating a List of the DBM Commands (MaxDB: Database Manager CLI)

Creating a List of the DBM Commands

Use

You request a list of DBM commands. You can view all valid DBM commands or modify the list by specifying options.

The commands are displayed with a description. Possible and/or necessary options for valid DBM commands are displayed as well as what type of session is required for Accessing the Database Instance. In the case of obsolete commands, the corresponding new commands are displayed.

Prerequisites

You do not need to log on to the Database Manager to execute this DBM command.

Syntax

help [-obsolete] [<string>]

-obsolete | Only obsolete commands are displayed. The system displays a reference to the current name for each of these commands
string | Only those commands are displayed which start with the specified character string

Examples

Call the Database Manager CLI, display all valid DBM commands:

dbmcli help

OK
archive_stage <medium> <stage> [verfiy|noverify] [remove|keep]
[FileNumberList <list>]
archive_stage_repeat <medium> <stage> [verfiy|noverify] [remove|keep]
autolog_cancel (need util session)
...

Call the Database Manager CLI, display all DBM commands that start with the character string auto:

dbmcli help auto

OK
autolog_cancel (needs util session)
autolog_off (needs util session)
autolog_on [<medium>] (needs util session)
autolog_show [LOG] [UNTIL <date> <time>] [IBID <internal_backup_id>]
(needs util session)
...

Call the Database Manager CLI, display all obsolete DBM commands:

dbmcli help -obsolete

OK
autosave_cancel (obsolete version of autolog_cancel)
autosave_off (obsolete version of autolog_off)
...

Reply

OK<NL>
<command_name> <description><NL>
<command_name> <description><NL>
...

In the event of errors, see Reply Format.

Reply lines with more than 80 characters are split up.


Ending the Database Manager (MaxDB: Database Manager CLI)

Ending the Database Manager

Use

This command ends the session with the Database Manager.

Syntax

release | bye | exit | quit

Reply

The system outputs an OK message.

In the event of errors, see Reply Format .


Overview of All DBM Commands (MaxDB: Database Manager CLI)

Overview of All DBM Commands

archive_stage | Creating a Single Archive of the Version Files
archive_stage_repeat | Creating Multiple Archives of the Version Files
autolog_cancel | Canceling the Automatic Log Backup
autolog_off | Deactivating the Automatic Log Backup
autolog_on | Activating the Automatic Log Backup
autolog_show | Displaying the Automatic Log Backup
backup_cancel | Terminating an Interrupted Backup
backup_ext_ids_forget | Releasing the Memory Occupied by the External Backup IDs
backup_ext_ids_get | Fetching External Backup IDs
backup_ext_ids_list | Displaying External Backup IDs
backup_ext_ids_listnext | Scrolling in the External Backup IDs
backup_history_close | Closing the Backup History
backup_history_date | Change Date of the Backup History
backup_history_list | Displaying the Backup History
backup_history_listnext | Scrolling in the Backup History
backup_history_open | Fetching the Backup History
backup_ignore | Continuing the Backup Without Last Known Full Backup Medium
backup_replace | Backing Up to a Succeeding Medium
backup_start | Backing Up the Database Instance
backup_state | Displaying the Current Backup Status
bye | Ending the Database Manager
db_activate | Activating a New Database Instance
db_activate RECOVER | Recovering a Database Instance with Initialization
db_addvolume | Adding a Volume
db_admin | Transferring to the ADMIN Operational State
db_clear | Deleting Runtime Information After a Database Error
db_connect | Opening a Database Session
db_cons | Using the Database Console
db_create | Creating a Database Instance
db_drop | Deleting the Current Database Instance
db_enum | List of All Registered Database Instances
db_execute | Executing a Database Statement
db_offline | Transferring to the OFFLINE Operational State
db_online | Transferring to the ONLINE Operational State
db_reg | Updating the Registration of a Database Instance
db_reg -R | Changing the Software Version of the Current Database Instance
db_release | Ending a Database Session
db_restart | Restarting the Database Instance
db_restartinfo | Displaying Current Information About the Database Instance
db_speed | Displaying the Database Kernel Variant
db_standby | Transferring to the STANDBY Operational State
db_start | Starting the Database Instance
db_state | Displaying the Operational State of the Database Instance
db_stop | Stopping the Database Instance
dban_start | Calling the Database Analyzer
dban_state | Determining the Status of the Database Analyzer
dban_stop | Ending the Database Analyzer
dbm_configget | Displaying a Configuration Parameter of the Database Manager
dbm_configset | Changing a Configuration Parameter of the Database Manager
dbm_getpath | Displaying the Version-Independent Directories
dbm_version | Displaying the Version Information
diag_histlist | Displaying the Diagnosis History
diag_pack | Packing Database Files
event_delete | Deactivating an Event
event_list | Creating a List of Events and Statuses
event_release | Ending an Event Session
event_set | Activating an Event
event_wait | Waiting for an Event
exec_lcinit | Executing the liveCache Initialization Script
exec_load | Starting the PythonLOAD Program
exec_xpu | Updating the Optimizer Statistics with the XPU Program
exit | Ending the Database Manager
file_backup | Backing Up a Database File
file_getfirst | Opening a Database File
file_getlist | Creating a List of the Database Files
file_getnext | Scrolling Through a Database File
file_operation | Editing Log Files of the Database Instance
file_restore | Restoring a Database File
help | Creating a List of DBM Commands
hss_addstandby | Defining an Additional Standby Component
hss_enable | Configuring a Master Component
hss_execute | Addressing a Standby Component
hss_getnodes | Querying Hot Standby Parameters
hss_removestandby | Removing a Standby Component
info | Displaying Status Information for the Database Instance
info_next | Scrolling in the Status Information of the Database Instance
inst_enum | List of All Registered Versions of the Database Software
inst_reg | Registering a Version of the Database Software
inst_unreg | Deleting the Registration of a Version of the Database Software
load_r3tab | Loading SAP-Specific Tables
load_systab | Loading the System Tables
medium_date | Change Date of the Media Definition File
medium_delete | Deleting a Backup Medium
medium_get | Displaying the Media Data
medium_getall | List of All Defined Backup Media
medium_label | Displaying the Backup Information in the Operational State ONLINE or ADMIN
medium_labeloffline | Displaying the Backup Information in the Operational State OFFLINE
medium_migrate | Copying an Existing Media Definition
medium_put | Defining or Changing a Backup Medium
param_abortsession | Terminating a Parameter Session
param_addvolume | Changing Volume Parameters
param_checkall | Checking All Database Parameters
param_commitsession | Confirming Changes to the Database Parameter File
param_copy | Copying a Database Parameter File
param_delvolume | Deleting Volume Parameters
param_directdel | Deleting a Database Parameter
param_directget | Displaying a Value from the Database Parameter File
param_directgetall | Displaying All Parameters of the Current Database Parameter File
param_directput | Directly Changing a Value in the Database Parameter File
param_extget | Displaying Individual Data for a Database Parameter
param_extgetall | Displaying the Data for All Database Parameters
param_getdefault | Displaying the System Default Value
param_getexplain | Displaying the Stored Explanatory Text
param_getfull | Displaying All Data for a Database Parameter
param_gethelp | Displaying the Stored Help Text
param_gethistory | Opening the Database Parameter History
param_gethistorynext | Scrolling in the Database Parameter History
param_getproperties | Displaying All Properties of a Database Parameter
param_gettype | Displaying the Data Type of a Database Parameter
param_getvalue | Displaying the Current Value of a Database Parameter
param_getvolsall | Displaying the Data for All Volume Parameters
param_getvolume | Displaying the Data for Individual Volume Parameters
param_init | Initializing the Database Parameter for a New Database Instance
param_put | Changing the Value of a Database Parameter
param_putconfirm | Correcting Database Parameters
param_restore | Resetting the Parameter File to a Previous Version
param_rmfile | Deleting the Database Parameter File
param_startsession | Opening a Parameter Session
param_versions | List of Available Parameter Files
quit | Ending the Database Manager
recover_cancel | Terminating an Interrupted Restore or Backup Check
recover_check | Checking a Backup
recover_config | Restoring the Parameter File from a Data Backup
recover_ignore | Continuing a Parallel Restore or Backup Check
recover_replace | Restoring or Checking a Backup with Succeeding Medium
recover_start | Restoring the Database Instance
recover_state | Displaying the Current Restore Status
recover_state_check | Displaying the Current Status of a Backup Check
release | Ending the Database Manager
service_connect | Opening a Service Session
service_release | Ending a Service Session
show | Displaying Information About the Database Instance
show_list | Displaying the Keywords for Information About the Database Instance
show_next | Scrolling in the Information About the Database Instance
sql_connect | Opening an SQL Session
sql_execute | Executing an SQL Statement
sql_fetch | Scrolling in the Result Data
sql_info | Displaying the Structure of a Result Set
sql_recreateindex | Recreating a Damaged Index
sql_release | Terminating an SQL Session
sql_updatestat | Updating the Optimizer Statistics
trace_off | Deactivating the Database Trace
trace_prot | Creating the Text Version of the Database Trace
trace_protopt | Displaying Options for the Text Version of the Database Trace
trace_show | Displaying the Logged Activities of the Database Trace
user_create | Creating DBM Operators
user_delete | Deleting DBM Operators
user_get | Displaying Operator Data
user_getall | List of DBM Operators
user_getrights | Displaying the Server Authorizations
user_put | Changing DBM Operator Data
user_set | Storing Special Users
util_connect | Opening a Utility Session
util_execute | Executing a Utility or SQL Command
util_release | Ending a Utility Session


Database Analyzer

The Database Analyzer program is a tool for analyzing the performance of database instances.

You can use the Database Analyzer independently of the version and the database instance type. You can also use this program to access the database instance from a remote host.

Scope of Functions

The Database Analyzer collects performance-relevant data by monitoring the performance of the database instance at regular (variable) intervals. It splits the results of its analysis into five classes – information, three different levels of warnings, and error messages.

This makes it easier for you to find out the following possible causes of problems with the database instance:

  • Database configuration (caches, parameters)
  • Synchronization (locks, critical sections, heap)
  • Processing of database requests (such as processing strategies, indexes, optimizer statistics)
  • Hardware configuration

To be able to interpret the information gathered by the Database Analyzer, you require a sound working knowledge of the architecture, the architecture of your application program, and your operating system.

For general information about the database system, see the database administration documentation.

  • Calling the Database Analyzer
  • Log Files
  • Messages
  • Configuration File


Calling the Database Analyzer (MaxDB: Database Analyzer)

Calling the Database Analyzer

You can call the Database Analyzer in several different ways:

From the operating system level
Enter the following command:
dbanalyzer
[–d <database_name>] [-u <user,password>]
[-t <interval>[,<number>]] [-n <database_server>]
[-f <configfile>] [-o <outputdir>]
[-c <level> ]
[-i] [-nologo] [-noenv] [-stop]
Options

In the Database Manager CLI
Database Manager CLI Call

In the CCMS (for SAP systems)
Database instance type liveCache: Bottleneck Analysis (Database Analyzer)
Database instance type MaxDB: Database Bottlenecks


Options (MaxDB: Database Analyzer)

Options

You can specify the following options when you call the Database Analyzer:

-d <database_name> | Name of the database instance
-u <user,password> | User name and password
-t <interval>,<number> | Time interval (in seconds) between two analyses and the chosen number of analyses If you specify a <number>, then the Database Analyzer ends after this number of analyses.
-n <database_server> | Name of the server on which the database instance runs If you specify the server name, you must also use the option –o to specify the directory for the log files.
-f <configfile> | Name of the configuration file If you do not specify a configuration file, the Database Analyzer uses the file dbanalyzer<version>.cfg in the database directory <dependent_path>/env.
-o <outputdir> | Directory for the log files If you start the Database Analyzer on the computer on which the database instance is installed, you do not need to specify –o. In this case, the Database Analyzer uses the subdirectory analyzer in the run directory of the database instance.
-c <outputlevel> | Specifies, on a scale of 1 (low) to 4 (high), how much additional information appears on the console If you do not specify -c, then no information appears on the console.
-i | Deletes any existing log files for the same day
-nologo | Suppresses the logo
-noenv | Suppresses logging and output of the environment variables from the configuration file
-stop | Stops a running Database Analyzer


Log Files (MaxDB: Database Analyzer)

Log Files

The data collected by the Database Analyzer during the day is saved in a range of log files in the log file directory.

You can specify the log file directory as follows:

When you call the Database Analyzer, you can use the option –o to specify the log file directory. The log files are saved in the subdirectories /YYYYMMDD.

If you start the Database Analyzer on the computer on which the database instance is installed, you do not need to specify –o. The log files are saved in the subdirectory analyzer in the run directory of the database instance.

The Database Analyzer generates the following log files:

DBAN.prt

This file contains the following information:

· Unique information about the configuration and performance-relevant data of the database instance

· Bottlenecks discovered by the Database Analysis during each measurement

The Database Analyzer weights the information and bottlenecks:

I | Information | General information, such as the number of executed commands
W1 to W3 | Warning levels 1 to 3 | Bottleneck warnings with low, medium, and high priority
E | Emergency | Critical problems, such as an imminent database crash

DBAN_<monitor_class>.csv

These files contain all analysis data. They allow you to check runtime behavior retrospectively.

One file exists for each monitor class (analysis area). You can use Microsoft Excel to open and read this file as soon as the Database Analyzer stops writing to it.

List of All Log Files

See also:

Messages


List of Log Files (MaxDB: Database Analyzer)

List of Log Files

This table shows you the information that you can find in the Database Analyzer log files.

Log Files for All Database Instance Types

DBAN.prt | Logs messages, including analysis rules and current values that caused the message
DBAN_CACHES.csv | Successful and unsuccessful accesses to the caches, and hit rates
DBAN_FILLING.csv | Fill level of the database instance (such as the size of the data volumes, number of permanently and temporarily used pages)
DBAN_IO.csv | Reads and writes to cache pages and data pages
DBAN_LOAD.csv | Accesses and selectivity of SELECT, FETCH, INSERT, UPDATE, and DELETE statements
DBAN_LOGGING.csv | Number of log pages written, fill level of the log queue
DBAN_REGIONS.csv | Information about accesses to critical sections
DBAN_STRATEGY_INDEX.csv | Accesses and selectivity for index searches
DBAN_STRATEGY_PRIMKEY.csv | Accesses and selectivity for PRIMARY KEY searches
DBAN_STRATEGY_SCANS.csv | Accesses and selectivity for INDEX SCAN and TABLE SCAN searches
DBAN_TASK_ACTIVITIES.csv | Information on task activities (such as number of SQL statements, number or running user tasks, number of task changes)
DBAN_TASK_IO.csv | Number and duration of physical writes and reads from perspective of the log writer, the user task, and the pager
DBAN_TASK_STATES.csv | Number and execution duration of processed statements Number and wait duration of the task states Vsuspend, Vwait, Vsleep
DBAN_TRANSACTIONS.csv | Number of SQL statements and procedure calls, PREPARE, EXECUTE, COMMIT, and ROLLBACK statements, subtransactions, TIMEOUTS caused by locks, and conversions of row locks to table locks (Lock List Escalations)

liveCache-Specific Log Files

DBAN_CACHES_OCCUPANCY.csv | Cache load and occupancy (proportion of OMS, SQL, and history pages in the data cache)
DBAN_OMS.csv | Number of calls by [image] DB procedures, dereferences, deleted objects, history accesses
DBAN_OMS_CONTAINER.csv | Information on [image] class containers (such as number of classes, occupancy, number of free pages)
DBAN_OMS_HEAP.csv | Information on [image] OMS heap (such as occupancy, current size, collisions)
DBAN_OMS_VERSIONS.csv | Information on [image] OMS versions (such as number and age of versions used)


Messages (MaxDB: Database Analyzer)

Messages

Database Analyzer can write the following messages in the log file, among others:

Avg user cmd exec time for task

Avg user suspend time for task

Avg user wait time for task

Catalog cache hitrate

Collision rate

Data cache hitrate

Data volume filling level

Deletes

Free user tasks

Index accesses

Index range accesses

Isolated index accesses

Isolated index range accesses

Isolated index scans

Log area filling level

Lock list escalations

Log queue overflows

Log write time

Max log queue filling

Number of cached history pages

Number of physical reads

Number of physical writes

Number of physical writes of temporary pages

OMS cache hitrate

OMS heap collisions

OMS heap utilization

OMS history cache hitrate

OMS terminates

OMS version is old

OMS version is unloaded

Out of memory exceptions

Parse activities

Physical reads for user task

Primary key accesses

Primary key range accesses

Selects and Fetches

Table scans

Updates

User task blocked in state

User task physical writes


Avg user cmd exec time for task (MaxDB: Database Analyzer)

Avg user cmd exec time for task

Avg user cmd exec time for task <task_ID>: <duration> ms,
<number_of> commands, application pid <pid>

Explanation

The time needed by the specified user task to execute the statements is very high. You see the average execution time of a statement, the number of statements checked, and the process ID of the relevant application process.

Whether this counts as a bottleneck, depends on the application structure.

Mass statements in background processes can often cause long runtimes. As well as this, situations such as locks in SQL objects, physical reads and writes, or dispatching caused by the prioritization of other tasks, can cause internal kernel wait situations that increase runtimes.

If, in liveCache instances, a [image] DB procedure takes a long time to execute, it is highly likely that other users are being blocked in the same liveCache thread. This can cause unexpectedly long runtimes for other transactions or DB procedures.


Avg user suspend time for task (MaxDB: Database Analyzer)

Avg user suspend time for task

Avg user suspend time for task <task_ID>: <duration> ms,
<number_of> suspends, application pid <pid>

Explanation

The execution of this user task has been interrupted by wait times. You see the average duration of all wait times that have been determined. This value is normally under 100 milliseconds.

You also see how often wait times occurred.

User Response

Check the state of the user task at regular intervals.


Avg user wait time for task (MaxDB: Database Analyzer)

Avg user wait time for task

Avg user wait time for task <task_ID>: <duration> ms, <number_of> waits, application pid <pid>

Explanation

In a lock collision, the wait for a lock to be released is very long.

This can be caused by a transaction that is too long. Long wait times (task state vwait) can also occur when many applications want to lock the same object.

The database system attempts to execute locking tasks with higher priority within the database kernel if the locks are requested by other sessions.

For information on the current locks, see the system tables TRANSACTIONS and LOCKS of the database instance.

User Response

Check the following aspects of the application:

  • Is it suitable for isolation level 0 (uncommitted)?
  • Can the time between the lock request and the COMMIT statement be reduced?
  • Can you avoid simultaneous locks on the same row by splitting tables?


Catalog cache hitrate (MaxDB: Database Analyzer)

Catalog cache hitrate

Catalog cache hitrate <percentage>%, <number> of <number> accesses failed

Explanation

The hit rate when accessing the catalog cache in which the parsed SQL statements are administered is too low. In a running database application, the catalog cache hit rate should be about 90%. If new program parts or programs are started, the hit rate can temporarily sink to a very low level. However, the average over 15 minutes should not be below 85%.

User Response

The size of the catalog cache should be about 100 pages for each database session. You can check this with the general database parameter MAXUSERTASKS and the special database parameter CAT_CACHE_SUPPLY.

The catalog cache is enlarged dynamically by the active database sessions, and released again with a RELEASE statement. You can determine the current cache sizes with the SQL statement SELECT * FROM CONNECTEDUSERS.

If sessions need significantly more than 100 pages, we recommend that you increase the catalog cache accordingly in the medium term, if the memory of the server is large enough.


Collision rate (MaxDB: Database Analyzer)

Collision rate

<region_name>: collision rate (<percentage>%), <number_of> collisions, <number_of> accesses on region <region_ID>

Explanation

The rate of lock collisions is high.

Tasks that run in different threads are attempting to access a global storage area in parallel. The synchronization that is necessary for this often leads to an increased collision rate.

One exception to this in liveCache instances is high collision rates in the areas ( <region_id>) OMSVDIR and CNSTVIEW. This is normal for certain actions, such as a simultaneous CIF queue transfer.

User Response

You need to act if the collision rate rises above 10%. Generally, the risk of collisions rises with the number of processors used (general database parameter MAXCPU). In multiprocessor systems, you should therefore check whether the database system can fulfill the needs of the applications with fewer CPUs.

If high collision rates occur in multiprocessor central systems (database system and application run on the same computer), check whether the computer’s CPU is overloaded, and whether the database threads are blocked by other applications. In this case, the database threads that contain user tasks should receive REAL TIME PRIORITY from the operating system. However, at the same time, the value of MAXCPU must be at least one lower than the number of real CPUs, to avoid operating system blocks.

Additional Actions

If the high collision rates occur in the areas DATAn, SPLITn or TREEn, then increase the values of both the general database parameter CACHE_SIZE and the special database parameters _DATA_CACHE_RGNS and _TREE_RGNS.

If the high collision rates occur in the regions TRACE or BUFWRTR, then activate the database trace temporarily for troubleshooting only.


Data cache hitrate (MaxDB: Database Analyzer)

Data cache hitrate

Data cache hitrate <percentage>%, <number> of <number> accesses failed

Explanation

The hit rate when accessing the data cache is too low. In a running liveCache application, the hit rate should not be under 100%.

Lower hit rates may occur for short periods of time, for example, when objects are accessed for the first time, or if a table that is being scanned repeatedly (TABLE SCAN) is larger than 10% of the data cache (only if the special database parameter LRU_FOR_SCAN has the value yes). Data cache hit rates that are lower than 99% over a fifteen minute average must be avoided.

User Response

Check the following points:

· Load in the data cache

· Configuration of the database instance and the hardware

· In liveCache instances, the size of the plan versions, as well as [image] OMS versions that have existed for a long time.

Individual SQL statements can often take up a large proportion of the total logical and physical reads. Increasing the cache just moves the load from the hard disk to the CPU, even though, for example, an additional index could turn a read-intensive table scan into a quick direct access. For information on creating optimized SQL statements, see the SQL Optimizer section.


Data volume filling level (MaxDB: Database Analyzer)

Data volume filling level

Data volume filling level <percentage>%, <number_of> pages configured, perm used <perm_used>, temp used <temp_used>

Explanation

The fill level of the data volumes is high. If the fill level is 100%, the database instance stops.

User Response

If the amount of data that needs administering in the database instance has increased, you may need to add a new data volume.

A large proportion of temporary data pages (temp used) indicates large amounts of (buffer) result sets. Find the statement that is causing these large amounts of (buffer) result sets to be created, and check the access strategies for this statement.

For information on creating optimized SQL statements, see the SQL Optimizer documentation.


Deletes/Updates (MaxDB: Database Analyzer)

Deletes/Updates

Delete selectivity <percentage>%: <number_of> deletes, <number_of> rows read, <number_of> rows qualified

Update selectivity <percentage>%: <number_of> updates, <number_of> rows read, <number_of> rows qualified

Explanation

The ratio of read rows to modified rows is poor for UPDATE or DELETE statements.

Before UPDATE and DELETE statements can modify or delete rows, the row must be located in the table. The same access strategies are used as in a SELECT statement.

User Response

Find the statement that causes this poor ratio of read rows to found rows, and check the access strategies for this statement.

For information on creating optimized SQL statements, see the SQL Optimizer documentation.


Free user tasks (MaxDB: Database Analyzer)

Free user tasks

Free user tasks: <count>, connected users: <count>

Explanation

The number of free user tasks is low. If there are no free user tasks, then no more applications can connect to the database instance.

User Response

Check the existing database connections. Check whether any applications have connected to the database more than once. If the number of applications that want to work with the database instance rises, you may need to increase the value of the general database parameter MAXUSERTASKS .


Lock list escalations (MaxDB: Database Analyzer)

Lock list escalations

Lock list escalations: <count>

Explanation

The number of row locks in a table is too high. The database system attempts to convert the row locks into a table lock.

User Response

You can specify the maximum possible number of row locks in the lock list in the general database parameter MAXLOCKS. The database system attempts to convert the row lock into a table lock if a task holds more than 0,1*MAXLOCKS row locks in a table. If too many escalations occur, increase the parameter value.

Whether escalations are a problem depends strongly on the application in question. If escalations occur, examine the application to see whether you can split any modifying transactions that lock a lot of rows into several individual transactions.

See also Locks in the Database Administration documentation.


Log area filling level (MaxDB: Database Analyzer)

Log area filling level

Log area filling level <percentage>%, <number_of> pages configured, <number> used

Explanation

The fill level of the log area is high. If the fill level is 100%, the database instance stops.

User Response

Back up the log area. If necessary, activate automatic log backups. If automatic log backups are already activated, check whether the last backup was successful.


Log queue overflows (MaxDB: Database Analyzer)

Log queue overflows

Log queue overflows: <count>

Log queue overflows: <count>, configured log queue pages: <count>

Explanation

The log queue is full before the log pages are written to the log area.

User Response

Use the special database parameter LOG_IO_QUEUE to check the size of the log queue, and increase its value, if possible.

Check the performance of the hard disk on which the log volumes are located.


Log write time (MaxDB: Database Analyzer)

Log write time

Avg log write time (log_writer_task) <duration> ms, <number_of> writes, <number_of> pages

Avg log write time (dev_thread) <duration> ms, <number_of> writes, <number_of> pages

Explanation

The physical writes of log entries take too long. There is the risk of a bottleneck.

User Response

Check the reads and writes in the disk area or device on which the log volumes are located. If possible, only the log entries should be made here, and no other reads or writes. In certain circumstances, you may need to move the log volumes to a quicker device.


Max log queue filling (MaxDB: Database Analyzer)

Max log queue filling

Max log queue filling: <percentage>%

Explanation

The fill level of the log queue is high. If the fill level reaches 100%, you risk a log queue overflow.

User Response

Check the value of the special database parameter LOG_IO_QUEUE, and increase it, if possible.

Check the performance of the hard disk on which the log volumes are located.


Number of cached history pages (MaxDB: Database Analyzer)

Number of cached history pages

Number of cached history pages (<number>) exceeds number of cached OMS pages (<number>)

Explanation

This message can occur only for liveCache instances.

In the [image] data cache, the number of history pages is higher than the number of OMS data pages.

User Response

Search for old [image] OMS versions and transactions that prevent the history pages from being deleted in the data cache.

Check whether the reports /SAPAPO/OM_REORG_DAILY and /SAPAPO/OM_DELETE_OLD_SIMSESS are being executed at regular intervals (see also [image] Monitoring OMS Versions).).


Number of physical reads (MaxDB: Database Analyzer)

Number of physical reads

Number of physical reads: <count>

Explanation

A large number of physical reads are being made on the volumes of the database instance, since the data requested by the applications was not found in the data cache.

User Response

If a table is accessed for the first time, or if it has not been used for a long time, and was therefore displaced from the data cache, then this situation is not a problem.

However, if this does not explain the read activity, check the hit rate for the data cache, and increase the size of the data cache, if necessary.

Also make sure that the SQL statements specified by the application do not read significantly more data than needed for processing, because of poor search strategies, for example.

If the special database parameter LRU_FOR_SCAN has the value yes, then table scans use only 10% of the data cache for caching the table. This could mean that it was not possible to hold the entire table in the data cache, and the next scan has to read it physically again.


Number of physical writes (MaxDB: Database Analyzer)

Number of physical writes

Number of physical writes: <count>

Explanation

Not all of the data used by the applications can be held in the data cache. This causes pages from the data cache to be displaced to the data area, which means that there are a large number of writes to the data volumes.

This phenomenon is almost unavoidable if load times (data import) are long, since the imported data is usually much larger than the size of the data cache.

Also, a savepoint also writes modified pages from the data cache to the data area at regular intervals. Read and write activity increases significantly at this time, without causing a genuine bottleneck. In normal operations, you should not be able to measure any significant write activities other than the savepoints.

User Response

If you notice a high level of write activity in normal operations, first make sure that no savepoint was active during the measurement interval (which is possibly too short).

If no savepoint was active, increase the size of the data cache.


Number of physical writes of temporary pages (MaxDB: Database Analyzer)

Number of physical writes of temporary pages

Number of physical writes of temporary pages: <count>

Explanation

When temporary data pages are generated to build (buffer) sets of results (in JOINS or ORDER BY statements, for example), the data cache is not large enough for the temporary pages, and they have to be swapped into the data area. However, these pages must be exported out of the data area again for the further processing of the SQL statement.

User Response

Find the statement that causes these large amounts of (buffer) results to be created, and check the access strategies for this statement.

For information on creating optimized SQL statements, see the SQL Optimizer documentation.


OMS cache hitrate (MaxDB: Database Analyzer)

OMS cache hitrate

OMS cache hitrate <percentage>%, <number> of <number of> accesses failed

Explanation

This message can occur only for liveCache instances.

The hit rate when accessing the [image] OMS data in the [image] data cache is too low. In a running liveCache application, the hit rate should not fall below 100%, otherwise the data must be read physically.

The hit rate may fall for short periods of time, for example, when objects are accessed for the first time.

User Response

Check the following points:

Load in the data cache

The size of the plan version

Long-running [image] OMS versions

Configuration of the liveCache instance and the hardware


OMS heap collisions (MaxDB: Database Analyzer)

OMS heap collisions

OMS heap collision rate <percentage>%, <number of> collisions during <number of> heap allocations/deallocations

Explanation

This message can occur only for liveCache instances.

Tasks that run in different threads attempt to request or release memory from the [image] OMS heap in parallel. This causes an increase in the number of collisions.

User Response

Check whether the parameter [image] OMS_HEAP_COUNT, which determines the number of OMS heap segments, has an optimum value.

Generally, the risk of collisions rises with the number of processors used (general database parameter MAXCPU). Check whether the liveCache instance can fulfill the requirements of the applications with fewer processors. If not, check whether the CPU on the computer is overloaded, and whether the liveCache threads are blocked by other applications running on the computer. In this case, the liveCache threads that contain user tasks should receive REAL TIME PRIORITY from the operating system. However, at the same time, the value of MAXCPU must be at least one lower than the number of real CPUs, to avoid operating system blocks.


OMS heap utilization (MaxDB: Database Analyzer)

OMS heap utilization

OMS heap utilization <percentage>%, used/max: <used_size>/<heap_limit_size> MB

Explanation

This message can occur only for liveCache instances.

The memory requirements in the [image] OMS heap are very high for the running [image] DB procedures.

If the memory utilization in the OMS heap reaches 100%, there is the risk of errors in the DB procedures ( Out Of Memory Exceptions), or that [image] OMS version data is swapped from the OMS heap to the global [image] data cache ( OMS version is unloaded).

User Response

If necessary, increase the size of the OMS heap.

Check whether the configuration of your database instance and hardware meets the requirements of the liveCache application.


OMS history cache hitrate (MaxDB: Database Analyzer)

OMS history cache hitrate

OMS history cache hitrate <percentage>%, <number> of <number of> accesses failed

Explanation

This message can occur only for liveCache instances.

The hit rate when accessing the [image] history data in the [image] data cache is too low. In a running liveCache application, the hit rate should not fall below 100%, otherwise the data must be read physically.

The hit rate may fall for short periods of time, for example, when objects are accessed for the first time.

User Response

Check the following points:

· Load in the data cache

· The size of the plan version

· Long-running [image] OMS versions

· Configuration of the liveCache instance and the hardware


OMS terminates (MaxDB: Database Analyzer)

OMS terminates

<number of> terminates of DB procedure '<DB_procedure_name>' due to errors

Explanation

This message can occur only for liveCache instances.

An error occurred during the execution of the specified [image] DB procedure.

User Response

Use the log files (such as knldiag and lcapo_com_trace_<xy>.txt) to find out the cause of the error.


OMS version is old (MaxDB: Database Analyzer)

OMS version is old

OMS version <OMS_version_ID> is <hours> hours old, uses <number> KB

Explanation

This message can occur only for liveCache instances.

OMS versions are often open for long periods of time and occupy memory in the [image] OMS heap. In this way, the number of [image] history pages grows in the [image] data cache and on the hard disk.

User Response

Find out the OMS version and the fill level of the data cache.

If the fill level of the data cache and the percentage of the history pages are high, try and find out the cause.

Check whether the reports /SAPAPO/OM_REORG_DAILY and /SAPAPO/OM_DELETE_OLD_SIMSESS are being executed at regular intervals (see also [image] Monitoring OMS Versions).).


OMS version is unloaded (MaxDB: Database Analyzer)

OMS version is unloaded

OMS version <OMS_version_ID> is unloaded, uses <number> KB

Explanation

This message can occur only for liveCache instances.

OMS version data was loaded from the [image] OMS heap into the [image] data cache, since the value of one of the two liveCache parameters [image] OMS_HEAP_THRESHOLD or [image] OMS_VERS_THRESHOLD was exceeded.

Performance suffers when accessing the relevant OMS versions, since it takes longer to access the data cache than the OMS heap.

User Response

Check the parameters OMS_HEAP_THRESHOLD and OMS_VERS_THRESHOLD.

If necessary, increase the size of the OMS heap.


Optimizer strategies (MaxDB: Database Analyzer)

Optimizer strategies

<number of> <optimizer_strategy_executes>, selectivity <percentage>%: <number of> rows read, <number of> rows qualified

Explanation

The ratio of read table rows to found table rows is poor when a particular access strategy (<optimizer_strategy_executes>) is used.

The access strategy can be one of the following strategies:

· Primary key accesses
(EQUAL CONDITION FOR KEY COLUMN,
EQUAL CONDITION FOR KEY COLUMN (SUBQ),
IN CONDITION FOR KEY COLUMN)

· Primary key range accesses
(RANGE CONDITION FOR KEY COLUMN,
RANGE CONDITION FOR KEY COLUMN (SUBQ),
IN CONDITION FOR KEY COLUMN)

· Index accesses
(EQUAL CONDITION FOR INDEX,
EQUAL CONDITION FOR INDEX (SUBQ),
IN CONDITION FOR INDEX)

· Index range accesses
(RANGE CONDITION FOR INDEX,
RANGE CONDITION FOR INDEX (SUBQ),
IN CONDITION FOR INDEX)

· Isolated index accesses
see: EXPLAIN Statement: Columns O,D,T,M, column O (Only Index)
and Index accesses

· Isolated index range accesses
see: EXPLAIN Statement: Columns O,D,T,M, column O (Only Index)
and Index range accesses

· Isolated index scans
(INDEX SCAN)

User Response

Find the statement that causes this poor ratio of read rows to found rows, and check the access strategies for this statement.

For information on creating optimized SQL statements, see the SQL Optimizer documentation.

See also: Table scans


Out of memory exceptions (MaxDB: Database Analyzer)

Out of memory exceptions

Out of memory exceptions: <count>

Explanation

This message can occur only for liveCache instances.

DB procedures failed due to too little memory in the [image] OMS heap.

User Response

· Search for more information in the log file knldiag.

Check the [image] OMS versions, and check how much space they occupy in the OMS heap, for example, by using the log files DBAN_OMS_VERSIONS.csv and DBAN_OMS_HEAP.csv.

· Check the OMS heap and, if possible, increase the size of the heap.


Parse activities (MaxDB: Database Analyzer)

Parse activities

Parse activities <percentage>%, <number of> prepares, <number of> commands

Explanation

The number of parse activities in the total number of statements executed is very high.

Before an SQL statement is executed for the first time, it has to be analyzed (parsed) first. When doing this, the database system determines the possible access strategies, and saves the statement to the database instance in a compact form. When the statement is executed again, only this internal information is accessed, and the statement executed directly.

For static SQL statements, the C/C++ precompiler makes sure that the parse activity is performed only once. In applications that are based on ODBC or the C/C++ precompiler, and that use the PREPARE statement, the developer is responsible for the number or parse or EXECUTE requests.

If the JDBC interface is used, and the parse info cache is active, the JDBC interface is responsible for the optimization of the parse requests. However, you must keep the number of PREPARE statements as small as possible here as well.

A high level of parse activity when the database is running can indicate a missing statement cache implementation in your application, or a deactivated parse info cache in the JDBC interface.

A high level of parse activity is normal when programs or program parts are started for the first time.


Physical reads for user task (MaxDB: Database Analyzer)

Physical reads for user task

<number of> physical reads for user task <task_ID>, <number of> commands, application pid <pid>

Explanation

The user task <task_id> makes a large number of physical reads on the volumes of the database instance, since the data requested by the applications was not found in the data cache.

User Response

If a table is accessed for the first time, or if it has not been used for a long time, and was therefore displaced from the data cache, then this situation is not a problem.

However, if this does not explain the read activity, check the hit rate for the data cache, and increase the size of the data cache, if necessary.

Also make sure that the SQL statements specified by the application do not read significantly more data than needed for processing, because of poor search strategies, for example.

If the special database parameter LRU_FOR_SCAN has the value yes, then table scans use only 10% of the data cache for caching the table. This means that the table cannot be held completely in the data cache, and the next scan has to read it physically again.


Selects and Fetches (MaxDB: Database Analyzer)

Selects and Fetches

<number of> selects and fetches, selectivity <percentage>%: <number of> rows read, <number of> rows qualified

Explanation

The strategies for accessing table data are poor for SELECT or FETCH statements. The system has to read a large number of table rows to find a small number of rows that fulfill a WHERE condition.

User Response

Find the statement that causes this poor ratio of read rows to found rows, and check the access strategies for this statement.

For information on creating optimized SQL statements, see the SQL Optimizer documentation.


Table scans (MaxDB: Database Analyzer)

Table scans

<number of> table scans, selectivity <percentage>%: <number of> rows read, <number of> rows qualified

Explanation

The ratio of read rows to found rows is poor for table scans (TABLE SCAN). This often indicates a poor search strategy, caused either by the application (missing or insufficient indexes), or by a problem in the SELECT optimization of the database kernel.

Scanning large tables can have seriously negative effects on the performance of the entire system.

User Response

Find the statement that causes this poor ratio of read rows to found rows, and check the access strategies for this statement.

For information on creating optimized SQL statements, see the SQL Optimizer documentation.


User task blocked in state (MaxDB: Database Analyzer)

User task blocked in state

User task <task_ID> blocked in state '<state_description>'

User task <task_ID> blocked in state '<state description>', DB procedure: <DB_procedure_name>

Explanation

The specified user task is active, however, its task state is not changing. This also blocks all other tasks in the same user kernel thread. In extreme cases, the blocking task may be in an endless loop.


User task physical writes (MaxDB: Database Analyzer)

User task physical writes

User task physical writes: <count>

Explanation

Modified pages are displaced from the data cache to the data area, since not all of the data used by the applications can be held in the data cache.

If the data cache were large enough, the physical write would be delayed to the next savepoint, and be performed asynchronously. Cache displacements, however, use synchronous writes and reads, and should be avoided if possible.

This phenomenon is almost unavoidable if load times (data import) are long, since the volume of imported data is usually much larger than the size of the data cache.

User Response

Increase the size of the data cache.


Configuration File (MaxDB: Database Analyzer)

Configuration File

The configuration file dbanalyzer<version>.cfg defines the rules and commands for how the Database Analyzer determines performance-relevant data.

The Analyzer either takes the performance-relevant data directly from the system tables of the database, or calculates it from these values.

The configuration file also describes the five classes (information, three levels of warnings, error messages) that the Database Analyzer uses to analyze the parameters and log them in the log file. You can specify fixed instructions for how the user should respond to these classes.

Changes to the rules and commands apply to the configuration file only; the Database Analyzer program remains unchanged.


Loader

The following documentation describes the Loader tool, which can be used for Loading and Unloading data.

For general information on the database system MySQL MaxDB, see the Database Administration documentation.

· Architecture of the Loader

· Concepts

· Overview

· Commands and SQL Statements

· Call

· Log Functions

· Commands: Overview and Syntax Rules

· Terms and Procedures


Concepts (MaxDB: Loader)

Concepts

The Loader uses the concepts of the database instance and also its own concepts.

Database Concepts

For all the concepts of the database, see the section Terms and Concepts in the Reference Handbook. In particular, the Loader uses the following concepts:

· Database Catalog

· Application Data

· System Tables

Loader Concepts

· Transformation

· System Tables

The Loader provides you with functions for unloading, loading, and formatting (transforming) data between different data sources and data targets using different data streams.

The range of language of the Loader allows transformation of the data for all users of a database, a user, a table of a user, or a set of qualified columns of a table or multiple tables (Commands for Unloading and Loading).

Media and database instances are supported as physical data sources and physical data targets. You can also use external backup tools to unload or load all your application data or the entire database catalog (see Unloading with External Backup Tools and Loading with External Backup Tools).

The Loader uses metadata, which can be in different formats, for the logical description of data and its transformation.

When the system tables are filled, this can, among other things, be used for restarting a transformation.


Transformation (MaxDB: Loader)

Transformation

The Loader provides you with functions for unloading, loading, and formatting data between different data sources and data targets using data streams.

This action is known as a transformation and is described using entries in the Loader-specific system tables.

A transformation is identified using Loader and database instance details, a transformation type, the required part of the database catalog, and the data streams.

· Loader connection:
Server node, database name, user name, password, SQL mode, ASCII code page, transaction size, MaxErrorCount, backup tool

· Database connection:
Server node, database name

· Transformations type:
EXTRACT: Data is to be unloaded.
LOAD: Data is to be loaded.
UPDATE Data is to be changed.

· Part of the database catalog:
You can define the scope of the database catalog objects of a database instance involved in a transformation.
ALL: Entire database catalog
USER: Part of the database catalog that belongs to the specified user
TABLE: Part of the database catalog that belongs to the specified table
You can specify a set of qualified columns of one or more tables.
You can determine the commands and their runtime information from the system tables for the parts of the database catalog specified using ALL and USER.

· Data Stream


System Tables (MaxDB: Loader)

System Tables

One important log function of the Loader is storing Loader-relevant information in system tables.

When you install the database system, the following system tables are created for the Loader:

· CODEPAGE

· TRANSFORMATIONMODEL

· TRANSFORMATIONMONITOR

· TRANSFORMATIONPACKAGES

· TRANSFORMATIONRESOURCES

· TRANSFORMATIONSTATISTICS

· TRANSFORMATIONSTEPS

The owner of these system tables is the SYSDBA user. You do not need to specify the owner when you access these tables.

The Loader logs information on the runtime responses of unload and load processes in the TRANSFORMATION system tables. If you perform a load or unload process that spans multiple tables, the system tables are filled with the corresponding information.

You can also configure a transformation using the system tables.

The Loader uses the entries in the system tables to restart commands. You can use this ability to restart by using the RESTART option (restart) of the command.


Overview (MaxDB: Loader)

Overview

Follow the links below for information on commands, call options, and log functions of the Loader.

Commands and SQL Statements

· Commands for Creating a Database Session

· Commands for Loading and Unloading

· SQL Statements

Call

· Call with the Loader CLI (LOADERCLI)

· Call with the Perl Interface of the Loader

· Call with the Python Interface of the Loader

· Call with the Java Interface of the Loader

Log Functions

· Log File

· System Tables


Commands and SQL Statements (MaxDB: Loader)

Commands and SQL Statements

The Loader can execute commands and SQL statements.

· Commands for creating a database session
The commands and SQL statements for loading and unloading can only be executed after a database session has been successfully created.This ensures that only suitably authorized owners can load and unload.

· Commands for unloading and loading
An important function of the Loader is unloading and loading the database catalog, parts of the database catalog, and application data.

· SQL statements
The Loader can execute the SQL statements required for loading and unloading.


Commands for Creating a Database Session (MaxDB: Loader)

Commands for Creating a Database Session

The Loader can process a range of commands and SQL statements, including commands for creating a database session:

· AUTOCOMMIT Command

· SET Command

· SQLMODE Command

· USE SERVERDB Command

· USE USER Command


Commands for Unloading and Loading (MaxDB: Loader)

Commands for Unloading and Loading

The Loader can process a range of commands and SQL statements, including commands for unloading and loading data.

The range of language of the Loader allows you load or unload, in increasing granularity, a complete database, the objects of a user, individual tables, or a set of columns of a table.

What do you want to unload or load? | Loader Commands
Database catalog and application data | DBEXTRACT/DBLOAD You can use external backup tools to unload or load the data.
Database catalog | CATALOGEXTRACT ALL/CATALOGLOAD ALL You can use external backup tools to unload or load the data.
Database catalog objects and the application data of a user | CATALOGEXTRACT USER/CATALOGLOAD USER TABLEEXTRACT USER/TABLELOAD USER
Tables | CATALOGEXTRACT TABLE/CATALOGLOAD TABLE TABLEXTRACT TABLE/TABLELOAD TABLE DATAEXTRACT/DATALOAD
Set of qualified columns of a table | DATAEXTRACT/DATALOAD FASTLOAD DATAUPDATE

See also:


Examples of DATALOAD Commands (MaxDB: Loader)

Examples of DATALOAD Commands

DATALOAD TABLE sqltravel20.reservation IF POS 4 >= '11.08.1999"
rno 1
cno 2
hno 3
arrival 4
departure 5
roomtype 6
INSTREAM 'reservation.data'
DATE 'dd.mm.yyyy'

DATALOAD TABLE sqltravel10.room
IF (POS 41-44 REAL < '400.00')
AND
(POS 41-44 REAL >= '50.00')
nno 01-04 INTEGER
roomtype 09-15
price 41-44 REAL
INSTREAM 'room.data' FORMATTED

DATALOAD TABLE edemo.products
productid 01-10
productname 11-51 NULL IF POS 10-12 = ' '
unitinstock 52-55 INTEGER NULL IF POS 52-55 INTEGER < '0'
unitprice 60-67 DECIMAL (2) NULL IF POS 60 <> 'X'
OR POS 60-67 DECIMAL < '0'
INSTREAM 'products.data' FORMATTED

DATALOAD TABLE edemo.suppliers
supplierid 1
phone 2 DEFAULT NULL
address 3 DEFAULT NULL
INSTREAM 'suppliers.data'
NULL '- '

DATALOAD TABLE edemo.orders
oderid 1
orderdate DATE
requireddate 2
INSTREAM 'orders.data'


SQL Statements (MaxDB: Loader)

SQL Statements

The Loader includes all functions (see Commands and SQL Statements) required for processing SQL statements, particularly for unloading and loading data. DDL statements, in particular, are vital for loading data (Reference Manual: Section SQL Statements: Overview).

Database queries, however, return only status messages.

COMMIT and ROLLBACK statements are only active in the mode AUTOCOMMIT OFF (AUTOCOMMIT Command).


Call (MaxDB: Loader)

Call

The Loader processes commands and SQL statements. Commands and SQL statements can be processed in the background or be embedded in programming languages.

The way in which the Loader Server is called varies, depending on which client of the Loader you are using.

· Call with the Loader CLI (LOADERCLI)

· Call with the Perl Interface of the Loader

· Call with the Python Interface of the Loader

· Call with the Java Interface of the Loader

See also:

Syntax Rules for Calling the Loader

This documentation contains only a short summary of the functions of the script languages that can be used in the Loader. For more information, see the vendor documentation for Perl, Python, or Java.


Call with the Loader CLI (LOADERCLI) (MaxDB: Loader)

Call with the Loader CLI (LOADERCLI)

You can call the Loader using the Loader CLI client (LOADERCLI).

Call

loadercli [<options>]

You can specify options when you call the Loader.Note the following options in particular:

· You can use the option -r to decide whether you want to use the Loader Server embedded in the Loader CLI, or the Loader Server that is separate from the Loader CLI.

· You can use the option -b to specify the operating mode. This determines whether the commands and SQL statements are processed interactively or in the background.

Process Flow

Before it connects to the database instance, the Loader CLI first evaluates the relevant options. The commands and SQL statements in the command file (or those entered interactively) are then executed.

Calling the separate Loader (server and client in one program), which then processes the commands and SQL statements in the background

loadercli -d demodb -u sqltravel01,travel01 –b command.dat -E 20

The Loader creates a connection to the database instance demodb for the user sqltravel01. The Loader processes the commands and statements contained in the command file command.dat. If errors occur (return code <> 0), the processing of the command file is terminated as soon as 20 error messages occur.

Calling the Loader Server separately from the Loader CLI on the local host. The Loader Server then processes the commands and SQL statements in the background.

loadercli –d demodb -u sqltravel01,travel01 –r loaderhost -b command.dat -E 20

The Loader CLI creates a connection to the Loader Server on the local host loaderhost. The Loader Server creates a connection to the database instance demodb for the user sqltravel01. The Loader processes the commands and statements contained in the command file command.dat. If errors occur (return code <> 0), the processing of the command file is terminated as soon as 20 error messages occur.

Calling the separate Loader (server and client in one program), which then processes the commands and SQL statements interactively

loadercli –d demodb -u sqltravel01,travel01

The Loader creates a connection to the database instance demodb for the user sqltravel01. The Loader then waits for the commands and SQL statements in the command line, and processes them.

Result

The Loader executes the commands and SQL statements. The Loader writes a log file.

Errors

If errors occur when commands or SQL statements are processed, the way in which the Loader responds depends on whether it is running interactively or in the background.

If you are using the Loader in interactive mode, it registers the error, and then waits for your next entry.

If you are using the Loader in the background, it stops processing commands and SQL statements after a defined number of errors, and exits.You can use the option –E to define the number of errors that the Loader ignores before it stops processing commands.If you do not use the option –E, the Loader stops running after the first command with an error. You cannot react to the errors when you are using the Loader CLI.

If you want to respond to errors, the Loader functions are available as a library for the Perl and Python script languages.

See also:
Call with the Perl Interface of the Loader
Call with the Python Interface of the Loader


Options (MaxDB: Loader)

Options

When you call the Loader using the Loader CLI (LOADERCLI), you can specify the following options (loadercli [<options]):

Options

-b <command_file> | Name of the command file, specify the operating mode
-d <database_name> | Name of the database instance
-u <user_name>,<password> | User name and password
-n <database_server> | Database server
-r <loader_server> | Name of the local Loader server, if you want to call the Loader CLI and Loader Server separately
-E <number> | Maximum permitted number of errors
-o[w|a] <file_name> | Name of the output file
-p <number><substitution_string> | Specifies a substitution parameter
-cs <command_separator> | Specifies a command separator
-R <directory_name> | Directory that contains the programs that depend on the version of the database software
-V | Version of the Loader
-v | Version of the Loader CLI
-h | Help

Use

When you call the Loader, you usually enter the name of the user (option -u) and the database instance (option -d). This creates a connection to the specified database instance for this user.

You can specify all required commands and SQL statements in a command file (option -b), or you can enter them interactively.

loadercli -d demodb -u sqltravel01,travel01 -b command.dat

You can also call the Loader without options, or by specifying only a database instance name (option -d). In this case, you must transfer all other commands for creating a database session in the command file. This creates the connection between the Loader and this database instance or another database instance.


Command File: -b (MaxDB: Loader)

Command File: -b

Option for calling the Loader with LOADERCLI to transfer the name of the command file and for setting the operating mode.

Syntax

-b <command_file>

<command_file>

Command File

Use

When you specify this option, the Loader CLI gets the commands and SQL statements from the specified command file and sends them to the Loader Server. The Loader CLI is in background mode.

If you do not specify this option, the Loader CLI opens an interactive session.


Command Separator: -cs (MaxDB: Loader)

Command Separator: -cs

Option for calling the Loader with LOADERCLI for transferring the command separator used.

Syntax

-cs <command_separator>

<command_separator>

Command_separator: minimum 1 character, maximum 2 characters

Use

You use this entry to specify which characters are recognized as command separators by LOADERCLI. This definition applies for the interactive operating mode of the LOADERCLI, as well as for the command file.

If the option -cs is not specified, a line that begins with a double slash is expected as a command separator (Syntax Rules for the Command File).


Database Instance: -d (MaxDB: Loader)

Database Instance: -d

Option for calling the Loader with LOADERCLI to transfer the name of the database instance.

Syntax

-d <database_name>

<database_name>

Name of the database instance to which a database user wants to connect

Use

The Loader creates a connection to the specified database instance. When it does this, the Loader executes the Loader command USE SERVERDB implicitly, or the Loader command USE USER, if both database instance name and user data have been specified.

You can also specify the name of the database instance with the commands USE SERVERDB or USE USER. This enables you to change the name during the Loader session.


User Data: -u (MaxDB: Loader)

User Data: -u

Option for calling the Loader with LOADERCLI for transferring user data

Syntax

-u [<user_name>,<password>]

<user_name> | User name (see database user)
<password> | User password

If you use –u without specifying <user_name>,<password>, then the Loader prompts you for a user name/password combination. This is how you avoid displaying the user password in the command line, command history, or process list of the operating system.

Prerequisite

At the same time, you use the option –d to specify a database instance.

Use

A database session is created for the specified user. At the same time, the Loader executes the Loader command USE USER implicitly. The database system automatically converts the user name and password to uppercase letters.

You can also use the command USE USER to specify user data.This enables you to change users during a Loader session.


Database Server: -n (MaxDB: Loader)

Database Server: -n

Option for calling the Loader with LOADERCLI for transferring the server name.

Syntax

-n <database_server>

<database_server>

Node name of the server on which the database instance is located.
Default value: name of the local server

Prerequisite

At the same time, you are using the option –d or –d and –u.

Use

The Loader creates a connection to the database instance on the specified server. When it does this, the Loader executes the Loader command USE SERVERDB implicitly, or the Loader command USE USER, if both database instance name and user data have been specified.

You can also use the command USE SERVERDB or USE USER to specify the name of the database server.


Loader Server: -r (MaxDB: Loader)

Loader Server: -r

Option when calling the Loader with LOADERCLI; use this option to control whether the Loader is started as a client-server application or as a separate program.

Syntax

-r <loader_server>

<loader_server>

Name of the local server on which the Loader CLI and the Loader Server are located

Use

If the option -r <loader_server> is specified, the Loader CLI creates a network connection to the Loader Server (both programs are on the local server) and sends all commands that need to be executed to the Loader Server.

If the option –r is not specified, the Loader CLI uses the embedded Loader Server to execute the commands. In this case, there is no network communication between the Loader CLI and the Loader Server.


Maximum Permitted Number of Errors: -E (MaxDB: Loader)

Maximum Permitted Number of Errors: -E

Option for calling the Loader with LOADERCLI for transferring the permissible number of errors

Syntax

-E <number>

<number>

Permitted number of commands with errors

Prerequisite

At the same time, you use the option –b to specify a command file. This option is ignored in the interactive operating mode.

Use

You use this option to specify after how many commands with errors the Loader stops processing the command file.


Output File: -o[w|a] (MaxDB: Loader)

Output File: -o[w|a]

Option for calling the Loader with LOADERCLI for specifying the output file

Syntax

-o[w|a] <file_name>

<file_name>

Name of the file to which the output of the Loader is to be written
Default value: Screen

Prerequisite

At the same time, you are using the option –b to specify a command file. If you specify this option in the interactive operating mode, an error is generated.

Use

The output of the Loader is written to the specified file.

Option -ow

The file is opened and any existing entries are deleted.

Option -oa

The file is opened and the outputs are appended to the end of the file without any previous entries being deleted.

This option refers only to output from the Loader. Despite this, the program still writes a log file.


Substitution Parameter: -p (MaxDB: Loader)

Substitution Parameter: -p

Option for calling the Loader with LOADERCLI for transferring a substitution parameter.

Syntax

-p<number> <substitution_value>

<number> | Defines the number n of the placeholder you want to substitute in the command file, where 1<=n<=9.
<substitution_value> | Value that substitutes the placeholder in the command file

Prerequisite

At the same time, you are using the option –b to specify a command file. This option is ignored in the interactive operating mode.

Use

You use this option to specify values for placeholders in the command file. These values can be any character strings. You can specify nine different parameters (and placeholders) for each command file.

In the command file, enter the placeholder in the form &<number>.

Entry in the command file:

DATAEXTRACT FOR DATALOAD TABLE customer OUTFILE '&1' OUTFILE 'customer.data'
DATAEXTRACT FOR FASTLOAD TABLE article OUTFILE '&1' APPEND OUTFILE 'article.data'

You can specify the name of the command file with the call of the Loader CLI, using the option –p :

loadercli ... –p1 command.dat


Dependent Directory: -R (MaxDB: Loader)

Dependent Directory: -R

Option for calling the Loader with LOADERCLI for setting up the connection to the Loader

Syntax

-R <dependent_path>

<dependent_path>

Name of the directory on the loader server that contains the programs that are dependent on the version of the database software
Default value: none

Use

If multiple versions of the Loader are installed on the server, you can start a specific version of the Loader. If you do not specify a directory name, the Loader for the newest version of the database software is started.


Loader Version: -V (MaxDB: Loader)

Loader Version: -V

Option when calling the Loader with LOADERCLI to determine the version of the Loader Server

Syntax

-V


LOADERCLI Version: -v (MaxDB: Loader)

LOADERCLI Version: -v

Option when calling the Loader with LOADERCLI to determine the version of the client of the Loader CLI (LOADERCLI)

Syntax

-v


Help: -h (MaxDB: Loader)

Help: -h

Option for displaying information (help) for all available options when calling the Loader with LOADERCLI

Syntax

-h


Command File (MaxDB: Loader)

Command File

When you call the Loader with the LOADERCLI, you can store the commands and SQL statements that are to be evaluated in a special file, the command file.

When you call the Loader, you specify the option –b to transfer the name of the command file.

loadercli -d demodb -u sqltravel01,travel01 -n DBHost -b command.dat

The commands and SQL statements are in the file command.dat.

Use

The commands and SQL statements in the command file that you specify are individually processed by the Loader in the specified order.

See also:

Syntax Rules for Command Files


Syntax Rules for Command Files (MaxDB: Loader)

Syntax Rules for Command Files

Note the following syntax rules for command files.

General Syntax Rules for Calling the Loader

Syntax Rules for Calling the Loader

Delimiting Lines Between Commands

Individual commands in a command file are separated by a line, at the beginning of which there is a double forward slash //.

When calling the LOADERCLI, you can use the option –cs to define an alternative command separator.

Comments

After a double forward slash // at the start of the line, you can enter comments. The comments are ignored by the Loader during the processing of the command file.

CREATE TABLE customer
(cno FIXED(4,0) NOT NULL,
title CHAR(7),
firstname CHAR(10),
name CHAR(10) NOT NULL,
zip CHAR(5),
address CHAR(25) NOT NULL,
PRIMARY KEY (cno),
CONSTRAINT cno_dom CHECK cno BETWEEN 1 AND 9999,
CONSTRAINT title CHECK title IN ('Mr','Mrs','Company'),
CONSTRAINT zip_dom CHECK
SUBSTR(ZIP,1,1) BETWEEN '1' AND '9' AND
SUBSTR(ZIP,2,1) BETWEEN '0' AND '9' AND
SUBSTR(ZIP,3,1) BETWEEN '0' AND '9' AND
SUBSTR(ZIP,4,1) BETWEEN '0' AND '9' AND
SUBSTR(ZIP,5,1) BETWEEN '0' AND '9',
FOREIGN KEY city_customer (zip) REFERENCES city (zip) ON DELETE RESTRICT
//
DATALOAD TABLE customer
cno 1 CHAR
title 2 CHAR DEFAULT NULL
firstname 3 CHAR DEFAULT NULL
name 4 CHAR
zip 5 CHAR DEFAULT NULL
address 6 CHAR
INSTREAM 'customer.data'
//create index
CREATE INDEX customer_index ON customer (name)
//
DATAEXTRACT cno, name, zip, address from customer
OUTFIELDS
cno 1
name 2
zip 3
address 4
OUTSTREAM 'newcustomer.data'


Call with the Perl Interface of the Loader (MaxDB: Loader)

Call with the Perl Interface of the Loader

You can call the Loader by processing a Perl script.

Prerequisites

Perl is installed on the host.

The following Perl modules are delivered with the Loader program, and allow you to create Perl scripts that can be processed by the Loader:

· Windows: loaderaperl.dll, loader.pm, instperl.pl

· UNIX: loadercperl.so, loader.pm, instperl.pl

· HP : loadercperl.sl, loader.pm, instperl.pl

Open the instperl.pl file. When you do this, the files are copied to the relevant directories.

Call

perl <perl_script_file> [<argument> ...]

You have the option of specifying arguments <argument>.

Frequently used arguments:

<user_name> <password> | User name (Database User) Password The database system automatically converts the user name and password into uppercase letters.
<database_name> | Name of the database instance
<data_path> | Directory in which the data file is stored
<server_node> | Name of the server on which the Loader is located

perl sample samplename secret TST C:\data\sapdb

The Perl script sample is called. The logon to the Loader is performed for the user samplename on the database instance TST. The data file is in the directory C:\data\sapdb.

Template for Background Files

The following section contains examples of background files in Perl. Their equivalents in the Python script language are also provided for comparison.

Example 1 Build a Perl module with reference to the Perl Libraries, parse the call arguments | Perl | Python
Example. 2 Set up a database session with the Loader Log on to the database instance, Log off | Perl | Python
Example no. 3 Start a database session Log on to the database instance Query error code to determine whether table exists Create a table without querying the error code Log off | Perl | Python
Example no. 4 Start a database session Log on to the database instance Create a table and query the error code Load data into the table using commands and query the error code Log off | Perl | Python
Example no. 5 Start a database session Log on to the database instance Load data to the table using commands and intercept exceptions Log off | Perl | Python

Perl Classes


Perl Classes (MaxDB: Loader)

Perl Classes

To Call the Loader with Perl Scripts, you use the following classes:

· Loader Class

· Exception Classes


Perl: Loader Class (MaxDB: Loader)

Perl: Loader Class

Constructor: Loader (<server_node>, <database_name>)

<server_node> | Server node name
<database_name> | Name of the database instance

Establishing a connection to the Loader.

If the server node name and name of the database instance are specified, the system assumes that the database instance, data, and Loader are located on a remote server.

If only the name of the database instance is specified, the system assumes that the database instance, data, and Loader are located on the local server. The suitable Loader is determined from the version of the specified database instance.

If neither the server node name nor the name of the database instance is specified, the system establishes a connection to the newest Loader on the local system.

The session is closed again when the object is deleted with undef $session.

$session = loader::Loader ('p12345', 'mydb')

Method: cmd (<command_string>)

An SQL statement or Loader command is executed.

The script is terminated if the command fails.

$output = $session->cmd ("DATALOAD TABLE kunde".
                        "cno       1-4".
                           "name      6-12  ".
                           "zip       14-18 ".
                           "city      20-31 ".
                        "INFILE '$data_path\customer.dat' ")

Method: sql (<command_string>)

An SQL statement or a Loader command is executed.

If a command fails, execution of the script is terminated.

If an SQL statement fails, a return code is output.

$result = $session->sql ('EXISTS TABLE MYTABLE')


Perl: Exception Classes (MaxDB: Loader)

Perl: Exception Classes

An exception is a string beginning with either CommunicationError or LoaderServError.

LoaderServError: 25011 SQL error -3005 = Invalid SQL Statement

Example of use in a script:

eval {$session->cmd ('complete nonsense;') };
if ($@) { print "command failed: $@\n"; }

Print output:

command failed: LoaderServError: 25011 SQL error -3005 = Invalid SQL Statement


Perl: Example 1 (MaxDB: Loader)

Perl: Example 1

Example of Calling the Loader with Perl Script

Create a Perl module with reference to the Perl Libraries,
Parse the call arguments:

# Reference to the Perl Library
# -------------------------------

use SAP::DBTECH::loader;

# Parse the call arguments
# --------------------------

$user_name = $ARGV[0];
$password = $ARGV[1];
$database_name = $ARGV[2];
$data_path = $ARGV[3];
$server_node = "localhost";


Perl: Example 2 (MaxDB: Loader)

Perl: Example 2

Example of Calling the Loader with Perl Script

Start a database session with the Loader,
Log on to the database instance,
Log off

# Reference to the Perl Library
# -------------------------------

use SAP::DBTECH::loader;

# Parse the call arguments
# --------------------------

$user_name = $ARGV[0];
$password = $ARGV[1];
$database_name = $ARGV[2];
$data_path = $ARGV[3];
$server_node = "localhost";

# Create a database session for the Loader
# -------------------------------------------

$session = loader::Loader ($server_node, $database_name);

# Log on to the database instance
# --------------------------------

$session->cmd("use user $user_name $password;");

# Log off
# --------

undef $session


Perl: Example 3 (MaxDB: Loader)

Perl: Example 3

Example of Calling the Loader with Perl Script

Start a database session,
Log on to the database instance,
Query error code to determine whether table exists
Create a table without querying the error code
Log off

# Reference to the Perl Library
# -------------------------------

use SAP::DBTECH::loader;

# Parse the call arguments
# --------------------------

$user_name = $ARGV[0];
$password = $ARGV[1];
$database_name = $ARGV[2];
$data_path = $ARGV[3];
$server_node = "localhost";

# Create a database session for the Loader
# -------------------------------------------

$session = loader::Loader ($server_node, $database_name);

# Log on to the database instance
# --------------------------------

$session->cmd("use user $user_name $password;");

# Query whether the table exists by querying the error code
# The sql method is used to do this
# -------------------------------------

$rc = $session->sql('EXISTS TABLE CUSTOMER')

If $rc!=0

# Create the table CUSTOMER
# -------------------------

$session->cmd ( 'CREATE TABLE customer ( '.
                    'cno             FIXED(4), '.
                    'name            CHAR(10) ASCII, '.
                    'zip             CHAR(5)  ASCII, '.
                    'city            CHAR(12) ASCII, '.
                    'PRIMARY KEY (cno) ')

# End the database session
# ----------------------------

undef $session


Perl: Example 4 (MaxDB: Loader)

Perl: Example 4

Example of Calling the Loader with Perl Script

Start a database session
Log on to the database instance
Create a table and query the error code
Load data to the table using Loader commands and query the error code
Log off

# Reference to the Perl Library
# -------------------------------

use SAP::DBTECH::loader;

# Parse the call arguments
# --------------------------

$user_name = $ARGV[0];
$password = $ARGV[1];
$database_name = $ARGV[2];
$data_path = $ARGV[3];
$server_node = "localhost";

# Create a database session for the Loader
# -------------------------------------------

$session = loader::Loader ($server_node, $database_name);

# Log on to the database instance
# --------------------------------

$session->cmd("use user $user_name $password;");

$rc = $session->sql('EXISTS TABLE CUSTOMER')

If $rc!=0

# Create the table CUSTOMER
# -------------------------

$session->cmd ( 'CREATE TABLE customer ( '.
                      'cno            FIXED(4), '.
                      'name           CHAR(10) ASCII, '.
                      'zip            CHAR(5)  ASCII, '.
                      'city           CHAR(12) ASCII, '.
                      'PRIMARY KEY (cno) ')

print $rc

If $rc==0

# Load the table CUSTOMER
# -------------------------

$loadrc = $session->cmd ("DATALOAD TABLE customer".
                           "cno       1-4   ".
                           "name      6-12  ".
                           "zip       14-18 ".
                           "city      20-31 ".
                           "INFILE $data_path\customer.dat" )

print $loadrc

# End the database session
# ----------------------------

undef $session


Perl: Example 5 (MaxDB: Loader)

Perl: Example 5

Example of Calling the Loader with Perl Script

If a command is changed at runtime, for example, because user inputs are part of the command, syntax errors can easily occur.
The SQL method only provides SQL error codes. You need exceptions to intercept syntax errors in the DATALOAD command.

Start a database session
Log on to the database instance
Load data to the table using Loader commands and intercept exceptions
Log off

An incorrect data path in the following example can lead to a syntax error or data access error.

# Reference to the Perl Library
# -------------------------------

use SAP::DBTECH::loader;

# Parse the call arguments
# --------------------------

$user_name = $ARGV[0];
$password = $ARGV[1];
$database_name = $ARGV[2];
$data_path = $ARGV[3];
$server_node = "localhost";

# Create a database session for the Loader
# -------------------------------------------

$session = loader::Loader ($server_node, $database_name);

# Log on to the database instance
# --------------------------------

$session->cmd("use user $user_name $password;");

# Example of Exception Handling
# -----------------------------

eval{
    $loadrc=$session->sql ("DATALOAD TABLE customer ".
                            "cno       1-4    ".
                            "name      6-12   ".
                            "zip       14-18  ".
                            "city      20-31  ".
                            "INFILE $data_path\customer.dat" );
    print "$loadrc\n";}
if ($@){
    print "command failed: $@\n";
}

# End the database session
# ----------------------------

undef $session


Call with the Python Interface of the Loader (MaxDB: Loader)

Call with the Python Interface of the Loader

You can call the Loader by processing a Python script.

Prerequisites

The following Python modules are delivered with the Loader program, and allow you to create Python scripts that can be processed by the Loader:

· Windows: loader.pyd

· UNIX: loadermodule.so

· HP: loadermodule.sl

These are the modules you need to use the Loader functions. You do not need a complete PYTHON installation.

If you already have a PYTHON installation, add %INSTROOT%\misc to the PYTHONPATH variable.

The Loader supports PYTHON as of version 1.5.2.

Call

x_python <python_script_file> [<argument>...]

You have the option of specifying arguments <argument>.

Frequently used arguments:

<user_name> <password> | User name (Database User) Password The database system automatically converts the user name and password into uppercase letters.
<database_name> | Name of the database instance
<data_path> | Directory in which the data file is stored
<server_node> | Name of the server on which the Loader is located

X_python sample samplename secret TST C:\data\sapdb

The Python script sample is called. The logon to the Loader is performed for the user samplename on the database instance TST. The data file is in the directory C:\data\sapdb.

Template for Background Files

The following section contains examples of background files in Python. Their equivalents in the Perl script language are also provided for comparison.

Example 1 Build a Python module with reference to the Python Libraries, parse the call arguments | Python | Perl
Example. 2 Set up a database session with the Loader Log on to the database instance, Log off | Python | Perl
Example no. 3 Start a database session Log on to the database instance Query error code to determine whether table exists Create a table without querying the error code Log off | Python | Perl
Example no. 4 Start a database session Log on to the database instance Create a table and query the error code Load data into the table using commands and query the error code Log off | Python | Perl
Example no. 5 Start a database session Log on to the database instance Load data to the table using commands and intercept exceptions Log off | Python | Perl

Python Classes


Python Classes (MaxDB: Loader)

Python Classes

To Call the Loader with Python Scripts , you use the following classes:

· Loader Class

· Exception Classes


Python: Loader Class (MaxDB: Loader)

Python: Loader Class

Constructor: Loader (<server_node>, <database_name>)

<server_node> | Server node name
<database_name> | Name of the database instance

Establishing a connection to the Loader.

If the server node name and name of the database instance are specified, the system assumes that the database instance, data, and Loader are located on a remote server.

If only the name of the database instance is specified, the system assumes that the database instance, data, and Loader are located on the local server. The suitable Loader is determined from the version of the specified database instance.

If neither the server node name nor the name of the database instance is specified, the system establishes a connection to the newest Loader version on the local system.

The session is closed again when the object is deleted with del session.

session = loader.Loader ('p12345', 'mydb')

Method: cmd (<command_string>)

An SQL statement or Loader command is executed.

The script is terminated if the command fails.

output = session.cmd ("""DATALOAD TABLE customer
                     cno       1-4
                     name      6-12
                     zip      14-18
                     city     20-31
                     INFILE '%s\customer.dat' """ %data_path)

Method: sql (<command_string>)

An SQL statement or a Loader command is executed.

If a command fails, execution of the script is terminated.

If an SQL statement fails, a return code is output.

result = session.sql ('EXISTS TABLE MYTABLE')


Python: Exception Classes (MaxDB: Loader)

Python: Exception Classes

Class: CommunicationError

Establishing a connection to the Loader has failed.

The value of the exception is an instance with the following attributes:

· errorCode

· message

Class: LoaderServError

The command failed.

The value of the exception is an instance with the following attributes:

· errorCode(Loader error number)

· message(Loader error text)

· sqlCode (SQL error number if an SQL command fails, otherwise 0)

· sqlMessage (SQL error text if an SQL command fails, otherwise 0)


Python: Example 1 (MaxDB: Loader)

Python: Example 1

Example of calling the Loader with Python Script

Build a Python module with reference to the Python Libraries,
parse the call arguments:

# Reference to the Python Libraries
# ---------------------------------

import sys
import loader

# Parse the call arguments
# --------------------------

user_name = sys.argv [1]
password = sys.argv [2]
database_name = sys.argv [3]
data_path = sys.argv[4]
server_node = ''


Python: Example 2 (MaxDB: Loader)

Python: Example 2

Example of calling the Loader with Python Script

Start a database session with the Loader,
Log on to the database instance,
Log off

# Reference to the Python Libraries
# ---------------------------------

import sys
import loader

# Parse the call arguments
# --------------------------

user_name = sys.argv [1]
password = sys.argv [2]
database_name = sys.argv [3]
data_path = sys.argv[4]
server_node = ''

# Create a database session for the Loader
# ----------------------------------------

session = loader.Loader (server_node, database_name)

# Log on to the database instance
# --------------------------------

session.cmd ('use user %s %s;' % (user_name, password))

# Log off
# --------

del session


Python: Example 3 (MaxDB: Loader)

Python: Example 3

Example of calling the Loader with Python Script

Start a database session,
Log on to the database instance,
Query error code to determine whether table exists
Create a table without querying the error code
Log off

# Reference to the Python Libraries
# ---------------------------------

import sys
import loader

# Parse the call arguments
# --------------------------

user_name = sys.argv [1]
password = sys.argv [2]
database_name = sys.argv [3]
data_path = sys.argv[4]
server_node = ''

# Create a database session for the Loader
# ----------------------------------------

session = loader.Loader (server_node, database_name)

# Log on to the database instance
# --------------------------------

session.cmd ('use user %s %s;' % (user_name, password))

# Query whether the table exists by querying the error code
# The sql method is used to do this
# -------------------------------------

rc = session.sql("EXISTS TABLE CUSTOMER")

If rc!=0

   # Then branch of the If statement must be indented in Python
   # Create the table CUSTOMER
   # ----------------------------------------------------------

   session.cmd ( """CREATE TABLE customer (
                       cno             FIXED(4),
                       name            CHAR(10) ASCII,
                       zip             CHAR(5)  ASCII,
                       city            CHAR(12) ASCII,
                       PRIMARY KEY (cno) """)

session.cmd ("COMMIT")

# End the database session
# ------------------------

del session


Python: Example 4 (MaxDB: Loader)

Python: Example 4

Example of calling the Loader with Python Script

Start a database session
Log on to the database instance
Create a table and query the error code
Load data to the table using Loader commands and query the error code
Log off

# Reference to the Python Libraries
# ---------------------------------

import sys
import loader

# Parse the call arguments
# --------------------------

user_name = sys.argv [1]
password = sys.argv [2]
database_name = sys.argv [3]
data_path = sys.argv[4]
server_node = ''

# Create a database session for the Loader
# ----------------------------------------

session = loader.Loader (server_node, database_name)

# Log on to the database instance
# --------------------------------

session.cmd ('use user %s %s;' % (user_name, password))

# Query whether the table exists by querying the error code
# The sql method is used to do this
# -------------------------------------

rc = session.sql("EXISTS TABLE CUSTOMER")

If rc!=0

   # Then branch of the If statement must be indented in Python
   # Create the table CUSTOMER
   # ----------------------------------------------------------

   rc = session.sql( """CREATE TABLE customer (
                       cno             FIXED(4),
                       name            CHAR(10) ASCII,
                       zip             CHAR(5)  ASCII,
                       city            CHAR(12) ASCII,
                       PRIMARY KEY (cno) """)

print rc

If rc==0

   # Then branch of the If statement must be indented in Python
   # Load the table CUSTOMER
   # ----------------------------------------------------------

   loadrc = session.sql ("""DATALOAD TABLE customer
                            cno       1-4
                            name      6-12
                            zip       14-18
                            city      20-31
                            INFILE %s\customer.dat""" %data_path )
   print loadrc

session.cmd ("COMMIT")

# End the database session
# ------------------------

del session


Python: Example 5 (MaxDB: Loader)

Python: Example 5

Example of calling the Loader with Python Script

If a command is changed at runtime, for example, because user inputs are part of the command, syntax errors can easily occur.
The SQL method only returns SQL error codes. You need exceptions to intercept syntax errors or other Loader errors in the commands.

Start a database session
Log on to the database instance
Load data to the table using Loader commands and intercept exceptions
Log off

# Reference to the Python Libraries
# ---------------------------------

import sys
import loader

# Parse the call arguments
# --------------------------

user_name = sys.argv [1]
password = sys.argv [2]
database_name = sys.argv [3]
data_path = sys.argv[4]
server_node = ''

# Create a database session for the Loader
# -------------------------------------------

session = loader.Loader (server_node, database_name)

# Log on to the database instance
# --------------------------------

session.cmd ('use user %s %s;' % (user_name, password))

# Example of Exception Handling
# -----------------------------

try:

  loadrc = session.sql ("""DATALOAD TABLE customer
                             cno       1-4
                             name      6-12
                             zip      14-18
                             city     20-31
                             INFILE %s\customer.dat""" %data_path )
  print "'%s'" % loadrc

except loader.LoaderServError, err:

    print 'command failed:', err

# End the database session
# ------------------------

del session


Call with the Java Interface of the Loader (MaxDB: Loader)

Call with the Java Interface of the Loader

You can call the Loader using Java.

Prerequisites

Java is installed on the server.

The following Java modules are delivered with the Loader program:

com.sap.dbtech.powertoys.Loader

com.sap.dbtech.powertoys.LoaderException

For a description of the modules, see Java Classes.


Java Classes (MaxDB: Loader)

Java Classes

Use the following classes to Call the Loader with Java:

· Loader Class

· Exception Classes


Java: Loader Class (MaxDB: Loader)

Java: Loader Class

The following Java module is delivered with the Loader program:

com.sap.dbtech.powertoys.Loader

public class Loader extends java.lang.Object

With the Loader class, you can create new Loader object instances and execute SQL statements or Loader commands.

Constructor: Loader

public Loader(java.util.Properties properties) throws RTEException

A new Loader object instance is created. The Loader class uses the following properties:

· host: The Loader is started on this host.

· dbname: The Loader is started for the specified database instance.

· dbroot: The Loader is started for this version/in this directory.

Method: cmd

public java.lang.String cmd(java.lang.String cmdString) throws RTEException, LoaderException

An SQL statement or a Loader command (cmdString) is executed.

Method: dbLoader

public static Loader dbloader(java.lang.String host, java.lang.String dbname) throws RTEException

A new Loader object instance is created in which the host name (host) and the name of the database instance (dbname) are specified.

Method: dbrootLoader

public static Loader dbrootloader(java.lang.String host, java.lang.String dbroot) throws RTEException

A new Loader object instance is created in which the host name (host) and the dbroot directory are specified.

Method: finalize

public void finalize() throws RTEException

This method overwrites the method finalize() of the class java.lang.Object.

Method: release

public void release() throws RTEException

The Loader session is ended.


Java: Exception Classes (MaxDB: Loader)

Java: Exception Classes

The following Java module is delivered with the Loader program:

com.sap.dbtech.powertoys.LoaderException

public class LoaderException extends java.lang.

If a Loader command fails, the Loader exception is output.

Method: getErrorCode

public int getErrorCode()

The error code set by the Loader is returned.

Method: getErrorID

public java.lang.String getErrorID()

The error number set by the Loader is returned.

Method: toString

public java.lang.String toString()

The exception is output as a string object.


Syntax Rules for Calling the Loader (MaxDB: Loader)

Syntax Rules for Calling the Loader

Not the following general syntax rules when you call the Loader.

Upper- and Lowercase Characters

A distinction is not made between upper- and lowercase characters. The Loader converts all names to uppercase characters internally, unless you place character strings in double quotation marks.

Keywords

Both the keywords of the Loader and SQL keywords can be used to denote database objects if they are placed in single or double quotation marks.


Log Functions (MaxDB: Loader)

Log Functions

The Loader logs its actions in a log file and in system tables.

· Log File

· System Tables

Unloading or loading a database takes some time, depending on the volume of data. The Loader can restart the action if it is interrupted. To do this, the information in the system tables is evaluated.


Log File (MaxDB: Loader)

Log File

One important log function of the Loader is to create and manage a log file.

When you start the Loader, a log file is created or updated. The name of this log file is loader.prt. The file is stored in the directory <independent_data_path>\wrk of the database instance.

The following information is logged in the log file:

· Database instance and user name

· Start and end of a load or unload action

· All executed SQL statements

· All executed load commands
– For each load command, the position of the rejected input records in the medium and the cause of error
- For each load command, the accumulated counts (inserted/modified lines and rejected lines)

· All executed unload commands
For each DATAEXTRACT command, the accumulated counts (number of extracted lines, and the number of lines extracted with errors)

· A message if the action was terminated

The log file is structured in such a way that parts of it can be easily used to create a command file.

All comments start in a new record with // * or // <letter> and are ignored by the Loader.

Special comment lines:

// M | Line with messages These are informative system messages, such as the number of lines inserted and rejected, last completed transaction, and so on.
// E | Line with error messages This is used to introduce the two lines with the table and position values as well as the error number or error text for rejected lines.
// R | Line with REMARK comment These are comments entered by the user using the REMARK command.


CODEPAGE (MaxDB: Loader)

CODEPAGE

The system table CODEPAGE contains the conversion tables that the Loader uses for conversion.

Table Structure

CREATE TABLE SYSDBA.CODEPAGE
    (CODEPAGEID CHAR (32)  NOT NULL,
     CODEPAGETABLE CHAR (512) BYTE NOT NULL,
     PRIMARY KEY (CODEPAGEID))

Column | Explanation
CODEPAGEID | Names of code pages (for example, ISO-8859-2)
CODEPAGETABLE | Conversion table from ASCII to UCS2 for each code page

Content

The system table CODEPAGE is preconfigured. When it is delivered, the CODEPAGE column contains 27 entries:

ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, WINDOWS-874, WINDOWS-932, WINDOWS-936, WINDOWS-949, WINDOWS-950, WINDOWS-1250, WINDOWS-1251, WINDOWS-1252, WINDOWS-1253, WINDOWS-1254, WINDOWS-1255, WINDOWS-1256, WINDOWS-1257.

The default value of the Loader, code page ISO-8859-1, is not included in the table.

Use

See code_page_spec


TRANSFORMATIONMODEL (MaxDB: Loader)

TRANSFORMATIONMODEL

The Loader system table TRANSFORMATIONMODEL contains all entries about transformations that span more than one table. After a successful transformation, these entries are unloaded to a data stream or deleted.

TRANSFORMATIONMODEL

PACKAGEGUID | CHAR(24) BYTE | Unique ID of the transformation package
TASKID | FIXED(6.0) | ID of the transformation task
SERVERNODE | CHAR(32) | Server node on which the database instance to be transformed is installed
SERVERDB | CHAR(32) | Name of the database instance that is to be transformed
CODETYPE | CHAR(32) | Code type of the database instance (ASCII | UNICODE)
USERNAME | CHAR(32) | User name
CODEPAGEID | CHAR(32) | ID of the ASCII code page that is to be used
STORAGEDEVICE | CHAR(32) | External storage medium that is to be used
TRANSACTIONSIZE | FIXED(6.0) | Minimum number of rows that are to be transformed before the status of the transformation step is logged
TRANSFORMATION | CHAR(32) | Transformation type (EXTRACT | LOAD | UPDATE)
PART | CHAR(32) | Parts of the database catalog (ALL | USER | TABLE)
STEPID | FIXED(6.0) | ID of the transformation step
OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Table name
TABLETYPE | CHAR(8) | Table type (TABLE | VIEW | SYNONYM)
CATALOGSTREAMNAME | CHAR(254) | ID of the CATALOG data stream
CATALOGSTREAMTYPE | CHAR(32) | Medium of the CATALOG data stream (FILE | PIPE | TAPE)
CATALOGSTREAMEBID | CHAR(32) | External backup ID of the CATALOG data stream
CATALOGSTREAMFORMAT | CHAR(32) | Format of the CATALOG data stream (DDL | XML)
DATASTREAMNAME | CHAR(254) | ID of the DATA data stream
DATASTREAMTYPE | CHAR(32) | Medium of the DATA data stream (FILE | PIPE | TAPE)
DATASTREAMEBID | CHAR(32) | External backup ID of the DATA data stream
DATASTREAMFORMAT | CHAR(32) | Format of the DATA data stream (PAGES | RECORDS | COMPRESSED | FORMATTED)
DATASTREAMHEADERBLOCK | FIXED(6.0) | Start position of the header of the DATA data stream (in 2 GB blocks)
DATASTREAMHEADERPOS | FIXED(10.0) | Start position of the header of the DATA data stream (in bytes, less than 2 GB)
DATASTREAMDATABLOCK | FIXED(6.0) | Start position of the data of the DATA data stream (in 2 GB blocks)
DATASTREAMDATAPOS | FIXED(10.0) | Start position of the data of the DATA data stream (in bytes, less than 2 GB)
DATASTREAMTRAILEBLOCK | FIXED(6.0) | Start position of the trailer of the DATA data stream (in 2 GB blocks)
DATASTREAMTRAILERPOS | FIXED(10.0) | Start position of the trailer of the DATA data stream (in bytes, less than 2 GB)
EXCLUDE | BOOLEAN | Transformation step was excluded (TRUE) or not (FALSE)
RESTART | BOOLEAN | Transformation step was executed (TRUE) or not (FALSE)
RESTORE | BOOLEAN | Transformation command was generated (TRUE) or not (FALSE)
PAGECOUNT | FIXED(10.0) | Number of pages that were transformed during a transformation step
ROWCOUNT | FIXED(10.0) | Number of rows that were transformed during a transformation step
STARTTIME | TIMESTAMP | Start of the transformation step
ENDTIME | TIMESTAMP | End of the transformation step
REQUESTTIME | FIXED(15.10) | Total execution time of a kernel request within a transformation step
RECEIVETIME | FIXED(15.10) | Total execution time of a kernel reply within a transformation step
IOTIME | FIXED(15.10) | Total I/O time within a transformation step
LOGTIME | FIXED(15.10) | Total time required for the management of actions within a transformation step
SEQ_NO | FIXED(6.0) | Sequence number with which split GRANT statements can be assigned to each other
CMD | CHAR(254) | Authorization statement


TRANSFORMATIONMONITOR (MaxDB: Loader)

TRANSFORMATIONMONITOR

The Loader system table TRANSFORMATIONMONITOR describes the resource consumption of a transformation.

TRANSFORMATIONMONITOR

PACKAGEGUID | CHAR(24) | Unique ID of the transformation package
ROWCOUNT | FLOAT(38) | Number of transformed rows
TRANSACTIONSIZE | FIXED(6.0) | Minimum number of rows that are to be transformed before the status of the transformation step is logged
SYSTEMDURATION | FLOAT(38) | System performance
KERNELDURATION | FLOAT(38) | Kernel performance
LOADERDURATION | FLOAT(38) | Loader performance
DATADURATION | FLOAT(38) | Pager performance
LOGDURATION | FLOAT(38) | Total time required for the management of actions within a transformation step
IODURATION | FLOAT(38) | Total I/O time within a transformation step


TRANSFORMATIONPACKAGES (MaxDB: Loader)

TRANSFORMATIONPACKAGES

The oader system table TRANSFORMATIONPACKAGES contains all steps of a transformation for a transformation package.

TRANSFORMATIONPACKAGES

PACKAGEGUID | CHAR(24) BYTE | Unique ID of the transformation package
TASKID | FIXED(6.0) | ID of the transformation task
STEPID | FIXED(6.0) | ID of the transformation step
OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Table name
EXCLUDE | BOOLEAN | Transformation step was excluded (TRUE) or not (FALSE)
RESTART | BOOLEAN | Transformation step was executed (TRUE) or not (FALSE)


TRANSFORMATIONRESOURCES (MaxDB: Loader)

TRANSFORMATIONRESOURCES

The Loader system table TRANSFORMATIONRESOURCES describes the data sources and data targets involved in a transformation.

TRANSFORMATIONRESOURCES

Column name | Data Type | Explanation
PACKAGEGUID | CHAR(24) BYTE | Unique ID of the transformation package
SERVERNODE | CHAR(32) | Server node on which the database instance to be transformed is installed
SERVERDB | CHAR(32) | Name of the database instance that is to be transformed
USERNAME | CHAR(32) | User name
CODEPAGEID | CHAR(32) | ID of the ASCII code page that is to be used
STORAGEDEVICE | CHAR(32) | External storage medium that is to be used
CATALOGSTREAMNAME | CHAR(254) | ID of the CATALOG data stream
CATALOGSTREAMTYPE | CHAR(32) | Medium of the CATALOG data stream (FILE | PIPE | TAPE)
CATALOGSTREAMEBID | CHAR(32) | External backup ID of the CATALOG data stream
DATASTREAMNAME | CHAR(254) | ID of the DATA data stream
DATASTREAMTYPE | CHAR(32) | Medium of the DATA data stream (FILE | PIPE | TAPE)
DATASTREAMEBID | CHAR(32) | External backup ID of the DATA data stream


TRANSFORMATIONSTATISTICS (MaxDB: Loader)

TRANSFORMATIONSTATISTICS

The Loader system table TRANSFORMATIONSTATISTICS describes the resource usage of a step of a transformation.

TRANSFORMATIONSTATISTICS

PACKAGEGUID | CHAR(24) BYTE | Unique ID of the transformation package
STEPID | FIXED(6.0) | Ascending number for each transformation package
OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Table name
BYTECOUNT | FIXED(11.0) | Size of the DATA data stream in bytes
ROWCOUNT | FIXED(10.0) | Number of table rows in the DATA data stream
TRANSACTIONSSIZE | FIXED(6.0) | Minimum number of rows that are to be transformed before the status of the transformation step is logged
SYSTEMTIME | FLOAT(38) | Transformation performance
KERNELTIME | FIXED(20.10) | Kernel performance
LOADERTIME | FLOAT(38) | Loader performance
DATATIME | FLOAT(38) | Pager performance
LOGTIME | FIXED(15.10) | Total time required for the management of actions within a transformation step
IOTIME | FIXED(15.10) | Total I/O time within a transformation step


TRANSFORMATIONSTEPS (MaxDB: Loader)

TRANSFORMATIONSTEPS

THE Loader system table TRANSFORMATIONSTEPS describes a transformation at table level.

TRANSFORMATIONSTEPS

PACKAGEGUID | CHAR(24) BYTE | Unique ID of the transformation package
TRANSFORMATION | FIXED(6.0) | Transformation type (EXTRACT | LOAD | UPDATE)
OWNER | CHAR(32) | Owner of the table
TABLENAME | CHAR(32) | Table name
CATALOGSTREAMNAME | CHAR(254) | ID of the CATALOG data stream
CATALOGSTREAMFORMAT | CHAR(32) | Format of the CATALOG data stream (DDL | XML)
DATASTREAMNAME | CHAR(254) | ID of the DATA data stream
DATASTREAMFORMAT | CHAR(32) | Format of the DATA data stream (PAGES | RECORDS | COMPRESSED | FORMATTED)
DATASTREAMHEADERBLOCK | FIXED(6.0) | Start position of the header of the DATA data stream (in 2 GB blocks)
DATASTREAMHEADERPOS | FIXED(10.0) | Start position of the header of the DATA data stream (in bytes, less than 2 GB)
DATASTREAMDATABLOCK | FIXED(6.0) | Start position of the data of the DATA data stream (in 2 GB blocks)
DATASTREAMDATAPOS | FIXED(10.0) | Start position of the data of the DATA data stream (in bytes, less than 2 GB)
DATASTREAMTRAILERBLOCK | FIXED(6.0) | Start position of the trailer of the DATA data stream (in 2 GB blocks)
DATASTREAMTRAILERPOS | FIXED(10.0) | Start position of the trailer of the DATA data stream (in bytes, less than 2 GB)
RESTART | BOOLEAN | Transformation step was executed (TRUE) or not (FALSE)
START | FIXED(10.0) | Number of transformed rows


Commands: Overview and Syntax Rules (MaxDB: Loader)

Commands: Overview and Syntax Rules

Each Loader command comprises one or more keywords, arguments, and options. These commands can be divided into commands for creating a database session and commands for unloading and loading data.

Command Overview

AUTOCOMMIT
CATALOGEXTRACT
CATALOGLOAD
DATAEXTRACT
DATALOAD
DATAUPDATE
DBEXTRACT
DBLOAD
FASTLOAD

REMARK
SET
SQLMODE
TABLEEXTRACT
TABLELOAD
USE SERVERDB
USE USER

Syntax Rules

Syntax Rules for Commands

Keywords


AUTOCOMMIT Command (MaxDB: Loader)

AUTOCOMMIT Command

You use this command for setting up a database session to activate/deactivate AUTOCOMMIT mode for a database session.

Syntax

<autocommit_statement> :: = AUTOCOMMIT ON | AUTOCOMMIT OFF

AUTOCOMMIT ON

The AUTOCOMMIT mode is activated (Loader default value).

With commands for loading data, a COMMIT is used to complete the insertion of a certain number of data records. The user can determine this number using the SET TRANSACTION SIZE command. This mode is not relevant when data is unloaded, because the table contents in the database are not modified.

If you execute COMMIT and ROLLBACK statements when AUTOCOMMIT mode is activated, the Loader ignores these statements.

The Loader terminates each SQL statement implicitly with a COMMIT.

AUTOCOMMIT OFF

AUTOCOMMIT mode is deactivated.

All transactions must be terminated explicitly using a COMMIT.

You can group commands in units so that they can be completed or reset at once.

This mode does not apply to the commands FASTLOAD, TABLEEXTRACT, and TABLELOAD, as these commands run outside the transaction concept of the database and are therefore always implicitly terminated with a COMMIT by the Loader.

Large transactions (such as a large number of data records to be loaded) require a correspondingly large log area.


CATALOGEXTRACT Command (MaxDB: Loader)

CATALOGEXTRACT Command

You can use this Loader command to control the unloading of the entire database catalog or parts of it.

Syntax

<catalogextract_statement> ::= CATALOGEXTRACT <part_spec > <outstream_spec >

You can also use the keywords EXTRACT CATALOG instead of the keyword CATALOGEXTRACT.

Prerequisites

THE command CATALOGEXTRACT ALL can only be executed by the database system administrator (SYSDBA user) .

Use

<part_spec>

· CATALOGEXTRACT ALL
The data stream <outstream_spec> contains all commands for creating a database session and SQL statements for data definition that are required for the definition of the entire database catalog.
You can useexternal backup tools to unload data.

· CATALOGEXTRACT USER
The data stream <outstream_spec> contains all commands for creating a database session and SQL statements for data definition that are required for the definition of the parts of the database catalog that belong to the specified user.

· CATALOGEXTRACT TABLE
The specified table is a basis table. The user is the owner of this table.
The data stream <outstream_spec> contains all SQL statements for data definition that are required for the definition of the table the database catalog objects connected to it.

Data Stream: <outstream_spec>

During unloading, the data stream <outstream_spec> is created for the database catalog definitions.

The system table TRANSFORMATIONMODEL and other system tables are filled.

Result

The desired parts of the database catalog are unloaded to the data stream <outstream_spec>.

You can use the corresponding CATALOGLOAD command to restore these database catalog objects.

Errors

The unload process cannot be successfully completed. In this case, the Loader logs the cause of the error in the log file.

The values PACKAGEGUID and CLIENTNODE are both written to the log file.


CATALOGLOAD Command (MaxDB: Loader)

CATALOGLOAD Command

You can use this Loader command to control the loading of the entire database catalog or parts of it.

Syntax

<catalogload_statement> ::= CATALOGLOAD <part_spec > <instream_spec >

You can also use the keywords LOAD CATALOG instead of the keyword CATALOGLOAD.

Prerequisite

A data stream was created with the CATALOGEXTRACT command.

THE command CATALOGLOAD ALL can only be executed by the database system administrator (SYSDBA user) .

Use

<part_spec>

· CATALOGLOAD ALL
The entire database catalog is restored from the data stream <instream_spec> using the commands for creating a database session and the SQL statements for data definition.
You can use external backup tools to load data.

· CATALOGLOAD USER
The user that executes the CATALOGLOAD USER command must have the same user name as the owner of the database catalog objects in the data stream <instream_spec>. The database catalog objects in the data stream are restored using the commands for creating a database session and the SQL statements for data definition.

· CATALOGLOAD TABLE
The user who executes the CATALOGLOAD TABLE command must have the same user name as the owner of the database catalog objects in the data stream <instream_spec>. The database catalog objects in the data stream are restored using the commands for creating a database session and the SQL statements for data definition.

Data Stream: <instream_spec>

The data stream <instream_spec> is required when loading.

If you want to use the data stream generated with the CATALOGEXTRACT command, specify this name.

The system table TRANSFORMATIONMODEL and other system tables are filled.

Result

The desired parts of the database catalog are loaded from the data stream <instream_spec> to the database catalog.

Errors

The load process cannot be successfully completed. In this case, the Loader logs the cause of the error in the log file.

The values PACKAGEGUID and CLIENTNODE are both written to the log file.


The DATAEXTRACT Command (MaxDB: Loader)

The DATAEXTRACT Command

With this Loader command, you can control the unloading of application data from database tables.

Syntax

<select_expression> [OUTFIELDS] [ <output_column_list> ] <extract_files_spec>
| DATAEXTRACT <restore_spec> TABLE <table_name> [ <order_clause> ] <extract_files_spec>

You can also use the keywords EXTRACT DATA instead of the keyword DATAEXTRACT.

Prerequisite

You must have access authorization for the tables from which you want to unload data.

You must be owner of the table to use the second variant of the DATAEXTRACT command.

Use

The Loader offers you the following variants of the DATAEXTRACT command.

Variant 1: DATAEXTRACT [OUTFIELDS]

You can use this variant of the command to:

· Define the columns of the table that is to be unloaded

· Link multiple tables that you want to unload

· Specify a sort sequence for the extracted data

DATAEXTRACT cno, name, zip, address from customer
OUTSTREAM 'customer.data'

DATAEXTRACT * from article
OUTFIELDS foa 01-08
des 09-39
stock 40-43 INTEGER
min_ord 44-45 INTEGER
ordered 46-49 INTEGER
del_date 50-57
price 58-65 DECIMAL (2)
weight 66-69 REAL
OUTSTREAM 'article.data' FORMATTED

Variant 2: DATAEXTRACT … TABLE

You can only use this variant of the command to unload complete single tables. You unload all application data of a table in one data stream and the table definition in the database catalog in a second data stream. You can use these two data streams to recreate the unloaded table and load all application data.

DATAEXTRACT FOR DATALOAD TABLE article
  OUTSTREAM 'article.command'
  OUTSTREAM' article.data'

Data stream for the definition from the database catalog: article.command
Data stream for application data: article.data

Process Flow

The Loader uses the information from the DATAEXTRACT command to generate an internal SELECT command and constructs a results table. The data in this results table is then unloaded into the target data stream, as instructed by the command.

All tables from which data is being unloaded are write-protected while the DATAEXTRACT command is being executed. This means that other users cannot make changes to this table while it is being unloaded.

Result

The data is unloaded from the tables to be unloaded into the target data stream(s).

You can use a DATALOAD or FASTLOAD command to reload the table data back into the database instance.

Errors

The unload process cannot be successfully completed. In this case, the SAP DB Loader logs the number of successfully unloaded data records in the log file.


DATALOAD Command (MaxDB: Loader)

DATALOAD Command

With this Loader command, you can control the loading of application data.

Syntax

<dataload_statement> ::=
DATALOAD TABLE < table_spec > [< duplicates_clause >] < load_column_spec_mlt > < instream_spec > [< longfile_spec_mlt >]

You can also use the keywords LOAD DATA instead of the keyword DATALOAD.

DATALOAD TABLE sqltravel00.customer
  cno         01-04
  name        06-16
  zip         17-22
  address     23-48
INSTREAM 'customer.data' FORMATTED

DATALOAD TABLE edemo.products
  productid     01-10 CHAR
  productname   11-51 CHAR
  unitinstock   52-55 INTEGER
  unitsonorder  56-59 INTEGER
  unitprice     60-67 DECIMAL (2)
INSTREAM 'products.data' FORMATTED

Additional Examples

Use

Like the FASTLOAD command , the DATALOAD command reads data from a data stream and writes it to the tables of a database instance.

DATALOAD commands are processed while the database is running.

A DATALOAD process lasts longer in total than a FASTLOAD process. The writing of the log entries, in particular, can lead to a loss of performance. If errors occur, you can undo DATALOAD entries, as the log entries can be evaluated.

Prerequisites

The table exists in the database instance. Otherwise, it must be created before the DATALOAD command is executed.

Process Flow

The Loader generates an internal mass INSERT statement from the DATALOAD command and then executes it.

During the load operation, all of the tables modified by this DATALOAD command can also be read and changed by other users.

Result

The data in the data stream has been loaded to the target table(s).All the changes made to the target table(s) as a result have also been written to the log area of the database instance.

Errors

If the load operation cannot be ended successfully, the Loader logs the last row that was inserted successfully in the table, the number of rows inserted, and the number of rows rejected in the log file.


DATAUPDATE Command (MaxDB: Loader)

DATAUPDATE Command

With this Loader command, you can control the update of individual column values in tables.

Syntax

<dataupdate_statement> ::=
DATAUPDATE TABLE <table_spec > <acc_column_spec_mlt > <set_column_spec_mlt > <instream_spec > [<longfile_spec_mlt >]

You can also use the keywords UPDATE DATA instead of the keyword DATAUPDATE.

Prerequisites

The target table exists on the database instance.

Process Flow

The Loader generates an internal UPDATE statement from the DATAUPDATE command and then executes it.

Result

The individual line values in the specified table columns are updated. All the changes made to the target table(s) as a result have also been written to the log area of the database instance.

Errors

If errors occur while a DATAUPDATE command is being executed, the Loader terminates the process and displays an error message. A log file is written.


DBEXTRACT Command (MaxDB: Loader)

DBEXTRACT Command

With this Loader command, you can control the unloading of all application data and the corresponding database catalog information.

Syntax

<dbextract_statement> ::=
DBEXTRACT [<configurationstream_spec >] <catalogoutstream_spec > <dataoutstream_spec > [<packagestream_spec >] [<restart>]

You can also use the keywords EXTRACT DB instead of the keyword DATAEXTRACT.

Prerequisite

THE DBEXTRACT command can only be executed by the database system administrator (SYSDBA user) .

Use

The DBEXTRACT command combines the commands CATALOGEXTRACT ALL and TABLEEXTRACT ALL. You can use external backup tools to unload data.

Data Streams: <catalogoutstream_spec> and <dataoutstream_spec>

At least two data streams must be created when unloading:

· Data stream for the database catalog definitions <catalogoutstream_spec>

· Data stream for the application data <dataoutstream_spec>

The system table TRANSFORMATIONMODEL and other system tables are filled.

Exclude Tables from Unload: <configurationstream_spec>

· Unless you specify the data stream <configurationstream_spec>, all the application data is unloaded.

· By specifying a data stream <configurationstream_spec>, you can exclude the application data of selected tables from the unload process<dataoutstream_spec>. The tables must be identified in the data stream by the specification of their owner and the table name.
The information about which tables are not unloaded is stored in the system tables. You can display this information by displaying the system table TRANSFORMATIONPACKAGES. The tables excluded from the unload of the application data have the value TRUE in the column EXCLUDE.

The database catalog entries (<catalogoutstream_spec>) of all tables are always unloaded, regardless of the restrictions made in <configurationstream_spec>.

Unloading the System Table TRANSFORMATIONPACKAGES: <packagestream_spec>

· When you specify a data stream <packagestream_spec>, all entries of the table TRANSFORMATIONPACKAGES are unloaded to this data stream. You are recommended to use this option to create a log of the unload process.

· If you do not specify the data stream <packagestream_spec>, the system table TRANSFORMATIONPACKAGES is not unloaded.

Result

The application data and the database catalog are unloaded to the data streams <dataoutstream_spec> and <catalogoutstream_spec>.

If necessary, all entries of the table TRANSFORMATIONPACKAGES are unloaded in the data stream <packagestream_spec>.

You can use the corresponding DBLOAD command to restore the database catalog and the application data.

Errors

The unload process cannot be successfully completed. In this case, the Loader logs the cause of the error in the log file.

The values PACKAGEGUID and CLIENTNODE are also written to the log file. The PACKAGEGUID is required if you want to restart the unload process.


DBLOAD Command (MaxDB: Loader)

DBLOAD Command

With this Loader command, you can control the loading of all application data and the corresponding database catalog information.

Syntax

<dbload_statement> ::=
DBLOAD [<configurationstream_spec>] <cataloginstream_spec> <datainstream_spec> [<packagestream_spec>] [<restart>]

You can also use the keywords LOAD DB instead of the keyword DBLOAD.

Prerequisite

THE DBLOAD command can only be executed by the database system administrator (SYSDBA user).

You have unloaded the database catalog and its content using the DBEXTRACT command.

Use

The DBLOAD command combines the commands CATALOGLOAD ALL and TABLELOAD ALL.

You can use external backup tools to load data.

Data Streams: <cataloginstream_spec> and <datainstream_spec>

At least two data streams are required when loading:

· Data stream for the database catalog definitions <cataloginstream_spec>

· Data stream for the application data <datainstream_spec>

If you want to use the data streams generated with the DBEXTRACT command, specify these names.

The system table TRANSFORMATIONMODEL and other system tables are filled.

Exclude Tables from Load: <configurationstream_spec>

· Unless you specify the data stream <configurationstream_spec>, all of the data contained in the data streams <cataloginstream_spec> and <datainstream_spec> is loaded.

· By specifying a data stream <configurationstream_spec>, you can exclude the application data of selected tables from the application data being loaded <datainstream_spec>.The tables must be identified in the data stream by the specification of their owner and the table name.
The information about which tables are not loaded is stored in the system tables. You can display this information by displaying the system table TRANSFORMATIONPACKAGES. The tables excluded from the loading of the application data have the value TRUE in the column EXCLUDE.

The database catalog entries (<cataloginstream_spec>) of all tables are always loaded, regardless of the restrictions made in <configurationstream_spec>.

Unloading the System Table TRANSFORMATIONPACKAGES: <packagestream_spec>

· When you specify a data stream <packagestream_spec>, all entries of the table TRANSFORMATIONPACKAGES are unloaded to this data stream. You are recommended to use this option to create a log of the load process.

· If you do not specify the data stream <packagestream_spec>, the system table TRANSFORMATIONPACKAGES is not unloaded.

Result

The application data and the database catalog definitions are loaded using the data streams <datainstream_spec> and <cataloginstream_spec>.

If necessary, all entries of the table TRANSFORMATIONPACKAGES are unloaded to the data stream <packagestream_spec>.

Errors

The load process cannot be successfully completed. In this case, the Loader logs the cause of the error in the log file.

The values PACKAGEGUID and CLIENTNODE are also written to the log file.The PACKAGEGUID is required if you want to restart the unload process.


FASTLOAD Command (MaxDB: Loader)

FASTLOAD Command

With this Loader command, you can control the loading of application data into the specified tables.

Syntax

<fastload_statement> ::=
FASTLOAD [< usage_spec >] TABLE < table_spec > [< load_column_spec_mlt >] < instream_spec >

FASTLOAD with 100 % USAGE
TABLE sqltravel00.customer
  cno           1
  name          2
  zip           3
  address       4
INSTREAM 'customer.data'

Use

FASTLOAD commands are processed while the database is running.

When application data is loaded with FASTLOAD, it is entered directly in the pages on the database instance. This command loads data more quickly than the DATALOAD command.However, because it does not write any log entries, you must back up the new data after you have loaded it.You can either back up the corresponding pages (incremental data backup) or all data (complete data backup). The table is write-protected until you have backed up the new application data.

Prerequisites

· The target table exists on the database instance. Otherwise, the table can be created using a corresponding SQL statement before the FASTLOAD commands is executed.

· You have logged on to the Loader with the user who is the owner of the target table.

· The data in the data stream to be imported is sorted in ascending order in the sequence of the primary key.

· The target table does not have an index.

· If the target table already contains application data, only those data records whose key values are greater than the largest key value in the target table can be inserted.

· The data that you want to load does not contain LONG columns.

Process Flow

When a FASTLOAD command is started, the target table of the load operation in the database instance is locked so other users cannot write to it.The target table can, however, still be read.

Unrestricted reading and writing is possible in all other tables.

Once a FASTLOAD command has been processed, other write operations triggered with FASTLOAD from the same user can be performed on this table.Once the load operation with FASTLOAD has been completed, all users only have read access for the table.

A backup of the database instance must be created before this table is released again for write operations from other users.

Result

The data from the source table has been loaded to the target table.

Errors

If the load operation cannot be ended successfully, the Loader logs the last row that was inserted successfully in the table, the number of rows inserted, and the number of rows rejected in the log file.


REMARK Command (MaxDB: Loader)

REMARK Command

You can use this Loader command to write comments in the Loader log file.

Syntax

<remark_statement> ::= REMARK ?<valRemark>?

valRemark

Comment

See also:

Log File


SET Command (MaxDB: Loader)

SET Command

This Loader command for creating a database session allows you to define many properties of a database session.

Syntax

bool_spec >
| SET CODETYPE < standard_code_spec >
| SET < code_page_spec >
| SET COMPRESSED '/<s>/<d>/'
| SET DATE < standard_date_mask >
| SET LANGUAGE '<ENG|DEU>'
| SET MAXERRORCOUNT <valMAXERRORCOUNT>
| SET < null_spec >
| SET < number_spec >
| SET TIME < standard_time_mask >
| SET TIMESTAMP < standard_timestamp_mask >
| SET TRANSACTION SIZE <valTRANSACTION_SIZE>

BACKUPTOOL <BACKINT|NETWORKER|TSM>

Specifies the external backup tool (see also mediumtype_spec)

COMPRESSED ' /<s>/<d>/'

Characters used in the COMPRESSED format to separate or select data; current value can be changed for individual commands

<s> Character used to separate data fields, default value: comma, value must be exactly one character long, and cannot be blank

<d> Character used to select data, default value: double quotation marks, value can be exactly one character long or blank,
if it is blank, no delimiter is defined

LANGUAGE '< ENG|DEU>'

Language in which the messages of the database instance and the Loader appear
ENG: English, DEU: German

MAXERRORCOUNT <valMAXERRORCOUNT>

The number of errors the Loader accepts during the processing of an individual command, before processing of the command is terminated
This value applies during a complete session or until it is overwritten by another SET MAXERRORCOUNT command

TRANSACTION SIZE <valTRANSACTION_SIZE>

The number of data records after which a COMMIT is performed when inserting data

Use

You can adjust predefined values of the control parameters of the Loader to your requirements.

The new values are only valid for the current database session and must be restored if they are needed in subsequent sessions.


SQLMODE Command (MaxDB: Loader)

SQLMODE Command

You can use this Loader command when creating a database session to specify the SQL Mode of the database instance.

Syntax

<sql_mode_statement> ::= SQLMODE < sql_mode>

Use

The commands for loading and unloading executed by the Loader and the SQL statements are interpreted in accordance with the defined SQL mode.

The defined SQL mode remains active until it is changed again with this command. If you enter an invalid SQL mode, the Loader uses the internal SQL mode of the database instance.


TABLEEXTRACT Command (MaxDB: Loader)

TABLEEXTRACT Command

With this Loader command, you can control the unloading of database tables.

Syntax

<tableextract_statement> ::=
TABLEEXTRACT <part_spec > [<configurationstream_spec >] <dataoutstream_spec > [<packagestream_spec >] [<restart>]

You can also use the keywords EXTRACT DATA instead of the keyword DATAEXTRACT.

Prerequisites

If you are using TABLEEXTRACT TABLE, the source table must exist in the database instance.
The command TABLEEXTRACT ALL can only be executed by the database system administrator (SYSDBA user).

Use

· You can unload the application data (including LONG values) of the specified database tables to data streams. The format of the data stream must be PAGES in each case.

· You can unload the application data (including LONG values) and the database catalog definitions of the specified database tables to data streams. The format of the data stream must be RECORDS in each case.

You cannot change the data streams.

Tables are write-protected while they are unloaded to the data stream.

<part_spec>

· TABLEEXTRACT ALL
The data stream <dataoutstream_spec> contains the application data of all tables.

· TABLEEXTRACT USER
The data stream <dataoutstream_spec> contains the application data of the tables that belong to the specified user.

· TABLEEXTRACT TABLE
The specified table is a base table. The user is the owner of this table.
The data stream <dataoutstream_spec> contains the application data of the specified table.

Data Stream: <dataoutstream_spec>

The data streams <dataoutstream_spec> are created during unloading.

When it processes the commands TABLEEXTRACT ALL and TABLEEXTRACT USER, the Loader creates one or more data streams (depending on the size of the tables it is unloading), each of which can contain the application data from one or more tables. The Loader specifies the maximum size of a single data stream as 1 GB.

The media names for the data streams are created using the name specified in the command, by adding a four digit extension of the format 0001 to the name. The maximum number of media for each TABLEEXTRACT is therefore set at 9999.

The system table TRANSFORMATIONMODEL and other system tables are filled.

Exclude Tables from Unload: <configurationstream_spec>

· Unless you specify the data stream <configurationstream_spec>, all specified tables are unloaded.

· By specifying a data stream <configurationstream_spec>, you can exclude the application data of selected tables from the unload process<dataoutstream_spec>. The tables must be identified in the data stream by the specification of their owner and the table name.
The information about which tables are not unloaded is stored in the system tables. You can display this information by displaying the system table TRANSFORMATIONPACKAGES. The tables excluded from the unload of the application data have the value TRUE in the column EXCLUDE.

Unloading the System Table TRANSFORMATIONPACKAGES: <packagestream_spec>

· When you specify a data stream <packagestream_spec>, all entries of the table TRANSFORMATIONPACKAGES are unloaded to this data stream. You are recommended to use this option to create a log of the unload process.

· If you do not specify the data stream <packagestream_spec>, the system table TRANSFORMATIONPACKAGES is not unloaded.

Result

The specified tables are unloaded to the data streams <dataoutstream_spec>.

If necessary, all entries of the table TRANSFORMATIONPACKAGES are unloaded to the data stream <packagestream_spec>.

You can reload the tables using the corresponding TABLELOAD command.

Errors

The unload process cannot be successfully completed. In this case, the Loader logs the cause of the error in the log file.

The values PACKAGEGUID and CLIENTNODE are also written to the log file. The PACKAGEGUID is required if you want to restart the unload process.


TABLELOAD Command (MaxDB: Loader)

TABLELOAD Command

With this Loader command, you can control the loading of database tables.

Syntax

<tableload_statement> ::=
TABLELOAD <part_spec> [<configurationstream_spec>] <datainstream_spec> [<packagestream_spec>] [<restart>]

You can also use the keywords LOAD TABLE instead of the keyword TABLELOAD.

Prerequisites

The command TABLELOAD ALL can only be executed by the database system administrator (SYSDBA user).

You have unloaded the database tables with the TABLEEXTRACT command.

You cannot change the format of the generated data streams (PAGES or RECORDS). If the data streams have the format RECORDS, you must create the required database table definitions in the database catalog using the corresponding data definition statements.

The target tables must be empty. If the tables are not empty, the Loader attempts to delete the contents of the tables.

Use

<part_spec>

· TABLELOAD ALL
The data streams <datainstream_spec> contain the application data of all tables.

· TABLELOAD USER
The data streams <datainstream_spec> contain the application data of the tables that belong to the current user.

· TABLELOAD TABLE
The specified table is a base table. The user is the owner of this table.
The data stream <datainstream_spec> contains the application data of the specified table.

Data Streams <datainstream_spec>

You can recover database tables using the data streams created with the TABLEEXTRACT command. If you want to use the data streams generated with the TABLEEXTRACT command, specify this name as <datainstream_spec>.

The system table TRANSFORMATIONMODEL and other system tables are filled.

Process Flow

The Loader restores the table in the following order:

1. The database catalog information is adjusted (case 1) or newly created (case 2).

2. The application data is loaded (including LONG values).

3. Indexes are created if they existed in the source table.

No log entries are written during a load process with TABLELOAD.

Case 1:
The table to be restored exists in the database instance

The Loader can adjust the following differences between the database catalog information for the source and target tables:

· Table name and column name of source table and target table
The table name and column names of the source table are copied.

· Differently defined defaults
The defaults defined in the source table are copied. The defaults defined in the target table are deleted.

· Differently defined indexes
The indexes defined in the source table are copied. The indexes defined in the target table are deleted.

· Differently defined constraints
The constraints defined in the source table are copied. The constraints defined in the target table are deleted.

If the definition of the type and the length of the individual columns are different in the source and target tables, the TABLELOAD process is terminated.

Case 2:
The table to be restored does not exist in the database instance

· If data streams have the format PAGES, the table is newly created using the existing database catalog information.

· If the data streams have the format RECORDS, you must create the required database table definitions in the database catalog using the corresponding data definition statements.

Exclude Tables from Load: <configurationstream_spec>

· Unless you specify the data stream <configurationstream_spec>, all data contained in the data streams <datainstream_spec> is loaded.

· By specifying a data stream <configurationstream_spec>, you can exclude the application data of selected tables from the application data being loaded <datainstream_spec>.The tables must be identified in the data stream by the specification of their owner and the table name.
The information about which tables are not loaded is stored in the system tables. You can display this information by displaying the system table TRANSFORMATIONPACKAGES. The tables excluded from the loading of the application data have the value TRUE in the column EXCLUDE.

Unloading System Tables: <packagestream_spec>

· When you specify a data stream <packagestream_spec>, all entries of the table TRANSFORMATIONPACKAGES are unloaded to this data stream. You are recommended to use this option to create a log of the load process.

· If you do not specify the data stream <packagestream_spec>, the system table TRANSFORMATIONPACKAGES is not unloaded.

Result

The database tables are loaded using the data streams <datainstream_spec>.

If necessary, all entries of the table TRANSFORMATIONPACKAGES are unloaded to the data stream <packagestream_spec>.

The table is write-protected during the restore process and after a successful restore. To remove the write-protection, back up the database instance after you have restored the table.

Errors

The load process cannot be successfully completed. In this case, the Loader logs the cause of the error in the log file.

The values PACKAGEGUID and CLIENTNODE are also written to the log file.The PACKAGEGUID is required if you want to restart the unload process.


USE SERVERDB Command (MaxDB: Loader)

USE SERVERDB Command

You can use this Loader command for creating a database session to create a connection to another database instance.

Syntax

<use_serverdb_statement> ::= USE < database_name_statement >

Prerequisites

A user with the same name and password must exist on the new database instance.

Use

You switch to another database instance without having to exit the Loader. It terminates the connection to the current database instance and sets up the new connection to the database instance.

All subsequent commands are referred to this database instance by the Loader.

USE SERVERDB MK1 ON DBHost;


USE USER Command (MaxDB: Loader)

USE USER Command

You can use this Loader command for creating a database session to create a connection with the specified information.

Syntax

<use_user_statement> ::= USE < user_statement>

Use

This command terminates the current connection of the Loader to the database instance and creates a new connection with the specified parameters.

If you do not enter a database instance name under <user_statement>, the new connection is created to the database instance that was used prior to the USE USER command.


Syntax Rules for Commands (MaxDB: Loader)

Syntax Rules for Commands

The syntax used for Loader commands is the Backus Naur Form (BNF) with the following conventions:

<Rule name> ::= <Rule section>

The terms in angle brackets represent syntactical units. Each rule name must be resolved by a rule section.

A rule section is any combination of rules and endsymbols. Endsymbols are numbers, literals, or keywords and are not resolved further.

Rule sections set in angle brackets indicate an optional user input.

The keywords used in the commands are written in uppercase for the sake of clarity. They can be specified by the user in upper- or lowercase letters.

Blank characters are allowed in commands. These are not interpreted by the Loader.

Endsymbols that start with val stand for values that must be specified by the user. Remember that values for 'valLITERAL' (as specified in the syntax rules) must be placed in single quotation marks.

If you use keywords as names of columns, tables or users, you must place them in double quotation marks.

The following documentation contains an alphabetical list of all the syntax rules that are used for the commands listed in the overview. The syntax rules can also be classified into the following areas:

· Syntax rules for setting up a session

· Syntax rules for table descriptions

· Syntax rules for column descriptions

· Syntax rules for describing the data stream


acc_column_spec (MaxDB: Loader)

acc_column_spec

Syntax Rules for Column Descriptions

Syntax

<acc_column_spec> ::= <key_column_spec> | <simple_column_spec>

Use

Use this syntax rule in a DATAUPDATE command to define whether the qualification columns are key columns or non-key columns of the target table.

If you use key columns as qualification columns (key_column_spec), each data record in the data stream updates that line in the target table that matches the specified key.

DATAUPDATE TABLE customer
KEY cno 01-04
SET city 05-16
INSTREAM 'customer.data' FORMATTED

If you use non-key columns as qualification columns (simple_column_spec), each data record in the source file updates each line in the target table that is identified with the value(s) of the qualification column(s).

DATAUPDATE TABLE customer
 city 1
SET zip 2
INSTREAM 'customer.data'


acc_column_spec_mlt (MaxDB: Loader)

acc_column_spec_mlt

Syntax Rules for Column Descriptions

Syntax

<acc_column_spec_mlt> ::= < acc_column_spec > <acc_column_spec_mlt>

Use

Use this syntax rule in a DATAUPDATE command to define the qualification columns.

You can use both key columns and non-key columns as qualification columns.

The qualification columns must be listed before the target columns ( set_column_spec ) in a DATAUPDATE command.


bool_spec (MaxDB: Loader)

bool_spec

Syntax Rules for Describing the Data Stream

Syntax

<bool_spec> ::= BOOLEAN <valVALUE_FOR_TRUE>/<valVALUE_FOR_FALSE>

valVALUE_FOR_TRUE | Defines the character string for values that are true
valVALUE_FOR_FALSE | Defines the character string for values that are false

The default value in the Loader is TRUE/FALSE.

The character strings can contain a maximum of 10 characters.

Use

Use this syntax rule to specify the character string that represents the BOOLEAN values in data streams to be unloaded from a database instance or to be loaded into a database instance.

You can also change the current value for individual commands.

See also:

Data Format


cataloginstream_spec (MaxDB: Loader)

cataloginstream_spec

Syntax Rules for Describing the Data Stream

Syntax

<cataloginstream_spec> ::= CATALOG < instream_spec >


catalogoutstream_spec (MaxDB: Loader)

catalogoutstream_spec

Syntax Rules for Describing the Data Stream

Syntax

<catalogoutstream_spec> ::= CATALOG < outstream_spec >


code_page_spec (MaxDB: Loader)

code_page_spec

Syntax Rules for Describing the Data Stream

Syntax

<code_page_spec> ::= CODEPAGE [<valCODEPAGE_NAME>]

valCODEPAGE_NAME

Name of code page
Default value: ISO-8859-1

If you specify an empty value, the code page is reset to the default value.

Use

If you convert CHAR data from ASCII to UCS2, you determine which code page is used (see also: standard_code_spec).

Case 1: The code page for the conversion is a user-defined code page and is not yet contained in the system table CODEPAGE.

To make user-defined code pages accessible to the Loader for conversions, you first have to load these code pages into the system table CODEPAGE. To do this, proceed as follows:

1. In the directory <dependent_path>/env, create a file with the name <valCODEPAGE_NAME>.txt. This file has to be formatted in the same was as the files that are provided by the Unicode consortium at ftp://ftp.unicode.org/Public/MAPPINGS/.

File ISO-8859-8.txt

# Name:             ISO/IEC 8859-8:1999 to Unicode
# Unicode version:  3.0
# Table version:    1.1
# Table format:     Format A
# Date:             2000-Jan-03
# Authors:          Ken Whistler kenw@sybase.com
#
# Copyright (c) 1991-1999 Unicode, Inc.  All Rights reserved.
#
# This file is provided as-is by Unicode, Inc. (The Unicode Consortium).
# No claims are made as to fitness for any particular purpose.  No
# warranties of any kind are expressed or implied.  The recipient
# agrees to determine applicability of information provided.  If this
# file has been provided on optical media by Unicode, Inc., the sole
# remedy for any claim will be exchange of defective media within 90
# days of receipt.
#
# Unicode, Inc. hereby grants the right to freely use the information
# supplied in this file in the creation of products supporting the
# Unicode Standard, and to make copies of this file in any form for
# internal or external distribution as long as this notice remains
# attached.
…
# Format:  Three tab-separated columns
#    Column #1 is the ISO/IEC 8859-8 code (in hex as 0xXX)
#    Column #2 is the Unicode (in hex as 0xXXXX)
#    Column #3 the Unicode name (follows a comment sign, '#')
…

0x00 0x0000   #  NULL
0x01 0x0001   #  START OF HEADING
0x02 0x0002   #  START OF TEXT
0x03 0x0003   #  END OF TEXT
0x04 0x0004   #  END OF TRANSMISSION
0x05 0x0005   #  ENQUIRY
0x06 0x0006   #  ACKNOWLEDGE
0x07 0x0007   #  BELL
0x08 0x0008   #  BACKSPACE
0x09 0x0009   #  HORIZONTAL TABULATION
0x0A 0x000A   #  LINE FEED

2. Load the code page into the system table CODEPAGE.
Use the SET command to do so. When processing the SET command SET CODEPAGE <valCODEPAGE_NAME>, the Loader first tries to find the specified code page in the system table CODEPAGE. If the table does not contain the code page, the SAP DB Loader tries to find the corresponding file <valCODEPAGE_NAME>.txt. If this file exists, it is read, and the conversion table is entered in the system table CODEPAGE.

If the file is not found, and if the code page is not contained in the system table, the Loader stops processing the SET command and displays an error message.

If the SET command is processed successfully, the user-defined code page is available in the system table CODEPAGE.

Case 2: The code page for the conversion is already contained in the system table CODEPAGE.

Process Flow

The Loader reads the conversion table from the system table CODEPAGE. All subsequent conversions of the CHAR data from ASCII to UCS2 are performed by using this conversion table.

See also:

Data Format

Format of the Data Stream


code_spec (MaxDB: Loader)

code_spec

Syntax Rules for Describing the Data Stream

Syntax

<code_spec> ::= < standard_code_spec > | CODESET <valCODESET_NAME>

valCODESET_NAME

Code attribute

Use

You can define the default value for the interpretation of data streams that contain plain text values .

See also:

Data Format


column_assignment (MaxDB: Loader)

column_assignment

Syntax Rules for Column Descriptions

Syntax

<column_assignment> ::= <valCOLUMN_NAME> '<valLITERAL>'
| <valCOLUMN_NAME> <generate_spec>

valCOLUMN_NAME | Column name Specify this according to the SQL conventions. It can also contain the table name as a prefix (such as, customer.cno).
valLITERAL | Constant

Use

When you load application data, you can use this syntax rule to specify that a constant value is loaded into the specified column for each loaded data record, and which value this constant must have.

To do this, specify the constant in a position in the command.No data is then loaded from the data stream for the appropriate column.

If the data stream is empty, the constants specified in the command are not loaded.

Loading Constants: <valCOLUMN_NAME> '<valLITERAL>'

To load any constant, enter the constant in a position.Place the value in single quotation marks.

The Loader handles the constant like a plain text value and converts it to the data type of the target column.

If you want to load the constant into a numeric column, it must have a valid numeric format.

DATALOAD TABLE article
ano 01-08 CHAR
descr 09-39 CHAR
stock 40-43 INTEGER
min_ord '50'
ordered 46-49 INTEGER
delivery_date 50-57 CHAR
price 58-65 DECIMAL (2)
weight 66-69 REAL
INSTREAM 'customer.data' FORMATTED

Loading Special Constants: <valCOLUMN_NAME> <generate_spec >

You can load the special values STAMP, USER, USERGROUP, DATE, TIME, TIMESTAMP, and TRUE and FALSE.

DATALOAD TABLE article
changed_by USER
changed_on DATE
changed_at TIME
ano 1
descr 2
stock 3 NULL IF POS 3 < '0'
INSTREAM 'customer.data'


column_descriptor (MaxDB: Loader)

column_descriptor

Syntax Rules for Column Descriptions

Syntax

<column_descriptor> ::= <valCOLUMN_NAME> <field_pos> <format_spec>

valCOLUMN_NAME

Column name
Specify this according to the SQL conventions. It can also contain the table name as a prefix (such as, customer.cno).

Use

In a command to load application data, you can use this syntax rule to assign a data field of the data stream to a column of the target table. To do this, you specify the column name, the position, and the external data type of the data in the data stream.

DATALOAD TABLE article
 ano 01-08 CHAR
 descr 09-39 CHAR
stock 40-43 INTEGER
min_ord 44-45 INTEGER
ordered 46-49 INTEGER
delivery_date 50-57 CHAR
price 58-65 DECIMAL (2)
weight 66-69 REAL
INSTREAM 'article.data' FORMATTED


column_id (MaxDB: Loader)

column_id

Syntax Rules for Column Descriptions

Syntax

<column_id> ::= <valCOLUMN_NAME> | <valCOLUMN_ID>

valCOLUMN_NAME | Column name Specify this according to the SQL conventions. It can also contain the table name as a prefix (such as, customer.cno).
valCOLUMN_ID | Column ID

Use

In a command for unloading application data, use it to assign a column of the source table to a data field of the data stream.

DATAEXTRACT cno, name, zip, city FROM customer
OUTFIELDS
cno 01-04
name 06-12
zip 14-18
city 20-31
OUTSTREAM 'customer.data' FORMATTED

The column number valCOLUMN_ID indicates the position of the column in the SELECT statement.

DATAEXTRACT cno, name, zip, city FROM customer
OUTFIELDS
1 01-04
2 06-12
3 14-18
4 20-31
OUTSTREAM 'customer.data' FORMATTED


column_id_spec (MaxDB: Loader)

column_id_spec

Syntax Rules for Column Descriptions

Syntax

<column_id_spec> ::= <column_id > <field_pos > <format_spec > <null_assign >

Use

Use it in unload commands to assign the data fields of the data stream to the columns of the source table. You specify the external data types and the conditions for unloading the application data.

Note the following rules:

Decide whether you want your column descriptions to contain field_pos field descriptions.

However, you must specify position descriptions for all or none of the described columns. If you do not, the Loader generates an error and terminates the command.

Format of the Data Stream: COMPRESSED

· Enter the position descriptions as relative positions only.

If you enter position descriptions with start and end positions for single columns or all columns, the Loader generates an error and terminates the command.

DATAEXTRACT * from customer
OUTFIELDS
  cno       1
  last name 2
  zip       3
  place     4-31
OUTFILE 'customer.data' COMPRESSED

· Assign position 1 to the first column in your list. The position numbers of the following columns increase by 1 each time. This also means that each position number can only be assigned once.
If you do not keep to these rules, the Loader generates an error and terminates the command.

DATAEXTRACT * from customer
OUTFIELDS
  cno       1
  last name 2
  street    3
  zip       3     ERROR
  place     5     ERROR
OUTFILE 'customer.data' COMPRESSED

· You can assign a column to multiple different positions.

DATAEXTRACT * from customer
OUTFIELDS
  cno       1
  last name 2
  zip       3
  place     4
  last name 5
OUTFILE 'customer.data' COMPRESSED

Format of the Data Stream: FORMATTED

· Specify all position descriptions with exact start and end positions.

· Specify only ascending, non-overlapping values for position descriptions.
If the positions entered are not consecutive, the Loader fills the gaps with blank characters. This also applies to binary data.

DATAEXTRACT * from customer
OUTFIELDS
  cno        01-04
  last name  06-12
  zip        14-18
  place      16-31
OUTFILE 'customer.data' FORMATTED

· Define the positions for the data stream at least as long as the length of the values in the database.
If you define a position for the data stream that is longer than the length of the value in the database, the following occurs:
- Character strings are aligned left and space characters entered to make them the correct length
- Numeric values are aligned right and space characters entered to make them the correct length
If you define a position for the data stream that is shorter than the length of the values in the database, the Loader generates an error and terminates the command.


column_names (MaxDB: Loader)

column_names

Syntax Rules for Column Descriptions

Syntax

<column_names> ::= <valCOLUMN_NAME> | <valCOLUMN_NAME>,<column_names>

valCOLUMN_NAME

Column name

Use

Use this syntax rule in a DATEXTRACT command with order_clause (see variant 2 of the DATAEXTRACT command) to specify the sort order of the columns that you want to unload.

DATAEXTRACT FOR DATALOAD TABLE article ORDER BY delivery date, price
OUTFILE 'article.command'
OUTFILE 'article.data’


compare_operator (MaxDB: Loader)

compare_operator

Syntax Rules for Table Descriptions

Syntax

<compare_operator> ::= < | > | = | <= | >= | !=

Use

In the syntax rule <simple_condition>, use this syntax rule to specify the value with which a value in the data record is to be compared.


Condition (MaxDB: Loader)

Condition

Syntax Rules for Table Descriptions

Syntax

<condition> ::= <simple_condition > | (<condition>) | <condition> AND <condition>
| <condition> OR <condition> | NOT <condition>

Use

The Loader distinguishes between simple conditions and compound conditions. Simple conditions can be negated with NOT, combined with AND and OR to form compound conditions, or encapsulated as required.

Operators in parentheses are evaluated before those that are not in parentheses.

If no operators are in parentheses, the Loader weights them as follows:

· NOT takes precedence over AND and OR

· AND takes precedence over OR

· If the weighting is identical, the operators are evaluated from left to right.

Only those records to which the simple or compound condition applies are loaded.

See also:

Selecting Data Records

You want to load only those data records from the data stream hotel.data where the place is  BERLIN and the price is less than 400.00 to the destination table hotel:

DATALOAD TABLE hotel
  IF POS 41-44 REAL < '400,00'
  AND
     POS 27-36 = 'BERLIN'
       hno     01-04 INTEGER
       name    09-18
       zip     20-25 DECIMAL
       place   27-36
       price   41-44 REAL
INFILE 'hotel.data' FORMATTED


configurationstream_spec (MaxDB: Loader)

configurationstream_spec

Syntax Rules for Describing the Data Stream

Syntax

<configurationstream_spec> ::= CONFIGURATION < instream_spec >


database_name_statement (MaxDB: Loader)

database_name_statement

Syntax Rules for Setting up a Session

Syntax

<database_name_statement> ::= SERVERDB <valDBNAME> [ON <valDBNODE>]

valDBNAME | Name of the database instance, applies to the whole database session with this database instance. If the name of the database instance is identical to a keyword or if the upper- and lowercase notation is relevant, the name must be placed in quotation marks.
valDBNODE | Name of the server on which the database instance that you want to open for a database session is installed.

Use

Use it to open a database session for the database instance specified with valDBNAME.

If you also specify the name of the server valDBNODE, on which this database instance is installed, the database session for this database instance is opened on this server. Otherwise, the Loader assumes that the specified database instance is on the host where the user is logged on to the Loader.


datainstream_spec (MaxDB: Loader)

datainstream_spec

Syntax Rules for Describing the Data Stream

Syntax

<dataoutstream_spec> ::= DATA < instream_spec >


dataoutstream_spec (MaxDB: Loader)

dataoutstream_spec

Syntax Rules for Describing the Data Stream

Syntax

<dataoutstream_spec> ::= DATA < outstream_spec >


date_spec (MaxDB: Loader)

date_spec

Syntax Rules for Describing the Data Stream

Syntax

<date_spec> ::= DATE <standard_date_mask > | DATE '<valFREE_MASK>'

valFREE_MASK

Freely definable output format

Use Y for the year, M for the month, D for the day.
The year must have two or four characters, days must have two characters,and months must have two or three characters. If you enter three characters for the month, that is MMM, the name of the month is displayed as the standard English abbreviation, for example, Oct for October.

Use

Use this syntax rule to specify the data format of the plain text values in which DATE columns are entered and output.

This format only applies to the load or unload command in which it is specified. If no date format is specified in a command, then either the Loader default is used, or a value specified with the SET DATE command.

Using a freely definable display in a DATAEXTRACT command

CREATE TABLE d_test (col1 DATE)
//
INSERT INTO d_test VALUES (DATE)
//
DATAEXTRACT * FROM d_test
OUTFILE 'd_test.data'
DATA 'YYYY-MMM-DD'

Example for the content of the target data stream
”2003-May-15”


delimiter_spec (MaxDB: Loader)

delimiter_spec

Syntax Rules for Describing the Data Stream

Syntax

<delimiter_spec> ::= DELIMITER '<valDELIMITER>'

valDELIMITER

DELIMITER display,

No character, or exactly one character long

Represent a blank DELIMITER by entering blank single quotation marks ('')

Use

You use this to define which character is used to select application data in data streams with the format COMPRESSED. If you want to load unselected data, enter a blank DELIMITER in the command.

Use the SET command to view the Loader default value.

See also:

Data Format


duplicates_clause (MaxDB: Loader)

duplicates_clause

Syntax Rules for Table Descriptions

Syntax

<duplicates_clause> ::= IGNORE DUPLICATES | REJECT DUPLICATES | UPDATE DUPLICATES

IGNORE DUPLICATES | The new line is not inserted.
REJECT DUPLICATES | The new line is rejected with an error message.
UPDATE DUPLICATES | The new line overwrites the existing line.

Use

Use this syntax rule in a DATALOAD command to specify how to proceed when loading data from a data stream , and a line with the same key as the new line already exists in the target file.

If you do not make a specification, REJECT DUPLICATES is the default.

DATALOAD TABLE sqltravel00.customer
  UPDATE DUPLICATES
  customerid    01-04
  name          06-16
  zip           17-22
  address       23-48
INFILE 'customer.data' FORMATTED


ebid_spec (MaxDB: Loader)

ebid_spec

Syntax Rules for Describing the Data Stream

Syntax

<ebid_spec> ::= EBID '<valEBID>'

valEBID

External Backup ID

Use

After you have finished unloading data with external backup tools, the external backup ID is written to the log file and the transformation tables of the Loader (see Loader: Log Functions).

When you load data with external backup tools, you must specify this ID as mediumtype_spec after the key word TAPE.


extract_files_spec (MaxDB: Loader)

extract_files_spec

Syntax Rules for Describing the Data Stream

Syntax

<extract_files_spec> ::= <data_outstream_spec> [<longfile_spec_mlt>]
| <command_outstream_spec> <data_outstream_spec> [<longfile_spec_mlt>]

data_outstream_spec | Definition of the data stream for application data
command_outstream_spec | Definition of the data stream for load commands to be generated (Command file)
longfile_spec_mlt | Target data stream for data from table fields defined as LONG values

Use

The first specification of this rule applies only to DATAEXTRACT commands that do not create command files (variant 1 of the DATEXTRACT command).

DATAEXTRACT * FROM article
OUTSTREAM 'article.data'

The second specification only applies for DATAEXTRACT commands that enable a complete recovery of the table (variant 2 of the DATAEXTRACT command).

DATAEXTRACT FOR DATALOAD TABLE article
OUTFILE 'article.command'
OUTFILE 'article.data’


field_format (MaxDB: Loader)

field_format

Syntax Rules for Table Descriptions

Syntax

<field_format> ::= /* leer */ | CHAR | DECIMAL [<valFRACTION>]
| ZONED [<valFRACTION>] | INTEGER | REAL

valFRACTION

Number of decimal places for the external data types DECIMAL and ZONED

Use

Use this syntax rule to describe the external data type of the data fields in the data streams .

You only need to specify the data type in a load or unload command or in a condition ( condition ), if the data field in question is to be read or output with a data type other than CHAR. Every internal database column format in the database can be read and output in CHAR format.

See also:

Converting Data Types


field_pos (MaxDB: Loader)

field_pos

Syntax Rules for Table Descriptions

Syntax

<field_pos> ::= <valSTART_POS> | <valSTART_POS> - <valEND_POS>

valSTART_POS | Start position of a data field
valEND_POS | End position of a data field

Use

Use this syntax rule to describe:

  • The position of the input field in the data stream when loading application data
  • The position of an output field in the data stream when unloading application data
  • The position of a comparison value for loading application data selectively ( simple_condition ).

The position specification is dependent on the format of the data stream .

Format FORMATTED

If the data stream has the format FORMATTED , enter only absolute start and end positions for the data fields in the data stream.

The data stream customer.data has the FORMATTED format. The data fields have a standard format and end with a line break.

Position no.

1 2 3 4 5 6 7 8 9 .....

0 1 m i l l e r – 1 0 2 7 7 N e w   Y o r k - - -
0 2 s m i t h - 6 0 6 7 8 C h i c a g o - - - - -
0 3 k l e i n e r t 3 3 1 8 4 M i a m i - - - - -

FASTLOAD command:

FASTLOAD TABLE customer
  cno       01-02
  name   03-10
  zip       11-15
  city      16-27
INFILE 'customer.data' FORMATTED

Format COMPRESSED

If the data stream has the format COMPRESSED , enter only relative positions for the data fields in the data stream.

The data stream customer.data has the COMPRESSED format. The data fields do not have a standard format but are separated by commas:

Position no.

1   2       3    4       ....

001,miller,10277,New York
002,smith,60678,Chicago
003,kleinert,33184,Miami

FASTLOAD command:

FASTLOAD TABLE customer
  cno       1
  name 2
  zip       3
  city   4
INFILE 'customer.data'

COMPRESSED is the SAP DB Loader default value.

The data stream customer.data has the FORMATTED BINARY format:

Position no. | 1 2 3 4 5 6 7 8 9 .....
 | 0 1 m i l l e r x x 1 0 2 7 7 N e w Y o r k : : : 0 2 s m i t h : 6 0 6 7 8 C h i c a g o : : : : : 0 3 k l e i n e r t 3 3 1 8 4 M i a m I

The data fields have a standard format but do not end with a line break.

FASTLOAD command:

FASTLOAD TABLE customer
  cno       01-02
  name    03-10
  zip       11-15
  city      16-26
INFILE 'customer.data' FORMATTED BINARY


format_spec (MaxDB: Loader)

format_spec

Syntax Rules for Column Descriptions

Syntax

<format_spec> ::= < field_format > [HEX] [< numerical_functions >]

Use

In a command to load or unload application data, use this syntax rule to specify the data fields in the data stream ( external data type , position, and so on).

HEX :You can define HEX values .


generate_spec (MaxDB: Loader)

generate_spec

Syntax Rules for Column Descriptions

Syntax

<generate_spec> ::= USER | USERGROUP
| STAMP | DATE | TIME | TIMESTAMP | <sequence_number>

USER | Name of the current user is loaded
USERGROUP | Name of the group of the current user is loaded. If this user is not assigned to a user group, the name of the current user is loaded. The column into which you want to load one of these values must have the type CHAR (n) where n >= 32.
DATE | Current date The column into which you want to load one of these values must have the type DATE.
TIME | Current time The column into which you want to load one of these values must have the type TIME.
TIMESTAMP | Current timestamp The column into which you want to load one of these values must have the type TIMESTAMP.
STAMP | A unique value generated by the database system that can only be loaded into columns of the type CHAR (n) BYTE where n >= 8.

Use

This is used to load the specified special constants into the database.


if_condition (MaxDB: Loader)

if_condition

Syntax Rules for Table Descriptions

Syntax

<if_condition> ::= IF <condition > | OTHERWISE

Use

Use this syntax rule to define the selection criterion that determines which records from the data stream are loaded to which target table.

You can selectively load data records that do not fulfill the selection criterion to a specific target table by using the OTHERWISE condition. This means that you can load all those records in the data stream, for which you cannot define a standard selection criterion, to a certain target table.

This syntax rule allows you to select data records when loading them from a data stream into a target table:

OTHERWISE can only be specified for the last table in a series of DATALOAD commands.


instream_spec (MaxDB: Loader)

instream_spec

Syntax Rules for Describing the Data Stream

Syntax

<instream_spec> ::= INSTREAM [< mediumtype_spec >] '<valSTREAM_NAME>' [< stream_format_spec >] [< stream_extract >] [ noheader_spec ]

valSTREAM_NAME

Name and path of the medium

Use

When loading data, use this syntax rule to describe the data stream .

The rules stream_extract and noheader_spec are only evaluated for FASTLOAD and DATALOAD commands . If you use these rules in other commands, they are ignored.

  • You can use stream_extract to specify that only certain parts of a data stream are to be loaded.
  • For data streams with binary values , you can use noheader_spec to specify that the corresponding medium does not have a special header containing the sizes of a data record.


int_spec (MaxDB: Loader)

int_spec

Syntax Rules for Describing the Data Stream

Syntax

<int_spec> ::= INTEGER HILO | INTEGER LOHI

INTEGER HILO | The current data stream stores integers so that the byte with the lowest valency is stored first; that is, is furthest right in the binary number (the big endian).
INTEGER LOHI | The current data stream stores integers so that the byte with the highest valency is stored first, that is, the furthest right in the binary number (little endian, byte swap).

Use

Use it to define the representation of integers in data streams. You can only do this for data streams with the FORMATTED BINARY format ( binary values ). This rule is ignored when you load or unload in data streams that have the COMPRESSED format.

If the representation specified for a data stream does not match the current server, the values are adjusted before being loaded into the database or written to the data stream.

See also:

Data Format


key_column_spec (MaxDB: Loader)

key_column_spec

Syntax Rules for Column Descriptions

Syntax

<key_column_spec> ::= KEY < simple_column_spec >

Use

Use this rule to specify that a certain qualification column in the DATAUPDATE command is a key column of the target table.


lit_column_spec (MaxDB: Loader)

lit_column_spec

Syntax Rules for Column Descriptions

Syntax

<lit_column_spec> ::= '<valLITERAL>' < field_pos >

valLITERAL

Text constant

Use

Use this rule to define text constants for output in addition to the output values in the DATAEXTRACT command .

DATAEXTRACT * from customer
OUTFIELDS
  'Customer number:'  01-15
  cno               16-19
  'Name:'           20-25
  name          26-32
  zip               34-38
  city               50-61
OUTFILE 'customer.data' FORMATTED

The text constant is specified in single quotation marks instead of the column name or column ID ( column_id ).


load_column_spec (MaxDB: Loader)

load_column_spec

Syntax Rules for Column Descriptions

Syntax

<load_column_spec> ::= <column_descriptor> [ <null_condition> ] | <column_assignment>

Use

Use this rule in a command for loading application data to assign the data fields in the data stream to the columns in the target table, and specify the external data types and conditions for loading the data.

DATALOAD TABLE article
  ano         01-08 CHAR
  descr       09-39 CHAR
  stock      40-43 INTEGER
  min_ord     44-45 INTEGER
  ordered     46-49 INTEGER
  del_date 50-57 CHAR
  price       58-65 DECIMAL (2)
  weight      66-69 REAL
INFILE 'article.data' FORMATTED


load_column_spec_mlt (MaxDB: Loader)

load_column_spec_mlt

Syntax Rules for Column Descriptions

Syntax

<load_column_spec_mlt> ::= <load_column_spec > <load_column_spec_mlt>

Use

Use this syntax rule in a command for loading application data to describe the data records you want to load from a data stream and their assignment to the columns of the target table.

Table definition:

CREATE TABLE sqltravel00.customer (cno FIXED(4,0), name CHAR(10) NOT NULL, zip CHAR(5), address CHAR(25), PRIMARY KEY (cno))

Load command:

DATALOAD TABLE customer
  cno       01-04
  name      06-16
  zip       17-22
  address   23-48
INFILE 'customer.data' FORMATTED

Rules

Data must exist in the data stream for every column that you specify in the load command.

If you do not specify columns in the target table in the command, the entire column is populated with the default value defined for this column during the load operation. The NULL value is loaded if no specific default value is defined for the column.

DATALOAD TABLE customer
  cno       01-04
  name      06-16
INFILE 'customer.data' FORMATTED

zip and address are filled with the default value when the data is loaded

Key columns and mandatory columns (columns that are defined as NOT NULL without a default value) must be specified in the load command. Otherwise, the processing terminates with an SQL error.

DATALOAD TABLE customer
  name      06-16
  zip       17-22
  address   23-48
INFILE 'customer.data' FORMATTED

The command is terminated with an SQL error, as the column cno is missing.

If you do not specify any columns for the target table in the load command, the table is loaded as if all columns in the target table were specified in the command. If this is the case, data must exist in the data stream for all of the columns in the target table.

DATALOAD TABLE customer
INFILE 'customer.data' FORMATTED

Data must exist in the data stream for all of the columns in the target table.


longfile_code_spec (MaxDB: Loader)

longfile_code_spec

Syntax Rules for Describing the Data Stream

Syntax

<longfile_code_spec> ::= <code_spec > | BINARY

Use

With this specification, you define the default value for the interpretation of LONG data streams.

Using this syntax rule, you can also transform LONG data between various code types when you load or unload the data.

If you are loading/unloading ASCII LONG data into an ASCII database or UCS2 LONG data into a UNICODE database, the data does not have to be converted.

The following combinations are possible (internal database data type and external data type):

Internal Database Data Type | Possible code attributes of the LONG data stream during unloading
LONG ASCII | ASCII, UCS2, UTF8
LONG UNICODE | UCS2, UTF8
LONG BYTE | BINARY, ASCII (HEX), UCS2 (HEX), UTF8 (HEX)

Internal Database Data Type | Possible code attributes of LONG data stream during loading
LONG ASCII | ASCII
LONG UNICODE | ASCII, UCS2, UTF8
LONG BYTE | BINARY, ASCII, UCS2 (HEX), UTF8 (HEX)


longfile_spec (MaxDB: Loader)

longfile_spec

Syntax Rules for Describing the Data Stream

Syntax

<longfile_spec> ::= LONGFILE <valCOLUMN_ID> < longfile_code_spec >
| LONGFILE <valCOLUMN_NAME> <longfile_code_spec>
| LONGFILE <valCOLUMN_ID> <valFILE_NAME> [<longfile_code_spec>]
| LONGFILE <valCOLUMN_NAME> <valFILE_NAME> [<longfile_code_spec>]

valCOLUMN_ID | Column ID
valCOLUMN_NAME | Column name
valFILE_NAME | Name and path of data stream

Use

If you use one of the first two syntax rules, longfile_code_spec is a required specification. In all other cases, this specification is optional.

  • The first two syntax rules relate to loading/unloading in cases where each LONG value of a column is in a separate LONG data stream.
  • The other rules relate to loading/unloading in cases where all LONG values of a column are in one LONG data stream.

See also:

Loading LONG Values

Unloading LONG Values


longfile_spec_mlt (MaxDB: Loader)

longfile_spec_mlt

Syntax Rules for Describing the Data Stream

Syntax

<longfile_spec_mlt> ::= <longfile_spec > <longfile_spec_mlt>

Use

You can use the DATALOAD, DATAEXTRACT, and DATAUPDATE commands to load LONG values to a target table, unload them from a data stream, or modify the LONG values in a table. Use this syntax rule to define the columns in a target table to which you want to load LONG values, or from which data source you want to unload them.

The data for LONG values is stored separately from the other data in LONG data streams. Specify these data streams with the syntax rule longfile_spec.

If, when you are unloading LONG values, you specify more LONG data streams than there are LONG columns in the column list (see output_column_list), the Loader ignores the surplus LONG data streams.

See also:

Loading LONG Values

Unloading LONG Values


mediumtype_spec (MaxDB: Loader)

mediumtype_spec

Syntax Rules for Describing the Data Stream

Syntax

<mediumtype_spec> ::= FILE | PIPE | TAPE [<ebid_spec >]

Use

You can use this syntax rule to assign a medium to the data stream.

· FILE: Medium for the data stream is the file system.

· PIPE: Medium for the data stream is a pipe.

· TAPE (relevant for unloading data only): The medium for the data stream is a tape that is addressed by an external backup tool.

· TAPE <ebid_spec> (relevant for loading data only): The medium for the data stream is a tape that is addressed by an external backup tool. You must also specify the external backup ID of the data stream that you want to load.

Explanation

The media type TAPE is supported for unloading or loading the entire database or database catalog (this means that it is currently only supported for the following commands: DBEXTRACT/DBLOAD, CATALOGEXTRACT ALL/CATALOGLOAD ALL). If you specify TAPE, an external backup tool is used for unloading or loading the data.

You must perform the following steps when you use external backup tools:

  1. Configuration of the external backup tool
    Connection to a Backint for Oracle Interface
    Connection to a Backint for SAP DB interface
    Connection to NetWorker
    Connection to TSM
  2. Specifying the external backup tool
    To do this, use the Loader command SET BACKUPTOOL.

After the data has been unloaded, the external backup ID is written to the log file and to the transformation table of the Loader. If necessary, you must use this log information to find out the external backup ID.


noheader_spec (MaxDB: Loader)

noheader_spec

Syntax Rules for Describing the Data Stream

Syntax

<noheader_spec> ::= NOHEADER <valRECORD_LENGTH>

valRECORD_LENGTH

Length of an individual data record in the data stream

Use

When loading data with a FASTLOAD or DATALOAD Command, you use this syntax rule to describe in instream_spec that a data stream with the FORMATTED BINARY format does not contain special headers. At the same time, you specify the length of an individual data record in the data stream.

This specification is optional.

If the data stream was generated with the DATAEXTRACT command, it contains a special header with the length of an individual data record in the data stream.

If this header is missing, the Loader can use noheader_spec to specify the length of an individual data record. If this rule is missing, the Loader calculates the length of an individual data record using the information on the column positions in the load command.


null_assign (MaxDB: Loader)

null_assign

Syntax Rules for Column Descriptions

Syntax

<null_assign> ::= [IF] NULL SET '<valLITERAL>'

valLITERAL

Null value representation

Explanation

Place the value for the null representation in single quotation marks.This is a plain text value that the Loader represents as a character string or binary numeric value. This depends on the external data type of the column for which you want to generate the null value.

If you want to display the null value representation in one of the external data types for binary values, it must have a valid numeral format. This means either a floating decimal number in mantissa/exponent representation, or a fixed point number with the currently agreed or standard decimal setting.

The generated null value representation is written to the same place in the data stream as the actual column value.

· If the null value representation is shorter than the length of the value specified by the position, the value is filled with blank characters. If the null value representation is longer, it is shortened to the specified length, and the Loader generates a warning.

· If columns in the target table permit NULL values and you have not specified a null value representation, the Loader default is used for unloaded NULL values ( null_spec ). This has the external data type CHAR.

· If you define a null value representation for unloading NOT-NULL columns, it does not cause an error.

Use

You use this syntax rule in a command for unloading data, to specify which value for the data field of the source table is written to the data stream if the value in the source table is a NULL value.

You want to unload the source table article from the database instance into the data stream article.data. Some of the columns in the table contain NULL values.
Define a separate condition for each of these columns. If this condition is met, the corresponding null value representation is entered in the data stream.

DATAEXTRACT * FROM article
OUTFIELDS
ano 01-08
descr 09-39 IF NULL SET ' '
stock 40-43 INTEGER IF NULL SET '0'
min_ord 44-45 INTEGER
price 46-53 DECIMAL (2) IF NULL SET 'X'
weight 54-57 REAL
OUTSTREAM 'article.data' FORMATTED

You want to unload the source table article from the database instance into the data stream article.data. Some of the columns in the table contain NULL values.
Because there is no null value representation defined for the column in the command, but all values have the external data type CHAR, the Loader default null value representation '?' is used.

DATAEXTRACT * FROM article
OUTFIELDS
ano 01-08
descry 09-39
stock 40-51
min_ord 52-63
price 64-74
weight 75-85
OUTSTREAM 'article.data' FORMATTED

You want to unload the source table article from the database instance into the data stream article.data. Some of the columns in the table contain NULL values.
Because there is no null value representation defined for the column in the command, the Loader attempts to use the null value representation defined as a default (data type CHAR).This causes an error if a numeric external data type has been defined for the columns. The command terminates with an error message.

DATAEXTRACT * FROM article
OUTFIELDS
ano 01-08
descr 09-39
stock 40-43 INTEGER
min_ord 44-45 INTEGER
price 46-53 DECIMAL (2)
weight 54-57 REAL
OUTSTREAM 'article.data' FORMATTED


null_condition (MaxDB: Loader)

null_condition

Syntax Rules for Column Descriptions

Syntax

<null_condition> ::= NULL [IF] <condition> | DEFAULT NULL

Explanation

When the condition is evaluated, the shorter of the comparison values (value in the data stream or the null value representation) is filled with blank characters.

A check is made before each line in the data stream is loaded to see whether the condition formulated for the columns applies. If it does, the NULL value is inserted in this column. If not, the value from the assigned field in the data stream is inserted.

Use

You use this syntax rule in a command for loading data, to specify the conditions under which the NULL value should loaded into a column of the target table.

You can use the DEFAULT-NULL condition if the NULL value in the data stream is represented in the same way for all columns that you want to load from the target table.The character string that you need to specify after NULL IF POS is only specified once as a NULL specification (null_spec) in the DEFAULT-NULL condition.

You cannot load columns defined as key columns (KEY) or NOT NULL with the NULL value.If you do, the table load action terminates with a corresponding error message.

If, when you created the table in the database instance, you defined a default other than NULL for columns, you cannot load NULL values into the columns.In this case, the Loader uses the default value defined for the column instead of the NULL value.

You want to load the data from the data stream article.data into the database instance. You want to load the NULL value into some columns of the target table. Define a separate condition for each of these columns.The NULL value is entered if this condition is met.

DATALOAD TABLE article
ano 01-08
descr 09-39 NULL IF POS 09-11 = ' '
stock 40-43 INTEGER NULL IF POS 40-43 INTEGER < '0'
min_ord 44-45 INTEGER
price 46-53 DECIMAL (2) NULL IF POS 1 <> 'X'
OR POS 46-53 DECIMAL < '0'
weight 54-57 REAL
INSTREAM 'article.data' FORMATTED

You want to load the data from the data stream article.data into the database instance. You want to load the NULL value into some columns of the target table. The same '?'representation of the NULL value applies to all columns in the command where DEFAULT NULL is specified.

DATALOAD TABLE article
ano 01-08
descr 09-39 DEFAULT NULL
stock 40-43 INTEGER DEFAULT NULL
min_ord 44-45 INTEGER
price 46-53 DECIMAL (2) DEFAULT NULL
weight 54-57 REAL
INSTREAM 'article.data' FORMATTED
NULL '?'


null_spec (MaxDB: Loader)

null_spec

Syntax Rules for Describing the Data Stream

Syntax

<null_spec> ::= NULL '<valLITERAL>'

valLITERAL

Null value representation; maximum length of 20 characters

The Loader default value is:
?                    (a question mark and 19 blank characters).

Use

You use this syntax rule to specify the character string used to represent null values that were loaded from the database instance in data streams.

You can also change the current value for individual commands.

See also:

Data Format


number_spec (MaxDB: Loader)

number_spec

Syntax Rules for Describing the Data Stream

Syntax

<number_spec> ::= DECIMAL '/[<t>]/<d>/'

t | Defines the character for structuring thousands The Loader default value is not a character.
d | Defines the character used to separate integers from decimal places The Loader default value is a period.

If no digit or character is specified for t or d, the Loader uses the default.

Use

You use this syntax rule to specify which characters are to be used in decimal numbers to group thousands and separate integers from decimal places.

· If you use this data format definition in the SET command, then you also specify the number format for all subsequent commands. In a single Loader session, this applies until a new SET command is executed.

Number format in the SET command

SET DECIMAL '/ /,/'
Specifies the following number format: 1 999 987,98

SET DECIMAL '///'
Specifies the following number format (Loader default): 1999987.98

· You can change the specified number format for individual commands. For more information, see Date Format.

Number format in a command

DATAEXTRACT freight FROM edemo.orders
OUTSTREAM FILE 'orders.data'
FORMATTED
DECIMAL '/./,/'

Results in the following number format for a value in the file: orders.data:
1.007,64


numerical_functions (MaxDB: Loader)

numerical_functions

Syntax Rules for Column Descriptions

Syntax

<numerical_functions> ::= <scale_spec>
| <round_or_trunc_spec>
| <scale_spec> <round_or_trunc_spec>

Use

Use this syntax rule to scale, round, or shorten numeric data values when you load data from the data stream to the target table or unload data from the source table to the data stream.

Note that you must always specify scale_spec before round_or_trunc_spec.

DATALOAD TABLE distance
...
 cm 7 SCALE 2
cm 7 SCALE -3 ROUND 1
...
INSTREAM 'meter.data'

DATAEXTRACT * FROM distance
cm 10-14 INTEGER SCALE 2
m 14-17 INTEGER
km 18-21 INTEGER SCALE -3 TRUNC 2

OUTSTREAM 'dimensions.bin' FORMATTED


order_clause (MaxDB: Loader)

order_clause

Syntax Rules for Column Descriptions

Syntax

<order_clause> ::= ORDER BY <column_names >

Use

Use this syntax rule as a supplement to the DATAEXTRACT FOR DATALOAD command (variant 2 of the DATAEXTRACT command) to specify the sort order of the extracted data.

For a description of this SQL statement, see the Reference Manual, in the section ORDER clause (order_clause).


output_column (MaxDB: Loader)

output_column

Syntax Rules for Column Descriptions

Syntax

<output_column> ::= <column_id_spec> | <lit_column_spec>

Use

Use this rule in a command for unloading application data to assign the columns of the source table to the data fields in the data stream, and to specify the external data types and conditions for unloading the data.

DATAEXTRACT * FROM article
OUTFIELDS
ano 01-08 CHAR
desrc 09-39 CHAR
stock 40-43 INTEGER
min_ord 44-45 INTEGER
ordered 46-49 INTEGER
delivery_date 50-57 CHAR
price 58-65 DECIMAL (2)
weight 66-69 REAL
OUTSTREAM 'article.data' FORMATTED


output_column_list (MaxDB: Loader)

output_column_list

Syntax Rules for Column Descriptions

Syntax

<output_column_list> ::= <output_column> | <output_column> <output_column_list>

Use

Use this syntax rule in a DATAEXTRACT command to describe the columns to be unloaded of a source table and the representation of the data records in the data stream.

Rules

· The columns can be in any order in the column description.

· The column list can only contain columns from the SELECT statement ( select_expression ) or a subset of them.

· Values are output only for those columns in the column list. If the column list contains more columns than the SELECT statement, the SAP DB Loader generates an error and terminates the command.

· If you do not describe the columns of the source table in the command, you must not specify the OUTFIELDS key word.The data is output as plain text values.

· If you have defined the format COMPRESSED for the data stream, the values of the columns to be extracted are output in the order in the SELECT statement, and separated with separators.

· If you have defined the format FORMATTED for the data stream, the values of the columns to be extracted are formatted and output in the order in the SELECT statement. The length of the individual output values depends on the defined sizes of the individual columns in the source table.

· If the SELECT statement does not contain any column names (DATAEXTRACT * FROM ...), the columns are formatted according to the format of the data stream. They are output in the order specified by the database for processing the command.

Definition of the source table:

create table customer (cno char (4), name char (6) NOT NULL, zip integer, city char (11), PRIMARY KEY (cno))

Unload command:

DATAEXTRACT * from customer
OUTFIELDS
cno 01-04
name 06-12
zip 14-18
city 20-31
OUTSTREAM 'customer.data' FORMATTED;


outstream_spec (MaxDB: Loader)

outstream_spec

Syntax Rules for Describing the Data Stream

Syntax

<outstream_spec> ::= OUTSTREAM < mediumtype_spec > '<valSTREAM_NAME>' [< stream_format_spec >] [< stream_extract >] [APPEND]

valSTREAM_NAME | Name and path of the medium , in a DATAEXTRACT command , also the name of the command file to be generated
APPEND | An existing medium is not overwritten. This means that data or generated load statements are added to the end of the medium. This does not apply to TABLEEXTRACT commands . A TABLEEXTRACT command overwrites an existing medium.

Use

When unloading data, use this syntax rule to describe the data stream .


packagestream_spec (MaxDB: Loader)

packagestream_spec

Syntax Rules for Describing the Data Stream

Syntax

<packagestream_spec> ::= PACKAGE < outstream_spec >

Use

DBEXTRACT command

DBLOAD command

TABLEEXTRACT command

TABLELOAD command


part_spec (MaxDB: Loader)

part_spec

Syntax Rules for Describing the Data Stream

Syntax

<part_spec> ::= TABLE <table_name > | USER | ALL

TABLE | A single table is unloaded to a data stream or loaded from a data stream. Prerequisite: The user must be the owner of this table
USER | The tables of the user currently logged on to the Loader are unloaded to one or more data streams, or the tables unloaded with the corresponding commands are restored from these data streams. The user who restores the tables does not need to be the same user who unloaded them. If you are loading tables that were unloaded by the user user1, the tables can be reloaded by user2.
ALL | All tables of the database catalog are unloaded to one or more data streams or are loaded from these data streams. Prerequisite: The user must be the Database System Administrator.

Use

This syntax rule is used in the following commands: TABLEEXTRACT, TABLELOAD, CATALOGEXTRACT, or CATALOGLOAD command.

You specify whether an individual table, the tables of the user logged on, or all tables of the database catalog are loaded or unloaded.


restart (MaxDB: Loader)

restart

Syntax Rules for Describing the Data Stream

Syntax

<restart> ::= RESTART <valPACKAGEGUID>

valPACKAGEGUID

ID that is generated during the Loader runtime for the commands that span more than one table

Use

The PACKAGEGUID and the host name of the client of the Loader are entered in the table TRANSFORMATIONPACKAGES and logged in the log file.

The user can determine the PACKAGEGUID from the table TRANSFORMATIONPACKAGES, or from the log file to restart the command with the corresponding PACKAGEGUID.


restore_spec (MaxDB: Loader)

restore_spec

Syntax Rules for Table Descriptions

Syntax

<restore_spec> ::= FOR DATALOAD| FOR FASTLOAD| FOR DATAUPDATE

Use

You use this syntax rule in a DATAEXTRACT command to specify which command is to be generated for loading data in the command file.

If a FASTLOAD command is generated this command contains the value of 80% for the fill level of the database ( <usage_spec> ). This is the default used by the Loader.

DATAEXTRACT FOR DATALOAD TABLE article
OUTFILE 'article.control'
OUTFILE 'article.data'


round_or_trunc_spec (MaxDB: Loader)

round_or_trunc_spec

Syntax Rules for Column Descriptions

Syntax

<round_or_trunc_spec> ::= ROUND <valFRACTION> | TRUNC <valFRACTION>

valFRACTION

Number of decimal places

The value must be between 0 and 18. This function doe not have any effect if the number does not have any decimal places.

Use

Use this syntax rule to specify the number of decimal places in a number.

ROUND <valFRACTION>

The value is rounded off at the (<valFRACTION>+1) th decimal place. If this number is >= 5, the value is rounded up. If it is < 5, the value is rounded down. The result is a number in which the (<valFRACTION>+1)th and all subsequent decimal places are equal to 0. The other digits in the number may have been changed if the value was rounded up.

DATALOAD TABLE distance
  ...
  cm 7 SCALE 2
  cm 7 SCALE -3 ROUND 1
...
INFILE 'meter.data'

TRUNC <valFRACTION>

The (<valFRACTION>+1)th and all subsequent decimal places of the value are set to 0. The first <valFRACTION> decimal places remain unchanged.

DATAEXTRACT * FROM distance
  cm    10-14 INTEGER SCALE 2
  m     14-17 INTEGER
  km    18-21 INTEGER SCALE -3 TRUNC 2

OUTFILE 'dimensions.bin' FORMATTED


scale_spec (MaxDB: Loader)

scale_spec

Syntax Rules for Column Descriptions

Syntax

<scale_spec> ::= SCALE <valSCALE_FACTOR>

valSCALE_FACTOR

Scaling factor, can be positive or negative

The value to which the syntax rule refers is multiplied by the corresponding power of ten.

Use

You can scale values using this syntax rule.

You can combine this syntax rule with round_or_trunc_spec .

DATALOAD TABLE distance
  ...
  cm 7 SCALE 2
  cm 7 SCALE -3
...
INFILE 'meter.data'

DATAEXTRACT * FROM
  cm    10-14 INTEGER SCALE 2
  m     14-17 INTEGER
  km    18-21 INTEGER SCALE -3

OUTFILE 'dimensions.bin' FORMATTED


select_expression (MaxDB: Loader)

select_expression

Syntax Rules for Column Descriptions

Syntax

<select_expression>

This database query is formulated in the same way as a SELECT statement, however, instead of SELECT, the keyword DATAEXTRACT or EXTRACT DB is used. All options of a SELECT statement are permitted:

· Select the result columns and determine their order in the result table

· Join multiple tables

· Use qualifications to select result lines

· Specify sort order

· Specify locks (WITH LOCK)

Use

Use this syntax rule in a DATAEXTRACT command to specify which columns in a table to extract.

DATAEXTRACT * FROM article
OUTFIELDS
  ano       01-08
  descr     09-39
  stock     40-51
  min_ord   52-63
  price     64-74
  weight    75-85
OUTFILE 'article.data' FORMATTED

DATAEXTRACT ano,descr,stock,min_ord FROM article order by ano
OUTFIELDS
  ano       1
  descr     2
  stock     3
  min_ord   4
OUTFILE 'article.data'

DATAEXTRACT ano,descr,stock,min_ord FROM article WITH LOCK
OUTFIELDS
  ano       1
  descr     2
  stock     3
  min_rod  4
OUTFILE 'article.data'


separator_spec (MaxDB: Loader)

separator_spec

Syntax Rules for Describing the Data Stream

Syntax

<separator_spec> ::= SEPARATOR '<valSEPARATOR>'

valSEPARATOR

Separator for data fields; must be one character long

Use

Use this syntax rule to specify which character is used to separate data fields in data streams that have the COMPRESSED format.

Use the SET command to view the Loader default.

See also:

Data Format


set_column_spec (MaxDB: Loader)

set_column_spec

Syntax Rules for Column Descriptions

Syntax

<set_column_spec> ::= SET <load_column_spec>

Use

Use this syntax rule in a DATAUPDATE command to define the columns of the target table that you want to update with this command.

DATAUPDATE TABLE customer
KEY cno 01-04
SET city 05-16
INSTREAM 'customer.data' FORMATTED


set_column_spec_mlt (MaxDB: Loader)

set_column_spec_mlt

Syntax Rules for Column Descriptions

Syntax

<set_column_spec_mlt> ::= <set_column_spec> <set_column_spec_mlt>

Use

Use this syntax rule in a DATAUPDATE command to define the columns of the target table that you want to update with this command.

DATAUPDATE TABLE customer
KEY  cno  01-04
SET  city 05-16
INSTREAM 'customer.data' FORMATTED


sequence_number (MaxDB: Loader)

sequence_number

Syntax Rules for Column Descriptions

Syntax

<sequence_number> ::= SEQNO | SEQNO <valSTART>
| SEQNO <valSTART> <valINCREMENT>

valSTART | Start value and first value to be loaded
valINCREMENT | Increment between loaded values

The keyword SEQNO specifies that sequential numbers are generated. Both the start value and the increment can be negative.

If you only enter the keyword SEQNO in the command, the start value is 0 and the increment between values is 1.

If you only enter the start value in the command after SEQNO, the increment between the values is 1.

Use

Use this syntax rule to load self-generated sequential numbers with a freely definable start value and increment.

The set of calculable numbers is cyclical. This means that the value that comes after the largest possible value is the smallest possible value. In this way, you can generate as many numbers as you want, including repeated sequential numbers.

A column of the type FIXED(10) is enough for storing the sequential numbers.

DATALOAD TABLE article
  ano       SEQNO 10000 5
  descr     2
  stock    3 NULL IF POS 3 < '0'
INFILE 'article.data' FORMATTED


simple_column_spec (MaxDB: Loader)

simple_column_spec

Syntax Rules for Column Descriptions

Syntax

<simple_column_spec> ::= <column_descriptor> | <column_assignment>

Use

Use this syntax rule in a DATAUPDATE command to assign the data fields of the qualification columns in the data stream to the columns of the target table and to specify the external data types.

DATAUPDATE TABLE article
    ano   01-08         CHAR
    descr 09-39         CHAR
SET min_ord 40-41    INTEGER
SET del_date 42-49 CHAR

INFILE 'article.data' FORMATTED


simple_condition (MaxDB: Loader)

simple_condition

Syntax Rules for Table Descriptions

Syntax

<simple_condition> ::= POS <field_pos > <field_format > [HEX] <compare_operator > '<valLiteral>'

valLITERAL

Constant

As with the other fields in a data record, you use the position of a value that you want to compare to describe it. You only need to specify the external data type of this value if the data type is not CHAR.

You specify a constant as a plain text value and place it in quotation marks. The constant is converted to the data type of the value that you want to compare in the data record.

If the constant you want to use as a comparison value is a number, it must have a valid number format, that is, it must be a floating point number in mantissa/exponent notation or a fixed-point number with the currently defined decimal representation or the default decimal representation in the Loader.

Use

You use this syntax rule to define the selection criterion that determines which records from the data stream are loaded to which target table. The data records that are you want to load are selected by comparing them with a constant.

You want to load only those data records from the source data stream hotel.data where the price is less than 400.00 to the target table hotel:

DATALOAD TABLE hotel
  IF POS 41-44 REAL < '400,00'
      hno     01-04 INTEGER
      name    09-18
      zip     20-25 DECIMAL
      city    27-36
      price   41-44 REAL
INFILE 'hotel.data' FORMATTED


sql_mode (MaxDB: Loader)

sql_mode

Syntax Rules for Setting up a Session

Syntax

<sql_mode> ::= INTERNAL | ANSI | DB2 | ORACLE

INTERNAL | Internal database system SQL Mode (system default)
ANSI | SQL dialect in accordance with the ANSI standard (ANSI X3.135-1992, Entry SQL)
DB2 | SQL dialect in accordance with the definition for DB2 Version 4
ORACLE | SQL dialect in accordance with the ORACLE7 definition

Use

The active SQL mode determines which SQL dialect is understood by the database system. It is transferred between the Loader and the database instance when the connection is set up. If the data stream does not have the format PAGES, the SQL statements and load commands are interpreted in accordance with the specified SQL mode.

· If you do not specify an SQL mode, the SQL mode INTERNAL is used.

· If you enter an invalid SQL mode, the database system automatically assumes that you want to use the INTERNAL SQL mode.

· The SQL mode can change within a command file or a script (SQLMODE command).


standard_code_spec (MaxDB: Loader)

standard_code_spec

Syntax Rules for Describing the Data Stream

Syntax

<standard_code_spec> ::= ASCII | UCS2 | UTF8

Use

In the code_spec, you define the default value for the interpretation of data streams that contain plain text values. The default value in the Loader is ASCII.

When you load or unload data, you can transform it between various code types.

If you load/unload ASCII data into an ASCII database or UCS2 data into a Unicode database, the data does not have to be converted.

The following combinations are possible (internal database data type and external data type):

Internal Database Data Type | Possible code attributes for data streams with plain text values when unloading
(VAR)CHAR ASCII | ASCII, UCS2, UTF8
(VAR)CHAR UNICODE | UCS2, UTF8
(VAR)CHAR BYTE | BINARY, ASCII (HEX), UCS2 (HEX), UTF8 (HEX)
Numerical data types | ASCII, UCS2, UTF8

Internal Database Data Type | Possible code attributes for data streams with plain text values when loading
(VAR)CHAR ASCII | ASCII
(VAR)CHAR UNICODE | ASCII, UCS2, UTF8
(VAR)CHAR BYTE | BINARY, ASCII, UCS2 (HEX), UTF8 (HEX)
Numerical data types | ASCII, UCS2, UTF8

If you want to use a particular code page for the ASCII to UCS2 conversion, you can specify the page with the SET command SET <code_page_spec >.

When you load/unload LONG data, you determine the default values by using the syntax rule longfile_code_spec.


standard_date_mask (MaxDB: Loader)

standard_date_mask

Syntax Rules for Describing the Data Stream

Syntax

<standard_date_mask> ::= EUR | INTERNAL | ISO | JIS | USA

YYYY | Year (four digits)
'MM' | Month (two digits, 01-12)
'DD' | Day (two digits, 01-31)

Format | General Form | Example
EUR | 'DD.MM.YYYY' | '23.01.2003'
INTERNAL | 'YYYYMMDD' | '20030123'
ISO/JIS | 'YYYY-MM-DD' | '2003-01-23'
USA | 'MM/DD/YYYY' | '01/23/2003'

Day and month entries must have two digits. In all formats except INTERNAL, the year must have two or four digits. In the format INTERNAL, the year must have four digits.

Use

Use the standard date definition to specify the format for plain-text values in which DATE columns are entered and displayed.

The default value in the Loader is INTERNAL.

· If you use this standard date definition in the SET command, then you also specify the date format for all subsequent commands. In a single Loader session, this applies until a new SET command is executed.

Date format in the SET command

SET DATE ISO

· You can change the specified date format for individual commands. For more information, see Date Format.

Date format in a command

CREATE TABLE d_test (col1 DATE)
//
INSERT INTO d_test VALUES (DATE)
//
DATAEXTRACT * FROM d_test
OUTSTREAM 'd_test.data'
DATE ISO

Example for the content of the target data stream
?2003-05-15?


standard_time_mask (MaxDB: Loader)

standard_time_mask

Syntax Rules for Describing the Data Stream

Syntax

<standard_time_mask> ::= EUR | INTERNAL | ISO | JIS | USA

'HHHH' | Hour (four digits)
'HH' | Hour (two digits)
'MM' | Minutes (two digits, 00-59)
'SS' | Seconds (two digits, 00-59)

Format | General Form | Example
EUR | 'HH.MM.SS' | '14.30.08'
INTERNAL | 'HHHHMMSS' | '00143008'
ISO/JIS | 'HH:MM:SS' | '14:30:08'
USA | 'HH:MM AM (PM)' | '2:30 PM'

Minutes and seconds must have two digits. Except in the format INTERNAL, the hours must have two digits. In the format INTERNAL, the hours must have two or four digits.

When data is loaded, hours greater than 24 cause errors, except in the format INTERNAL. When data is unloaded, hours are displayed modulo 24, except in the format INTERNAL. In the format INTERNAL, you can specify hours up to 9999.

Use

Use the standard time definition to specify the format for plain-text values in which TIME columns are entered and displayed.

The default value in the Loader is INTERNAL.

· If you use this standard time definition in the SET command, then you also specify the time format for all subsequent commands. In a single Loader session, this applies until a new SET command is executed.

Time format in the SET command

SET TIME ISO

· You can change the specified time format for individual commands. For more information, see Date Format.

Time format in a command

CREATE TABLE t_test (col1 TIME)
//
INSERT INTO t_test VALUES (TIME)
//
DATAEXTRACT * FROM t_test
OUTSTREAM 't_test.data'
TIME ISO

Example for the content of the target data stream
?2003-05-15?


standard_timestamp_mask (MaxDB: Loader)

standard_timestamp_mask

Syntax Rules for Describing the Data Stream

Syntax

<standard_timestamp_mask> ::= EUR | INTERNAL | ISO | JIS | USA

'YYYY' | Year (four digits)
'MM' | Month (two digits, 01-12)
'DD' | Day (two digits, 01-31)
'HH' | Seconds (two digits, 0-24)
'MM' | Minutes (two digits, 00-59)
'SS' | Seconds (two digits, 00-59)
'NNNNNN' | Microseconds (six digits)

Format | General Form | Example
EUR/JIS/USA | 'YYYY-MM-DD-HH.MM.SS.NNNNNN' | '2003-01-23-14.30.08.456234'
INTERNAL | 'YYYYMMDDHHMMSSNNNNNN' | '20030123143008456234'
ISO | 'YYYY-MM-DD HH:MM:SS.NNNNNN' | '2003-01-23 14:30:08.456234'

Years must have four digits. Months and days must have two digits.
Hours, minutes, and seconds must have two digits.
For microseconds, you can choose any number of digits from 0 to 6.

Use

Use the standard time stamp definition to determine the format for plain-text values, in which TIMESTAMP columns are entered and displayed.

The default value in the Loader is INTERNAL.

· If you use this standard time stamp definition in the SET command, then you also specify the time stamp format for all subsequent commands. In a single Loader session, this applies until a new SET command is executed.

Time stamp format in the SET command

SET TIMESTAMP ISO

· You can change the specified time stamp format for individual commands. For more information, see Date Format.

Time stamp format in a command

CREATE TABLE ts_test (col1 TIMESTAMP)
//
INSERT INTO ts_test VALUES (TIMESTAMP)
//
DATAEXTRACT * FROM ts_test
OUTSTREAM 'ts_test.data'
TIMESTAMP ISO

Example for the content of the target data stream
?2003-05-15 11:36:55.123456?


stream_extract (MaxDB: Loader)

stream_extract

Syntax Rules for Describing the Data Stream

Syntax

<stream_extract> ::= START <valSTART_POS>
| START <valSTART_POS> <valEND_POS>
| START <valSTART_BLOCK> : <valSTART_POS> <valEND_BLOCK> : <valEND_POS>

valSTART_POS | Number of the first data record to be loaded
valEND_POS | Number of the last data record to be loaded
valSTART_BLOCK | Block number of the first data record to be loaded
valEND_BLOCK | Block number of the last data record to be loaded


stream_format_spec (MaxDB: Loader)

stream_format_spec

Syntax Rules for Describing the Data Stream

Syntax

<stream_format_spec> ::=
  < code_spec > <stream_format_spec>
| < number_spec > <stream_format_spec>
| < date_spec > <stream_format_spec>
| < time_spec > <stream_format_spec>
| < timestamp_spec > <stream_format_spec>
| < null_spec > <stream_format_spec>
| < bool_spec > <stream_format_spec>
| < int_spec > <stream_format_spec>
| < separator_spec > <stream_format_spec>
| < delimiter_spec > <stream_format_spec>
| COMPRESSED <stream_format_spec>
| FORMATTED <stream_format_spec>
| FORMATTED BINARY <stream_format_spec>
| PAGES <stream_format_spec>
| RECORDS <stream_format_spec>

Use

Use this syntax rule within a load and unload command to define the data formats and the format of the data stream .


table_name (MaxDB: Loader)

table_name

Syntax Rules for Table Descriptions

Syntax

<table_name> ::= <valTABLE_NAME> | <valTABLE_OWNER>.<valTABLE_NAME>

valTABLE_NAME | Name of the table Specify the table name in accordance with the SQL conventions. You can also define a user name as a prefix.
valTABLE_OWNER | Owner of the table

Use

You use this syntax rule for specifying a table name in a command to load or unload data.

FASTLOAD TABLE hotel
  IF (POS 41-44 REAL < '400.00')
  AND
     (POS 41-44 REAL >= '400.00')
      hno     01-04 INTEGER
      name    09-18
      zip     20-25 DECIMAL
      city    27-36
      price   41-44 REAL
INFILE 'hotel.data' FORMATTED;

DATALOAD TABLE berolina.hotel
  IF (POS 41-44 REAL < '400.00')
  AND
     (POS 41-44 REAL >= '400.00')
      hno     01-04 INTEGER
      name    09-18
      zip     20-25 DECIMAL
      city     27-36
      price   41-44 REAL
INFILE 'hotel.data' FORMATTED;


table_spec (MaxDB: Loader)

table_spec

Syntax Rules for Table Descriptions

Syntax

<table_spec> ::= < table_name > < if_condition >

Use

Use this syntax rule in a DATALOAD command to specify the name(s) and contents of the target table(s).

It also applies to loading a table in the FASTLOAD command .

You want to load from the data stream adresses.data the data records that begin with the letter 'k' into the target table with the name customer.

DATALOAD TABLE sqltravel00.customer     IF POS 1 = 'k'
  customerid  2
  name        3
  zip         5
  address     6


time_spec (MaxDB: Loader)

time_spec

Syntax Rules for Describing the Data Stream

Syntax

<time_spec> ::= TIME < standard_time_mask > | TIME '<valFREE_MASK>'

valFREE_MASK

Freely definable output format

Use H for hours, M for minutes, and S for seconds. Minutes and seconds must have two digits. Hours must have two or four digits.

Use

You use this syntax rule to specify the data format of the plain text values in which TIME columns are entered and displayed.

This format only applies to the load or unload command in which it is specified. If no time format is specified in a command, then either the Loader default is used, or a value specified with the SET TIME command.

Freely definable display in a command

CREATE TABLE t_test (col1 TIME)
//
INSERT INTO t_test VALUES (TIME)
//
DATAEXTRACT * FROM t_test
OUTFILE 't_test.data'
TIME 'HHHH-MM-SS'

Example for the content of the target data stream

?0011-46-56?


timestamp_spec (MaxDB: Loader)

timestamp_spec

Syntax Rules for Describing the Data Stream

A time stamp consists of a date value, a time value, and microseconds.

Syntax

<timestamp_spec> ::= TIMESTAMP <standard_timestamp_mask >
| TIMESTAMP '<valFREE_MASK>'

valFREE_MASK

Freely definable output format

Use Y for the year, M for the month, D for the day, H for the hours, M for the minutes, S for the seconds, and N for the microseconds.
The year must have two or four characters, days must have two characters, and months must have two or three characters. If you enter three characters for the month, that is MMM, the name of the month is displayed as the standard English abbreviation, for example, Oct for October.
Minutes and seconds must have two digits. Hours must have two or four digits. For microseconds, you can choose any number of digits from 0 to 6.

Use

You use this syntax rule to specify the data format of the plain text values in which TIMESTAMP columns are entered and output.

This format only applies to the load or unload command in which it is specified. If no time stamp format is specified in a command, then either the Loader default is used, or a value specified with the SET TIMESTAMP command.

Freely definable display in a command

CREATE TABLE ts_test (col1 TIMESTAMP)
//
INSERT INTO ts_test VALUES (TIMESTAMP)
//
DATAEXTRACT * FROM ts_test
OUTFILE 'ts_test.data'
TIMESTAMP 'YYYY-MM-DD-HH-MM-SS-NNNNNN'

Example for the content of the target data stream
?2003-11-15-13-14-12-987654?


usage_spec (MaxDB: Loader)

usage_spec

Syntax Rules for Table Descriptions

Syntax

<usage_spec> ::= WITH <valUSAGE> % USAGE | WITH <valUSAGE> ROWS USAGE

valUSAGE

Positive integer

For a percentage, this number must be between 50 and 100.

If you specify the number of rows, the length of a single table record plays a role.

Use

Use this syntax rule in a FASTLOAD command to specify the extent to which you want to fill a table page with data records.

To do this, you can specify a percentage between 50 and 100 or define the number of rows (data records) that you want to load in each table page. If you specify a number of rows that exceeds the actual number possible, the Loader displays an error message during the load operation, indicating the maximum number of rows permitted in each table page.

The default setting in the Loader is 80 %.

· If the table is not modified at all, or only slightly, it is a good idea to utilize the occupied memory by more than 80%.

· If considerable dynamic growth is anticipated for the table, it is a good idea to utilize the occupied memory by less than 80%.

Specifying the desired memory utilization does not guarantee that it will actually be achieved. Use the Database Manager program to check the current memory utilization for the relevant table.

You want to specify a memory utilization of 100% to FASTLOAD data from the data stream customer.data to the customer table.

FASTLOAD with 100 % USAGE
TABLE customer
  cno        1
  surname    2
  zip        3
  place      4
INFILE 'customer.data'

You want to enter 25 data records in each table page on the database instance.

FASTLOAD with 25 ROWS USAGE
TABLE customer
  cno           1
  surname       2
  zip           3
  place         4
INFILE 'customer.data'


user_statement (MaxDB: Loader)

user_statement

Syntax Rules for Setting up a Session

Syntax

<user_statement> ::= USER <valUSERNAME> <valPASSWORD> [<database_name_statement> ]

valUSERNAME | User name (see database user)
valPASSWORD | User password

The database system automatically converts the user name and password to uppercase letters. If you want to suppress the conversion, you must place the names in quotation marks.

Use

The user data transferred is used to set up a database session with the database instance.

If you call the Loader CLI, then you can specify user data with the option -u or by calling the Perl interface or the Python interface of the Loader.


Syntax Rules for Describing the Data Stream (MaxDB: Loader)

Syntax Rules for Describing the Data Stream

The syntax rules listed here are components of the description of the data stream in the load and unload commands. The use of these syntax rules is explained in more detail.

You can go from the commands for setting up a database session directly to the descriptions of the syntax rules used in each case.

bool_spec | cataloginstream_spec catalogoutstream_spec code_page_spec code_spec configurationstream_spec | datainstream_spec dataoutstream_spec date_spec delimiter_spec
ebid_spec extract_files_spec | instream_spec int_spec | longfile_code_spec longfile_spec longfile_spec_mlt
mediumtype_spec | noheader_spec null_spec number_spec | outstream_spec
packagestream_spec part_spec | restart |


Syntax Rules for Column Descriptions (MaxDB: Loader)

Syntax Rules for Column Descriptions

The syntax rules listed here are components of the column description in the commands for loading and unloading application data . The use of these syntax rules is explained in more detail.

You can go from the description of the commands for loading and unloading data directly to the description of the syntax rules used in each case.

If you want to use keywords as column names, you must place them in double quotation marks.

acc_column_spec acc_column_spec_mlt | column_assignment column_descriptor column_id column_id_spec column_names | format_spec
generate_spec | key_column_spec | lit_column_spec load_column_spec load_column_spec_mlt
null_assign null_condition numerical_functions | order_clause output_column output_column_list | round_or_trunc_spec


Syntax Rules for Table Descriptions (MaxDB: Loader)

Syntax Rules for Table Descriptions

The syntax rules listed here are components of the table description in the commands for loading and unloading application data . The use of these syntax rules is explained in more detail.

You can go from the description of the commands for loading and unloading data directly to the description of the syntax rules used in each case.

If you want to use keywords as table or user names, you must place them in double quotation marks.

compare_operator condition | duplicates_clause | field_format field_pos
if_condition | restore_spec | simple_condition
table_name table_spec | usage_spec |


Syntax Rules for Setting up a Session (MaxDB: Loader)

Syntax Rules for Setting up a Session

The syntax rules listed here are components of the commands for setting up a database session. The use of these rules is explained in more detail.

You can go from the commands for setting up a database session directly to the descriptions of the syntax rules used in each case.

database_name_statement

sql_mode

user_statement


Keywords (MaxDB: Loader)

Keywords

Keywords are components of commands. They define the function of the command, which is modified by arguments and options.

DATALOAD TABLE article
  ano         01-08 CHAR
  descr       09-39 CHAR
  stock       40-43 INTEGER
  min_order   44-45 INTEGER
  ordered     46-49 INTEGER
  del_date    50-57 CHAR
  price       58-65 DECIMAL (2)
  weight      66-69 REAL
INFILE 'customer.data' FORMATTED

The Loader uses the keywords listed below. In some cases, you can also use the alternative keywords provided.

Keywords A - C

Keywords D - E

Keywords F - K

Keywords L - P

Keywords R - S

Keywords T - Z


Keywords A - C (MaxDB: Loader)

Keywords A - C

Key words for the Loader

Keyword | Alternative Keywords
ALL AND ANSI APPEND ASCII AUTOCOMMIT BINARY BOOLEAN BY CATALOG CATALOGEXTRACT CATALOGLOAD CHAR CODESET CODETYPE COMPRESS CONFIGURATION COUNT CURRENT | EXTRACT CATALOG LOAD CATALOG


Keywords D - E (MaxDB: Loader)

Keywords D - E

Key words for the Loader

Keyword | Alternative Keywords
DATA DATAEXTRACT DATALOAD DATAUPDATE DATE DB2 DBEXTRACT DBLOAD DEC DECIMAL DEFAULT DELIMITER DUPLICATES EBCDIC EUR EXTRACT CATALOG EXTRACT DATA EXTRACT DB EXTRACT TABLE | EXTRACT DATA LOAD DATA UPDATE DATA EXTRACT DB LOAD DB CATALOGEXTRACT DATAEXTRACT DBEXTRACT TABLEEXTRACT


Keywords F - K (MaxDB: Loader)

Keywords F - K

Key words for the Loader

FASTLOAD
FILE
FOR
FORMATTED
HEX
HILO
IF
IGNORE
INFILE
INSTALLATION
INSTREAM
INTERNAL
INTEGER
ISO
JIS
KEY


Keywords L - P (MaxDB: Loader)

Keywords L - P

Keywords for the Loader

Keywords | Alternative Keyword
LANGUAGE LOAD CATALOG LOAD DATA LOAD DB LOAD TABLE LOHI LONGFILE MESSAGE NOT NULL NUMBER OFF ON OR ORACLE ORDER OTHERWISE OUTFILE OUTFIELDS OUTSTREAM PACKAGE PAGES PIPE POS | CATALOGLOAD DATALOAD DBLOAD TABLELOAD


Keywords R - S (MaxDB: Loader)

Keywords R - S

Key words for the Loader

REAL
RECORDS
REJECT
RELEASE
RESTART
ROUND
ROWS
SCALE
SEPARATOR
SEQNO
SERVERDB
SET
SQLMODE
STAMP
START
SQLID
SYSDATE


Keywords T - Z (MaxDB: Loader)

Keywords T - Z

Key words for the Loader

Keywords | Alternative Keywords
TABLE TABLEEXTRACT TABLELOAD TABLEUNLOAD TABLEUPDATE TAPE TERMCHARSET TIME TIMESTAMP TRUNC UID UPDATE UPDATE DATA UPDATE TABLE USA USAGE USE USER USERKEY USERGROUP VERSION WITH ZONED | EXTRACT TABLE LOAD TABLE UPDATE TABLE DATAUPDATE TABLEUPDATE


Terms and Procedures (MaxDB: Loader)

Terms and Procedures

Call | AUTOCOMMIT |
Operating Mode | Binary Values |
CATALOGEXTRACT | CATALOGLOAD | COMPRESSED
DATAEXTRACT | DATALOAD | DATAUPDATE
Data | Internal Database Data Types | Data Stream
Data Types | DBEXTRACT | DBLOAD
Unloading Data | Unloading with External Backup Tools | Unloading LONG Values
External Data Types |  |
FASTLOAD | FORMATTED | FORMATTED BINARY
HEX Values | Background Operating Mode |
INSTREAM | Interactive Operating Mode |
Java |  |
Plain Text Values | Command File | Commands
Command Separators |  |
Loading Data | Loading with External Backup Tools | Loading Binary Values
Loading LONG Values | Loader | Loader CLI
Loader Server |  |
Medium | Metadata |
Options | OUTSTREAM |
PAGES | Perl | Log Files
Python |  |
RECORDS | REMARK |
Selecting Data Records | SET | SQL Statements
SQLMODE | System Tables |
TABLEEXTRACT | TABLELOAD | Transformation
USE SERVERDB | USE USER |


Operating Mode (MaxDB: Loader)

Operating Mode

You can choose from two operating modes when you call the Loader with the Loader CLI. The modes are activated implicitly by the way in which the Loader CLI is called.

· Background or script mode(specify the option -b)
The required commands and SQL statements must be stored in a command file. When you call the Loader, you must specify the command file with the option –b <command_file>.

· Interactive or session mode (do not specify the option -b)
The Loader CLI runs in interactive mode if you do not specify the command file option -b when you call the Loader CLI.
In this case, you can enter commands and SQL statements in the command line after you start the Loader CLI.
If you enter a Loader command that runs over more than one line, and you end one of these lines with a forward slash (‘/’), then the Loader CLI recognizes that the command is not yet complete. This stops the command from being executed when you enter the line.
Only when you enter a line without preceding it with a forward slash does the Loader CLI recognize that the command is complete. It then sends the command to the Loader Server, which executes it. After all the commands and SQL statements have been executed, the Loader CLI displays a message.
To exit interactive mode, enter release or exit.


Binary Values (MaxDB: Loader)

Binary Values

For the Loader:

All numeric external data types (INTEGER, REAL, DECIMAL, ZONED) are interpreted as binary values. These can be converted to any of the internal database data types (FIXED, SMALLINT, INTEGER, FLOAT).

· The Loader always interprets data of the data type INTEGER as signed values. You can adjust its display in a data stream with int_spec (Specified in commands to load and unload as a processing specification for the data stream as the syntax rule stream_format_spec ).

· Data of the data type REAL is coded in a host-specific format and cannot be transported between different operating systems and computer platforms without being converted again.

See also:

Converting Data Types


Data (MaxDB: Loader)

Data

The Loader provides you with functions for unloading, loading, and formatting data between different data sources and data targets in different granularities (Commands for Unloading and Loading).

The Loader recognizes two types of data:

· Application Data

· Metadata


Application Data (MaxDB: Loader)

Application Data

Application data is the data that is stored in the database tables.

The Loader writes the application data to a data stream when unloading from the database system and to the database system when loading from a data stream.


Metadata (MaxDB: Loader)

Metadata

The database system manages its metadata in the database catalog.

For the Loader, metadata is data that mirrors the database catalog information, and also data that describes the application data, database catalog information, and load and unload processes (Transformations) in accordance with the requirements of the Loader.

· Metadata of the Application Data

· Metadata of the Database Catalog

· Metadata of Transformations


Data Stream (MaxDB: Loader)

Data Stream

The Loader transforms metadata of the database catalog, application data, and pages of a database instance into metadata and application data (data definitions, data records, and data fields), and pages and conversely, in a format that the Loader can read. The data is unloaded into data streams, or loaded from these streams.

Every data stream is identified using the following data:

· Metadata and/or Application Data

· Data Format and Format of the Data Stream

· Direction

· Medium


Data Format (MaxDB: Loader)

Data Format

With most Loader commands for loading and unloading data, you can specify the external data type and the data format that the relevant field values in the data stream have or should have.

You can also define which separators and delimiters are to be used.

Procedure

You can specify the data format in load and unload commands as a processing specification for the data stream (syntax rule stream_format_spec).

code_spec
number_spec
date_spec|time_spec|timestamp_spec
null_spec
bool_spec
int_spec
separator_spec|delimiter_spec

The specified data format applies to the columns that have the corresponding internal database data type.


Format of the Data Stream (MaxDB: Loader)

Format of the Data Stream

Data streams can have the following formats:

· COMPRESSED

· FORMATTED

· FORMATTED BINARY

· PAGES

· RECORDS

You can specify the format in unload and load commands as a processing specification for the data stream (syntax rule stream_format_spec).

The Loader requires that data streams with clear text values have the format COMPRESSED. If this is not the case, you must explicitly specify the FORMATTED format or, with binary coded data streams, FORMATTED BINARY format in the unload or load command.


COMPRESSED (MaxDB: Loader)

COMPRESSED

COMPRESSED (CSV, Comma Separated Values) is a possible format of a data stream.

If a command for unloading or loading data does not explicitly specify the format FORMATTED or FORMATTED BINARY, the system assumes that the data in the source data stream is in the COMPRESSED format (Loader default value). This means that it does not have to be specified explicitly in an unload or load command.

The COMPRESSED format can only be used for source data streams with plain text values. Data streams with binary values must be loaded with the FORMATTED BINARY format.

If you do not specify a format in an unload or load command, however, the data is not in plain text, the Loader creates an error message.

customer.data

Position number

1   2       3    4       ....

001,miller,10277,New York
002,smith,60678,Chicago
003,kleinert,33184,Miami

The data fields do not have a uniform format but are separated by commas:

FASTLOAD command:

FASTLOAD TABLE customer
  cno       1
  surname   2
  zip       3
  place     4
INFILE 'customer.data’

Data Lines

In COMPRESSED format, a data line is compressed to the minimum required to represent the data. The length of the individual data fields and the total length of the data lines can vary. Each data line ends with a line break.

When data is unloaded, a data line in a source table of this format corresponds to exactly one data record in the target data stream.

When data is loaded, a data line in a source data stream of this format corresponds to exactly one data record in the target table.

Data Fields

Data fields in the data streams must have the external data type CHAR.

The individual data fields are separated by a freely selectable character (default value of the Loader: comma). They can also be encapsulated in freely selectable characters (default value of the Loader: double quotation marks).

If delimiters follow each other directly in a data line, then the value is the empty character string. If the relative position is larger than the number of values in the line, the value is also the empty character string.

Position Specification

The assignment of a data field of the data stream to a column in the table is determined by the position specification <field_pos> in a command for unloading or loading data. This specifies a relative position within the data record. It therefore specifies which value in a data record is to be loaded into or unloaded from a specific column.

When you unload data from the database to a target data stream, assign the position 1 to the first column in your list. The position numbers of the following columns rise by 1 each time. This also means that each position number can only be assigned once.

When you load data from a source table, the data fields in the target table in the database must be sorted in ascending order. You can also assign the same input values to different columns or even omit positions. If consecutive delimiters are detected or if the relative position is greater than the number of values in the line, the value is the empty character string.


FORMATTED (MaxDB: Loader)

FORMATTED

FORMATTED (FWV, Fixed Width, Columnar Values) is a possible format of a data stream. As this format is not the default value of the Loader, it must be explicitly specified in an unload or load command.

The FORMATTED format can only be used for source data streams in plain text. Data streams with binary values must be loaded with the FORMATTED BINARY format.

customer.data

Position no.

1 2 3 4 5 6 7 8 9 .....

0 1 m i l l e r – 1 0 2 7 7 N e w   Y o r k - - -
0 2 s m i t h - 6 0 6 7 8 C h i c a g o - - - - -
0 3 k l e i n e r t 3 3 1 8 4 M i a m i - - - - -

The data fields have a uniform format.

FASTLOAD command:

FASTLOAD TABLE customer
  cno       01-02
  surname   03-10
  zip       11-15
  place     16-27
INFILE 'customer.data' FORMATTED

Data Lines

A data line in a data stream corresponds to a data record that you want to unload or load.

All data lines have the same fixed length. Each line in the data stream contains the individual data fields at the same position with a fixed length. Each data line ends with a line break.

Data Fields

The assignment between data fields in the data stream and the table columns is made using the position specification in a command for unloading or loading data.

Position Specification

The data fields in the data stream are described using their byte start and end position. The first possible byte start position is 1. Specifying an end position is optional. If no end position is specified for a data field, it has a length of 1.

The assignment between the data fields in the data stream and table columns can be made in any order. The order does not affect the processing speed.

The positions do not need to follow each other directly when you unload or load data. When it unloads data, the Loader fills any gaps with blank characters.


FORMATTED BINARY (MaxDB: Loader)

FORMATTED BINARY

FORMATTED BINARY (FWV, Fixed Width, Columnar Values) is a possible format of a data stream. As this format is not the default value of the Loader, it must be explicitly specified in an unload or load command.

This format can be used to unload and load binary values.

The FORMATTED BINARY format is largely the same as the FORMATTED format. The only difference is that the length of a data record is only determined by the total length of the individual data fields.

customer.data

Position no. | 1 2 3 4 5 6 7 8 9 .....
 | 0 1 m i l l e r x 1 0 2 7 7 N e w Y o r k 0 2 s m i t h 6 0 6 7 8 C h i c a g o 0 3 k l e i n e r t 3 3 1 8 4 M i a m i

The data fields have a uniform format.

FASTLOAD command:

FASTLOAD TABLE customer
  cno       01-02
  surname   03-10
  zip       11-15
  place     16-26
INFILE 'customer.data' FORMATTED BINARY

Data Fields

The data fields can contain special characters and all have the same fixed length. This also applies to the individual data records.

The assignment between data fields in the data stream and table columns is made in accordance with the <field_pos> position specification in the unload or load command.

Unlike the FORMATTED format, a data record does not end with an additional line break.

Position Specifications

Data fields are described by their byte start and end positions. The first possible byte start position of a data record is 1. Specifying an end position is optional. If you do not specify an end position, the corresponding data field has a length of 1.

The data fields of the data stream can be assigned in any order to the table columns. The order does not affect the processing speed.

The positions do not need to follow each other directly when you unload or load data. When it unloads data, the Loader fills any gaps with blank characters.


PAGES (MaxDB: Loader)

PAGES

PAGES is a possible format of a data stream. The application data is stored in pages.


RECORDS (MaxDB: Loader)

RECORDS

RECORDS is a possible format of the data stream.

This is a proprietary SAP DB format.


Direction (MaxDB: Loader)

Direction

Direction of the data stream

INSTREAM: From a Loader data stream to a SAP DB database instance

OUTSTREAM: From a SAP DB database instance to a Loader data stream


Data Types (MaxDB: Loader)

Data Types

With most loader commands for loading and unloading, you can specify the data type which the relevant field values in the data stream have or should have. This specification tells the Loader how to interpret the data in the data stream.

· When loading application data in a table, the specified external data types are converted to internal database types and the corresponding column values of a table are loaded.

· When unloading application data from a table, the internal database types are converted to the specified external data types and the corresponding column values are unloaded.

See also:

Converting Data Types

You cannot specify an external data type with the TABLELOAD and TABLEEXTRACT commands.

The external data type and the corresponding internal database data type of the column value in the target table do not have to be identical.

The database table article requires the internal database data type FIXED for the value in the ordered column.

The FASTLOAD command defines the external data type INTEGER for the column ordered.

FASTLOAD TABLE article
ano            01-08
des            09-39 CHAR
stock          40-43 INTEGER
min_ord        44-45 INTEGER
ordered        46-49 INTEGER
delivery_date  50-57 CHAR
price          58-65 DECIMAL(2)
weight         66-69 REAL
INFILE 'article.data' FORMATTED

The data in the column ordered is converted to the internal database data type FIXED when it is loaded.


Internal Database Data Types (MaxDB: Loader)

Internal Database Data Types

Internal database data types are the data types defined for the columns in the database table.

For an explanation of all internal database data types, see the Reference Manual: section Data Type (data_type).


External Data Types (MaxDB: Loader)

External Data Types

External data types are the data types into which the Loader can convert internal database data types when it unloads application data, or they are the data types that the Loader converts into internal database data types when it loads data.

You can specify an external data type as a field specification in the unload or load command for each field value that you want to unload or load (see format_spec).

You cannot specify an external data type in the commands TABLEEXTRACT and TABLELOAD.

If no external data type is specified for a field value, the Loader selects the CHAR data type as the default for this field value. Therefore, if the field value does not have the data type CHAR or the data type CHAR is not desired, you must specify the data type.

The Loader can process the following external data types:

CHAR (plain text value) | ASCII, UCS2, or UTF8-coded, depending on the server, max. 254 Bytes long
INTEGER (Binary value) | Binary coded (server-specific), 1, 2, or 4 bytes long, sign in bit 0, negative values in two's complement notation
REAL (Binary value) | Floating point notation with mantissa and exponent, 4 or 8 bytes long, in server-specific notation
DECIMAL (Binary value) | Packed decimal: one digit per half byte, sign in extreme right half byte, 1 to 10 bytes long, maximum of 18 digits, the position of the decimal point is derived from the table column type
DECIMAL(n) (Binary value) | n specifies the number of digits on the right of the decimal point
ZONED (Binary value) | Zoned decimal: /370 zoned data format is permitted, the position of the decimal point is derived from the table column type
ZONED(n) (Binary value) | n specifies the number of digits on the right of the decimal point


Converting the Data Types (MaxDB: Loader)

Converting the Data Types

The Loader can convert between numeric data types, if necessary.

You can use the external data type CHAR to read or output any internal database data type.

· When loading data into a table, the specified external data type is converted to internal database data types and the corresponding column values of a table are loaded.

· When unloading data from a table, the internal database types are converted to the specified external data types and the corresponding column values are unloaded.

 | External Data Type | Internal Database Data Type
Loading data to a database instance | INTEGER, DECIMAL, ZONED, REAL | FIXED, FLOAT, SMALLINT, INT[EGER]
Unloading data from a database instance | FIXED, SMALLINT, INTEGER | INTEGER, DECIMAL, ZONED, REAL
 | FLOAT | REAL or CHAR[ACTER]

DATALOAD TABLE article
  ano         01-08
  des         09-39
  stock       40-43 INTEGER
  min_ord     44-45 INTEGER
  ordered     46-49 INTEGER
  del_date    50-57
  price       58-65 DECIMAL (2)
  weight      66-69 REAL
INFILE 'customer.data' FORMATTED


Unloading with External Backup Tools (MaxDB: Loader)

Unloading with External Backup Tools

If you use the loader commands DBEXTRACT or CATALOGEXTRACT ALL to unload data, then you can use an external backup tool.

Prerequisite

Connecting External Backup Tools

The external backup tool for the loader session is determined using the loader command SET BACKUPTOOL.

Procedure

You start to unload the data directly from the Loader. The Loader creates the pipes for unloading the backup data implicitly as part of the unload. These pipes must not exist before the unload.

Enter TAPE as the media type (mediumtype_spec).


Unloading LONG Values (MaxDB: Loader)

Unloading LONG Values

When unloading application data, there are special features, if values with the internal database data type LONG are unloaded.

In the syntax rule longfile_spec in longfile_spec_mlt , specify the name and path of the LONG data stream in which the LONG values are to be inserted.

You can use both variants of the syntax rule to unload the data.

  • Always use a column ID for the LONG column that you want to unload if a column ID is specified in the column list for this column (see output_column_list ).
  • Use the column name if the column name is specified in the column list.

DATAEXTRACT * FROM hotel
OUTFILE 'hotel.data'
LONGFILE info 'info.data'

DATAEXTRACT cno, name, zip, address, info FROM hotel
OUTFIELDS
   cno    1
   name     2
   zip      3
   address  4
   info     5
   OUTFILE 'hotel.data'
LONGFILE info 'info.data'

When you unload LONG values, you must differentiate between the following cases:

  • Each LONG Value to Be Unloaded in a Separate LONG Data Stream
  • All LONG Values to Be Unloaded in One LONG Data Stream


Each LONG Value to Be Unloaded in a Separate LONG Data Stream (MaxDB: Loader)

Each LONG Value to Be Unloaded in a Separate LONG Data Stream

Each LONG value to be unloaded from a column is written to a separate data stream.

In the command for unloading data, you specify the name of the LONG data stream with a number of placeholders for sequential numbering of the generated LONG data streams for each LONG column that you want to unload.

If the LONG column you want to unload has no value in a data record (the value is an empty character string), an empty LONG data stream is generated for this LONG value.

Using the unique media name generated in this way, the individual LONG data streams are assigned to the corresponding data record in the target table.

Use a sufficient number of numeric characters at the end of the media name as a placeholder. If the upper limit is reached while the data is being unloaded, but there are still values left to be unloaded, the Loader generates an error message and terminates the command.

DATAEXTRACT * FROM hotel
   cno      1
   name     2
   info     3
OUTFILE 'hotel.data' FORMATTED
LONGFILE info 'info.data.###'

The Loader generates the data stream with the name info.data.001 for the first LONG value to be unloaded, the data stream info.data.002 for the second, and so on.
Content of the target data stream:

10,Excelsior,'info.data.001'
30,Flora, 'info.data.002'
60,Bellevue,'info.data.003'

See also:

Unloading LONG Values

All LONG Values to Be Unloaded in One LONG Data Stream


All LONG Values to Be Unloaded in One LONG Data Stream (MaxDB: Loader)

All LONG Values to Be Unloaded in One LONG Data Stream

All LONG values to be unloaded from a column are written in one data stream.

In the command for unloading data you enter the name of a data stream for each LONG column, into which the each of the LONG values of this LONG column to be unloaded are entered.

If the LONG column you want to unload has no value in a data record (the value is an empty character string), the position specification for this LONG value is generated as follows: the start position is the end position of the preceding LONG value in the column plus 1; the end position is the end position of the preceding LONG value in the column. This means that the start position is always one value larger than the end position.

The start and end position of the generated LONG value in the data stream enable the LONG values to be assigned to data records.

DATAEXTRACT * FROM hotel
OUTFIELDS
   hno      1
   name     2
   info     3
OUTFILE 'hotel.data'
LONGFILE info 'info.data'

Content of the target data stream:

10,Excelsior,1-880
30,Flora,881-1046
60,Bellevue,1047-1360

See also:

Unloading LONG Values

Each LONG Value to Be Unloaded in a Separate LONG Data Stream


HEX Values (MaxDB: Loader)

HEX Values

You can use the additional specification HEX to describe an external data type as a hexadecimal value.

This enables you to load or unload all data types in hexadecimal form. Every byte of data in the result is then represented by two hexadecimal numbers. Every value in the data stream then occupies twice as much space as the value of the same data type without the specification as a HEX value.

FASTLOAD TABLE customer
  cno       01-03 CHAR HEX
  name    04-12 CHAR HEX
  zip       13-17 INTEGER HEX
  place     18-29 CHAR HEX
INFILE 'customer.data' FORMATTED

DATALOAD TABLE article IF POS 40-47 INTEGER HEX > '0'
  ano       01-08
  descr     09-39 NULL IF POS 09-11 = ' '
  stock     40-47 INTEGER HEX
  min_ord   47-48 INTEGER
  price     48-55 DECIMAL (2)
  weight     56-59 REAL
INFILE 'article.data' FORMATTED


Plain Text Values (MaxDB: Loader)

Plain Text Values

Field values with the external data type CHAR are plain text values; that is, these values consist of readable characters.

  • Plain text values can conform to different specifications: ASCII, UCS2 or UTF8 (data format code_spec ).
  • You can specify the data formats for plain text values that represent the date, time, or a timestamp ( date_spec , time_spec , timestamp_spec ).

You can specify these data formats in load and unload commands as a processing specification for the data stream (syntax rule stream_format_spec ).

Plain text values can be used to input data into columns of any internal data type used by the database and can be converted to any data type. If you want to load plain text values into numerical columns, the values must be able to be interpreted as numbers.


Loading with External Backup Tools (MaxDB: Loader)

Loading with External Backup Tools

If you use the loader commands DBLOAD or CATALOGLOAD ALL to load data, then you can use an external backup tool.

Prerequisite

Connecting External Backup Tools

Use the loader command SET BACKUPTOOL to specify the external backup tool for the loader session.

Procedure

You start the load process directly from the Loader.

Specify the external backup ID (TAPE <ebid_spec>) as the medium type (mediumtype_spec).


Loading Binary Values (MaxDB: Loader)

Loading Binary Values

All numeric external data types (INTEGER, REAL, DECIMAL, ZONED) are interpreted as binary values.
These can be converted to any of the internal database data types (FIXED, SMALLINT, INTEGER, FLOAT) (Converting Data Types).

· The Loader always interprets data of the data type INTEGER as signed values. You use the syntax rule <int_spec> to specify how these values are represented in the source data stream.

· Data of the data type REAL is coded in a host-specific format and cannot be transported between different operating systems and computer platforms without being converted again.

You can use the FASTLOAD command and the DATALOAD command to load external binary values into database tables.

DATALOAD TABLE hotel
      hno     01-04 INTEGER
      name    09-18
      zip     20-25 DECIMAL
      city    27-36
      price   41-44 REAL
INFILE 'hotel.data' FORMATTED

Prerequisites

You must specify the source data stream in the load command with either the FORMATTED format or the FORMATTED BINARY format. The data stream must be coded in binary.


Loading LONG Values (MaxDB: Loader)

Loading LONG Values

In a command for loading application data, use the syntax rule longfile_spec in longfile_spec_mlt to specify for each column with the internal database data type LONG the name and path of the data stream from which you want to load the LONG values.

When you load LONG values, you can only use the LONGFILE <valCOLUMN_NAME> '<valFILE_NAME>' variant of the syntax rule, since you can only use column names in the load command, and no column IDs (see: column_descriptor ).

When you load LONG values, you must differentiate between the following cases:

  • Each LONG Value to Be Inserted in a Separate LONG Data Stream
  • All LONG Values to Be Inserted in One LONG Data Stream


Each LONG Value to Be Inserted in a Separate LONG Data Stream (MaxDB: Loader)

Each LONG Value to Be Inserted in a Separate LONG Data Stream

Each LONG value to be inserted into a column is in a separate data stream .

In the data stream, you specify the names of the data streams that contain the LONG values instead of the column values (if necessary, also entering position specifications). The entire data streams or parts of them are loaded as LONG values.

Complete data stream is loaded as LONG values

DATALOAD TABLE sqltravel10.hotel
   hno      1
   name     2
   info     3
INFILE 'hotel.data'

Content of the data stream:

10,Excelsior,'EXCELSIOR.LNG'
30,Flora,'FLORA.LNG'
60,Bellevue,'BELLEVUE.LNG'

Parts of the data stream are loaded as LONG values.

DATALOAD TABLE sqltravel10.hotel
   hno      1
   name     2
   info     3
INFILE 'hotel.data'

Content of the data stream:

10,Excelsior,'EXCELSIOR.LNG' 1-880
30,Flora,'FLORA.LNG' 8-1046
60,Bellevue,'BELLEVUE.LNG' 100-260

Specifying a Code Attribute

You can optionally specify a code attribute in the load command for all data streams that contain LONG values that are to be loaded. You can only enter a single code attribute for all data streams. You cannot specify a code attribute for each individual specified data stream.

Code Attribute for a Data Stream with LONG Values

Specifying the Code Attribute ASCII

DATALOAD TABLE sqltravel10.hotel
   hno      1
   name     2
   info     3
INFILE 'hotel.data'
LONGFILE info ASCII

Content of the data stream:

10,Excelsior,'EXCELSIOR.LNG'
30,Flora,'FLORA.LNG'
60,Bellevue,'BELLEVUE.LNG'

No media name can be used after the keyword LONGFILE.

See also:

Loading LONG Values

All LONG Values to Be Inserted in One LONG Data Stream


All LONG Values to Be Inserted in One LONG Data Stream (MaxDB: Loader)

All LONG Values to Be Inserted in One LONG Data Stream

All LONG values to be inserted into a column are in one data stream .

Variant 1

In the data stream, you specify the name of the data stream containing the LONG values with the start and end position of the LONG value to be loaded, instead of a column value.

DATALOAD TABLE sqltravel10.hotel
   hno      1
   name     2
   info     3
INFILE 'hotel.data'

Content of the data stream:

10,Excelsior,'HOTEL.LNG' 1-880
30,Flora,'HOTEL.LNG' 881-1046
60,Bellevue,'HOTEL.LNG' 1047-1360

Variant 2

You specify the name of the data stream that contains the LONG values after the keyword LONGFILE. In the data stream itself, specify only the position specifications without a preceding data stream name.

DATALOAD TABLE sqltravel10.hotel
   hno     1
   name    2
   info    3
INFILE 'hotel.data'
LONGFILE info 'HOTEL.LNG'

Content of the data stream:

10,Excelsior,1-880
30,Flora,881-1046
60,Bellevue,1047-1360

Specifying a Code Attribute for the Media Specified with LONGFILE

In the load command, you can optionally specify a code attribute for data streams specified with LONGFILE.

Code Attribute for a Data Stream LONG Values

Specifying the Code Attribute ASCII

DATALOAD TABLE sqltravel10.hotel
   hno      1
   name     2
   info     3
INFILE 'hotel.data'
LONGFILE info 'HOTEL.LNG' ASCII

Content of the data stream:

10,Excelsior,1-880
30,Flora,881-1046
60,Bellevue,1047-1360

See also:

Loading LONG Values

Each LONG Value to Be Inserted in a Separate LONG Data Stream


Code Attribute for a Data Stream with LONG Values (MaxDB: Loader)

Code Attribute for a Data Stream with LONG Values

If no code attribute is specified in the command, the Loader uses a default value for the code attribute of the data stream. This is derived from the internal database data type of the column to be loaded. The following conversion table is used:

Internal Database Data Type | External Code Attribute
LONG ASCII | ASCII
LONG BYTE | BINARY
LONG UNICODE | UCS2

If the external code attribute and the internal database data type are different, the Loader converts the data. If the types are incompatible, the Loader generates an error message and stops processing the command.

Compatibility Table

External Code Attribute | Internal Database Data Type | Compatible Yes/No
ASCII | LONG ASCII LONG BYTE LONG UNICODE | yes yes yes
UCS2 | LONG ASCII LONG BYTE LONG UNICODE | no yes yes
BINARY | LONG ASCII LONG BYTE LONG UNICODE | no no yes

Use

Each LONG Value to Be Inserted in a Separate LONG Data Stream

All LONG Values to Be Inserted in One LONG Data Stream


Medium (MaxDB: Loader)

Medium

The Loader uses a medium to physically store the data stream outside the database instance. When you unload or load data using the Loader, the data source and data target are databases and media.

The Loader differentiates between the media types specified in mediumtype_spec.


Metadata of the Application Data (MaxDB: Loader)

Metadata of the Application Data

The metadata of the application data (metadata of the type DATA) are defined in the data streams using commands and SQL statements.

If the transformation spans multiple tables, the Loader stores this information in the system tables.

The corresponding data is stored in the database instance in the form of pages or rows, and in a data stream in the non-readable formats PAGES and RECORDS or in the readable formats FORMATTED, COMPRESSED, and LONG.

If the data are transformed to the format of rows, columns of the external data type CHAR with the code attribute ASCII can be transformed to values of data fields with the code attribute ASCII, UCS-2 or UTF-8.


Metadata of the Database Catalog (MaxDB: Loader)

Metadata of the Database Catalog

Metadata of the database catalog (metadata of the type CATALOG) describes the structure of the data in the database catalog.

If the transformation spans multiple tables, the Loader stores this information in its system tables.

The corresponding data is stored in the database instance in the form of rows in the system tables and in a data stream in the form of SQL statements for data definition.


Metadata of the Transformations (MaxDB: Loader)

Metadata of the Transformations

The metadata of the transformations (metadata of types CONFIGURATION and PACKAGE) is declared in the form of commands or in the form of Loader-specific system tables.

This metadata describes the configuration and the runtime behavior of the transformations that span multiple tables.

The corresponding data, such as user names and table names, is stored, sorted by referential constraint conditions.

In the database instance, the data is stored in the form of rows in the system tables in a data stream in the readable format COMPRESSED.


Selecting Data Records (MaxDB: Loader)

Selecting Data Records

When you load application data, you can select the data records according to their content.

The conditions defined here can be negated with NOT, linked with AND and OR, or encapsulated as required. The Loader evaluates the operators accordingly.

See also:

condition

if_condition

You want to load only those data records from the source data stream hotel.data into the target table hotelthat satisfy the following conditions:

The price in the data record is less than 400.00 (IF).
The name of the hotel is not City (NOT).
The hotel is located in BERLIN (AND).
The zip code is 13125 or 13126 (OR):

DATALOAD TABLE hotel
  IF POS 41-44 REAL < '400.00'
  AND
     POS 27-36 = 'BERLIN'
  AND
    (POS 20-25 = '13125' OR POS 20-25 = '13126')
  AND NOT
     POS 09-18 = 'City'
      hno     01-04 INTEGER
      name    09-18
      zip     20-25 DECIMAL
      city    27-36
      price   41-44 REAL
INFILE 'hotel.data' FORMATTED

You want to load only those data records from the source file hotel.data into the target table hotel where the price is not more than 400.00:

DATALOAD TABLE hotel
  IF NOT POS 41-44 REAL > '400.00'
      hno     01-04 INTEGER
      name    09-18
      zip     20-25 DECIMAL
      place     27-36
      price   41-44 REAL
INFILE 'hotel.data' FORMATTED


SQL Studio

MySQL MaxDB is a relational database system with an SQL-compatible user interface.

"Relational" means that the database system provides its users with all its information in the form of tables. The standard language SQL (Structured Query Language) provides a set of statements that you can use to administer, maintain, and analyze these tables.

SQL Studio provides easy access to the data held in a MaxDB database instance. As well as its use as a query definition tool, SQL Studio is a comfortable tool, both for application programmers who want to test SQL statements, and also for database designers who can benefit from the graphical support it provides for the creation and modification of database objects.

You can use SQL Studio for the following tasks:

· Creating and managing database tables, indexes, and sequences, and managing stored SQL statements, database users, and database procedures with the Catalog Manager

· Creating and executing SQL statements in the SQL Dialog

· Selecting and editing data records in a screen display with the Form Dialog

· Formulating database queries with the help of visual tools in the Visual Query Dialog

The SQL Studio as it is described here can be used on Microsoft Windows operating systems only. For other operating system platforms you can use the Web SQL Studio.

For general information about the Max DB database system, see Database Administration.


Starting SQL Studio (MaxDB: SQL Studio)

Starting SQL Studio

Procedure

To start SQL Studio, select Start ® Programs ® MaxDB ® SQL Studio.

Starting from the command line

You can also start SQL Studio from the command line. If you do launch SQL Studio from the command line, you can also specify options for it.

...

...

1. Switch to the directory where the program sqlsto.exe is located.

2. Enter the following command: sqlsto [<options>]

You can use the following options:

-? | Display all command line options
-version | Display information on software version
-n <server_name> | Name of database server
-d <database_name> | Name of the database instance
-u <user_name[,password]> | User name and password
-c oracle | SQL mode ORACLE. After starting the SQL Studio, you can also change the SQL mode in the user settings.
-t <trace_file> | Generate a log file for logging SQL statements (see also ODBC Manual)


Opening a Database Session (MaxDB: SQL Studio)

Opening a Database Session

Use

Before you can use SQL Studio to access the data in a database instance, you must establish a connection with the database server and log on to the database.

When you do so, you can suppress the timeout behavior of the database if you want to. Over a longer period of time, inactive database connections are therefore no longer automatically terminated.

Procedure

...

1. If you want to suppress the timeout behavior of the database, first activate the No Timeout checkbox in the toolbar.

2. Choose Session ® Connect.

3. Enter the name of the database server and the database instance.

4. Enter your user name and password, and choose OK.

When you enter the user name and password, the system automatically uses upper case. If you want the system to differentiate between upper and lower case, you must put quotation marks around your user name and password. The quotation marks are also necessary if the user name or password includes special characters. Quotation marks must not be used as part of the user name or password itself.

Result

The system establishes a connection with the database. The current session is entered in the recent sessions list.

You can also open a new database session directly in the same window by using the recent sessions list. The current session is then closed.

If you want to open an additional database session in a new window, choose Session ® New SQL Studio.


Recent Sessions List (MaxDB: SQL Studio)

Recent Sessions List

Use

You can open a new database session directly from the recent sessions list.

The list contains up to 10 sessions. Depending on your user settings, the password may be stored for these sessions.

Procedure

Choose Session and then the required session.

· If the password was stored for the selected session, the system connects directly to the database.

· If the password was not stored for the selected session, you must enter the password. The system then connects to the database.

You can delete the list of recent SQL Studio sessions if no current session is open. To do this, choose Session ® Clear Recent Sessions.


Logging Off from the Database (MaxDB: SQL Studio)

Logging Off from the Database

To end a current database connection, choose Session ® Disconnect.

You may want to log off if, for example, you are only authorized to connect to the database once and you want to log on to it from another SAP DB component without ending the SQL Studio program.

If you want to re-logon, or log on with a different user or options, you do not need to log off first. The system automatically closes the existing connection to the database as soon as you log on again with Session ® Connect or via the recent sessions list .


User Settings (MaxDB: SQL Studio)

User Settings

Use

You can personalize the settings in SQL Studio during operation. These settings are stored when you exit SQL Studio.

Procedure

To change your settings, choose Session ® Settings.

You can now make your changes.

General

Store Password | The system stores the password that you used at logon for the next logon.
Confirmation for saving SQL Studio Objects | When the dialog window closes, the system asks whether you want to save the newly created SQL Studio object.
Open Form Dialog read only | Form dialogs are opened in read-only mode first.
Remove failed connection attempts from Recent Sessions list | The system deletes the failed attempts from the recent sessions list.
Identifiers in Create Dialogs uppercase | When you create a new SQL Studio object, the system automatically converts the entries to uppercase.

Result Window

Limit for long columns (Bytes) | Maximum number of bytes that can be loaded from the database for a LONG column
Limit for binary zoom (Bytes) | Maximum number of bytes that can be displayed when zooming in the LONG column of a result table
Representation of null value | How the NULL value is displayed
Clipped result view (Internal Mode) | Result set displayed in segments
Replace non chars in long columns | ASCII codes < 32 are replaced by a blank character when LONG columns are displayed.
Copy columns tab separated to clipboard | When results are temporarily stored on the clipboard, the system separates the columns with tabs.
Copy Result with Column Header | When the results are copied, the system also copies the column headers.
Append Exported Data to File | When you export a result table into a file, the content of this result table is attached to the existing file content.
Display Char Byte Column as Hex Values | Data with the data type CHAR BYTE is stored as hexadecimal digits. If you do not choose this option, then this data is displayed in binary format.

Catalog Manager

Selected table types | Specifies which table types are displayed in the Catalog Manager
Path for local folder | Path to be used to save SQL Studio Objects in a local folder
Restore catalog state | When you log on to the database again, the last view of the Catalog Manager is restored.
Convert input for catalog filter to uppercase | The system automatically converts filter entries in the Catalog Manager to upper case

Query Dialog

Isolation Level | Isolation level for creating SQL statements
SQL mode | SQL mode for creating SQL statements in the SQL dialog The SQL mode INTERNAL is always used for the Form dialog and the Visual Query dialog.
Execute Statements Asynchronously | SQL statements are executed asynchronously. You can specify a period of time (in milliseconds) during which the SQL Studio is inactive when SQL statements are executed.

If you have the user attribute EXCLUSIVE, you cannot change the standard settings for the isolation level and SQL mode. In this case, SQL Studio automatically works with the isolation level COMMITTED and in SQL mode INTERNAL.

For an explanation of the user attributes, see the authorization section of the Reference Manual.


Catalog Manager (MaxDB: SQL Studio)

Catalog Manager

The Catalog Manager is displayed in the left-hand area of the SQL Studio window. It displays all directories and database objects which you are authorized at least to read:

SQL Studio Objects | Stored SQL statements and draft database tables
Tables | Database and system tables, view tables and synonyms arranged according to user
Indexes | Indexes that have been created for tables, arranged according to table and owner
Number sequences | Generated number sequences, arranged according to owner
Favorites | Database tables selected by the user
Users | All users for which the user logged onto the database has owner rights
Database Procedures | Database procedures that the user created in the database
Triggers | Triggers that the user created in the database

If you want the Catalog Manager to show you certain objects only, specify a filter for the object names. Enter the first few letters of the name that you want to use as a filter, and choose Catalog Manager ® Refresh. However, the filter does not apply to your saved SQL statements and drafts.

To show or hide the Catalog Manager, choose View ® Catalog Manager.


SQL Studio Objects (MaxDB: SQL Studio)

SQL Studio Objects

You can store SQL statements and drafts of database tables as SQL Studio objects in the database on locally in the Local Folder subdirectory. This means that you can use the objects at a later date.

Creating SQL Studio Objects

· To create a new folder for SQL Studio objects in the database using the Catalog Manager, choose Catalog Manager ® New ® Folder.

· To create SQL statements and store them as SQL Studio objects, use the SQL dialog, the Form dialog or the Visual Query dialog.

· To store drafts of database tables as SQL Studio objects, create the table definition with the Catalog Manager.

You can enter the path for the Local Folder in the user profile settings.

Editing and Executing SQL Studio Objects

· To edit a stored SQL Studio object, select the object and choose Catalog Manager ® Open Object Definition.

· To use a stored SQL Studio object in dialogs or a table definition, select the object. Choose Catalog Manager ® Send Object To and then the relevant dialog type.

· To execute the SQL statements of a stored SQL Studio object directly, select the object and choose Catalog Manager ® Execute. The system displays the result table in a separate window. If an error occurred, an error message is displayed in the status window of the SQL Studio. Depending on your settings, additional information such as the time it took to execute your SQL statements is also displayed there.

Renaming and Deleting SQL Studio Objects

· To rename a stored SQL Studio object, select the object and choose Catalog Manager ® Rename Object.

· To edit a stored SQL Studio object, select the object and choose Catalog Manager ® Drop Object.


Tables (MaxDB: SQL Studio)

Tables

Under Tables, the Catalog Manager displays the database tables, view tables and synonyms that you have access to in accordance with your user settings. The entries are arranged by owner.

You can create and edit database tables. You can create, rename, and delete view tables and synonyms.

· Creating a database table

· Creating a view table

· Creating a synonym

· Displaying the definition of a table

· Changing the definition of a database table

· Displaying the content of a table

· Using a Table in Dialogs or Definitions

· Renaming a table

· Deleting all rows of a table

· Deleting a table


Creating a Database Table (MaxDB: SQL Studio)

Creating a Database Table

Use

You can use SQL Studio to create new database tables in the database that you are logged on to. When you do so, you can use existing database tables or stored SQL Studio objects as a template for new database tables.

Prerequisites

You have the necessary user authorizations and the user attribute NOT EXCLUSIVE.

For an explanation of user authorizations and user attributes, see the User Concept section of the documentation Database Administration and the Authorization section of the Reference Manual.

Procedure

...

1. Choose Catalog Manager ® New ® Table Definition.
The system opens a window for table definition.

2. To use an existing database table or a saved SQL Studio object as a template for your new database table, choose Table Definition ® Get Table. Select the relevant table or the SQL Studio object, and choose OK to confirm.

3. Enter a table name.

4. Carry out the following steps:

· Defining Columns

· Defining Constraints for Columns

· Defining Foreign Key Dependencies

· Defining Miscellaneous Information

5. To use or edit your table draft again later, save it as an SQL Studio object by choosing Table Definition ® Save As.

6. Choose Table Definition ® Create Table. The system creates the new table in the database.

7. To export the SQL statement for creating the database table to the SQL dialog, choose Table Definition ® Export to SQL Dialog.

For information on the syntax of CREATE TABLE statements, see the CREATE TABLE Statement section of the Reference Manual.


Defining Columns (MaxDB: SQL Studio)

Defining Columns

Use

This section shows you how to define a table column when you create a database table or change a table definition.

Procedure

...

1. In the Name field, enter a name for the column, and confirm it with Enter.

2. In the Datatype field, select the relevant data type.

3. Depending on the data type, you can specify additional properties:

¡ Dimension (Dim)

¡ Code type(Code)

¡ Column is key column

¡ Columns may not contain NULL values (Not NULL)

¡ Default value for column value (Default)

¡ Uniqueness of column values (Unique)

¡ Comment

· To insert a new column, choose New Column. The new column is added to the end of the table.

· To insert a new column and at the same time copy the definition of existing columns in the same table, select the required columns, and choose Clone Column. The new column is added to the end of the table.

· To insert new columns and copy the definition of existing columns from existing tables, choose Import Column. A window opens, containing all columns defined by the current user. Select one or more columns and choose OK. The new column is added to the end of the table.

· In order to remove a column from the table, select the column and choose Remove Column.

You can change the columns sequence by selecting one or more columns and moving them upwards or downwards using the arrows Ý ß.


Defining Constraints (MaxDB: SQL Studio)

Defining Constraints

Use

This section shows you how to define constraints for table columns when you create a database table or change a table definition. A constraint for the values of a column is composed of one or more conditions that you formulate line-by-line and can link together.

Prerequisites

You have already defined the table columns.

You can only formulate constraints for columns with valid column definitions.

Procedure

1. In the Name field, enter a name for the constraint (optional).

2. In the Column field, select the column that you want to formulate the condition for.

3. In the Predicate field, select a predicate for the condition. To negate the condition, use the NOT operator !. Negation is not possible with relational operators.

4. In the Expression field, enter the relational expression for the condition, and confirm it with Enter.
When you enter the relational expression, you can choose between the following options:

Option | Meaning
Single Value | The expression consists of a single value.
ALL | The condition must be fulfilled with all expressions in the list (Expression List).
ANY | The condition must be fulfilled with at least one expression in the list (Expression List).
DEFAULT | The expression consists of the default value of the column.

5. Enter how the formulated condition is to be linked with the next condition (AND/OR).

If you retrospectively reset the relation type to <none>, all subsequently formulated conditions are deleted immediately.

6. To insert a new constraint, choose New Constraint.

7. To insert new constraints and at the same time copy the definition of existing constraints in the same table, select the required constraints, and choose Copy Constraint.

8. To insert new constraints and copy the definition of existing constraints from existing tables, choose Import Constraint. A window opens, containing all constraints defined by the current user. Select one or more constraints and choose OK to confirm.

9. In order to delete a constraint, select the constraint and choose Remove Constraint.


Defining Foreign Key Dependencies (MaxDB: SQL Studio)

Defining Foreign Key Dependencies

Use

This section shows you how to define foreign key dependencies to other database tables when you create a database table or change the table definition. Foreign key dependencies describe the dependencies between the data of two tables.

Prerequisites

You have already defined the table columns.

Procedure

1. In the field Foreign Key Name, enter the name for the foreign key (optional).

2. In the field Referencing Columns, choose the referencing column, and confirm with Enter.

3. Copy the referenced database table from the Catalog Manager into Reference by using Drag&Drop. Select the column that is referenced and confirm with Enter.

4. In the field On Delete, select how you want the referenced table to behave if a data record in the referencing table is deleted (DELETE rule).

5. In the Comment field, enter a comment (optional).

6. To add a new link, choose New Foreign Key.

7. To insert new links and at the same time copy the definition of existing links of the same table, select the required links, and choose Copy Foreign Key.

8. To insert new links and copy the definition of existing links from existing tables, choose Import Foreign Key. A window opens, containing all links defined by the current user. Select one or more links and choose OK.

9. To delete a link, select it and choose Remove Foreign Key.

For information on the syntax of referential CONSTRAINT definitions, see the referential CONSTRAINT definition section of the Reference Manual.


Defining Miscellaneous Information (MaxDB: SQL Studio)

Defining Miscellaneous Information

When you create database tables or change table definitions, you can make the following additional entries in the Misc field:

Entry | Meaning
Comment | Comment
Duplicates | You can use the DUPLICATES clause to control behavior if key collisions occur.
Statistics | Sample Value specifies how large the portion of data is that is included for optimization of the database strategy.
Temporary Table Ignore Rollback | The table is a temporary table and is saved locally under Temp. For temporary tables, you can specify the option Ignore Rollback.
Identifiers Uppercase | Automatic conversion of table names, column headers and other names into upper case. A change to this setting affects the entire table definition immediately. If you use a database table as a template for the creation of another database table, the user setting is copied from the template.

For information on the syntax of CREATE TABLE statements, see the CREATE TABLE Statement section of the Reference Manual.


Anlegen einer Viewtabelle (MaxDB: SQL Studio)

Anlegen einer Viewtabelle

Use

You can use SQL Studio to create view tables.

Prerequisites

· If you want the view table to be based on a database query, you must have already saved this query as an SQL Studio object.

· You have the necessary user authorizations and the user attribute NOT EXCLUSIVE.

For an explanation of user authorizations and user attributes, see the User Concept section of the documentation Database Administration and the Authorization section of the Reference Manual.

Procedure

...

1. Choose Catalog Manager ® New ® View Definition.
A window for defining the view table is opened.

2. To use a database table as a basis for the view table, choose View Definition ® Get Table. Select the relevant database table, and choose OK to confirm.

3. To use the structure of the result set of a stored database query as the basis for the view table, choose View Definition ®Get Stored Query. Select the relevant database query, and choose OK to confirm.

4. Enter a name for the view table.

5. If you want to rename the columns of your view table, enter the new column names in Alias in View.

6. Select the required options:

Replace Existing View | Replace the existing view table
Check on Insert or Update | Check the view conditions when changing values
Identifiers Uppercase | Automatic conversion of table names and column headers into upper case.

7. Choose View Definition ® Create View.

To export the SQL statement for creating the view table to the SQL dialog, choose View Definition ® Export to SQL Dialog.

For information on the syntax of CREATE VIEW statements, see the CREATE VIEW Statement section of the Reference Manual.


Creating a Synonym (MaxDB: SQL Studio)

Creating a Synonym

Use

You can use SQL Studio to create synonyms for database tables.

Prerequisites

You have the necessary user authorizations and the user attribute NOT EXCLUSIVE.

For an explanation of user authorizations and user attributes, see the User Concept section of the documentation Database Administration and the Authorization section of the Reference Manual.

Procedure

1. In the Catalog Manager select the database table that you want to create a synonym for, and choose Catalog Manager ® New ® Synonym Definition.
A window for defining the synonym is opened.

2. Enter a synonym name, and select whether the synonym is to be private or public.

3. Choose Synonym Definition ® Create Synonym.

To export the SQL statement for creating the synonym to the SQL dialog, choose Synonym Definition ® Export to SQL Dialog.

For information on the syntax of CREATE SYNONYM statements, see the CREATE SYNONYM Statement section of the Reference Manual.


Displaying the Definition of a Table (MaxDB: SQL Studio)

Displaying the Definition of a Table

Use

You can use SQL Studio to display the definition of a database table, view table, or synonym.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the table that you want to display the definition of.

2. Choose Catalog Manager ® Open Object Definition.


Changing the Definition of a Database Table (MaxDB: SQL Studio)

Changing the Definition of a Database Table

Use

You can use SQL Studio to change the definition of a database table.

Prerequisites

You have the necessary user authorizations and the user attribute NOT EXCLUSIVE.

For an explanation of user authorizations and user attributes, see the User Concept section of the documentation Database Administration and the Authorization section of the Reference Manual.

Procedure

...

1. Select the table and choose Catalog Manager ® Alter Table.
The system opens a window for table definition.

2. Make the required changes:

· Defining Columns

· Defining Constraints for Columns

· Defining Foreign Key Dependencies

· Defining Miscellaneous Information

3. Choose Table Definition ® Alter Table.

To export the SQL statement for changing the database table to the SQL dialog, choose Table Definition ® Export to SQL Dialog.

For information on the syntax of ALTER TABLE statements, see the ALTER TABLE Statement section of the Reference Manual.


Displaying the Content of a Table (MaxDB: SQL Studio)

Displaying the Content of a Table

Use

You can use SQL Studio to display the content of a table.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the table that you want to display the content of.

2. Choose Catalog Manager ® Show Content.


Using a Table in Dialogs or Definitions (MaxDB: SQL Studio)

Using a Table in Dialogs or Definitions

Use

You can copy tables directly from the Catalog Manager into an SQL dialog, a form dialog, or a Visual Query dialog. You can also use tables as the basis for a table definition or view definition.

Procedure

Select the table in the Catalog Manager. Choose Catalog Manager ® Send Object To and then the relevant dialog type.


Renaming a Table (MaxDB: SQL Studio)

Renaming a Table

Use

You can use SQL Studio to rename tables.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the table that you want to rename.

2. Choose Catalog Manager ® Rename Object and enter the new name.


Deleting all Rows of a Table (MaxDB: SQL Studio)

Deleting all Rows of a Table

Use

You can use SQL Studio to delete all rows of a table.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the table for which you want to delete the rows.

2. Choose Catalog Manager ® Delete All Rows

If you delete the rows of a synonym, you thereby delete the rows of the original database table.


Deleting a Table (MaxDB: SQL Studio)

Deleting a Table

Use

You can use SQL Studio to delete a table from the database.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the table that you want to delete from the database.

2. Choose Catalog Manager ® Drop Object.


Indexes (MaxDB: SQL Studio)

Indexes

Under Indexes, the Catalog Manager displays all the tables that indexes have been created for. The following options are available:

  • Creating an index
  • Displaying the definition of an index
  • Deleting an index


Creating an Index (MaxDB: SQL Studio)

Creating an Index

Use

You can use SQL Studio to create new indexes for database tables.

Prerequisites

You have the necessary user authorizations and the user attribute NOT EXCLUSIVE.

For an explanation of user authorizations and user attributes, see the User Concept section of the documentation Database Administration and the Authorization section of the Reference Manual.

Procedure

...

1. In the Catalog Manager select the database table that you want to create an index for, and choose Catalog Manager ® New ® Index Definition.

2. In the Index Name field, enter a name for the index.

3. In the In Index field, choose Yes for the columns that you want to index values for.

4. To sort the index values in ascending or descending order, select the option ASC or DESC in the Sort field.

5. To change the sequence of the table columns, select a table column and use the Ý ß, arrows to move it up or down.

6. Select the required options:

Unique | Ensures the uniqueness of the indexed columns
Index Name Uppercase | Automatic conversion of table names and column headers into upper case.

7. Choose Table Definition ® Create Index.

8. To export the SQL statement for creating the index to the SQL dialog, choose Index Definition ® Export to SQL Dialog.

For information on the syntax of CREATE INDEX statements, see the CREATE INDEX Statement section of the Reference Manual.


Displaying the Definition of an Index (MaxDB: SQL Studio)

Displaying the Definition of an Index

Use

You can use SQL Studio to display the definition of an index.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the index that you want to display the definition of.

2. Choose Catalog Manager ® Open Object Definition.


Deleting an Index (MaxDB: SQL Studio)

Deleting an Index

Use

You can use SQL Studio to delete the index of a database table.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the index that you want to delete.

2. Choose Catalog Manager ® Drop Object.


Number Sequences (MaxDB: SQL Studio)

Number Sequences

Under Sequences , the Catalog Manager displays all the sequences that were created in the database. The following options are available:

  • Creating a sequence
  • Displaying the definition of a sequence
  • Deleting a sequence


Creating a Sequence (MaxDB: SQL Studio)

Creating a Sequence

Use

You can use SQL Studio to create new sequences in the database.

Prerequisites

You have the necessary user authorizations and the user attribute NOT EXCLUSIVE.

For an explanation of user authorizations and user attributes, see the User Concept section of the documentation Database Administration and the Authorization section of the Reference Manual.

Procedure

...

1. Choose Catalog Manager ® New ® Sequence Definition.

2. Enter a name for the sequence, and define the required values.

3. Choose Sequence Definition ® Create Sequence.

4. To export the SQL statement for creating the sequence to the SQL dialog, choose Sequence Definition ® Export to SQL Dialog.

For information on the syntax of CREATE SEQUENCE statements, see the CREATE SEQUENCE Statement section of the Reference Manual.


Displaying the Definition of a Sequence (MaxDB: SQL Studio)

Displaying the Definition of a Sequence

Use

You can use SQL Studio to display the definition of a sequence and the most recently generated value of this sequence.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the sequence that you want to display the definition of.

2. Choose Catalog Manager ® Open Object Definition.


Deleting a Sequence (MaxDB: SQL Studio)

Deleting a Sequence

Use

You can use SQL Studio to delete sequences from the database.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the Catalog Manager, select the sequence that you want to delete.

2. Choose Catalog Manager ® Drop Object.


Favorites (MaxDB: SQL Studio)

Favorites

So that you can access database objects quickly and easily, you can store them in the Favorites folder in the Catalog Manager.

· To store a database object in the Favorites folder, select the required database object and choose Catalog Manager ® Add to Favorites.

· To remove a database object from the Favorites folder, select the relevant database object and choose Catalog Manager ® Remove from Favorites.

· To remove all database objects from the Favorites folder, select the Favorites folder and choose Catalog Manager ® Clear Favorites.


User (MaxDB: SQL Studio)

User

Under Owned Users, the Catalog Manager displays the users for which you have owner rights. SQL Studio enables you to view information about these users, and rename and delete users.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

· To display information about a user, select the user name, choose Catalog Manager ® Open Object Definition.

· To change a user name, select it and choose Catalog Manager ® Rename Object.

· To delete a user, select the user name, and choose Catalog Manager ® Drop Object.


Database Procedures (MaxDB: SQL Studio)

Database Procedures

Under Procedures, the Catalog Manager displays all the database procedures that were created in the database. You can use SQL Studio to display the definitions of these database procedures, and to delete the database procedures.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations and user properties, see the User Concept section of the documentation Database Administration.

Procedure

· To display a database procedure, choose Catalog Manager ® Open Object Definition.

· To delete a database procedure, select it and choose Catalog Manager ® Drop Object.

For information on the syntax of CREATE DBPROC statements, see the CREATE DBPROC Statement section of the Reference Manual.


Triggers (MaxDB: SQL Studio)

Triggers

Under Triggers, the Catalog Manager displays all the triggers that were created in the database. You can use SQL Studio to display the definitions of these triggers, and to delete the triggers themselves.

Prerequisites

You have the required user authorizations.

For an explanation of user authorizations and user properties, see the User Concept section of the documentation Database Administration.

Procedure

· To display the definition of a trigger, select it and choose Catalog Manager ® Open Object Definition.

· To delete a trigger, select it and choose Catalog Manager ® Drop Object.

For information on the syntax of CREATE TRIGGER statements, see the CREATE TRIGGER Statement section of the Reference Manual.


SQL Dialog (MaxDB: SQL Studio)

SQL Dialog

If you want to create SQL statements directly in SQL, you use the SQL dialog.

The following options are available in the SQL dialog:

· Creating and executing SQL statements

· Setting parameters for SQL statements

· Importing and exporting SQL statements

For information on the syntax and semantics of the SQL statements of the database system, see the Reference Manual.


Creating and Executing SQL Statements (MaxDB: SQL Studio)

Creating and Executing SQL Statements

Use

In the SQL dialog, you can create and save SQL statements in a number of different modes.

Procedure

1. Choose View ® SQL Dialog. The system opens a window for the SQL dialog.

2. The default values that you set in the user settings are used for the SQL mode and the isolation level. If you want to use different values, select a different SQL mode and isolation level in the lower part of the dialog box.

3. You can also change the commit mode in the lower part of the dialog box.

If you have the user attribute EXCLUSIVE, you can select the mode Auto Commit: ON only. For an explanation of the user attributes, see the authorization section of the Reference Manual.

4. Enter your SQL statements.

You can add SQL statements that were already executed during the current database session. Choose SQL Dialog ® Recent Statements. Select the required statement, and choose Get.

The keyword list also supports you in creating SQL statements.

5. To comment out a row, use // or –– at the start of the row.

6. To separate several SQL statements from one another, enter a commented-out separator line.

7. To scroll through the statement history of the database session, choose SQL Dialog ® Previous Statement or SQL Dialog ® Next Statement.

8. You can set parameters for SQL statements.

9. To use or edit your statements again later, save them as SQL Studio objects by choosing SQL Dialog ® Save As.

10. To execute the SQL statements, choose SQL Dialog ® Execute. If you only want to execute some of the displayed SQL statements, select the section that you want to execute and choose SQL Dialog ® Execute.

Result

The status line of the statement window indicates whether your SQL statements were executed successfully. If an error occurred, an error message is displayed in the status window of the SQL Studio. Depending on your settings, additional information such as the time it took to execute your SQL statements is also displayed there.

If your SQL statement returns a result table, this is displayed in a separate window.


Keyword List (MaxDB: SQL Studio)

Keyword List

Use

In the SQL dialog, the Keyword List supports you in creating SQL statements.

Procedure

1. To access the list of keywords, choose SQL Dialog ® Show Keyword List.

2. To add your own keywords to the list, select the required word in your SQL statement and choose SQL Dialog ® Add to Keyword List.

3. To remove your own keywords from the list, select the required word in your SQL statement and choose SQL Dialog ® Remove from Keyword List.


Setting Parameters for SQL Statements (MaxDB: SQL Studio)

Setting Parameters for SQL Statements

Use

In the SQL dialog, you can set parameters for SQL statements. When you execute the SQL statement for which a parameter has been set, a dialog window opens in which you must enter a value for the parameter.

Procedure

1. When you create an SQL statement, insert square brackets in all the places you want a variable entry to be possible.

2. If you want to formulate a prompt for the dialog window, enter this prompt within the square brackets.

If you want to set parameters for queries for the columns Article No. and Unit Price in the Article table, you can set the following parameters among the selection criteria:

SELECT  "Article No.", "Unit Price" FROM "Article"
WHERE  "Article No." > [article number (from)]
AND  "Article No." < [article number (to)]
AND  "Unit Price" <= [upper price limit]

By setting parameters you can also replace entire sections of an SQL statement.

You can formulate a SELECT statement and add a WHERE condition using a parameter:

SELECT * FROM USERS [Your WHERE condition]

If you specify a comparison value for the data type CHAR, VARCHAR, DATE or TIME, you must enclose the comparison value in single quotation marks.


Importing and Exporting SQL Statements (MaxDB: SQL Studio)

Importing and Exporting SQL Statements

Use

In the SQL dialog , you can import and export SQL statements as ASCII format text files.

Procedure

Choose Import File or Export File in the context menu of the SQL dialog.


Form Dialog (MaxDB: SQL Studio)

Form Dialog

You use the Form dialog if you want to display, select, and edit data records from tables in a screen display.

The following options are available in the Form dialog:

· Executing a Form dialog

· Selecting data records using search conditions

· Changing data records

· Inserting data records

· Deleting a data record

· Importing and exporting LONG columns

If you want to create statements directly in SQL or want to use database options other than the editing of data records, use the SQL dialog.


Executing a Form Dialog (MaxDB: SQL Studio)

Executing a Form Dialog

Use

You can use the form dialog to execute statements to edit data records at different isolation levels.

Procedure

...

1. Choose View ® Form Dialog. The system opens a window for the Form dialog.

2. Depending on your user settings, at first you are in read only or in change mode. If you want to change the dialog mode, activate or deactivate the Read Only selection in the lower part of the dialog box.

3. The default value that you set in the user settings is entered for the isolation level. If you want to use a different isolation level, select the relevant isolation level in the lower part of the dialog box.

4. Choose Form Dialog ® Get Table. Select the table that you want to edit, and choose OK to confirm.
The first data record is displayed in the left half of the window. You can use the arrows < > to scroll through the data records. In change mode, you can change, insert, or delete data records. In the right half of the window, you can enter search conditions for selecting specific records.

To hide the window area for entering the search conditions, deselect the Filter flag.

5. To view the data records as a list, choose Report. To switch back to the screen display, choose Record.

6. To use or edit the dialog again later, save it as an SQL Studio object by choosing Form Dialog ® Save As.

7. To export the SQL statement of your Form dialog to the SQL dialog, choose Dialog ® Export to SQL Dialog.


Selecting Data Records Using Search Conditions (MaxDB: SQL Studio)

Selecting Data Records Using Search Conditions

Use

To display only certain data records of a table, you can enter search conditions in the Form dialog.

Procedure

1. To display the window area for entering the search conditions, select the Filter flag.

2. Formulate your search conditions for the appropriate table columns. Select the required predicate, and enter comparison values or relational expressions.

3. Enter how the formulated search condition is to be linked with the next search condition.

4. Choose Refresh. SQL Studio downloads the data records from the database.

For information on the syntax of predicates, see the predicate section of the Reference Manual.


Changing Data Records (MaxDB: SQL Studio)

Changing Data Records

Use

You can use the Form dialog to edit and change data records in a screen display.

Prerequisites

· You have selected change mode for executing the Form dialog.

· You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the screen display, scroll to the data record that you want to change.

2. Enter your changes.

The names of key columns are emboldened.

You can import and export the contents of LONG columns.

3. Confirm with Update. SQL Studio transfers the changes to the database.


Inserting Data Records (MaxDB: SQL Studio)

Inserting Data Records

Use

You can use the Form dialog to insert new data records in tables in a screen display.

Prerequisites

· You have selected change mode for executing the Form dialog.

· You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

...

1. In the screen display, choose Form Dialog ® New. An empty input form opens.

2. Enter your data. Note the following:

¡ The names of key columns are emboldened.

¡ For a NULL value, enter the display of the NULL value according to your user settings (?, for example).

¡ If you leave a field blank when you insert a data record, the system interprets this in the following ways:

§ If a DEFAULT value is defined for the relevant column, this value is copied to the database table.

§ If no DEFAULT value is defined for the relevant column, the NULL value is copied to the database table.

¡ You can import and export the contents of LONG columns.

3. Choose Insert. SQL Studio stores the new data record in the table.
Another input form opens. You can enter further data directly and insert this as data records.

4. If you do not want to insert any more data records, deselect Form Dialog ® New.

5. To view the new data records in a list display, choose Refresh and then Report.

When you insert data records, you can use an existing data record from the same table as a template. Scroll to this data record, enter your changes, and choose Insert. The data record is inserted in the table as a new data record.


Deleting a Data Record (MaxDB: SQL Studio)

Deleting a Data Record

Use

You can use the Form dialog to delete data records.

Prerequisites

· You have selected change mode for executing the Form dialog.

· You have the required user authorizations.

For an explanation of user authorizations, see the User Concept section of the documentation Database Administration.

Procedure

1. In the screen display, scroll to the data record that you want to delete.

2. Choose Delete.

SQL Studio deletes the data record from the database immediately.


Importing and Exporting LONG Columns (MaxDB: SQL Studio)

Importing and Exporting LONG Columns

Use

You can use the Form dialog to import the content of LONG columns from a file or the clipboard, and export them to a file or the clipboard.

Procedure

1. To import the content of a LONG column from a file, click the input field of this column in the screen display, and choose Form Dialog ® Import Long ® Import from File.

2. To import the content of a LONG column from the clipboard, click the input field of this column in the screen display, and choose Form Dialog ® Import Long ®Import Text from Clipboard.

3. To export the content of a LONG column to a file, click the input field of this column in the screen display, and choose Form Dialog ® Export Long ® Export to File.

4. To export the content of a LONG column to the clipboard, click the input field of this column in the screen display, and choose Form Dialog ® Export Long ® Export to Clipboard as Text.


Visual Query Dialog (MaxDB: SQL Studio)

Visual Query Dialog

If you want the system to provide you with visual support when you formulate database queries, you can use the Visual Query dialog.

The following options are available in the Visual Query dialog:

· Creating and executing a Visual Query

· Linking table columns with JOINS

· Entering search conditions

· Setting parameters for search conditions

· Defining a result view

If you want to create statements directly in SQL or want to use other database options in addition to database queries, use the SQL dialog.


Creating and Executing a Visual Query (MaxDB: SQL Studio)

Creating and Executing a Visual Query

Use

In the Visual Query dialog, you can create and save SQL statements on a number of different isolation levels.

Procedure

...

1. Choose View ® Visual Query. The system opens a window for the Visual Query dialog. The window consists of the following areas:

¡ The top half of the window is the area for selecting tables.

¡ The bottom half of the window is the area for defining the result.

2. The default value that you set in the user settings is entered for the isolation level. If you want to use a different isolation level, select the relevant isolation level in the lower part of the dialog box.

3. Choose Visual Query ® Get Table. Select the table that you want to use in your database query, and choose OK to confirm. In this way, you can copy up to 16 tables to the area for selecting tables. For each of the tables copied, the system opens a window containing the names of the table columns.

¡ To rearrange the tables, choose Visual Query ® Arrange Tables or Visual Query ® Cascade Tables.

¡ To remove a table from the table selection, close the relevant window.

¡ To remove all tables from the table selection, choose Visual Query ® Clear Window.

4. Select the names of the table columns that your database query relates to, and use the Drag&Drop function to copy them to the area for defining the result.

If you enter *, you copy all table columns of a table into the area for defining the result. To remove a table column from the result definition, select the column and choose Visual Query ® Delete Column.

5. You can link table columns with JOINS, enter search conditions for the data records, and define the result view.

6. To use or edit your Visual Query again later, save it as an SQL Studio object by choosing Visual Query ® Save As.

7. To execute the database query that you created with Visual Query, choose Visual Query ® Execute.

8. To export the SQL statements of your Visual Query to the SQL dialog, choose Visual Query ® Export to SQL Dialog.

Result when Executing a Visual Query

The status line of the statement window indicates whether your SQL statements were executed successfully. If an error occurred, an error message is displayed in the status window of the SQL Studio. Depending on your settings, additional information such as the time it took to execute your SQL statements is also displayed there.

If your database query returns a result table, this is displayed in a separate window.


Linking Table Columns with JOINS (MaxDB: SQL Studio)

Linking Table Columns with JOINS

Use

You can use the Visual Query dialog to link table columns with JOINS in database queries.

For information on the syntax of JOINS, see the JOIN predicate section of the Reference Manual.

Prerequisites

When you created the Visual Query, you copied the tables containing the columns you want to link together to the area for selecting tables.

Procedure

1. In the table selection, select the table column that you want to link, and choose the Drag&Drop function to link it to the relevant column in the other table. The system displays a connecting line between the two table columns.

2. To specify the JOIN in more detail, select it, and choose Show Join Definition in the context menu. The system opens a window for the JOIN definition. Select the JOIN type and relational operator, and choose OK.

3. To delete a JOIN, select it and choose Delete Join in the context menu.

If you copy the same table to the table selection twice, SQL Studio assigns an alias name. In this way, you can create SELF JOINS.


Entering Search Conditions (MaxDB: SQL Studio)

Entering Search Conditions

Use

In the Visual Query dialog, you can enter search conditions when you formulate your database query.

Prerequisites

When you created the Visual Query, you copied the table columns that your database query relates to into the area for defining the result.

Procedure

1. In the relevant table column, enter your search condition in the Predicate field.
You can set parameters for the search condition .

If you specify a search condition for a column with the data type CHAR, VARCHAR, DATE or TIME, you must put the relational expression between single quotation marks.

2. You can formulate several search conditions with AND links or OR links. If you want to use one column several times to formulate search conditions, but only want to display it once, you can hide it in the result view.

· To formulate several search conditions with AND links, enter these conditions in the same row.

· To formulate several search conditions with OR links, enter each of these conditions in a new row.

For information on the syntax of search conditions and predicates, see the search condition and predicate sections of the Reference Manual.


Setting Parameters for Search Conditions (MaxDB: SQL Studio)

Setting Parameters for Search Conditions

Use

In the Visual Query dialog, you can set parameters for search conditions for database queries. When you execute the database query a dialog window then opens in which you must enter a value for the parameter.

Procedure

1. When you create a search condition, insert square brackets in all the places you want a variable entry to be possible.

2. If you want to formulate a prompt for the dialog window, enter this prompt within the square brackets.

You can set parameters for the search condition for the Order_No column of the table Purchase orders as follows:
=[order number:]


Defining the Result View (MaxDB: SQL Studio)

Defining the Result View

Use

In the Visual Query dialog, you can specify how SQL Studio displays the result of your database query.

Prerequisites

When you created the Visual Query, you copied the table columns that your database query relates to into the area for defining the result.

Procedure

1. To assign a synonym to a column name, enter the name of the synonym in the Synonym line.

2. To hide a column in the result view, choose No in the Visible line of the relevant column.

This is particularly useful if you only need the column in order to formulate search conditions.

3. To group the results according to the column values, choose Yes in the Group line of the relevant column.

You can use this grouping feature to define average values, maximum values, minimum values, totals, and the number of found data records in the result view.

4. To sort the data records in ascending or descending order, in the Order field, select Ascending or Descending in the column that you want to use for sorting.


Result Tables (MaxDB: SQL Studio)

Result Tables

SQL Studio displays the results of each database query in a separate area of the window. You can use the navigation functions in the context menu of a result to scroll through the result table.

The following options are also available:

  • Adjusting the result view
  • Saving a result

If you execute several SQL statements at once in the SQL dialog , several individual result tables are generated. You can use the selection list in the status line of the result window to switch between these result tables.


Adjusting the Result View (MaxDB: SQL Studio)

Adjusting the Result View

Use

You can display the result table in segments or consecutively. You can rename or hide columns, or fix (freeze) them in the result table to make scrolling easier, and you can change the font of the result table.

Procedure

1. To always display the result table in segments, choose Clipped Result View in the user settings.
In the SQL dialog and the Visual Query dialog, you can change this setting for the current dialog window. To do this, choose SQL Dialog ® Clipped Result View or Visual Query ® Clipped Result View.

2. To rename, hide or fix columns, choose Customize in the context menu for the result. Make the following settings:

¡ Change the column names, if required.

¡ Change the Visible setting for the individual columns, if required.

¡ In Fixed Columns, enter the number of columns that you want to fix, starting from the left.

Confirm your settings with OK.

3. To change the font of the result table, choose Font in the context menu for the result. Select the required font, and confirm with OK.


Saving a Result (MaxDB: SQL Studio)

Saving a Result

Use

In the SQL mode INTERNAL, you can save the complete result of a database query as a text file, or export it to Microsoft Excel. You can save individual cells as a text file, or display them in a separate zoom window.

Procedure

· To save the complete result table as a text file, choose Export Result to ® File in the context menu for the result.
Depending on your user settings, the content of the result table is attached to the existing file content, or a new file content is generated.
When SQL Studio saves the result, it separates the columns with tabs, and the rows with line breaks. Column contents with the datatype CHARACTER or LONG are cut off after 16 characters. Characters that cannot be displayed are replaced by blanks.

· To export the complete result table to Microsoft Excel, choose Export Result to ® Excel in the context menu for the result.
Microsoft Excel opens automatically, and transfers a maximum of 1024 bytes per cell. Data with type CHARACTER are cut off after 1021 bytes.

· To save a cell as a text file, choose Export Cell to ® File.
Depending on your user settings, the content of the result table is attached to the existing file content, or a new file content is generated.

· To display a cell in a separate zoom window, choose Export Cell to ® Zoom Window.In the user settings you can decide how many bytes are displayed in the zoom window.

Exporting and/or displaying the contents of cells is particularly helpful for column contents that have data type LONG.


Status Window (MaxDB: SQL Studio)

Status Window

In the status window on the lower part of the screen of the SQL Studio, the system displays information such as error messages or the time it takes to execute particular SQL statements.

You can search for words or terms, copy the text in the status window, or export it as a text file.

The following options are also available:

· If, in addition to error messages, you want to see information about your actions in the SQL Studio, choose Status Window ® Trace All.

· If you want to select the entire content of the status window, choose Status Window ® Select All.

· If you want to delete the content of the status window, choose Status Window ® Clear.

· If you want to show or hide the status window, choose View ® Status Window.


Web SQL Studio

MySQL MaxDB is a relational database system with an SQL-compatible user interface.

"Relational" means that the database system provides its users with all its information in the form of tables. The standard language SQL (Structured Query Language) provides a set of statements that you can use to maintain and analyze these tables.

The Web-based query tool Web SQL Studio allows easy access to the data of a database instance. Once you have installed Web SQL Studio in your network, you can start it from all browsers, and open a database session. You can now create SQL statements, edit saved SQL statements, and manage and execute SQL statements.

For Microsoft Windows users, the query tool SQL Studio with enhanced functions is also available.

For information about installing Web SQL Studio, see the Web Tools Installation Guide.

For general information about the database system, see Database Administration.


Starting Web SQL Studio (MaxDB: Web SQL Studio)

Starting Web SQL Studio

Prerequisites

The Web Tools have been installed once in the network and the Web Server has been started (see the Web Tools Installation Guide).

Procedure

To start Web SQL Studio, open your Web browser and enter the following URL:

http://<web_server>:<port>/websql

· For <web_server>, enter the name of the host where the Web Server is installed.

· For <port>, enter the port address of the Web Server.

You have now started Web SQL Studio, and you can open a database session.


Opening a Database Session (MaxDB: Web SQL Studio)

Opening a Database Session

Use

To use Web SQL Studio to access the data of a database instance, you must first create a connection to the database host and log on to the database.

Prerequisites

· You have started Web SQL Studio.

· The operational state of the database instance that you want to access is ONLINE.

If the operational state of the database instance is not ONLINE, use the Database Manager to start the database instance.

Procedure

...

1. Enter the name of the database host and the name of the database instance.

2. Enter your user name and password, and choose Logon.

When you enter your user name and password, the system automatically changes all the letters to uppercase. If you want the system to differentiate between lowercase and uppercase, you have to enter the user name and password enclosed by quotation marks. The quotation marks are also necessary if the user name or password includes special characters. Your user name and password are not allowed to contain quotation marks.

Result

Web SQL Studio creates a connection to the selected database instance. You can now create SQL statements, edit saved SQL statements, and execute SQL statements.

To end the database session, choose Logoff in the header of Web SQL Studio.


Creating an SQL Statement (MaxDB: Web SQL Studio)

Creating an SQL Statement

Use

You can use Web SQL Studio to create, save, and execute new SQL statements.

Prerequisites

· You have opened a database session.

· You have the required user authorizations.

For an explanation of user authorizations and user attributes, see the Authorization section of the Reference Manual.

Procedure

...

1. Enter your SQL statements in the SQL dialog window.

2. To make a line into a comment, enter // or –- at the beginning of the line.

3. To separate two SQL statements from one another, enter an excluding separator line.

4. To display statements that have already been executed in this database session, choose Prev Statement or Next Statement.

5. To delete all the contents of the SQL dialog window, choose Clear.

6. Set parameters, if necessary.

7. To reuse or edit your SQL statement at a later stage, you can save it. To do this, select the relevant folder, and choose Save in Selected Folder. Enter a name for the SQL statement, and choose OK.


Setting Parameters for an SQL Statement (MaxDB: Web SQL Studio)

Setting Parameters for an SQL Statement

Use

You can set parameters for SQL statements. When you execute an SQL statement for which parameters exist, the system displays a dialog box where you have to enter a value for the parameter.

Procedure

  1. When you create the SQL statement, insert square brackets in all the places where you want the user to enter variables.
  2. If you want to formulate a prompt for the dialog box, enter this prompt within the square brackets.
  3. By setting parameters you can also replace entire sections of an SQL statement.


Processing a Saved SQL Statement (MaxDB: Web SQL Studio)

Editing a Saved SQL Statement

Use

You can use Web SQL Studio to open, edit, and execute SQL statements.

Prerequisites

· You have opened a database session.

· You have the required user authorizations for editing the SQL statement.

For an explanation of user authorizations and user attributes, see the Authorization section of the Reference Manual.

Procedure

...

1. To open a saved SQL statement, expand the relevant folder on the left-hand side, and select the SQL statement. The system displays the statement in the SQL dialog window.

2. Edit the statement in the SQL dialog window.

3. Choose Save.

Web SQL Studio accesses the same dataset as SQL Studio. All the folders that were created with SQL Studio, and all the saved SQL Studio objects are also visible in Web SQL Studio. One exception is the Local Folder.

If you open objects that were created in SQL Studio with Form Dialog or Visual Query, or that are table definitions, the system displays the underlying SQL statement. You can only save this statement under a new name. To do this, select a folder, and choose Save in Selected Folder. Enter a name for the SQL statement, and choose OK.

Under Type on the right-hand side next to the SQL dialog window, you can see the object type of the statement that you opened.


Executing an SQL Statement (MaxDB: Web SQL Studio)

Executing an SQL Statement

Use

You can use Web SQL Studio to execute new or saved SQL statements. Before you execute an SQL statement, you can select its commit mode, SQL mode, and isolation level.

Prerequisites

You have created a new SQL statement or edited a saved SQL statement. The system displays the statement that you want to execute in the SQL dialog window.

Procedure

...

1. On the right-hand side next to the SQL dialog window, select the relevant modes and the isolation level for executing the statement.

2. Choose Execute.

Result

· If your SQL statement returns a results table, the system displays this table in the lower screen area.

· If you executed multiple SQL statements simultaneously, you can browse the result tables by using the dropdown menu.

· If your SQL statement does not return a results table, the system displays information in the results window about whether your statement was executed successfully.


WebDAV GUI

The MaxDB WebDAV GUI is an HTML-based application that simplifies administration and metadata management when you index XML documents. These XML documents are stored in the Document Store (WebDAV store) of the WebDAV Service.

· Overview: XML Indexing and the WebDAV Service

· How the WebDAV GUI Works

· Terms

· Supported Subset of the XPATH Standard

WebDAV XML Indexing is one of the WebDAV Services. These are installed and set up with the WebTools (see also the WebTools Installation Guide).

For general information on the database system, see the documentation Database Administration.


Overview: XML Indexing and the WebDAV Service (MaxDB: WebDAV GUI)

Overview: XML Indexing and the WebDAV Service

A MaxDB database instance is used as a store for the WebDAV documents and their properties (WebDAV Properties). The metadata needed for the indexing of XML documents, such as XML index definitions, is also stored in the database.

The indexing service accesses this metadata, and uses it to determine the index values for the XML documents that you want to index. These index values are stored as WebDAV properties with the documents in the database instance.

For the synchronous indexing of documents, an internal indexing service is already available as part of the WebDAV Service. You can adapt this internal service to your requirements.

If you want to index XML documents asynchronously, then you must define at least one separate indexing service.


Synchronous Indexing (MaxDB: WebDAV GUI)

Synchronous Indexing

When you perform synchronous indexing for an XML document, the document is indexed each time you use a modified PUT request to save it to the document store. The index values are stored as WebDAV properties.

If the indexing fails, the document is not saved to the document store.

Procedure

...

1. Use the following HTTP header to assign the XML document to a document class:

SAPDB_DocumentClass: <document_class>

2. If you want to prevent the document being indexed synchronously, even though it is assigned to a document class, then use an additional header, as follows:

SAPDB_AsyncIndexing: {F|T}

¡ If you specify F (False) or if you do not specify this header, then the document is indexed synchronously.

¡ If you specify T (True), then the XML document is saved only with the information about its document class. The document is then indexed asynchronously by the index engine.

PUT /webdav/test.xml HTTP/1.1
Host: <web_server>
Content-Type: text/xml
Content-Length: 1000
SAPDB_DocumentClass: BOOK
SAPDB_AnsyncIndexing: F

<mediadescription>
   <header mediatype="BOOK">
      <subtype>PAPERBACK</subtype>
      <isbn>3-446-12345-8</isbn>
      <pages>244</pages>
   </header>
   <data>
      <authors>
         <author>
            <name>Shepard, Francis</name>
         </author>
      </authors>
      <title>XML Indexing. Basics.</title>
      <shortdesc>
         All you need to know about XML Indexing to
         get a good start.
      </shortdesc>
      <price>$49.90</price>
      <longdesc>...</longdesc>
   </data>
</mediadescription>

See also Overview: XML Indexing and the WebDAV Service


Asynchronous Indexing (MaxDB: WebDAV GUI)

Asynchronous Indexing

The asynchronous indexing of documents is performed by the index engine. This means that XML documents do not need to be indexed as soon as they are saved to the document store. The documents are indexed independently of the PUT request.

This enables a reindexing of existing indexed documents, in which the XML indexes are updated. You can request the reindexing of documents from the WebDAV Explorer.

Asynchronous indexing also gives you scaling options. You can operate multiple index engines in parallel on multiple hosts.

See also Overview: XML Indexing and the WebDAV Service


XML Indexes (MaxDB: WebDAV GUI)

XML Indexes

XML indexes are always assigned to a specific document class. The definition of an XML index specifies how XML documents in this document class are indexed. The required index values are determined using the XPATH location path.

· Creating/Changing an XML Index Definition

· Deleting an XML Index Definition


XPATH Location Path (MaxDB: WebDAV GUI)

XPATH Location Path

XPATH is a Web standard for navigating in XML documents. XPATH location paths are used to extract information from the structure of an XML document, such as the author or the page number. This information is then used for XML indexing.

An XPATH location path comprises a base path and a value path.

· The base path describes a node set in the XML document.

· The value path describes the values that you want to determine from this node set.

The XPATH location path /mediadescription/header/@mediatype determines the value of the attribute mediatype of the XML tag <h eader> as an index value.

The XPATH location path //author/name/text() determines the name of the author from the XML document.

The XML indexing function of the MaxDB WebDAV Service currently supports a subset of the accepted XPATH standard.


Document Classes (MaxDB: WebDAV GUI)

Document Classes

An XML document can belong to precisely one document class. The document class is used to index different types of XML documents, such as books or articles, by different criteria. To enable this, definitions of your chosen XML indexes are assigned to the document class. The indexing service uses these definitions to determine the index values in all documents in this document class.

· Creating/Changing/Deleting a Document Class

· WebDAV Explorer: Displaying/Changing the Properties of Folders or Files


Indexing Service (MaxDB: WebDAV GUI)

Indexing Service

An index engine is an indexing service if it is configured with the following information: the document classes that you want to process, definitions of the XML indexes, and the document store that you want to use.

The information about the configuration (the definition of the indexing service) can be used by multiple index engines at the same time.

See also: Defining/Changing an Indexing Service


Index Engine (MaxDB: WebDAV GUI)

Index Engine

An index engine is a program that uses the definition of the indexing service to index the XML documents stored in the document store.

The index engine can be installed on a separate host. To improve scaling, you can also operate multiple index engines, each on a separate host.

You can use the index engine monitoring functions to monitor all registered index engines.


Document Store (MaxDB: WebDAV GUI)

Document Store

A MaxDB database instance is used as a document store (WebDAV store) for the XML documents that you index with the WebDAV GUI.

You specified this database instance when you set up the WebDAV Service.

To enable it to connect with the database instance, the indexing service requires information such as the name of the database instance, its host, and a valid user name and password.

· Specifying or Changing the Document Store

· Deleting the Information on a Document Store


How the WebDAV GUI Works (MaxDB: WebDAV GUI)

How the WebDAV GUI Works

Calling the WebDAV GUI

To call the WebDAV GUI, enter the following URL:
http://<web_server>:<port>/webdav?gui

See also: Variables Used in the Web Tools Installation Guide

The initial screen of the WebDAV GUI appears.

Using the WebDAV GUI

You can choose from the following functions:

· Choose WebDAV Explorer if you want to navigate through the Document Store.

· Choose Document Retrieval if you want to search for indexed XML documents.

· Choose Index Engine Monitoring if you want to monitor the Index Engine.

· Choose Indexing Service Settings if you want to set up an indexing service. This involves creating, changing, or deleting metadata for XML indexing.


WebDAV Explorer (MaxDB: WebDAV GUI)

WebDAV Explorer

You can use the WebDAV Explorer to navigate through the document store. You can view the properties and content of the files and folders, change the document class of files, update their indexes, and delete files and folders.

· Navigating Through the Document Store

· Displaying Properties of Folders or Files

· Changing the Document Class of a File

· Updating the Indexing of a File

· Deleting Folders or Files

· Using the Deleted Items Folder with WebDAV HTTP


Navigating Through the Document Store (MaxDB: WebDAV GUI)

Navigating Through the Document Store

Use

You can use the WebDAV Explorer to navigate through the document store.

Procedure

· To display the content of a folder or file, click its name.

· To display the next highest level of the document store, click [image].

· To refresh the display, click [image].


Displaying Properties of Folders or Files (MaxDB: WebDAV GUI)

Displaying Properties of Folders or Files

Use

The WebDAV Explorer shows you when the folders and files in your document store were last changed. It also shows you the size of the stored files, as well as additional information on the files, folders, their locks, and XML indexing.

Procedure

· For information on the WebDAV properties and lock properties of a folder or file, click [image] (Show Properties).

The following information is displayed for each folder:

Contained Files | Number of files in this directory tree
Contained Folders | Number of directories in this directory tree
Size | Total size of all files in this directory tree

The following information is displayed for each file:

Content Type | Format of the file content
Size | File size
Last Modified | Date on which the file was last modified

The following information is displayed for file and folder locks:

Lock Type | Lock type
Scope | Scope of the lock (EXCLUSIVE or SHARED)
Owner | Owner of the lock
Depth | Depth of the lock
Timeout | Time for which the lock is valid
Lock Token | Lock ID

· For information on the XML indexing of a file, click [image] (Show XML Indexing Properties). You see the document class and current indexing status. You can assign a different document class, or update the indexing.


Changing the Document Class of a File (MaxDB: WebDAV GUI)

Changing the Document Class of a File

To assign a new or changed document class to a file, use the WebDAV Explorer to display the information on the XML indexing of this file. Choose a document class, and then Update.

If you change the document class of a file, or remove all assignments to a document class (No Document Class Assigned), then the existing index values for this file are deleted, and the indexing status changed accordingly. If you have assigned a different document class to the file, then the file is indexed again automatically, if the corresponding index engine is running.


Updating the Indexing of a File (MaxDB: WebDAV GUI)

Updating the Indexing of a File

To update the XML indexing of a file, use the WebDAV Explorer to display the information on the XML indexing. Choose Trigger Reindexing, and then Update.


Deleting Folders or Files (MaxDB: WebDAV GUI)

Deleting Folders or Files

Use

In the WebDAV Explorer, you can delete folders and files, restore deleted folders and files, or remove them from the document store permanently.

Procedure

· To delete a folder or file, click [image] (Delete). The folder or file is moved to the folder [image] (Deleted Items).

If the Deleted Items folder already contains a folder or file with the same name as an item you have just deleted, then the existing item in the Deleted Items folder is overwritten. This removes the item from the document store permanently.

· To restore a deleted folder or file, proceed as follows:

a. Open the Deleted Items folder and click [image] (Restore) for the folder or file that you want to restore.

b. Under Restore to, enter a directory for the folder or file.

c. If you want to overwrite an existing folder or file with the same name in this target directory, then choose Overwrite.

An overwritten folder or file is removed from the document store permanently.

d. Confirm the action by choosing Restore.

· To remove a deleted folder or file from the document store permanently, open the Deleted Items folder and click [image] (Discard) for the folder or file that you want to discard.

· To empty the Deleted Items folder (and remove its entire contents from the document store permanently), click [image] (Empty Deleted Items Folder).

You can also use the Deleted Items folder with WebDAV HTTP.


Using the Deleted Items Folder with WebDAV HTTP (MaxDB: WebDAV GUI)

Using the Deleted Items Folder with WebDAV HTTP

Use

As well as accessing the Deleted Items folder when you delete folders or files in the WebDAV Explorer, you can also access it with WebDAV requests.

Procedure

· When you use the DELETE request, also use the HTTP header
 SAPDB_DeletedItems: {F|T}.

¡ If you specify F (False) or if you do not specify the header, then the DELETE request performs the standard action, that is, the folder or file is removed from the document store permanently.

¡ If you specify T (True), then the folder or file is moved from the document store to the Deleted Items folder.

DELETE /folder/ HTTP/1.1
Host: <web_server>
SAPDB_DeletedItems: T

· You can access the content of the Deleted Items folder with the following WebDAV requests:

¡ GET

¡ PROPFIND

¡ DELETE

¡ COPY

The WebDAV request
 DELETE /Deleted Items HTTP/1.1
removes the entire contents of the Deleted Items folder from the document store permanently.


Document Retrieval (MaxDB: WebDAV GUI)

Document Retrieval

Use

You can use the Document Retrieval function to search for indexed XML documents quickly and simply. You can search for documents in a specific document class, or search for specific index values. You can make any type of query, no matter how complex.

Procedure

...

Enter your conditions, and choose Search.

· To find all documents in a specific document class, choose this document class.

· To find all documents with a specific index value, choose the name of the XML index, a comparison operator, and the index value.

· Use OR and/or AND operators to link multiple search conditions together.

¡ When you use OR, you can specify only one alternative comparison value for the same XML index.

¡ When you use AND, you can specify one more comparison value for the same XML index or another XML index.

· To delete your entries, choose Clear.

Result

You get a list of all documents that meet your search conditions.You can open a document directly by clicking its name.


Index Engine Monitoring (MaxDB: WebDAV GUI)

Index Engine Monitoring

Use

The Index Engine Monitoring function gives you a quick overview of the registered index engines. It tells you on which host the index engines are registered, as which indexing services they are working, and which document stores they are using.

You can display this information as an overview, or in more detail for each index engine.

Overview Display

To display the overview, choose Overview in the navigation area of the Index Engine Monitoring function. An overview of all the index engines appears, sorted by the hosts on which they are registered. The following information is displayed:

· The name and a short description of each index engine

· The corresponding indexing service

· The document store used

· The time of the last communication with the index engine. This indicates whether the index engine is working correctly. A communication should be received about once every 10 minutes.

To refresh the display, choose Refresh.

Single Display

To display the details of a single index engine, choose its name in the navigation area of the Index Engine Monitoring function. The following information is displayed:

· The host on which this index engine is registered

· The name and a short description of the index engine

· The installation directory (Installation Root) of the index engine

· The directory path and name of the corresponding log file

· The corresponding indexing service

· The document store used

· The indexing library used

· The time of the last communication with the index engine. This indicates whether the index engine is working correctly. A communication should be received about once every 10 minutes.

To refresh the display, choose Refresh.


Indexing Service Settings (MaxDB: WebDAV GUI)

Indexing Service Settings

Use

You manage the indexing services under Indexing Service Settings. You can specify all information needed for indexing documents, as well as changing or deleting information for existing indexing services.

Procedure

...

1. Choose the indexing service that you want to display or edit.

¡ If you want to adapt an existing indexing service, then choose the name of this service from the list.

§ If you want to adapt the indexing service for synchronous indexing, then choose Synchronous Indexing.

§ If you want to configure the predefined indexing service for asynchronous indexing, then choose Asynchronous Indexing.

¡ If you want to create a new indexing service for asynchronous indexing, then choose New.

2. You can now define or change the indexing service.

Any changes that you make to document store information, document classes, and XML indexes have an effect on all indexing services that use the information you change.

3. If you want to delete an existing indexing service, then choose the name of this service from the list. Information on this service is displayed. Click Delete.


Defining/Changing an Indexing Service (MaxDB: WebDAV GUI)

Defining/Changing an Indexing Service

Prerequisite

You have opened the dialog for defining or changing an indexing service. You do this by choosing either New or the name of an existing service under Indexing Service Settings.

Procedure

To define or change an indexing service, proceed as follows:

...

1. If the indexing service does not yet have a name, specify a name under Service Name. This name must be unique.

2. You can specify a short description of the indexing service under Description, however, this is not mandatory.

3. The list under Assigned Document Classes shows you which document classes are assigned to the indexing service. These are the classes of XML documents that the service will process and index. You can create new document classes, change them, or delete them.

All available document classes are always assigned to each indexing service. It is not possible for individual document classes to be processed by certain indexing services only.

Note that, therefore, all changes to a document class affect all indexing services.

4. Choose the document store under Document Store. You can specify a new document store, or change a document store.

If you remove the assignment between a document store and an indexing service, then you also delete all information about this document store, if it is not assigned to another indexing service (see also Deleting the Information About a Document Store).

5. Confirm your entries.

¡ If you define a new indexing service, choose Create.

¡ If you change an existing indexing service, choose Update.

6. Restart the indexing engines.


Creating/Changing/Deleting a Document Class (MaxDB: WebDAV GUI)

Creating/Changing/Deleting a Document Class

Prerequisite

You are in the dialog for defining or changing an indexing service to which the document class is assigned.

Any changes that you make to a document class affect all indexing services.

Creating or Changing a Document Class

Öf..

1. Open the dialog for creating or changing a document class as follows:

¡ To change a document class, select a name from the list of assigned document classes, and click Change.

¡ To create a new document class, choose New.

2. If the document class does not yet have a name, choose a name and enter it under Document Class Name. This name must be unique.

3. You can specify a short description of the document class under Description, however, this is not mandatory.

4. The list under Assigned XML Indexes shows you which XML indexes are assigned to the document class, in other words, the index values that the indexing service searches for in documents in this document class. You can assign more indexes, remove existing assignments, create new XML index definitions, or change existing definitions.

¡ To assign a defined XML index to the document class, choose the arrow ▼, and choose a name from the list of XML indexes.

¡ To remove the assignment between an XML index and the document class, select this XML index in the list, and click Remove.

¡ To remove the assignment for all XML indexes, click Remove All.

You can assign up to 100 XML indexes to a document class.

When you remove the assignment of an XML index to a document class, you also delete all information about this XML index, if it is not assigned to another document class (see also Deleting an XML Index Definition).

5. Confirm your entries.

¡ If you are creating a new document class, choose Create.

¡ If you are changing an existing document class, choose Update.

6. Restart the indexing engines.

Deleting a Document Class

To delete a document class, select a name from the list of assigned document classes, and click Delete.

To assign a document class to a document, or to change the assignment, use the WebDAV Explorer.


Creating/Changing an XML Definition (MaxDB: WebDAV GUI)

Creating/Changing an XML Index Definition

Prerequisite

You are in the dialog for creating or changing a document class.

Procedure

...

1. Open the dialog for creating or changing the definition of an XML index:

¡ To change an existing XML index definition, click its name in the list of assigned XML indexes.

¡ To create a new XML index definition, choose New.

2. If the XML index does not yet have a name, then specify a name under XML Index Name. This name must be unique.

3. You can specify a short description of the XML index under Description, however, this is not mandatory.

4. Specify the XPATH by entering your chosen values for the Base Path and the Value Path.

5. Confirm your entries.

¡ If you are defining a new XML index, choose Create.

¡ If you are changing an existing XML index definition, choose Update.

6. Restart the indexing engines.


Deleting an XML Index Definition (MaxDB: WebDAV GUI)

Deleting an XML Index Definition

You cannot delete definitions of XML indexes explicitly. Instead, an implicit deletion mechanism is used.

An XML index definition is deleted automatically under the following circumstances:

· You defined the XML index when you created or changed a document class, however, you decided not to assign the definition to this document class.

· You defined the XML index while you were creating or changing a document class, however, you terminated the create or change function for this class.

· You removed the assignment of the XML index to a document class when you changed this class, and the XML index is not assigned to any other document class.

· The document class that is assigned to this XML index has been deleted, and the XML index is not assigned to any other document class.


Specifying or Changing the Document Store (MaxDB: WebDAV GUI)

Specifying or Changing the Document Store

Prerequisite

You are in the dialog for defining or changing an indexing service that is assigned to this document store, or that you want to assign to this document store.

Procedure

...

1. Open the dialog for specifying or changing the document store as follows:

¡ To change the information on an existing document store, choose its name under Document Store, and click Change.

¡ To enter information for a new document store, choose New.

2. If the document store does not yet have a name, choose a name and enter it under Document Store Name. This name must be unique.

3. You can specify a short description of the document store under Description, however, this is not mandatory.

4. Specify the following parameters for the connection to the document store:

Database Server | Name of the server on which the relevant database instance is installed
Database Name | Name of the database instance
Database User | Name of the database user who is the owner of the WebDAV tables. This is usually the database administrator (DBA user).
Password | Password of the user

5. If you want an ODBC trace, then specify a file name under Trace File, including the absolute path under which you want to generate the trace file. The ODBC trace is written from the time at which you connect to the database.

To deactivate the ODBC trace, delete the file name under Trace File, and restart all indexing engines that use this document store.

6. Confirm your entries.

¡ If you want to specify a new document store, choose Create.

¡ If you are changing the information on an existing document store, choose Update.

7. Restart the indexing engines.


Deleting the Information on a Document Store (MaxDB: WebDAV GUI)

Deleting the Information About a Document Store

You cannot delete the information about a document store explicitly. Instead, an implicit deletion mechanism is used.

Information about a document store is deleted automatically in the following circumstances:

· You entered the information when you defined or changed an indexing service, however, you decided not to assign the information to the service.

· You entered the information while you were creating or changing an indexing service, however, you terminated the create or change function for this service.

· You removed the assignment of the document store to an indexing service when you changed the indexing service, and the document store is not assigned to any other indexing service.


Supported Subset of the XPATH Standard (MaxDB: WebDAV GUI)

Supported Subset of the XPATH Standard

The MaxDB WebDAV XML indexing functions support a subset of the XPATH standard, as defined in the W3C document www.w3.org/TR/xpath.

The supported syntax includes the following access types:

Access Type

Meaning

Example

Child axis+ node test text()

The child axis indicates a node set in the XML document.

child::text() determines the text nodes of the nodes in this node set.

/child::a/child::b/child::text()

or (for short)

/a/b/text()

Child axis + attribute axis

The child axis indicates a node set in the XML document.

The attribute axis determines all values of attr attributes of the nodes in this node set.

/child::a/child::b/attribute::attr

or (for short)

/a/b/@attr

Name test ‘*’

Determines the text nodes of all child nodes of nodes in a node set

/child::a/child::*/child::text()

or (for short)

/a/*/text()

Predicate filter

Determines the text nodes of all nodes of a node set that have an attribute attr with the specified value.

Only the attribute axis and the comparison operators = and != are allowed within predicate filters. The attribute value must be a character string literal.

Only one attribute is allowed.

/a/b[attribute::attr=‘aaa’]/text()

Descendant axis+ node test text()

The descendant axis indicates all node sets whose path contains a specific node.

child::text() determines the text nodes of the nodes in this node set.

/descendant::a/child::text()

or (for short)

//a/text()

Descendant axis + attribute axis

The descendant axis indicates all node sets whose path contains a specific node.

The attribute axis determines all values of attr attributes of the nodes in this node set.

/descendant::a/attribute::*

or (for short)

//a/@*


Terms (MaxDB: WebDAV GUI)

Terms

· XML Indexes

· Synchronous Indexing

· Asynchronous Indexing

· XPATH Location Path

· Document Classes

· Indexing Service

· Index Engine

· Document Store


Interfaces

Title of the Documentation | Contents
C/C++ Precompiler Manual | Options for the C/C++ Precompiler, Embedded SQL
ODBC Manual | Basics and special features of the MaxDB ODBC driver
JDBC Manual | Basics and special features of the MaxDB JDBC driver
Perl Manual | Description of the programming interfaces SQL, Database Manager and Loader for programming database applications with the Perl script language
Python Manual | Description of the programming interfaces SQL, Database Manager and Loader for programming database applications with the Python script language
Backint for MaxDB | Description of the Backint for MaxDB interface for external backup tools


C/C++ Precompiler Manual

The interface between the MaxDB database system and its application programs is the database language SQL (Structured Query Language). SQL statements embedded in the application program (Embedded SQL) are used for communication with the database instance. Parameter values are exchanged in special program variables, called host variables.

The C/C++ Precompiler prepares C/C++ source code with embedded SQL statements for translation into an executable application program. The compiler checks the syntax and semantics of the embedded statements, converts them to procedure calls in the precompiler runtime environment, and generates a C/C++ file, which can then be compiled.

This user manual describes how to embed SQL statements for the MaxDB database system in the programming language C/C++, and how to work with the precompiler.

This manual requires a sound working knowledge of the meaning of elementary SQL statements. For a description of the syntax and semantics of database statements, and the conventions for syntax notation, see the Reference Manual.

For general information about the MaxDB database system, see the Database Administration documentation.


Embedding SQL Statements in C/C++ (MaxDB: C/C++ Precompiler Manual)

Embedding SQL Statements in C/C++

When you embed database statements in the source code of an application program, observe the following points as well as the general rules:

· Conventions for the Order of Embedded SQL Statements

· Rules for the Declaration Segment

· Conventions for Host Variables

· Using Indicator Variables

· Permitted Data Types

· Connecting to a Database Instance

· Overview of Precompiler Statements

· Database System Messages

· Programming Notes


General Rules (MaxDB: C/C++ Precompiler Manual)

General Rules

Observe the following general rules when you embed SQL statements.

· Precede each embedded SQL statement with the key words EXEC SQL to delimit it from the programming language statements. These key words must be on the same line, and can only be split with a blank character.

· Finish each embedded SQL statement with a semicolon.

· You can write embedded SQL statements that run over multiple lines.

· You can interrupt embedded SQL statements with comments. Place the comments between the characters /* and */.

· You can place comments about SQL statements at the end of the line. Precede comments at the end of a line with two dashes, --.

· Precede the names of host variables and indicator variables within embedded SQL statements with a colon :

· No other names used in an application program are allowed to start with a colon :

· Names used in an application program must not start with the characters sq. This combination of characters is also reserved by the precompiler.

· The program parts analyzed by the precompiler must not be elements of the preprocessor include statements (#define, #include).

See also: Overview of Precompiler Statements

EXEC SQL BEGIN DECLARE SECTION;
char addr [6];
char fname [8], lname [8];
EXEC SQL END DECLARE SECTION;

/* Generate table „customer“ */

EXEC SQL CREATE TABLE customer
(cno FIXED (4) KEY, address CHAR (5),
firstname CHAR (7), lastname CHAR (7));

/* Get values */

/* Add values to database */

EXEC SQL INSERT INTO customer
(cno, address, first name, last name)
VALUES (100, :addr, :fname, :lname);

/* Message in event of error */

if (sqlca.sqlcode != 0)
printf ("%d       ",sqlca.sqlcode);


Conventions for the Order of SQL Statements (MaxDB: C/C++ Precompiler Manual)

Conventions for the Order of SQL Statements

When the precompiler runs with the precompiler option check, it runs once, sequentially, through the source code of the application program, and sends any static SQL statements that it finds to the database kernel . So that the check can run correctly, the embedded SQL statements must appear in an executable order in the source code.

Observe the following conventions when you embed SQL statements.

· CREATE TABLE comes before INSERT, UPDATE, DELETE, and SELECT.

· INSERT, UPDATE, DELETE, and SELECT come before DROP TABLE.

· SELECTcomes before FETCH. It must be possible to make a unique assignment between the SELECT statement and the FETCH statement.

· DECLARE CURSOR comes before OPEN.

· OPENcomes before FETCH.

· FETCHcomes before CLOSE.

The process flow of the program solely is responsible for the order in which the SQL statements are actually executed at runtime of the program.

The precompiler does not send dynamic SQL statements to the database, since their content is unknown before runtime.


Rules for the Declare Section (MaxDB: C/C++ Precompiler Manual)

Rules for the Declare Section

In the declare section, you declare all host variables and indicator variables that are exchanged between the database instance and the application program in embedded SQL statements. You can use multiple declaration sections within an application program.

Observe the following rules:

· Start the declare section with EXEC SQL BEGIN DECLARE SECTION;.

· End the declare section with EXEC SQL BEGIN DECLARE SECTION;.

· Follow the permitted syntax for the declaration section.

· Observe the conventions for host variables and the rules for indicator variables.

· Use the data types permitted for the precompiler.

· You can use the memory classes typedef, static, extern or auto.

· You can specify declarations both outside of and within functions.

· As well as variable declarations, you can specify type definitions and parameter-free constant definitions (#define) for positive whole numbers in the declare section.

#define n(a) (a+10) is not permitted.
#define n 7 is permitted.
You can, for example, use n as the length of an array variable:
int array [n]

· Also specify array lengths for the memory class extern. These lengths must lie within the range of the corresponding external definitions.

To improve efficiency, only declare those variables in EXEC SQL declare sections that you are actually using as host variables in embedded SQL statements.

EXEC SQL BEGIN DECLARE SECTION;

char no [6];

char fname [8], lname [8];

EXEC SQL END DECLARE SECTION;


Syntax of the Declaration Section (MaxDB: C/C++ Precompiler Manual)

Syntax of the Declare Section

This syntax list shows you the syntax of the declaration section. The syntax notation used is BNF.

<arrdim> ::=
  <identifier>
| <unsigned_integer>

<chardecspec> ::=
  <storclspec>
| <chartype>
| <chardecspec> [<storclspec>]
| <chardecspec> <typespec>

<chartype> ::=
  char
| VARCHAR
| varchar

<constant> ::=
  <identifier>
| <unsigned_integer>

<decimaldef> ::=
  DECIMAL [<decimaltag>] [(<decimalscale>)]

<decimaldigits> ::=
  <identifier>
| <unsigned_integer>

<decimalfract> ::=
  <identifier>
| <unsigned_integer>

<decimalref> ::=
  DECIMAL <identifier>

<decimalscale> ::=
  decimaldigits
| decimaldigits,decimalfract

<decimaltag> ::=
  <identifier>

<decimaltype> ::=
  <decimaldef>
| <decimalref>

<declaration> ::=
  <decspec> <declist>;

<declarator> ::=
  <identifier>
| * <identifier>
| <declarator> [ <arrdim> ]

<declist> ::=
  <possinitdec>
| <declist>,<possinitdec>

<decspec> ::=
  <typespec>
| <chardecspec>
| <intdecspec>
| <filedecspec>
| <floatdecspec>
| decimaltype
| <decspec> [<storclspec>]
| <decspec> <typespec>
| <longdescdecspec>

<expression> ::=
  <basexpr>
| <basexpr> (<expression>) <basexpr>

<fieldlist> ::=
  <typespec> <declist>;
| <fieldlist> <typespec> <declist>;

<filedecspec> ::=
  <storclspec>
| <filetype>
| <chardecspec> [<storclspec>]
| <filedecspec> <typespec>

<filetype> ::=
  SQLFILE
| sqlfile

<floatdecspec> ::=
  <storclspec>
| <floattype>
| <chardecspec> [<storclspec>]
| <floatdecspec> <typespec>

<floattype> ::=
  float
| long
| double

<initializer> ::=
  <expression>
| {<initlist>}

<initlist> ::=
  <initializer>
| <initlist>,<initializer>

<intdecspec> ::=
  <storclspec>
| <inttype>
| <chardecspec> [<storclspec>]
| <intdecspec> <typespec>

<inttype> ::=
  short
| long
| int
| unsigned

<longdescdecspec> ::=
  <storclspec>
| <longdesctype>
| <longdescdecspec> [<storclspec>]
| <longdescdecspec> <typespec>

<longdesctype> ::=
  SQLLongDesc
| sqllongdesc

<possinitdec> ::=
  <declarator>
| <declarator> = <initializer>

<prepcomline> ::=
  #define <identifier_constant>

<statement> ::=
  <prepcomline>
| <declaration>

<storclspec> ::=
  external
| static
| auto
| typedef

<structdef> ::=
  struct [<structag>] {<fieldlist>}

<structref> ::=
  struct <identifier>

<structag> ::=
  <identifier>

<structype> ::=
  <structdef>
| <structref>

<typespec> ::=
  <inttype>
| <floatptye>
| <chartype>
| <floattype>
| <decimaltype>
| <longdesctype>
| <structype>
| <identifier>
| const
| volatile

<unichardecspec> ::=
  <storclspec>
| <unichartype>
| <unichardecspec> [<storclspec>]
| <unichardecspec> <typespec>

<unichartype> ::=
  SQLUCS2
| SQLUTF16
| TCHAR (only available for use with Unicode applications)


Host Variables (MaxDB: C/C++ Precompiler Manual)

Host Variables

Host variables are variables that are used in embedded SQL statements to exchange values between the application program and the database instance .

Observe the following points when you use host variables:

· Declare the host variables in the declare section. When you do this you can use data types predefined by the precompiler, as well as C/C++ basic data types.

See also: Permitted Data Types

· Observe the conventions for host variables. You can also use structures and arrays in host variables. You can generate structure definitions from database tables and database procedures.


Conventions for Host Variables (MaxDB: C/C++ Precompiler Manual)

Conventions for Host Variables

Observe the following conventions for host variables.

· The name of a host variable can have a maximum of 32 characters.

· The name of a host variable cannot start with the characters sq.

· A host variable can be a structure or an array . A structure can contain arrays, and arrays of structures are also possible.

· A host variable can be a pointer variable of permitted data types. Pointer to Pointer and Pointer to Array are not permitted.

· In each declaration, you can specify a maximum of one pointer and arrays with up to four dimensions. Arrays of pointer variables are permitted, but not Pointer to Array.

· The precompiler cannot check the lengths of host variables with the data type char *, and writes a warning to the precompiler log. At runtime, the character pointer must point to a NULL-delimited character string.

· So that they can include the closing NULL bytes, host variables with the data type char [n] must be declared with one more field than the corresponding column in the database table.
When char variables are send to a database table, the variable content is copied up to the closing NULL byte. Longer table columns are filled up with blank characters.
When char variables are read from a database table, all following blank characters in the table content are truncated, and the closing NULL byte is set in the variable after the last character that is not a blank character. If the host variable is shorter than the table column, then the last character is overwritten.


Structures as Host Variables (MaxDB: C/C++ Precompiler Manual)

Structures as Host Variables

Host variables can be structures. When the precompiler runs, it splits the structure into its individual components, in the order of the component declarations.

When you use structures as host variables, you can, for example, specify multiple values in the INTO clause of a SELECT statement at the same time.

EXEC SQL BEGIN DECLARE SECTION;

typedef char string8 [8];

  struct {
char addr [6];
struct {
string8

lname, fname [3];
} name;
} person;

EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT !person INTO :person
         FROM customer WHERE cno = 100;

You can use a simplified notation for structures in SQL statements.

You can also specify the corresponding indicator variable as a structure with the same number of components.

You can generate the structure definition from a database table or a database procedure.


Arrays as Host Variables (MaxDB: C/C++ Precompiler Manual)

Arrays as Host Variables

Host variables can be arrays. In an array statement they cause an SQL statement to be executed more than once.

In multi-dimensional arrays, the last dimension is run first.

EXEC SQL BEGIN DECLARE SECTION;

float p[3][2];

EXEC SQL END DECLARE SECTION;

EXEC SQL CREATE TABLE KOORD (x float, y float);

p[0][0] = 0.0;

p[0][1] = 0.1;

p[1][0] = 1.0;

p[1][1] = 1.1;

p[2][0] = 2.0;

p[2][1] = 2.1;

EXEC SQL INSERT INTO KOORD VALUES (:p);

/* insert generates following content */

/*      x  |  y

*/
/*

---------

*/
/*     0.0 |

0.1

*/
/*     1.0 |

1.1

*/
/*     2.0 |

2.2

       */

Also specify the corresponding indicator variable as an array, with the same length and dimension.

You can use a simplified notation for array variables in SQL statements.


Simplified Notation for Structure and Array Variables (MaxDB: C/C++ Precompiler Manual)

Simplified Notation for Structure and Array Variables

Use

In SQL statements, you can use a simplified notation for structure variables and array variables, so avoiding the need to list the columns of the database table that are addressed explicitly.

Procedure

· Specify the name of a structure variable or array variable as !<var>, for example, in the <select_list> of the SELECT statement.

· You can use the tilde character (~<var>) instead of an exclamation mark.

· The precompiler derives the column names from the names of the structure components or array elements. The column names can have a maximum of 18 characters.

· You can specify <[owner.]tablename.> before !<var>. This information is then inserted in front of each column name.

· Instead of the complete variable !<var>, you can specify a structured component of var of your choice, for example, !var.x.y. In this case, the appropriate subset of column names is generated.

EXEC SQL BEGIN DECLARE SECTION;

  typedef char string8 [8];
  struct {char addr [6];
  struct {string8 lname, fname [3];} name;} person;

EXEC SQL END DECLARE SECTION;

EXEC SQL CREATE TABLE customer
(cno FIXED(4) key, addr

CHAR(5),
name_lname CHAR(7), name_fname1

CHAR(7),
name_fname2 CHAR(7), name_fname3

CHAR(7));

/* Get values */

EXEC SQL INSERT INTO customer
  (cno, !person )
  VALUES (100, :person);

/* Has same effect as: */

EXEC SQL INSERT INTO customer
  (cno, addr, name_lname,
  name_fname1, name_fname2, name_fname3)
  VALUES (100, :person.addr,
  :person.name.lname, :person.name.fname[0],
  :person.name.fname[1],
  :person.name.fname[2]);


Indicator Variables (MaxDB: C/C++ Precompiler Manual)

Indicator Variables

If you want your application program to process NULL values or DEFAULT values, or if values might be truncated when they are exchanged between host variables and the database, then you must specify an indicator variable as well as the host variable in the embedded SQL statement.

Observe the rules for indicator variables.

The value of an indicator variable is called an indicator value, and performs the following tasks:

· It provides information on whether the corresponding host variables have been processed correctly. For this reason, query the indicator value after the SQL statement has been processed.

· It is used to transfer NULL values to the database instance.

· It is used to transfer DEFAULT values to the database instance.

· It is used in GETVAL statements and PUTVAL statements to ignore individual LONG columns.

If a SELECT statement or a FETCH statement specifies that values are transferred from columns in which NULL values can appear, then you must specify an indicator variable. Otherwise the C/C++ precompiler writes a warning when the precompiler runs with the precompiler option check, and you see an error message when you select a NULL value at runtime ( sqlcode = -809).

In dynamic SQL statements with a descriptor, the hostindicator component of an sqlvar entry performs the same task as an indicator variable.


Rules for Indicator Variables (MaxDB: C/C++ Precompiler Manual)

Rules for Indicator Variables

Note the following points when you use indicator variables:

...

· Declare each indicator variable as a data type long int, int or short int in the declaration segment.

· Specify the indicator variable behind the corresponding host variable in the embedded SQL statement, divided by a blank character.

· Observe the same conventions as for host variables.

EXEC SQL BEGIN DECLARE SECTION;

char fname [8], lname [8];

int fnameind, lnameind;

EXEC SQL END DECLARE SECTION;

/* Insert NULL value */

fnameind = -1;

strcpy (lname, "COMPANY X");

lnameind = 0;

EXEC SQL INSERT INTO customer (firstname,lastname)
VALUES (:fname :fnameind, :lname :lnameind);

/* Test for truncation */

EXEC SQL SELECT lastname
INTO :lname :lnameind
FROM customer
WHERE lname = "COMPANY X";

if (lnameind > 0)
printf ("%d      ", lnameind );


Indicator Values (MaxDB: C/C++ Precompiler Manual)

Indicator Values

The table shows the possible indicator values that can be taken by an indicator variable of the hostindicator component or an sqlvar entry in the descriptor.

Indicator Value | Meaning
0 | A value has been transferred between the database and the application program without errors. The value sent to the table column or host variable is a defined value.
-1 | The value of the host variables or of the corresponding table entry is the NULL value.
-2 | An error occurred (overflow, or division by zero). The value of the host variables or of the corresponding table entry is not defined.
> 0 | A truncated value has been sent to the host variable or to the corresponding table column. The indicator value specifies the actual length of the value.
SQL_DEFAULT_PARAM | Used to transfer DEFAULT values to the database instance.
SQL_IGNORE | Used to ignore LONG columns in GETVAL statements and PUTVAL statements

See also: Database System Messages (sent through the sqlca structure)


Permitted Data Types (MaxDB: C/C++ Precompiler Manual)

Permitted Data Types

You can use the following data types for host variables in the declaration section:

· All basic data types

· The data type struct

· The data types predefined by the precompiler ( VARCHAR, SQLFILE and SQLLongDesc), and UNICODE data types

· Any data types you have defined yourself previously in a declaration section


Basic Data Types (MaxDB: C/C++ Precompiler Manual)

Basic Data Types

In the declare section, you can use the C/C++ basic data types to declare host variables. A corresponding MaxDB data type exists for each basic data type.

The precompiler performs the following tasks:

· When the precompiler runs, it checks whether the memory of the host variables and the corresponding table column is large enough for the maximum possible value to be sent between the database instance and the application program. If this is not the case, the precompiler writes a warning in the precompiler log.

· If necessary, the precompiler converts the data types at runtime.

The following table shows the corresponding MaxDB data types for the basic data types:

Description

C/C++ Data Type

MaxDB Data Type

Alphanumeric character

char

CHAR (1)

Character string with closing NULL byte

char*
char [n+1], n £ 8000
char [n+1], n > 8000

CHAR (n)
VARCHAR (n)
LONG

Integer

[unsigned] int, short int, long int

SMALLINT, INTEGER (2 or 4 bytes), FIXED (5), FIXED (10)

Fixed point number

float, double

FIXED (n,m)

Floating point number

float
double

FLOAT (6)
FLOAT (15)

Date

char [9]

DATE

Time

char [9]

TIME

Timestamp with closing NULL byte

char [21]

TIMESTAMP

Boolean

All numeric data types (null or not null)

BOOLEAN

Byte

char [n], n  £  8000
char [n], n > 8000

[VAR]CHAR (n) BYTE
LONG BYTE

When you specify dates, times, and timestamps, stick to the correct date and time format.


Predefined Data Types (MaxDB: C/C++ Precompiler Manual)

Predefined Data Types

The C/C++ precompiler predefines the following permitted data types to make it easier to handle database tables. You can use them to declare host variables in the declaration section.

· VARCHAR

· SQLFILE

· UNICODE data types


VARCHAR (MaxDB: C/C++ Precompiler Manual)

VARCHAR

Use

You can use the predefined data type VARCHAR to declare host variables to which you want to assign character strings with variable lengths.

The C/C++ precompiler converts the VARCHAR declaration into a structure declaration with a two-byte length and an array or pointer. The current length of a VARCHAR variable is determined by the length field. NULL bytes do not contribute to the calculation of the length. In a VARCHAR declaration with pointer declarer, the application program is responsible for assigning memory at runtime.

VARCHAR v [n];

is replaced by

struct {unsigned short len; unsigned char arr [n];} v;

where the current length of the character string is assigned to len and the characters themselves are assigned to arr.

VARCHAR *v;

is replaced by

struct {unsigned short len; unsigned char arr [1];} *v;

See also: Examples for Permitted VARCHAR Declarations


Example for Permitted VARCHAR Declarations (MaxDB: C/C++ Precompiler Manual)

Examples for Permitted VARCHAR Declarations

Examples for permitted VARCHAR declarations:

VARCHAR a [21], b [100] [133];

typedef VARCHAR longstring [ 65534 ];
longstring c, d;

typedef VARCHAR *PVC;
PVC p;

You can assign memory for p:

n = 100; /* Maximum length of VARCHAR variables*/
p = (PVC) malloc (sizeof (p->len) + n * sizeof

(p->arr));

You can declare VARCHAR pointers with fixed maximum lengths as follows:

typedef VARCHAR VC30 [30];
VC30 *q;

q is a pointer to a VARCHAR with a maximum length of 30.

Memory is assigned to q with the following statement:

q = (VC30* ) malloc (sizeof (VC30));


SQLFILE (MaxDB: C/C++ Precompiler Manual)

SQLFILE

Use

You can enable the direct transfer of file content in and out of LONG columns by using the predefined data type SQLFILE to declare host variables.

Procedure

Assign the name of a file to the value of the host variable. Note the following:

· If this file already exists, then its content must be a character string (of any length). The SQL statements INSERT and UPDATE write the content of the file to the LONG column.

· If this file does not already exist, the SELECT statements of a LONG column generate it with the specified file name. The column content becomes the content of the file.

· If this file already exists when a SELECT statement is executed, then the content of the LONG column is appended to its existing content. If you want to avoid this, you must delete the existing file before the SELECT statement is executed, for example, with an EXEC COMMAND statement.

· Any errors in the processing of the file terminate the SQL statement and trigger a database error message sqlcode < 0.

EXEC SQL BEGIN DECLARE SECTION;

SQLFILE f1[30] = "document.doc";

char title[41] = "Manual";

SQLFILE f2[30];

EXEC SQL END DECLARE SECTION;

EXEC SQL CREATE TABLE documents(title CHAR (40) KEY,
document LONG BYTE);

EXEC SQL INSERT INTO documents VALUES (:title, :f1);

strcpy (f2, "tempdocument.doc");

EXEC SQL SELECT document INTO :f2 FROM documents
WHERE title = :title;


SQLLongDesc (MaxDB: C/C++ Precompiler Manual)

SQLLongDesc

You can make working with LONG columns easier by using the predefined data type SQLLongDesc to declare host variables. In a FETCH statement, for example, this gives you information on the total length of the LONG column.

The data type SQLLongDesc is declared as a structure in the header file cpc.h:

typedef struct sqllongdesc {
  char *szBuf;
  int cbColLen;
  int cbBufLen;
  int cbBufMax;
} sqllongdesc;

typedef sqllongdesc SQLLongDesc;

The components of this structure declaration have the following meaning:

  • szBuf: Pointer to a memory area that includes the LONG data
  • cbColLen: Total length of the corresponding LONG column in the table
  • cbBufLen: Length of the data currently saved in szBuf
  • cbBufMax: Size (in bytes) of the memory area to which szBuf points

When a FETCH or GETVAL statement is executed, the precompiler enters the length of the LONG column in the component cbColLen.

You must assign values to the other components before SQL statements. See also: Special Features when Using Data Type SQLLongDesc


Special Features when Using Data Type SQLLongDesc (MaxDB: C/C++ Precompiler Manual)

Special Features when Using Data Type SQLLongDesc

Note the following points when you use the data type SQLLongDesc:

· If you want to execute INSERT statements or PUTVAL statements with host variables of data type SQLLongDesc, you must first assign values to the structure components szBuf, cbBufMax and cbBufLen of this data type.

· If you want to execute FETCH statements or GETVAL statements with host variables of data type SQLLongDesc, you must first assign values to the structure components szBuf and cbBufMax of this data type.

SQLLongDesc ldesc;

#define LONGLEN 100000

#define FILLLEN 80000

/* Assign memory for including data */

ldesc.szBuf = (char *) malloc (LONGLEN);

/* Fill memory with values */

memset(ldesc.szBuf, ‘X’, FILLLEN);

/* Specify size of memory area */

ldesc.cbBufMax = LONGLEN;

/* Specify length of data in buffer */

Ldesc.cbBufLen = FILLLEN;

EXEC SQL INSERT INTO LONGTEST VALUES (:i1, :ldata :il1, :l2 :il2);


UNICODE Data Types (MaxDB: C/C++ Precompiler Manual)

UNICODE Data Types

The C/C++ precompiler provides predefined data types for working with UNICODE data.

The table gives you an overview of these UNICODE data types:

Description

C/C++ Data Type

MaxDB Data Type

Unicode character string with closing NULL byte

The basic C/C++ data type is unsigned short.

In UCS 2, the characters are coded in a platform-specific byte configuration.

SQLUCS2*
SQLUCS2 [n+2], n < 4000
SQLUSC2 [n+2], n ³ 4000

CHAR (n) UNICODE, VARCHAR (n) UNICODE
LONG UNICODE

Unicode character string with closing NULL byte

The basic C/C++ data type is unsigned short.

In UTF 16 without surrogate, the characters are coded in a platform-specific byte configuration.

SQLUTF16*
SQLUTF16 [n+2], n < 4000
SQLUTF16 [n+2], n ³ 4000

CHAR (n) UNICODE, VARCHAR (n) UNICODE
LONG UNICODE

Generic data type

CHAR or SQLUCS2 data type, depending on the precompiler option –G unicode.

TCHAR*
TCHAR [n+1], n < 4000
TCHAR [n+1], n ³ 4000

CHAR (n) UNICODE, VARCHAR (n) UNICODE
LONG UNICODE

See also: Converting Data Types


Converting Data Types (MaxDB: C/C++ Precompiler Manual)

Converting Data Types

If, in an embedded SQL statement, the C/C++ basic data type or the UNICODE data type of a parameter does not correspond to the MaxDB data type of the corresponding table column, but can be converted, then the precompiler runtime environment converts the data types at runtime of the application program.

The following tables show the possible conversions, and the errors that can occur:

C/C++ Basic Data Types

MaxDB Data Types

FIXED

FLOAT

BOOLEAN

LONG

CHAR

VARCHAR

DATE/TIME

short int, int,
long int

1,2

1b,2

6

Not permitted

4,5

Not permitted

Not permitted

float, double, long float

1a,2

2

6

Not permitted

4,5

Not permitted

Not permitted

char [n]

4,5

4,5

Not permitted

3

3

3

3

char

4,5

4,5

Not permitted

Not permitted

3

3

3

UNICODE Data Types

MaxDB Data Types

FIXED

FLOAT

BOOLEAN

LONG

CHAR

VARCHAR

DATE/TIME

SQLUCS2 [n],
SQLUTF16 [n],
TCHAR [n]

4,5,7

4,5,7

Not permitted

3,7

3,7

3,7

3,7

SQLUCS2,
SQLUTF16,
TCHAR

4,5,7

4,5,7

Not permitted

3,7

3,7

3,7

3,7

1 An overflow can occur ( sqlcode < 0).

1a An overflow can occur when a value is transferred to the database table.

1a An overflow can occur when a value is transferred to the host variable.

2 Some decimal places may be cut off (indicator value > 0).

3 Some characters may be cut off. The warning message sqlwarn1 is set. The indicator value specifies the actual length of the character string.

4 An overflow can occur when numerical values are converted into character strings ( sqlcode < 0).

5 An overflow or invalid number can occur when character strings are converted into numerical values ( sqlcode < 0).

6 The value 0 is mapped to false. All values other than 0 are mapped to true.

7 An error message is written when UNICODE values are converted that cannot be translated to 8 bit ASCII ( sqlcode < 0).

See also: Database System Messages


Generating Structure Definitions (MaxDB: C/C++ Precompiler Manual)

Generating Structure Definitions

Use

You can use the INCLUDE DECLARE statement to generate a file <file_name> from a database table or database procedure. This file derives a corresponding structure definition from the structure of the database table. You can use this structure definition to declare host variables and the corresponding indicator variables.

A table has been defined as follows:

CREATE TABLE example (
  A FIXED (5),
  B FIXED (8),
  C FIXED (5, 2),
  D FLOAT (5),
  E CHAR (80))

The application program can then contain the following statements:

EXEC SQL BEGIN DECLARE SECTION;

EXEC SQL INCLUDE "example.h" TABLE example AS STRUCT IND;

struct example s, sa[10], *sp;

struct iexample indi;

EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT * FROM example;

EXEC SQL FETCH INTO :s :indi;

EXEC SQL FETCH INTO :sa[4] :indi;

sp = &sa[9];

EXEC SQL FETCH INTO :sp :indi;

The include statement generates the following declarations:

struct example {short A;long B;float C,D;char E [81];};

and

struct iexample {short IA, IB, IC, ID, IE;};


Working with UNICODE Data (MaxDB: C/C++ Precompiler Manual)

Working with UNICODE Data

Use

The C/C++ Precompiler supports the use of UNICODE data in MaxDB application programs. The only permitted coding formats are UCS2 or UTF-16 (without surrogate), both with a platform-specific byte configuration. All output in the trace file is in UTF 8.

You can use UNICODE character strings in the following locations in host variables only:

  • As user name and password in the CONNECT statement
  • As a statement name in dynamic SQL statements
  • As a result table name in OPEN CURSOR statements
  • As an SQL statement
  • As parameters for SQL statements

You cannot use UNICODE application programs with ASCII database instances.

Prerequisite

You have installed a UNICODE-compliant database instance.

After a CONNECT statement, the precompiler can recognize automatically whether it is connected to a UNICODE-compliant database instance.

Procedure

· Use suitable host variables with the appropriate predefined UNICODE data types for your UNICODE character strings.

· If the user name or password contains UNICODE characters, then also use UNICODE host variables.

· If host variables contain complete SQL statements, then these statements are sent as ASCII or UNICODE character strings, depending on the type of the host variables. For performance reasons, only use UNICODE host variables for an SQL statement if the statement actually contains UNICODE characters.

· Run the precompiler with the precompiler option –G unicode.

EXEC SQL BEGIN DECLARE SECTION;

/* "SELECT TABLENAME FROM DOMAIN.TABLES " encoded in UCS2 */

SQLUCS2 sqlstmt[36] = {0x0053, 0x0045, 0x004C, 0x0045, 0x0043,

0x0054, 0x0020, 0x0054, 0x0041, 0x0042,

0x004C, 0x0045, 0x004E, 0x0041, 0x004D,

0x0045, 0x0020, 0x0046, 0x0052, 0x004F,

0x004D, 0x0020, 0x0044, 0x004F, 0x004D,

0x0041, 0x0049, 0x004E, 0x002E, 0x0054,

0x0041, 0x0042, 0x004C, 0x0045, 0x0053,

0x0000};

SQLUCS2 resultstring[64];

EXEC SQL END DECLARE SECTION;

/* connect ... */

/* parse a unicode sql command and give it a statement name */

EXEC SQL PREPARE stmt1 FROM :sqlstmt;

EXEC SQL DECLARE curs1 CURSOR FOR stmt1;

EXEC SQL OPEN curs1;

/* loop over resultset */

while (sqlca.sqlcode != 100)

{

EXEC SQL FETCH curs1 INTO :resultstring;

/* ... */

}

EXEC SQL CLOSE curs1;


Working with LONG Columns (MaxDB: C/C++ Precompiler Manual)

Working with LONG Columns

To make it easier to work with LONG columns, the C/C++ Precompiler offers the predefined data types SQLFILE and SQLLongDesc, as well as the GETVAL statement and the PUTVAL statement, for step-by-step processing of the columns.

However, you can also declare host variables for LONG columns as char arrays or VARCHAR data types.

EXEC SQL CREATE TABLE LONGTEST
(I1 INTEGER, L1 LONG BYTE, L2 LONG BYTE);

EXEC SQL BEGIN DECLARE SECTION;

VARCHAR l1[1000], l2[50];

int i1, il1, il2;

EXEC SQL END DECLARE SECTION;

EXEC SQL INSERT INTO LONGTEST VALUES
(:i1, :l1 :il1, :l2 :il2);

Example for using a descriptor:

sqlvartype *actvar;

EXEC SQL BEGIN DECLARE SECTION;

char *insert = "INSERT INTO LONGTEST VALUES (:I1, :L1, :L2)";

EXEC SQL END DECLARE SECTION;

EXEC SQL PREPARE ins from :insert;

EXEC SQL DECLARE :C1 CURSOR FOR ins;

EXEC SQL DESCRIBE ins;

/* ... */

actvar = &sqlda.sqlvar[1];

(*actvar).hostvartype = sqlvchar;

/* ... */

EXEC SQL OPEN :C1 USING DESCRIPTOR;


Transferring NULL Values to the Database Instance (MaxDB: C/C++ Precompiler Manual)

Transferring NULL Values to the Database Instance

Use

In the application program, you can use indicator values to transfer a NULL value to a database table, for example, in an INSERT or UPDATE statement.

Procedure

Before calling the embedded SQL statement, set the indicator value to -1. The database instance ignores the value of the corresponding host variable, and enters the NULL value in the table that is being addressed.

You can also use indicator values for transferring DEFAULT values to the database instance.


Transferring DEFAULT Values to the Database Instance (MaxDB: C/C++ Precompiler Manual)

Transferring DEFAULT Values to the Database Instance

Use

In the application program, you can use indicator values to transfer a DEFAULT value to a database table, for example, in an INSERT or UPDATE statement.

Procedure

Before calling the embedded SQL statement, set the indicator value to the predefined constant SQL_DEFAULT_PARAM. The database instance ignores the value of the corresponding host variable, and enters the DEFAULT value in the table that is being addressed.

This procedure is not permitted for LONG columns.

You can also use indicator values for transferring NULL values to the database instance.


Connecting to a Database Instance (MaxDB: C/C++ Precompiler Manual)

Connecting to a Database Instance

Before your application program can execute SQL statements, the program must connect to the database instance and open a database session.

Use the statements for connecting to the database instance. Note the following:

· The statements for connecting to the database instance must be the first SQL statements executed by the application program. However, they do not have to be the first SQL statements in the source code.

For the correct order of the SQL statements in the source code, see Conventions for the Order of SQL Statements.

· One application program can have multiple sessions with one or more database instances. The database instance handles each session as an independent transaction. In the SQL mode INTERNAL, there can be a maximum of eight parallel sessions with different MaxDB database instances.


Overview of Precompiler Statements (MaxDB: C/C++ Precompiler Manual)

Overview of Precompiler Statements

You have the following options when you embed SQL statements in the source code of an application program:

· Static SQL statements

· Dynamic SQL statements

· ARRAY statements

The embedded statements consist of statements to the precompiler, and the actual statement that is sent to the database.

The key words EXEC SQL form the simplest precompiler statement. The static SQL statement EXEC SQL <statement> specifies that the database kernel executes the database statement <statement>.

This table gives you an overview of the precompiler statements and how they are used:

CANCEL statement | Cancels a running SQL statement
CONNECT statement | Statement for connecting to the database instance
DECLARE statements | Indicate declare sections
DESCRIBE statement | Initializes a descriptor structure for a dynamic SQL statement
EXEC COMMAND statement | Executes an operating system command
EXECUTE statement | Executes a dynamic SQL statement
EXECUTE IMMEDIATE-statement | Calls a dynamic SQL statement without parameters
GETVAL statement | Reads LONG columns piecewise
INCLUDE DECLARE statement | Generates structure definitions
INCLUDE FILE statement | Inserts file content in the source text
OPEN CURSOR statement | Executes a dynamic SQL statement with named result table
PREPARE statement | Prepares a dynamic SQL statement
PUTVAL statement | Inserts values in LONG columns piecewise
SET SERVERDB statement | Statement for connecting to the database instance
TRACE statements | Activates logging in a trace file
USING clause | Assigns parameter values in a dynamic SQL statement
VERSION statement | Displays the software version
WHENEVER statements | Calls actions with conditions

See also: Syntax List, Working with Multiple Database Sessions, Compatibility with Other Database Systems

For the syntax of the database statements in the SQL mode INTERNAL, see the Reference Manual.


Working with Multiple Database Sessions (MaxDB: C/C++ Precompiler Manual)

Working with Multiple Database Sessions

When you work with multiple database connections in parallel, you must specify the relevant database session in your embedded SQL statements.To do this, specify the following in <session_spec>:

· In SQL mode INTERNAL, specify the session number <session_number>.

· In SQL mode ORACLE, specify the key word AT and the session name <session_name>.

See also: CONNECT Statement and Overview of Precompiler Statements


DECLARE Statements (MaxDB: C/C++ Precompiler Manual)

DECLARE Statements

Use

DECLARE statements mark the beginning and end of a declare section.

Syntax

EXEC SQL BEGIN DECLARE SECTION;

EXEC SQL END DECLARE SECTION;


INCLUDE DECLARE Statement (MaxDB: C/C++ Precompiler Manual)

INCLUDE DECLARE Statement

Use

You can use the INCLUDE DECLARE statement to generate structure definitions.

Prerequisites

· The precompiler must run with the precompiler option check, so that the application program gets the information it requires from the database instance.

· The file <filename> must not exist. If it exists, an INCLUDE FILE statement is executed instead of the INCLUDE DECLARE statement.

Syntax

EXEC SQL INCLUDE <file_name> <declare_clause>
[<as_clause>] [<ind_clause>];

<declare_clause> ::= <table_clause> | <dbproc_clause>

<table_clause>   ::= TABLE <table_name>

<dbproc_clause>  ::= DBPROC <dbproc_name>

<as_clause>      ::= AS VAR [<variable_declarator>]
|                    AS TYPE [<type_declarator>]
|                    AS STRUCT [<structure_tag>]

<ind_clause>     ::= IND [<ind_variable_declarator>] [<structure_tag>]

· AS VAR generates a variable declaration. AS TYPE generates a type declaration. AS STRUCT generates a structure declaration.

· If you do not specify an AS clause, the INCLUDE DECLARE generates a variable declaration by default.

· The default name of the structure definition is the name of the database table or procedure. However, you can also choose another name in the AS clause.

· The names of the structure components are derived from the column names of the table. The data types of the structure components are compatible with the data types of the corresponding table columns.

· You use the IND clause to generate another structure definition that you can specify as a type definition when you declare the indicator variables.

· If you do not specify a name in <structure_tag>, then, by default, the name of the structure definition for the indicator variable is generated from the table name and preceded by an I.

· The names of the structure components for the indicator variable are, by default, derived from the table name and the column names, preceded by an i.

· The data types of the structure components are short int.

· If the table contains columns with the data type long, then the precompiler generates, as a structure component, a character string with 32767 characters for each of these columns, and displays a warning on the screen. You can then redefine or modify these structure components in the source code.


Statements for Connecting to the Database Instance (MaxDB: C/C++ Precompiler Manual)

Statements for Connecting to the Database Instance

Use

Use these embedded SQL statements to connect to a database instance and open a database session.

Procedure

...

1. In the SQL mode INTERNAL, use the SET SERVERDB statement to specify the name of the database instance to which you want to connect, and the name of the server on which the database instance is running.

In the SQL mode ORACLE, enter the name and server of the database instance in the USING clause of the CONNECT statement.

2. Use the CONNECT statement to specify the user name and password and open the database session. At the same time, you can choose options for the database connection.


SET SERVERDB Statement (MaxDB: C/C++ Precompiler Manual)

SET SERVERDB Statement

Use

You use the SET SERVERDB statement to specify information on connecting to the database instance in the SQL mode INTERNAL. This includes defining which database instance on which server you want the application program to connect to.

Syntax

EXEC SQL [<session_number>] SET SERVERDB <database_name> [ON <database_server>];

· You can also specify the name of the database instance <database_name> and the server <database_server> on which it runs in a host variable with the data type char.

· Enter <session_number> as the session number if you want your application program to open multiple database sessions in parallel. In the SQL mode INTERNAL, there can be a maximum of eight parallel sessions with different MaxDB database instances.

You can override the information from the SET SERVERDB statement with the KEY in the CONNECT statement.

When the precompiler runs, you can also override the information from the SET SERVERDB statement for all database sessions with the precompiler options –d and -n.


CONNECT Statement (MaxDB: C/C++ Precompiler Manual)

CONNECT Statement

Use

Use the CONNECT statement to connect to the database instance, and specify the user name and password for the database session.

Prerequisite

In the SQL mode INTERNAL, you have specified the name of the chosen database instance and server in the SET SERVERDB statement.

You can do without the SET SERVERDB statement if you choose the database instance and server by specifying a KEY in the CONNECT statement.

Syntax

CONNECT Statement in the SQL Mode INTERNAL

CONNECT Statement in the SQL Mode ORACLE

· When you run the precompiler, you can use the precompiler option –u to override the user name and password specified in the CONNECT statement for the first database session. The values for all subsequent database sessions of the application program are, if possible, taken from the source code when the precompiler runs. A warning appears if these values are missing, and the embedded SQL statements of the subsequent database sessions are not checked.

· When you run the precompiler, you can use the precompiler option –U to override the KEY specified in the CONNECT statement of the first database session.


CONNECT Statement in the SQL Mode INTERNAL (MaxDB: C/C++ Precompiler Manual)

CONNECT Statement in the SQL Mode INTERNAL

Use

Use the CONNECT statement to connect to the database instance, and specify the user name, password, and options for the database session.

Syntax

EXEC SQL [<session_number>] CONNECT
[<user_name> IDENTIFIED BY <password> | <uidpwd>]
[<connect_option>...] [KEY <key>];

<uidpwd> ::= <user_name>/<password>

<connect_option> ::= [ISOLATION LEVEL <unsigned_integer>]
[TIMEOUT <unsigned_integer>]

· Enter <session_number> as the session number if you want your application program to open multiple database sessions in parallel. In the SQL mode INTERNAL, there can be a maximum of eight parallel sessions with different MaxDB database instances.

· The user name <user_name> and password <password> can also be specified as a character string in a host variable (character or UNICODE data types).

· In <connect_option> you can specify an isolation level and timeout value.

· You can specify the <key> in a host variable with data type char. You can specify an XUSER user key, DEFAULT or the environment variable SQLOPT. For information on setting the connection options at runtime in this environment variable, see your operating system documentation.

· The values of the <key> complete or override the values from the SET SERVERDB statement, as well as the explicitly specified user name, password, and CONNECT options.


CONNECT Statement in the SQL Mode ORACLE (MaxDB: C/C++ Precompiler Manual)

CONNECT Statement in the SQL Mode ORACLE

Use

Use the CONNECT statement to connect to the database instance, and specify the user name, password, and options for the database session.

Syntax

EXEC SQL CONNECT
[<user_name> IDENTIFIED BY <password> | <uidpwd>]
AT <session_name>
USING <database_server-database_name>
[<connect_option>...] [KEY <key>];

<uidpwd> ::= <user_name>/<password>

<connect_option> ::= [ISOLATION LEVEL <unsigned_integer>]
[TIMEOUT <unsigned_integer>]

· Choose a name for the database name in <session_name>. The only limit on the possible number of parallel database sessions in the SQL mode ORACLE is the maximum possible number of database sessions of the database instances.

· The user name <user_name> and password <password> can also be specified as a character string in a host variable (character or UNICODE data types).

· In <connect_option> you can specify an isolation level and timeout value.

· You can specify the <key> in a host variable with data type char. You can specify an XUSER user key, DEFAULT or the environment variable SQLOPT. For information on setting the connection options at runtime in these environment variables, see your operating system documentation.

· The <key>values complete or override the explicitly specified user name, password, and CONNECT options.


Static SQL Statements (MaxDB: C/C++ Precompiler Manual)

Static SQL Statements

Use dynamic SQL statements particularly if you already know the structures of the database tables during the programming phase, and the embedded SQL statements do not change at runtime of the application program. The C/C++ precompiler checks the syntax of static SQL statements by sending them to the database kernel when you run the precompiler with the precompiler option check.

If the SQL statements or the structures of the database tables change at runtime of the program, use dynamic SQL statements.

You can formulate the following types of static SQL statements:

· Static SQL statement without parameters

· Static SQL statement with parameters


Static SQL Statement Without Parameters (MaxDB: C/C++ Precompiler Manual)

Static SQL Statement Without Parameters

Use

One example of static SQL statements without parameters are DDL statements such as the CREATE TABLE statement. However, you can also formulate INSERTs, UPDATEs, DELETEs, and other statements.

Syntax

EXEC SQL [<session_spec>] <statement>;

Specify <session_spec> , when you are working with multiple database sessions.

EXEC SQL CREATE TABLE hotel
(hno FIXED (4,0) KEY CONSTRAINT hno BETWEEN 1 AND 9999,
name CHAR(15) NOT NULL, zip FIXED (5,0) NOT NULL, loc CHAR(20), price FIXED(6,2));

EXEC SQL INSERT INTO hotel VALUES (10,'Excelsior', 79000,'Atlanta', 135.00);

EXEC SQL INSERT INTO hotel VALUES (20,'Flora', 44000,'Philadelphia', 45.00);

EXEC SQL COMMIT WORK;


Static SQL Statement with Parameters (MaxDB: C/C++ Precompiler Manual)

Static SQL Statement with Parameters

Use

The most common use of parameters in a static SQL statement is the use of host variables as parameters in a WHERE condition.

The host variables must be declared in the declaration section.

You can use host variables in static SQL statements only in positions where the SQL syntax allows a parameter. For example, you cannot specify table names with host variables.

Syntax

EXEC SQL [<session_spec>] <statement>;

Specify <session_spec> , when you are working with multiple database sessions.

EXEC SQL BEGIN DECLARE SECTION;

char name[16];

EXEC SQL END DECLARE SECTION;

sprintf (name, "Excelsior");

EXEC SQL SELECT name FROM hotel WHERE name = :name;

EXEC SQL FETCH INTO :name;


Dynamic SQL Statements (MaxDB: C/C++ Precompiler Manual)

Dynamic SQL Statements

Use dynamic SQL statements if you do not know the structures of the database tables during the programming phase, and the embedded SQL statements can change at runtime of the application program.

If the SQL statements and table structures do not change at runtime, use static SQL statements.

You can formulate the following types of dynamic SQL statements:

Dynamic SQL statements without parameters

Dynamic SQL statements with parameters


Dynamic SQL Statements Without Parameters (MaxDB: C/C++ Precompiler Manual)

Dynamic SQL Statements Without Parameters

Use

Specify dynamic SQL statements without parameters as a character string <statement_source> in a host variable in the application program. The character string itself cannot contain any other host variable.

Call the dynamic SQL statement with the EXECUTE IMMEDIATE statement.

Syntax

EXEC SQL [<session_spec>] EXECUTE IMMEDIATE <statement_source>;

Specify <session_spec> , when you are working with multiple database sessions.

EXEC SQL BEGIN DECLARE SECTION;

char statement [40];

EXEC SQL END DECLARE SECTION;

strcpy (statement, "INSERT HOTEL VALUES (80, 'Royal Plaza', 2000, \'Denver', 90.00)");

EXEC SQL EXECUTE IMMEDIATE :statement;

EXEC SQL EXECUTE IMMEDIATE 'COMMIT WORK';


Dynamic SQL Statements with Parameters (MaxDB: C/C++ Precompiler Manual)

Dynamic SQL Statements with Parameters

Use

You can set parameters for dynamic SQL statements, so that any values unknown during the programming phase can be exchanged between the application program and the database instance.

Procedure

...

1. Replace the values that need to be exchanged with the placeholder ? in the statement.

2. Use the PREPARE statement to prepare the dynamic SQL statement for execution, and assign it a statement name.

3. Execute the dynamic SQL statement with the EXECUTE statement or OPEN CURSOR statement.
Use the USING clause to assign values to the previously unknown parameters at runtime, for example, from a program variable of your choice. This does not have to be a host variable.
You can execute a prepared SQL statement as often as you want, specifying new values as parameters each time.

If, during the programming phase, you do not know the table columns addressed by a dynamic SQL statement, and, therefore, the required parameters, then also use a descriptor.

EXEC SQL BEGIN DECLARE SECTION;

int hno;

char name[16];

float price;

char cmd[100];

char *stmt;

EXEC SQL END DECLARE SECTION;

strcpy (cmd, "INSERT (INTO???) hotel VALUES(10, 'Excelsior', \
79000, 'Atlanta', 135.00)");

EXEC SQL PREPARE STMT1 FROM :cmd;

EXEC SQL EXECUTE STMT1;

hno = 10;

strcpy (cmd, "SELECT name, price INTO ?, ? \
FROM hotel WHERE hno=?");

stmt = "STMT2";

EXEC SQL PREPARE :stmt FROM :cmd;

EXEC SQL EXECUTE :stmt USING :name, :price, :hno;


Using the Descriptor (MaxDB: C/C++ Precompiler Manual)

Using the Descriptor

Use

If, during the programming phase, you do not know the table columns addressed by a dynamic SQL statement with parameters, and, therefore, the required parameters, then use a descriptor.

At runtime, the application program determines the number, data types, and lengths of the table columns addressed by an SQL statement, and saves this information in the structure sqlda (SQL Descriptor Area, descriptor for short).

You can then use this information to assign the appropriate program variables to the parameters in the SQL statement.

See also: Example for Using a Descriptor

Prerequisite

You have used the PREPARE statement to prepare the dynamic SQL statement.

Procedure

1. Initialize the descriptor with the DESCRIBE statement.

2. Use the information in the descriptor to assign appropriate program variables to the parameters in the dynamic SQL statement. To do this, enter the addresses of these program variables in the descriptor structure as well.

Make sure that the program variables contain valid values at runtime.

3. Use the EXECUTE statement or the OPEN CURSOR statement with the USING clause.

If you use the SQL mode INTERNAL, the C/C++ precompiler defines an initial descriptor called sqlda automatically. In other modes, and if you want to use other descriptors, declare them as variables with the data type sqlda. This data type is defined in the header file cpc.h.


Structure of the Descriptor (MaxDB: C/C++ Precompiler Manual)

Structure of the Descriptor

This table describes the structure of the descriptor (the data structure sqlda) that you can use in dynamic SQL statements with parameters in the SQL mode INTERNAL.

The C/C++ precompiler also supports ORACLE sqlda data structures (see Compatibility with Other Database Systems).

sqldaid | Contains the character string sqlda for finding the structure in a memory dump
sqlmax | Maximum number of sqlvar entries The C/C++ precompiler specifies the constant sqlmax = 300 for this value, however, you can change it.
sqln | Number of sqlvar entries currently allocated
sqld | Number of output parameters used in the SQL statement Any parameters that can be both input and output parameters are also counted as output parameters.
sqlvar | array [sqlmax] of sqlvar entries For each parameter, an entry sqlvar [i] is generated according to the order in which the parameter appears in the SQL statement. This entry contains information on the data type and the length of the addressed table column.

All constants used in the descriptor are declared in the header file cpc.h.

If you do not want to use the standard descriptor, you can declare the descriptor <descriptor_name> as a variable of the type sqldatype or struct sqlda (in SQL mode ORACLE, SQLDA only). However, the descriptor must always have the same type within a program.


sqlvar [i] Entries in the Descriptor (MaxDB: C/C++ Precompiler Manual)

sqlvar [i] Entries in the Descriptor

Each sqlvar [i] entry in the descriptor structure describes the properties of a parameter in the dynamic SQL statement, as well as the properties of the required or assigned program variables.

Each sqlvar [i] entry consists of the following components:

colname

Contains the name of the table column for a FETCH statement.

For all other SQL statements, colname contains the entry columnx, where x is a sequential number.

colio

Specifies whether the parameter is an input or output parameter.

sqlinppar: Input parameter
sqloutpar: Output parameter
sqlinoutpar: Input and output parameter

colmode

Specifies whether NULL values are permitted for the parameter.

colmode is a byte whose four low-order bits are interpreted as a bit mask.

Bit 0: Mandatory
Bit 1: Optional (NULL permitted)
Bit 2: Default
Bit 3: Escape Character

coltype

Specifies the MaxDB data type of the parameter.

See: MaxDB Data Types in sqlvar Entries

collength

Specifies the length of the parameter or table column.

For numerical data types, collength specifies the number of digits.

For all other data types, collength specifies the number of characters.

You can modify the value of collength, for example, if the closing NULL byte increases the number of characters in a character string by 1.

colfrac

Specifies the number of decimal places for numerical parameters or table columns.

For the data type FLOAT/REAL colfrac = -1.

hostindicator

Contains the indicator value, so performing the same task as an indicator variable.

For input parameters, the user can set hostindicator.

For output parameters, query hostindicator. If the table column contains a NULL value, the value of the program variable is not overwritten.

hostvartype

In hostvartype, specify the C/C++ data type of the program variable assigned to the parameter (see C/C++ Data Types in sqlvar Entries).

If necessary, modify the values of collength and colfrac.

The DESCRIBE statement initializes hostvartype with the value –1 (undefined).

hostcolsize

In hostcolsize, specify the size of an array element (in bytes) for array statements.

hostvaraddr

In hostvaraddr, specify the address of the program variable assigned to the parameter.

For array statements, specify the address of the first array element.

The DESCRIBE statement initializes hostvaraddr with the NULL value.

hostindaddr

Contains the address of hostindicator.

Instead of this, you can also specify the address of an indicator variable. The indicator value is then written to this variable, and the content of hostindicator is undefined.

For array statements, specify the address of the first array element of the indicator variable.

If you do not want to use an indicator value, specify NULL.

colinfo

Used for internal information on converting program variables.

Do not change this value.


MaxDB Data Types in sqlvar Entries (MaxDB: C/C++ Precompiler Manual)

MaxDB Data Types in sqlvar Entries

This table shows the possible sqlvar entries coltype and the corresponding MaxDB data types.

coltype | MaxDB Data Type
sqlfixed | FIXED
sqlfloat | FLOAT
sqlchar | CHAR
sqlbyte | CHAR (n) BYTE
sqldate | DATE
sqltime | TIME
sqlexpr | FLOAT
sqltimestamp | TIMESTAMP
sqllong | LONG
sqllongbyte | LONG BYTE
sqlboolean | BOOLEAN
sqlunicode | CHAR UNICODE
sqlsmallint | SMALLINT
sqlinteger | INTEGER
sqlvarchar | VARCHAR
sqlvarbyte | VARCHAR BYTE
sqllongunicode | LONG UNICODE
sqlvarunicode | VARCHAR UNICODE


C/C++ Data Types in sqlvar Entries (MaxDB: C/C++ Precompiler Manual)

C/C++ Data Types in sqlvar Entries

This table shows the possible sqlvar entries hostvartype and the corresponding C/C++ data types.

hostvartype | C/C++ Data Type
sqlvint1 | integer (1 byte)
sqlvint2 | integer (2 bytes)
sqlvint4 | integer (4 bytes)
sqlvint8 | integer (8 bytes)
sqlvuns1 | unsigned integer (1 byte)
sqlvuns2 | unsigned integer (2 bytes)
sqlvuns4 | unsigned integer (4 bytes)
sqlvuns8 | unsigned integer (8 bytes)
sqlvreal4 | float (4 bytes)
sqlvreal8 | float (8 bytes)
sqlvchar | char array (ends with null byte)
sqlvcharp | char array (filled up with blank characters)
sqlvbyte | char array (null bytes permitted and filled up with null bytes)
sqlvstring1 | String with variable length struct {len char; char array}
sqlvstring2 | String with variable length struct {len short; char array}
sqlvstring4 | String with variable length struct {len int; char array}
sqlvfile | char array (filled up with blank characters) The value of this parameter must be a file name. See also SQLFILE
sqlvfilec | char array (ends with null byte) The value of this parameter must be a file name. See also SQLFILE
sqlvlongdesc | SQLLongDesc
sqlvucs2 | UCS2 array (filled up with blank characters)
sqlvutf16 | UTF16 array without surrogate (filled up with blank characters)
sqlvunicode | UTF8 array (filled up with blank characters)
sqlvunicodec | UTF8 array (ends with null byte)
sqlvstringunicode | UTF8 array with variable length struct {len short; char array}
sqlvstringunicode4 | UTF8 array with variable length struct {len int; char array}


Example for Using a Descriptor (MaxDB: C/C++ Precompiler Manual)

Example for Using a Descriptor

EXEC SQL BEGIN DECLARE SECTION;

char stmnt [255];

EXEC SQL END DECLARE SECTION;

strcpy (stmnt, "select hno, name, price from hotel");

EXEC SQL PREPARE SEL FROM :stmnt;

EXEC SQL EXECUTE SEL;

EXEC SQL PREPARE FET FROM 'FETCH USING DESCRIPTOR';

EXEC SQL DESCRIBE FET;

/* Bind each column to a piece of memory */

for (i=0;i<sqlda.sqln;i++) {
  sqlvartype *sqlvar = &sqlda.sqlvar[i];

  switch(sqlvar->coltype){
    case (sqlfixed) : {
      if (sqlvar->colfrac == 0) {
        sqlvar->hostvartype = sqlvint4;

        sqlvar->hostcolsize = sizeof(int);

        sqlvar->hostvaraddr = malloc(sizeof(int));
      }
      else {
        sqlvar->hostvartype = sqlvreal4;

        sqlvar->hostcolsize = sizeof(float);

        sqlvar->hostvaraddr = malloc(sizeof(float));
      }
      break;

    }
    case (sqlchar) : {
      sqlvar->hostvartype = sqlvchar;

      sqlvar->hostcolsize = sqlda.sqlvar[0].collength;

      sqlvar->hostvaraddr = malloc(sizeof(int));

      break;

    }
default : {
/* TODO:

support more datatypes */

    }
    }
    }

    /* Process result table */

    EXEC SQL EXECUTE FET USING DESCRIPTOR;

    while (sqlca.sqlcode == 0) {
      EXEC SQL EXECUTE FET USING DESCRIPTOR;
    }


PREPARE Statement (MaxDB: C/C++ Precompiler Manual)

PREPARE Statement

Use

Use the PREPARE statement to prepare a dynamic SQL statement with parameters for execution, and assign it a statement name.

Syntax

EXEC SQL [<session_spec>] PREPARE <statement_name>
         [INTO <descriptor_name> [USING <using_clause>]]
         FROM <statement_source>;

· Specify <session_spec>, when you are working with multiple database sessions.

· In <statement_name>, specify the statement name either in a host variable or as a constant character string.

· In <statement_name>, specify the dynamic SQL statement either in a host variable or as a constant character string.

In the PREPARE statement, the <descriptor_name> and the <using_clause> have no meaning in the SQL mode INTERNAL. They are used for DB2 compatibility.


DESCRIBE Statement (MaxDB: C/C++ Precompiler Manual)

DESCRIBE Statement

Use

Use the DESCRIBE statement to initialize the descriptor structure, and to determine the parameter and table column information needed for a dynamic SQL statement with descriptor.

Prerequisite

You have used the PREPARE statement to prepare the SQL statement for execution.

Syntax

EXEC SQL [<session_spec>] DESCRIBE <statement_name>
[INTO <descriptor_name> [<using_clause>]];

· Specify <session_spec>, when you are working with multiple database sessions.

· If the INTO clause is not specified, the precompiler uses the standard descriptor sqlda.

· If you do not want to use the standard descriptor, you can declare the descriptor <descriptor_name> as a variable of the type sqldatype or struct sqlda (in SQL mode ORACLE, SQLDA only). However, the descriptor must always have the same type within a program.

In the SQL mode INTERNAL, the <using_clause> has no meaning in the DESCRIBE statement. It is used for DB2 compatibility.


EXECUTE Statement (MaxDB: C/C++ Precompiler Manual)

EXECUTE Statement

Use

Use the EXECUTE statement to execute a dynamic SQL statement with parameters.

Prerequisites

· You have used the PREPARE statement to prepare the SQL statement for execution.

· If you are using a descriptor, you have initialized it with the DESCRIBE statement.

Syntax

EXEC SQL [<session_spec>] [<for_clause>] EXECUTE <statement_name> [<using_clause>];

· Specify <session_spec> , when you are working with multiple database sessions.

· Use the USING clause to assign values to the parameters.

· Use the FOR clause for array statements.


OPEN CURSOR Statement (MaxDB: C/C++ Precompiler Manual)

OPEN CURSOR Statement

Use

You can use the OPEN CURSOR statement to execute a dynamic SQL statement with parameters, and generate a named result table (cursor).

Prerequisites

· You have used the PREPARE statement to prepare the SQL statement for execution.

· If you are using a descriptor, you have initialized it with the DESCRIBE statement.

· You have already defined the cursor (the named result table) with a DECLARE CURSOR statement.

Syntax

EXEC SQL [<session_spec>] [<for_clause>] OPEN <cursor_name>
         [ USING <parameter_list>
         | USING DESCRIPTOR [<descriptor name>] [KEEP]
         | INTO <parameter_list>
         | INTO DESCRIPTOR [<descriptor name>] [KEEP]]

· If, in the programming phase, you do not know how many different result tables are processed by your application program, you can specify the result table name <cursor_name> in a host variable in the OPEN CURSOR statement.

· Specify KEEP if you want to follow the OPEN CURSOR statement with PUTVAL statements.

· Here, INTO has the same meaning as specifying USING <parameter_list>. It guarantees compatibility with other database systems.

EXEC SQL BEGIN DECLARE SECTION;

int hno;

char name[16];

float price;

char cmd[100];

char *stmt;

char *cursor;

EXEC SQL END DECLARE SECTION;

strcpy (cmd, "INSERT (INTO???) hotel VALUES(10, 'Excelsior', \
79000, 'Atlanta', 135.00)");

EXEC SQL PREPARE STMT1 FROM :cmd;

EXEC SQL DECLARE cur1 CURSOR FOR STMT1;

EXEC SQL OPEN cur1;

hno = 10;

strcpy (cmd, "SELECT name, price FROM hotel WHERE hno=?");

stmt = "STMT2";

EXEC SQL PREPARE :stmt FROM :cmd;

cursor = "cur2";

EXEC SQL DECLARE :cursor CURSOR FOR :stmt;

EXEC SQL OPEN :cursor USING :hno;

EXEC SQL FETCH :cursor INTO :name, :price;


USING Clause (MaxDB: C/C++ Precompiler Manual)

USING Clause

Use the USING clause for dynamic SQL statements with parameters to assign values to the parameters in EXECUTE or OPEN CURSOR statements.

Prerequisites

· You have used the PREPARE statement to prepare the SQL statement for execution.

· If you are using a descriptor, you have initialized it with the DESCRIBE statement.

Syntax

<using_clause> ::=
  USING <parameter_list>
| USING DESCRIPTOR [<descriptor_name>]
| INTO <parameter_list>
| INTO DESCRIPTOR [<descriptor_name>]

· If you do not specify <descriptor_name>, the standard structure sqlda is used.

· Here, INTO has the same meaning as specifying USING. It guarantees compatibility with other database systems.


Array Statement (MaxDB: C/C++ Precompiler Manual)

Array Statement

Use

Use array statements to read or change more than one data record in a data table with only a single embedded SQL statement. An array statement executes an SQL statement multiple times in a loop, and applies each array element as a parameter in a row of the database table.

You have the following options when you formulate an array statement:

· You specify all parameters in a static SQL statement in array host variables.

· You use the FOR clause together with a descriptor and array program variables in a dynamic SQL statement.

Syntax

EXEC SQL [<session_spec>] [FOR <loop_parameter>] <sql_statement>;

· Specify <session_spec>, when you are working with multiple database sessions.

· The value of <loop_parameter> determines the number of loop repeats. If the array variable has more or fewer components than specified in <loop_parameter>, a warning appears in the precompiler log and the statement is executed with the lowest dimension. This also applies if you use multiple array variables that do not have the same number of elements.

If errors occur in the database kernel while the array statement is being executed, the statement is terminated, and the number of successfully processed records is entered under sqlerrd[2] in the structure sqlca.

The SQL statement SELECT INTO is not permitted for array statements in the SQL mode INTERNAL.

Example

Example of a static array statement:

/* Array Insert */

EXEC SQL BEGIN DECLARE SECTION;

int hno[3];

int zip[3];

float price[3];

char *name[3], *loc[3];

EXEC SQL END DECLARE SECTION;

hno[0]   = 10;

name[0]  = "Excelsior";

zip[0]   = 89073;

loc[0]   = "Philadelphia";

price[0] = 135.00;

hno[1]   = 30;

name[1]  = "Flora";

zip[1]   = 48159;

loc[1]   = "Atlanta";

price[1] = 45.00;

hno[2]   = 20;

name[2]  = "Continental";

zip[2]   = 86165;

loc[2]   = "Cincinnati";

price[2] = 70.00;

EXEC SQL INSERT INTO HOTEL VALUES (:hno, :name, :zip, :loc, :price);


INCLUDE FILE Statement (MaxDB: C/C++ Precompiler Manual)

INCLUDE FILE Statement

Use

You can use the INCLUDE FILE statement to include source code from a file <file_name> in your application program. The precompiler places this text at the location of the INCLUDE FILE statement in the source code. The text itself cannot contain an INCLUDE FILE or INCLUDE DECLARE Statement.

Syntax

EXEC SQL INCLUDE <file_name>;

If necessary, you can use EXEC SQL INCLUDE sqlca to select the position in the source code at which you want the precompiler to declare the structure sqlca. This statement ensures compatibility with other embedded SQL compilers. If you do not select a position, the precompiler places the declaration at the start of the program.


PUTVAL Statement (MaxDB: C/C++ Precompiler Manual)

PUTVAL Statement

Use

You can use PUTVAL statements to insert data in a LONG column piecewise.

The PUTVAL statements must follow a INSERT statement. Each PUTVAL statement that follows this INSERT statement appends the current content of the corresponding host variable to the LONG column of the database table.

Prerequisite

You have started to insert the data in the LONG column with an INSERT statement.

Syntax

EXEC SQL [<session_spec>] PUTVAL INTO <table_name>
         [(<column_name>,...)] VALUES (<parameter_list>)

· Apart from the key word PUTVAL, the PUTVAL statement must be the same as the preceding INSERT statement. For example, the order and number of the parameters in the parameter list must be the same as the parameter list <parameter_list> of the INSERT statement.

· Before each PUTVAL statement, assign the new data to the host variable for the LONG column.

· The PUTVAL statement ignores any values in the parameter list that refer to table columns other than the LONG column.

· You cannot execute any other SQL statements between the INSERT statement and the subsequent PUTVAL statement, or between the PUTVAL statements themselves.

Every other SQL statement closes the LONG column in the database table, so that no more data can be appended.

· Inform yourself about the special features when using the data type SQLLongDesc.

· If you want to insert more than one row in a table, use an array statement.

EXEC SQL CREATE TABLE LONGTEST
(I1 INTEGER, L1 LONG BYTE, L2 LONG BYTE);

EXEC SQL BEGIN DECLARE SECTION;

  int array_size;

  VARCHAR l1[100][500], l2[100][50];

  int i1[100];

EXEC SQL END DECLARE SECTION;

array_size = 100;

EXEC SQL FOR :array_size INSERT INTO LONGTEST VALUES
(:i1, :l1 :il1, :l2 :il2);

· If you do not want a PUTVAL statement to insert any data in a certain LONG column, then assign the predefined constant SQL_IGNORE to the appropriate indicator value in this statement.

You cannot insert LONG data with the length NULL.


GETVAL Statement (MaxDB: C/C++ Precompiler Manual)

GETVAL Statement

Use

You can use the GETVAL statement to read data piecewise from a LONG column.

The GETVAL statements must follow a FETCH statement. Each GETVAL statement that follows this FETCH statement reads the next part of the content from the LONG column of the database table from the current position.

Prerequisite

You have started to read the data from the LONG column with a FETCH statement.

Syntax

EXEC SQL [<session_spec>] GETVAL INTO (<parameter_list>)

· Apart from the key word GETVAL, the GETVAL statement must be the same as the preceding FETCH statement. For example, the order and number of the parameters in the parameter list must be the same as the parameter list <parameter_list> of the FETCH statement.

· You cannot execute any other SQL statements between the FETCH statement and the subsequent GETVAL statement, or between the GETVAL statements themselves.

· If the host variable that corresponds to the LONG column has the data type SQLLongDesc, then you can read the total length of the LONG column in the corresponding structure component cbColLenafter the GETVAL statement has been executed.

· You can determine how often you need to execute the GETVAL statement by querying the warning message sqlwarn1. If sqlwarn1 has the value W, then the LONG column has not yet been read completely.

After the FETCH statement has been executed, the remaining content of the LONG column is read by the following statement:

while (sqlca.sqlwarn[1] == 'W')
EXEC SQL GETVAL INTO :i1, :l1, :l2;

· If you do not want a GETVAL statement to read the data of a certain LONG column, then assign the predefined constant SQL_IGNORE to the appropriate indicator value in this statement.


WHENEVER Statements (MaxDB: C/C++ Precompiler Manual)

WHENEVER Statements

Use

You can use WHENEVER statements to program actions that you want to be executed for each subsequent embedded SQL statement.

You have the following options:

· You program actions that are executed before or after each SQL statement.

· You program error handling actions.

The WHENEVER statement must be located in the source code of the application program in front of the SQL statements that it handles. This is so that the C/C++ precompiler can generate the appropriate individual statements when the precompiler runs. The WHENEVER statement is valid for all subsequent SQL statements in the source code until another WHENEVER statement for the same condition takes over, or until the program ends.

Syntax

EXEC SQL WHENEVER <condition> <action>;

Where <condition> is an error (see Handling Errors with WHENEVER Statements), or one of the following conditions:

SQLBEGIN | The specified <action> is executed before each SQL statement.
SQLEND | The specified <action> is executed after each SQL statement.

For <action>, specify one of the possible actions for the WHENEVER statement.

Example

Example for Using WHENEVER Statements


Handling Errors with WHENEVER Statements (MaxDB: C/C++ Precompiler Manual)

Handling Errors with WHENEVER Statements

Use

You can use WHENEVER statements to program standard error handling procedures for errors and exceptions that can occur when embedded SQL statements are executed. You can check four different types of database system messages, and choose from four standard reactions to these messages.

Use a WHENEVER statement if, for example, the application program does not query the values of the messages sqlcodeor sqlwarn0 after an SQL statement.

Syntax

EXEC SQL WHENEVER <condition> <action>;

Where <condition> is one of the following cases:

SQLWARNING | sqlwarn0 has the value W. At least one warning exists.
SQLERROR | sqlcode has a negative value. An error has occurred.
NOT FOUND | sqlcode has the value 100 (ROW NOT FOUND). No table row found.
SQLEXCEPTION | sqlcode has a positive value greater than 100. An exception has occurred.

For <action>, specify one of the possible actions for WHENEVER statements.

If SQLERROR occurs, the application program must terminate, and the error must be analyzed.

If you call an error handling function <action> that also contains SQL statements, and these SQL statements can send error messages, then start the function with a WHENEVER CONTINUE statement to avoid endless loops.

Example

EXEC SQL WHENEVER SQLEND CALL CheckSQLCode(&sqlca);

EXEC SQL SELECT DIRECT NAME, LOC
         INTO :name, :loc FROM HOTEL KEY HNO = :hno;

void

CheckSQLCode(sqlcatype *sqlca)
{
if (sqlca->sqlcode != 0)

{
code =

sqlca->sqlcode;
EXEC SQL WHENEVER

SQLERROR CONTINUE;
EXEC SQL INSERT INTO

ERROR VALUES (:code);
}
}


Actions for the WHENEVER Statement (MaxDB: C/C++ Precompiler Manual)

Actions for the WHENEVER Statement

Use WHENEVER statements to call the following actions <action>:

STOP | Resets the running transaction correctly, ends the database connection with the RELEASE statement COMMIT WORK RELEASE and terminates the program
CONTINUE | Continues to run the application program. Use CONTINUE to deactivate a previous WHENEVER action for this condition.
GOTO <label> | The application program jumps to the label <label>. <label> can have a maximum of 45 characters.
CALL <function> | The application program calls the function <function>. The function call can have a maximum of 50 characters, including the parameters used.


Example for Using WHENVER statements (MaxDB: C/C++ Precompiler Manual)

Example for Using WHENEVER Statements

The following examples show the usage of different WHENEVER statements.

EXEC SQL WHENEVER SQLWARNING CALL warnproc();

EXEC SQL SELECT * FROM dual;

/* receives a warning and calls warnproc */

EXEC SQL WHENEVER SQLERROR CALL errproc();

EXEC SQL DELETE FROM unknowntable;

/* receives an error and calls errorproc */

EXEC SQL WHENEVER SQLERROR STOP;

/* receives also an error but stops execution */

EXEC SQL DELETE FROM unknowntable;


CANCEL Statement (MaxDB: C/C++ Precompiler Manual)

CANCEL Statement

Use

Use the CANCEL statement to cancel the processing of an SQL statement by the database kernel. This means that the SQL statement has no effect.If successful, the CANCEL statement has the return code sqlcode 0. The canceled statement has the sqlcode –102.

Syntax

EXEC SQL CANCEL [<cancel_session>];

<cancel_session> ::= <session_number> | <session_name> | CURRENT


EXEC COMMAND Statement (MaxDB: C/C++ Precompiler Manual)

EXEC COMMAND Statement

Use

You can use the EXEC COMMAND statement to execute operating system commands, for example, to delete files or call the Database Manager CLI.

The same general rules apply to EXEC COMMAND statements as to SQL statements. Precede each system call with the key words EXEC COMMAND .

Syntax

EXEC COMMAND SYNC <command> RESULT <result_parameter>
| EXEC COMMAND ASYNC <command>;

<command> ::= <string_constant> | <host_variable>

<result_parameter> ::=  <host_variable>

· Declare <result_parameter> as a host variable with the type int (2 bytes).

· In SYNC mode, the application program stops until the operating system command has been completed.

· In ASYNC mode, the operating system command is executed in the background.

· For information on the correct syntax of the operating system command, see your operating system documentation.


VERSION Statement (MaxDB: C/C++ Precompiler Manual)

VERSION Statement

Use

You can use the VERSION statement to display the versions of the general MaxDB runtime environment and the precompiler runtime environment.

Syntax

EXEC SQL VERSION <runtime_version>, <precompiler_version>;

You can specify <runtime_version> and <precompiler_version> as host variables with the data type char and a length of 40 bytes.


TRACE Statements (MaxDB: C/C++ Precompiler Manual)

TRACE Statements

Use

You can use the TRACE statements to specify that the precompiler runtime environment logs the execution of individual embedded SQL statements in the trace file <filename>.pct at runtime of the application program.

Procedure

Include the SQL statements that you want to log in the statements SET TRACE ON or SET TRACE LONG and SET TRACE OFF.

Any SQL statements that appear in external subroutines or modules called by the included SQL statements are also logged.

To activate logging for the whole application program, set your chosen trace option when you run the precompiler or call the program. The trace option then overrides the individual TRACE statements.

Syntax

EXEC SQL SET TRACE ON; | Activates logging with the trace option TRACE SHORT Every executed SQL statements is logged, including the messages sqlcode und sqlerrd[2].
EXEC SQL SET TRACE LONG; | Activates logging with the trace option TRACE LONG Every executed SQL statements is logged, including the messages sqlcode und sqlerrd[2] and all parameter values.
EXEC SQL SET TRACE OFF; | Deactivates logging
EXEC SQL SET TRACE LINE <trace_line>; | The content of <trace line> is written to the trace file as a comment. You can specify <trace line> as a character string or in a host variable.


Database System Messages (MaxDB: C/C++ Precompiler Manual)

Database System Messages

Database system messages and warnings are sent using the global structure sqlca (SQL Communication Area). The precompiler includes this structure automatically in every MaxDB application program. At runtime of the application program, the database saves information on the execution of the last embedded SQL statement in the structure components, for example, information on any errors that occurred.

Query the structure component sqlcodeafter every SQL statement.

The sqlca components have the following meaning:

sqlcaid

char [8]

Contains the character string sqlca and is used to find the sqlca when analyzing a memory dump

sqlcabc

integer (4 byte)

Specifies the length of the sqlca in bytes

sqlcode

integer (4 byte)

Contains the message code of the database system message

sqlcode = 0 indicates that a statement was executed successfully.

sqlcode > 0 indicates problems that must be handled in the program.

sqlcode < 0 indicates errors that terminated the program.

For descriptions of all the messages, see Messages.

sqlerrml

integer (2 byte)

Specifies the current length of sqlerrmc

sqlerrmc

char [70]

Contains an explanation of the message if sqlcode ? 0

sqlerrd

Array of six 4 byte integer numbers

sqlerrd [2] specifies how many table rows were processed by the SQL statement. -1 indicates that the number of processed rows is unknown.
If there are errors in array statements, sqlerrd [2] contains the number of the last row that was processed without errors.

sqlerrd [5] specifies the runtime of the statement in the database kernel (in seconds).

sqlerrd [6] specifies the position in the SQL statement at which a syntax error was found. This value is undefined for array statements. If the SQL statement did not have any errors, then sqlerrd [6] = 0.

sqlwarn0

char [1]

sqlwarn0 = W specifies that the SQL statement generated at least one of the warnings sqlwarn1..sqlwarnc.

If no warning exists, then sqlwarn0 contains a blank character.

sqlwarn1..sqlwarnc

Warning messages in the structure sqlca

sqlresn

char [18]

Contains the name of the result table after a SELECT statement is called

sqlresn contains a blank character after all other calls

sqldatetime

integer (2 byte)

Specifies which date and time format the data types DATE, TIME und TIMESTAMP have.

1 INTERNAL
2 ISO
3 USA
4 EUR
5 JIS

All other sqlca components are used for internal purposes.


Warning Messages in the Structure sqlca (MaxDB: C/C++ Precompiler Manual)

Warning Messages in the Structure sqlca

This table shows you the warning messages that can occur as database system messages.

Each of the sqlca components sqlwarn1..sqlwarnc has the value W if the execution of an embedded SQL statement generates the corresponding warning.
If the corresponding warning does not exist, the component contains a blank character.

sqlwarn1

char [1]

Specifies whether a character string of the type char was truncated when a host variable and the database exchanged values.

If you use an indicator variable, and a warning occurs, the variable specifies the length of the original character string.

sqlwarn2

char [1]

Specifies whether COUNT, MAX, MIN, SUM, AVG, STDDEV or VARIANCE NULL values were found in the database table and ignored by the database kernel when the SET functions were executed

sqlwarn3

char [1]

Specifies whether the number of result columns of a SELECT or FETCH statement did not match the number of host variables in the INTO clause

sqlwarn4

char [1]

Specifies whether an UPDATE or DELETE statement was performed without a WHERE clause and, therefore, in the entire database table

sqlwarn6

char [1]

Specifies whether the values of a date (DATE or TIMESTAMP) needed to be corrected

You see this warning for incorrect dates such as 31.2 or 37.7.

sqlwarn8

char [1]

Specifies whether all table rows needed to be searched to generate a result table

sqlwarnb

char [1]

Set if a TIME value is greater than 99 (or greater than 23 in the USA format) The value is corrected to modulo 100 (or 24).

sqlwarnc

char [1]

For a SELECT statement, specifies whether more rows were found than permitted by the ROWNO predicate in the WHERE clause


Programming Notes (MaxDB: C/C++ Precompiler Manual)

Programming Notes

To optimize your application program, remember the following programming notes:

· In SELECT statements, identify the columns that you want to select.

· Use key specifications to identify the table rows that need to be processed. You can determine key columns from the system tables.

· SELECT statements with multiple result rows with no ORDER clause do not specify the order in which the table rows are read from the database table. In this case, the logic of your application program cannot assume that there is a specified order.,

· You can use the SINGLE SELECT statement to process individual rows in the SQL mode INTERNAL.

· Note the different way of handling named result tables (CURSOR) in the different SQL modes.

For information on the special features of the SQL mode ORACLE in the MaxDB database system, see the documentation SQL Mode ORACLE.

· Inform yourself about the user and role concept of the database system.

· Execute a RELEASE statement as the final SQL statement in your application program. This releases the resources needed by the precompiler runtime environment.

· In the MaxDB database system, remember that DDL statements such as CREATE TABLE are also subject to the transaction concept, which means that they can be undone or that they must be completed with a COMMIT statement.

· Read the information about the locks in the database, and define a suitable isolation level for your statements.

· Program reactions to possible TIMEOUT messages. You can do this by, for example, querying the structure component sqlcode after each SQL statement (see Database System Messages).

For more information on the meaning of optimized SQL statements and the available options for creating them, see SQL Optimizer.


Compatibility with Other Database Systems (MaxDB: C/C++ Precompiler Manual)

Compatibility with Other Database Systems

The MaxDB database system can execute database statements that are written in other SQL modes.

You specify the SQL mode of your application program in the precompiler options when you run the precompiler.

Inform yourself about the special features in the SQL mode ORACLE and the SQL mode ANSI.

If you only want to create individual embedded SQL statements in another SQL mode, then precede them with the following key words:

· EXEC SAPDB or EXEC INTERNAL for individual statements in the INTERNAL mode

· EXEC ORACLE for individual statements in the ORACLE mode

· EXEC ANSI for individual statements in the ANSI mode


Special Features in SQL Mode ORACLE (MaxDB: C/C++ Precompiler Manual)

Special Features in SQL Mode ORACLE

· The isolation levels 0, 1, 2, 3 are permitted in the SQL mode ORACLE. The default isolation level is 1.

· You need to define the appropriate sqlda structures for dynamic SQL statements. They are compatible with the ORACLE sqlda structures, but contain additional internal MaxDB information. Use the appropriate INCLUDE files that are included automatically when the precompiler runs.

/*Declaration*/

SQLDA orada;

/*Initialization*/

orada = sqlald (max_vars, max_name, max_ind_name);

where max_vars indicates the number of parameters, max_name the maximum number of characters in the parameter names, and max_ind_name the maximum number of characters in the indicator names.

· With a few exceptions, the return code sqlcode of the database system is copied from MaxDB (see Messages).

This table shows the exceptions and the corresponding MaxDB message codes:

ORACLE Message Code | MaxDB Message Code
-1008 | Warnung3
-1007 | -804
-1034 | -813
0 | -4000
Warnung1 | -743
100 | 1403 ROW NOT FOUND


Special Features in SQL Mode ANSI (MaxDB: C/C++ Precompiler Manual)

Special Features in SQL Mode ANSI

· The isolation levels 0, 1, 2, 3 are permitted in the SQL mode ANSI. The default isolation level is 3.

· Dynamic SQL statements in ANSI mode use the MaxDB sqlda structure that is included automatically when the precompiler runs.

· With a few exceptions, the return code sqlcode of the database system is copied from MaxDB (see Messages).

This table shows the exceptions and the corresponding MaxDB message codes:

ANSI Message Code | MaxDB Message Code
-250 | +250
-300 | +300
-320 | +320
ANSISTATE 01004 | sqlwarn1
ANSISTATE 01003 | sqlwarn2

The warning messages sqlwarn1and sqlwarn2 appear in the structure sqlca.


How the C/C++ Precompiler Works (MaxDB: C/C++ Precompiler Manual)

How the C/C++ Precompiler Works

When you run the precompiler, the C/C++ precompiler translates the SQL statements embedded in the application program into calls of procedures of the precompiler runtime environment, and prepares the source code for the C/C++ compiler

The precompiler performs the following tasks:

· Generates the descriptor structure sqlda

· Generates the structure sqlca for database system messages

· Includes the standard header file cpc.h

· Checks the syntax of the embedded SQL statements

· Generates the precompiler log with any error messages and warnings

Precompiler Option check

If you choose the precompiler option check , the precompiler checks the existence of the called database tables and columns, as well as the compatibility of the data types and the access privileges of the users. It does this by sending the embedded SQL statements to the parser or database kernel. A ROLLBACK resets the effects of all SQL statements executed in this way after the precompiler has completed its run.

Only the syntax can be checked for statements with components unknown to the precompiler. These can be, for example, dynamic SQL statements or CONNECT statements with host variables.

The SQL statements are executed in the order in which they appear in the source code, and not in the logical order of the program statements.

Connecting to a Database

Before it can check the embedded SQL statements (with the check option), the precompiler must connect to the database instance. The following rules apply:

· If the first static SQL statement of a database session is not a CONNECT statement, then all user data of the XUSER user key DEFAULT applies.

· If the first static SQL statement of a database session is a CONNECT statement, then all data is taken from this statement, and any missing data from the XUSER user key DEFAULT.

· In the first database session, you can use appropriate precompiler options to override all user data.


Running the Precompiler (MaxDB: C/C++ Precompiler Manual)

Running the Precompiler

To check the source code file <filename>.cpc of your application program with the C/C++ Precompiler, and so make it executable, perform the following tasks:

...

1. Use the following call to start the precompiler and compiler from the command line:
cpc <precompiler_options> <filename> <compiler_options>
Specify your preferred precompiler options and compiler options. The precompiler generates a C file <filename>.c or a C++ file<filename>.cpp, depending on the chosen precompiler options.

2. Translate this file with your C/C++ compiler. The compiler generates an object file. Depending on your chosen precompiler options, the compiler can be started at the same time as the precompiler, so that the object file can be generated from your source code in a single step.

3. Combine this object file with other object files and libraries until you have an executable program. To do this, call the precompiler linker cpclnk with your chosen options, or include the precompiler runtime environment libpcrl manually.

See also Example: Compiling a MaxDB Application Program


Call Options for the Precompiler Linker (MaxDB: C/C++ Precompiler Manual)

Call Options for the Precompiler Linker

After running the precompiler and compiling your application program, call the precompiler linker with the following options:

Options for Microsoft Windows Operating Systems

cpclnk [-<sdkver>] [-BIT32|-BIT64] [-MT|-MD|-SMT] [<link_options>] <file_name> [<object_archive>]

· If you have installed multiple versions of the precompiler software, choose a version with <sdkver>.

For example, enter –7402, if you have installed Version 7.4.02.

· Use the options -BIT32|-BIT64 and -MT|-MD|-SMT to specify the runtime libraries that you want the linker to use.

· Specify your linker options in <link_options>. For information on your linker, see your operating system documentation.

· Choose a name for the executable program in <file_name>.

· Specify the object files in <object_archive>. You can also specify the relevant path.

Options for UNIX Operating Systems

cpclnk [-P] [-s] [<link_options>] <file_name> [<object_archive>]

· Use option –P to call the C++ linker.

· Use option –s if you want to link the object files statically.


Precompiler Options (MaxDB: C/C++ Precompiler Manual)

Precompiler Options

This table shows all the options you can specify when you call the precompiler.

-E cansi

Generates ANSI C-compatible code

-E cplus

Generates C++-compatible code

-BIT32

Generates 32 bit-compatible code

If you do not specify this option, the precompiler generates 64 bit-compatible code, if possible.

-m <m_begin,m_end>

Defines the valid column range in which the precompiler interprets source code

If you do not specify this option, the following defaults apply:
m_begin = 1
m_end = 132

-e

Generates a program module that can be combined with other modules

Only translate the main module without this option, all other modules must be compiled with this option.

-H <check_option>

<check_option> = nocheck|syntax|check

Sets the chosen check option for the precompiler

nocheck: the precompiler checks only the syntax of the exec sql commands for the embedded SQL statements

syntax: the precompiler also checks the syntax of the database statements themselves

check: the precompiler also checks the existence of the called database tables and columns, their compatibility with the data types of the corresponding host variables, and the access privileges of the specified database user

If you do not specify a check option, the precompiler uses check automatically.

-b <maxpacketsize>

Restricts the size of the request buffer for SQL statements when the precompiler runs

The default when the precompiler runs is <maxpacketsize> = 16000

At runtime of the application program, the request buffer is restricted by the support database parameter _PACKAGE_SIZE of the database instance that is being addressed.

-G unicode

Specifies that the generic precompiler data types, such as TCHAR and LPSTR, are converted to UNICODE data types such as WCHAR and LPWSTR

At the same time, the precompiler integrates the macro SAPDB_WITH_UNICODE with the source code.

If you do not specify this option, then the generic data types are converted to ANSI data types (CHAR, CHAR*).

-s

Suppresses the screen output of precompiler messages

-w

Suppresses the output of any precompiler warnings

-o

Specifies that the embedded SQL statements are copied to the source code generated by the precompiler as comments

-l

Specifies that the precompiler writes the embedded SQL statements and their error messages to the precompiler log

-c

Prevents the compiler from being called automatically after the precompiler has run successfully

However, the source file for the compiler is retained.

-T

Sets the default TRACE SHORT for the trace option

-X

Sets the default TRACE LONG for the trace option

-F <trace_file_name>

Sets the default for the name of the trace file (see Trace Options)

-n <server_name>

Overrides the database server specified in the SET SERVERDB statement or CONNECT statement for the first database session

-d <database_name>

Overrides the database instance specified in the SET SERVERDB statement or CONNECT statement for the first database session

-u <user_name>,<password>

Overrides the user name and password specified in the CONNECT statement of the first database session

-U <user_key>

Overrides the KEY specified in the CONNECT statement for the first database session

-S <sql_mode>

<sql_mode> = internal|ansi|oracle

Defines the SQL mode for your application program

If you do not specify an SQL mode, the precompiler uses the INTERNAL mode automatically.

-D <datetimeformat>

<datetimeformat> = eur|iso|jis|usa|internal

Defines the date and time format used in the application program

If you do not specify a format, the precompiler uses the INTERNAL format automatically.

-V

Displays the precompiler version

-<sdkver>

Specifies the version of the precompiler software

For example, enter –7402, if you have installed Version 7.4.02.

-h

Displays all call options for the precompiler and precompiler runtime environment


Precompiler Log (MaxDB: C/C++ Precompiler Manual)

Precompiler Log

When the precompiler runs, the C/C++ precompiler writes a log file <filename>.pcl. Depending on the specified precompiler options, this file can contain the source code, warnings, and error messages from the precompiler.

If errors occur before the precompiler can generate the log file, then they are logged in the file sqlerror.pcl.


Example: Compiling a MaxDB Application Program (MaxDB: C/C++ Precompiler Manual)

Example: Compiling a MaxDB Application Program

You have written a source code file test.cpc.

Use the command
cpc –d DB –u Jones,secret test

to generate the file test.o. This uses the database instance DB with the user Jones and the password secret.

Use the command
cpclnk test

to link the file with the runtime library and generate an executable program.

If you want a trace file to be written when the test program is executed, set the environment variable SQLOPT to -X. The corresponding command in a Bash shell is as follows:

export SQLOPT=-X

The trace file test.pct is written when the test program is executed. This file is located in the same directory as the test program.


Functions of the Precompiler Runtime Environment (MaxDB: C/C++ Precompiler Manual)

Functions of the Precompiler Runtime Environment

The precompiler runtime environment performs the following functions at runtime of the application program:

· Connecting to the databases and opening database session as specified in the connection options

· Assigning parameter values

· Converting Data Types

· Executing precompiler statements

· Using indicator variables to denote NULL values (undefined values)

· Writing database system messages in the structure sqlca

· Writing the trace file as specified in the trace options

See also Example: Executing an Application Program

You can use the IRCONF tool to administer the installed versions of the runtime library of the interface programs, including the precompiler.


Connection Options at Runtime (MaxDB: C/C++ Precompiler Manual)

Connection Options at Runtime

The table shows you all options that you can set for the precompiler runtime environment in the environment variable SQLOPT when you connect to the database instance.

The options–u, -U, -t and –I are then valid for all database connections of the application program for which you have specified the key <key> DEFAULT or SQLOPT in the CONNECT statement.

The options –n and –d apply to all database connections and override the settings specified in the CONNECT or SET SERVERDB statement.

For information on setting the environment variable, see your operating system documentation.

-n <server_name> | Name of the database server
-d <database_name> | Name of the database instance
-u <user_name,password> | User name and password
-U <user_key> | XUSER user key
-t <timeout> | Timeout value in seconds If the default -1 is specified, then the precompiler runtime environment uses the timeout value specified in the special database parameter SESSION_TIMEOUT.
-I <isolation_level> | Isolation level If no isolation level is specified, the precompiler runtime environment uses level 10 automatically.


Trace Options (MaxDB: C/C++ Precompiler Manual)

Trace Options

Use

You can use the trace options to specify that the precompiler runtime environment logs the execution of the entire application program in the trace file <filename>.pct at runtime.

If you want to log individual embedded SQL statements only, then use the TRACE statements.

You can use the IRTRACE tool to activate and deactivate the trace at runtime.

Procedure

· Specify your chosen default for the trace option in the precompiler options when you run the precompiler.

· Set your chosen trace option for runtime in the environment variable SQLOPT.

The following table shows the possible trace options that you can specify when running the precompiler and calling the application program.

-T

Logs with the option TRACE SHORT

Every executed SQL statements is logged, including the messages sqlcode und sqlerrd[2].

-X

Logs with the option TRACE LONG

Every executed SQL statements is logged, including the messages sqlcode und sqlerrd[2] and all parameter values.

-F <trace_file_name>

Allows you to choose a name other than <filename>.pct for the trace file

If you do not specify any other trace options, then the option TRACE SHORT is activated at the same time.

If you specify pid or PID for <trace_file_name>, then the name of the trace file becomes pid<process_id>.pct automatically. In this way, you can generate multiple trace files in parallel. If you do not specify any other trace options, then logging is deactivated at the same time.

The following table shows the possible trace options that you can specify only when you call the application program:

-N

Suppresses the logging of the date and time for the start and end of each executed SQL statement

-L <execution_time>

Specifies that any SQL statements that take longer to execute than <execution_time> are logged

Specify <execution_time> in seconds.

The log option TRACE LONG is used automatically. Dates and times cannot be suppressed with –N.

-Y <statement_count>

Specifies that logging alternates between the two trace files < filename>.pct and < filename>.prot in the run directory of the application program.

Use <statement_count> to specify how many SQL statements are logged in each file. If the number of SQL statements exceeds <statement_count> then the trace files are overwritten cyclically.

If you specify this option, then the option TRACE LONG is used automatically. Dates and times cannot be suppressed with –N.

See also Example of a Trace File


Using IRTRACE (MaxDB: C/C++ Precompiler Manual)

Using IRTRACE

IRTRACE is a tool for changing the trace settings and displaying the current trace setting of the precompiler runtime environment for a MaxDB application program translated with the C/C++ precompiler.

To do this, you enter commands at the operating system level. IRTRACE and the application program communicate through a shared memory segment.

If you use IRTRACE to change trace settings, the system makes an entry in the shared memory segment. The application program checks the entries in the shared memory at regular intervals, and changes its trace setting accordingly. The assignment of an application program to the correct entry in the shared memory is made using the process ID of the application program. The entry remains in the shared memory for as long as the corresponding process is active, and can be queried.

When a shared memory segment is being used, the system creates the synchronization file irtrace.shm, which the processes of the application program and IRTRACE use to access the shared memory. The system creates this release-independent file in the directory /opt/sdb/programs/wrk. In the installation, the system registers the path /opt/sdb/programs and creates the subdirectory wrk. The system also gives read and write rights to the IRTRACE tool and the application program.


Displaying the Current Trace Setting (MaxDB: C/C++ Precompiler Manual)

Displaying the Current Trace Setting

Use the IRTRACE tool to display the current trace setting.

To do this, enter the following commands:

· Display the current trace setting for the application program:

irtrace -p <process_id>

· Display overview of trace settings for all application programs where changes have been made with IRTRACE:

irtrace -p all


Changing the Trace Setting (MaxDB: C/C++ Precompiler Manual)

Changing the Trace Setting

You can use the IRTRACE tool to change the current trace setting.

· Activating/deactivating/switching the trace for a specified process:
irtrace -p <process_id> -t <trace_setting>

· Activating or deactivating the trace for all application programs on the local server that have been translated by the precompiler.
irtrace -p all -t <trace_setting>

This table shows the possible values for <trace_setting>:

<long> | Activates logging with option TRACE LONG
<short> | Activates logging with option TRACE SHORT
<off> | Deactivates trace

See also: Trace Options.


Example of a Trace File (MaxDB: C/C++ Precompiler Manual)

Example of a Trace File

PREPARE        :

select name, price into ?, ? from hotel where hno=?

SQL STATEMENT  :  FROM MODULE : docu07             AT LINE : 80

Statement Name : STMT2

PARSEID: OUTPUT:  00000347 00000901 3D001400

START  :  DATE :  2001-11-02    TIME :  0015:40:00

END    :  DATE :  2001-11-02    TIME :  0015:40:00

SQL STATEMENT  :  FROM MODULE : docu07             AT LINE : 80

Statement Name : STMT2

PARSEID: INPUT :  00000347 00000901 3D001400

INPUT :    3: hno                             :                  10

OUTPUT:    1: name                            : Excelsior

OUTPUT:    2: price                           :               135.00

SQLERRD(INDEX_3) : 1

START  :  DATE :  2001-11-02    TIME :  0015:40:00

END    :  DATE :  2001-11-02    TIME :  0015:40:00


Example: Executing an Application Program (MaxDB: C/C++ Precompiler Manual)

Example: Executing an Application Program

You want to execute an application program, test, that you have translated with the C/C++ Precompiler.

If you want a trace file to be written when the test program is executed, set the environment variable SQLOPT to -X. The corresponding command in a Bash shell is as follows:

export SQLOPT=-X

The trace file test.pct is written when the test program is executed. This file is located in the same directory as the test program.

In a Bash shell you can, for example, execute the following command:

export SQLOPT="-d TST -u TEST,TEST"

The result of this is that your application program uses, at runtime, the database instance TST and the user TEST with the password TEST.


Return Codes (MaxDB: C/C++ Precompiler Manual)

Return Codes

The precompiler returns the following return codes:

0 | Precompiler and compiler ran without errors
1 | Precompiler ran with errors
2 | Precompiler ran without errors; compiler ran with errors
3-120 | Number of precompiler errors
126 | Error in precompiler data management
127 | Precompiler called; compiler not yet called

The application program returns the following return codes:

1 | No error
2 | Error when reading the XUSER file
3 | Database instance is not in the operational state ONLINE
4 | Too many database sessions
5 | Unknown combination of user name and password
6 | Application program ended with WHENEVER STOP statement
7 | SQLOPT contains incorrect options
8 | Error when opening or writing to the trace file
9 | Internal data structures inconsistent (system error)


Using the IRCONF Tool (MaxDB: C/C++ Precompiler Manual)

Using the IRCONF Tool

For connections and communication between the database server and the client, the runtime library of the interface programs (such as the precompiler and ODBC) must be installed on the client.

You can update this part of the client software. So that you can continue to use and administer any older applications, the various versions of the runtime library of the interface programs are installed in different directories. The registrations in the system perform these installations automatically.

IRCONF is a tool that you can use to register and display the installed versions of the runtime library of the interface programs at a later time. You do this by entering commands at the operating system level, with your choice of options.


Options for IRCONF (MaxDB: C/C++ Precompiler Manual)

Options for IRCONF

The following options are available when you use the IRCONF tool:

Specifying the installation path | -p <path>
Displaying registered versions of the runtime library | -s
Deleting the registration of the runtime library | -r
Overriding the driver name | -d <CPC_driver>
Registering the version of the runtime library | -i
Overriding the version check | -v <version>
Specifying an additional key | -k <key>
Displaying options and help | -h


Specifying the Installation Path: -p (MaxDB: C/C++ Precompiler Manual)

Specifying the Installation Path: -p

Use

Use the option –p to define the installation path. You only need to specify the root directory here.

After the installation, the runtime library of the interface programs is in a subdirectory of the root directory:

· Windows NT: .\pgm

· UNIX (32 bit): ./lib

The installation saves the runtime library of the interface programs for 64 bit UNIX operating systems in the subdirectory ./lib/lib64.

You can link the option -p with the options -i (Registering the Version of the Runtime Library) and/or -v (Overriding the Version).


Displaying Registered Versions of the Runtime Library: -s (MaxDB: C/C++ Precompiler Manual)

Displaying Registered Versions of the Runtime Library: -s

Use

Use the option -s to display the registered versions of the runtime library of the interface programs on the client.

Syntax

irconf -s

Result

You see the paths and versions of the installed runtime library of the interface programs.

/opt/sdb/interfaces/precompiler/runtime/7400 -> 7.4.00.00
/opt/sdb/interfaces/precompiler/runtime/7501 -> 7.5.01.00


Deleting the Registration of the Runtime Library: -r (MaxDB: C/C++ Precompiler Manual)

Deleting the Registration of the Runtime Library: -r

Use

Use the option –r to delete the registration of a runtime library of the interface programs on the client. Specify the path in which the client installation is located.

Syntax

irconf -r -p <path>

irconf -r -p /opt/sdb/interfaces/precompiler/runtime/7.4

Result

You see a message about the deletion of the registration, including the path and the version of the runtime library of the interface programs.

/opt/sdb/interfaces/precompiler/runtime/7501 -> 7.5.01.00 registration removed


Overriding the Driver Name: -d (MaxDB: C/C++ Precompiler Manual)

Overriding the Driver Name: -d

Use

The driver name is used for finding out versions information about the runtime libraries of the interface programs. The default is libpcr.

The option –d <CPC_driver> is needed for support purposes only.

Syntax

irconf -i -d <CPC_driver>

irconf -i -d <libpcr.old>


Registering the Version of the Runtime Library: -i (MaxDB: C/C++ Precompiler Manual)

Registering the Version of the Runtime Library: -i

Use

Use the option –i to register a version of the runtime library of the interface programs on the client. Use the option -p <path> to specify the path under which this version of the runtime library has been installed.

During registration, the version of the runtime library of the interface programs (Windows NT: libpcr.dll, UNIX: libpcr.so or libpcr.sl) is checked, and the version found by the system is registered. In special cases, you may need to avoid this version check (Overriding the Version: -v).

Syntax

irconf -i -p <path>

irconf -i -p /opt/sdb/interfaces/precompiler /runtime/7501

Result

You see a message about the successful registration, including the path and the version of the installed runtime library of the interface programs.

/opt/sdb/interfaces/precompiler /runtime/7501 -> 7.5.01.00 registered


Overriding the Version Check: -v (MaxDB: C/C++ Precompiler Manual)

Overriding the Version Check: -v

Use

The IRCONF tool attempts to determine the version of the installed runtime library of the interface programs. In special cases, you can use the option -v to override this feature. You can specify this option when you register the version of a runtime library, and then save the version under a version string of your choice.

You want to register a 64 bit version of the runtime library of the interface programs with a 32 bit version of IRCONF. The 32 bit version of IRCONF cannot determine the version of the 64 bit software, and you need to override the feature that determines the version.

In a special support scenario, you need to register the version of the runtime library under another name, and you need to override the feature that determines the version.

Syntax

irconf -i -v <version> -p <path>

Result

You see which version is installed under the specified path.

/usr/sapdb-if/runtime/7501 -> 7.5.01.00


Specifying an Additional Key: -k (MaxDB: C/C++ Precompiler Manual)

Specifying an Additional Key: -k

Use

The registration procedure does not permit two identical versions of the runtime library of the interface programs to be determined uniquely on one server (in different directories). This can be the case if the test system and the production system are both installed on the same server, but the binaries come from different directories.

In this case, use the option –k to name and retrieve the versions. Set the environment variable SAPDBINSTKEY to the value specified in <key>, so that the applications can use the version registered in this key.

Syntax

irconf -i -p <path> -k <key>

irconf -i –p /opt/sdb/interfaces/precompiler/runtime/7401 -k db_instance_name

Result

You see under which path the version specified in <key> was registered.

/opt/sdb/interfaces/precompiler/runtime/7401 -> 7.4.01.00 db_instance_name


Displaying Options and Help: -h (MaxDB: C/C++ Precompiler Manual)

Displaying Options and Help: -h

Use

You can use this option to display a summary of all options possible with IRCONF.

Syntax

irconf -h

Result

You see the following output:

Usage : irconf -i[-v | -d | -p | -k] | -r -p | -s | -h

Options:

-i Registers a version

-r Unregisters a version

-s Displays all installed versions

-v <version> Overrides version number identified by the system

-d <CPC_driver> Default is 'libpcr'

-p <path> Installation path

-k <key> Installation name

-h Displays help


IRCONF Error Messages (MaxDB: C/C++ Precompiler Manual)

IRCONF Error Messages

IRCONF can write the following error messages:

· Invalid option
An invalid option was specified when IRCONF was called.

· Invalid combination of options

· Missing CPC Driver name
Option -d specified without arguments.

· Missing path name
Option -p specified without arguments.

· Missing installation name
Option -k specified without arguments.

· Missing version number
Option -v specified without arguments.

· Cannot get version info of CPC Driver
The version of the runtime library of the interface programs on the client cannot be found.

· The specified driver does not exist
The specified driver does not exist or cannot be loaded.

· Cannot find any installed version of CPC Driver
No installations of the runtime library of the interface programs are registered.

· The specified installation does not exist


Syntax List (MaxDB: C/C++ Precompiler Manual)

Syntax List

This syntax list shows you the syntax of all precompiler statements. The syntax notation used is BNF.

For the syntax of the database statements in the SQL mode INTERNAL, see the Reference Manual.

as_clause

array_statement

cancel_session

cancel_statement

c_function

char_host_var

close_statement

command

connect_option

connect_statement

connect_statement_internal

connect_statement_oracle

cursor_name

database_name

database_server

dbproc_clause

dbproc_name

ddl_statement

declare_clause

declare_cursor_statement

declare_statement

describe_statement

descriptor_name

dml_statement

dyna_parameter

dyna_parameter_list

embedded_sql_statement

exec_command_statement

execute_immediate_statement

execute_statement

fetch_spec

fetch_statement

file_host_var

file_name

float_host_var

for_clause

getval_statement

host_variable

hostvarprefix

include_declare_statement

include_file_statement

include_sqlca_statement

include_statement

ind_clause

indicator_marker

indicator_variable

ind_variable_declarator

int_host_var

key

label

loop_parameter

open_cursor_statement

os_command

os_command_async

os_command_sync

parameter

parameter_list

parameter_marker

precom_version

prepare_statement

putval_statement

result_param

rte_version

session_name

session_number

session_spec

set_serverdb_statement

sqlda_variable

statement_name

statement_source

string_constant

structure_tag

table_clause

trace_line

trace_state

trace_statement

type_declarator

uidpwd

unichar_host_var

using_clause

using_expr

variable_declarator

variable_name

version_statement

whenever_action

whenever_condition

whenever_statement


as_clause (MaxDB: C/C++ Precompiler Manual)

as_clause

<as_clause> ::=
  AS VAR [< variable_declarator >]
| AS TYPE [< type_declarator >]
| AS STRUCT [< structure_tag >]


array_statement (MaxDB: C/C++ Precompiler Manual)

array_statement

< array_statement > ::=
  [< for_clause >] < dml_statement >


cancel_session (MaxDB: C/C++ Precompiler Manual)

cancel_session

<cancel_session> ::=
  < session_number >
| < session_name >
| CURRENT


cancel_statement (MaxDB: C/C++ Precompiler Manual)

cancel_statement

< cancel_statement > ::=
  EXEC SQL CANCEL [< cancel_session >];


c_function (MaxDB: C/C++ Precompiler Manual)

c_function

<c_function> ::=
  < simple_identifier >


char_host_var (MaxDB: C/C++ Precompiler Manual)

char_host_var

< char_host_var > ::=
  <hostvarprefix> < identifier >

(for variables of type chardecspec only)


close_statement (MaxDB: C/C++ Precompiler Manual)

close_statement

<close_statement> ::=
  CLOSE [< cursor_name >]


command (MaxDB: C/C++ Precompiler Manual)

command

<command> ::=
  < string_constant >
| < char_host_var >
| < unichar_host_var >


connect_option (MaxDB: C/C++ Precompiler Manual)

connect_option

<connect_option> ::=
  [ISOLATION LEVEL < unsigned_integer >] [TIMEOUT < unsigned_integer >]


connect_statement (MaxDB: C/C++ Precompiler Manual)

connect_statement

< connect_statement > ::=
  < connect_statement_internal >
| < connect_statement_oracle >


connect_statement_internal (MaxDB: C/C++ Precompiler Manual)

connect_statement_internal

< connect_statement_internal > ::=
  EXEC SQL [< session_number >]
  CONNECT [< user_name > IDENTIFIED BY < password > | < uidpwd >]
  [< connect_option >...] [KEY < key >];


connect_statement_oracle (MaxDB: C/C++ Precompiler Manual)

connect_statement_oracle

< connect_statement_oracle > ::=
  EXEC SQL
  CONNECT [< user_name > IDENTIFIED BY < password > | < uidpwd >]
  AT < session_name > USING < database_server - database_name >
  [< connect_option >...] [KEY < key >];


cursor_name (MaxDB: C/C++ Precompiler Manual)

cursor_name

<cursor_name> ::=
  < result_table_name >
| < char_host_var >
| < unichar_host_var >


database_name (MaxDB: C/C++ Precompiler Manual)

database_name

<database_name> ::=
  < string_constant >
| < char_host_var >


database_server (MaxDB: C/C++ Precompiler Manual)

database_server

<database_server> ::=
  < string_constant >
| < char_host_var >


dbproc_clause (MaxDB: C/C++ Precompiler Manual)

dbproc_clause

<dbproc_clause> ::=
  DBPROC < dbproc_name >


dbproc_name (MaxDB: C/C++ Precompiler Manual)

dbproc_name

<dbproc_name> ::=
  [< owner >.]< procedure_name > [(< parameter_list >)]


ddl_statement (MaxDB: C/C++ Precompiler Manual)

ddl_statement

<ddl_statement> ::=
  < create_table_statement >
| < drop_table_statement >
| < alter_table_statement >
| < rename_table_statement >
| < rename_column_statement >
| < exists_table_statement >
| < create_domain_statement >
| < drop_domain_statement >
| < create_sequence_statement >
| < drop_sequence_statement >
| < create_synonym_statement >
| < drop_synonym_statement >
| < rename_synonym_statement >
| < create_view_statement >
| < drop_view_statement >
| < rename_view_statement >
| < create_index_statement >
| < drop_index_statement >
| < alter_index_statement >
| < rename_index_statement >
| < comment_on_statement >
| < create_trigger_statement >
| < drop_trigger_statement >
| < create_dbproc_statement >
| < drop_dbproc_statement >


declare_clause (MaxDB: C/C++ Precompiler Manual)

declare_clause

<declare_clause> ::=
  < table_clause >
| < dbproc_clause >


declare_cursor_statement (MaxDB: C/C++ Precompiler Manual)

declare_cursor_statement

<declare_cursor_statement> ::=
  EXEC SQL [< session_spec >]
  DECLARE < cursor_name > CURSOR FOR < statement_source >;


declare_statement (MaxDB: C/C++ Precompiler Manual)

declare_statement

< declare_statement > ::=
  EXEC SQL BEGIN DECLARE SECTION;
| EXEC SQL END DECLARE SECTION;


describe_statement (MaxDB: C/C++ Precompiler Manual)

describe_statement

< describe_statement > ::=
  EXEC SQL [< session_spec >] DESCRIBE < statement_name >
  [INTO < descriptor_name > [< using_clause >]];


descriptor_name (MaxDB: C/C++ Precompiler Manual)

descriptor_name

<descriptor_name> ::=
  < sqlda_variable >


dml_statement (MaxDB: C/C++ Precompiler Manual)

dml_statement

<dml_statement> ::=
  < select_statement >
| <select_into_statement> (nur SQL-Modus ORACLE)
| < insert_statement >
| < update_statement >
| < delete_statement >
| < close_statement >
| < putval_statement >
| < getval_statement >
| < call_statement >
| < explain_statement >


dyna_parameter (MaxDB: C/C++ Precompiler Manual)

dyna_parameter

<dyna_parameter> ::=
  < parameter_marker > [< indicator_marker >]


dyna_parameter_list (MaxDB: C/C++ Precompiler Manual)

dyna_parameter_list

<dyna_parameter_list> ::=
  < dyna_parameter ,...>


embedded_sql_statement (MaxDB: C/C++ Precompiler Manual)

embedded_sql_statement

< embedded_sql_statement > ::=
  EXEC SQL [< session_spec >]
| < ddl_statement >;
| < dml_statement >;
| < array_statement >;


exec_command_statement (MaxDB: C/C++ Precompiler Manual)

exec_command_statement

< exec_command_statement > ::=
  EXEC COMMAND < os_command >;


execute_immediate_statement (MaxDB: C/C++ Precompiler Manual)

execute_immediate_statement

< execute_immediate_statement > ::=
  EXEC SQL [< session_spec >] EXECUTE IMMEDIATE < statement_source >;


execute_statement (MaxDB: C/C++ Precompiler Manual)

execute_statement

< execute_statement > ::=
  EXEC SQL [< session_spec >] [< for_clause >]
  EXECUTE < statement_name > [< using_clause >];


fetch_spec (MaxDB: C/C++ Precompiler Manual)

fetch_spec

<fetch_spec> ::=
  FIRST
| LAST
| NEXT
| PREV
| SAME
| POS (< unsigned_integer >)
| POS (< int_host_var >)


fetch_statement (MaxDB: C/C++ Precompiler Manual)

fetch_statement

<fetch_statement> ::=
  EXEC SQL [< session_spec >] [< for_clause >]
  FETCH [< fetch_spec >] [< cursor_name >] < using_clause >;


file_host_var (MaxDB: C/C++ Precompiler Manual)

file_host_var

<file_host_var> ::=
  < hostvarprefix >< identifier >

(nur für Variablen vom Typ vfldecspec erlaubt)


file_name (MaxDB: C/C++ Precompiler Manual)

file_name

<file_name> ::=
  < string_constant >


float_host_var (MaxDB: C/C++ Precompiler Manual)

float_host_var

<float_host_var> ::=
 < hostvarprefix >< identifier >

(for variables of type flpdecspec only)


for_clause (MaxDB: C/C++ Precompiler Manual)

for_clause

<for_clause> ::=
  FOR < loop_parameter >


getval_statement (MaxDB: C/C++ Precompiler Manual)

getval_statement

< getval_statement > ::=
  GETVAL INTO (<parameter_list>)

(For LONG columns only)


host_variable (MaxDB: C/C++ Precompiler Manual)

host_variable

< host_variable > ::=
  < char_host_var >
| < unichar_host_var >
| < int_host_var >
| < float_host_var >


hostvarprefix (MaxDB: C/C++ Precompiler Manual)

hostvarprefix

<hostvarprefix> ::=
  :


include_declare_statement (MaxDB: C/C++ Precompiler Manual)

include_declare_statement

< include_declare_statement > ::=
  EXEC SQL INCLUDE < file_name > < declare_clause >
  [< as_clause >] [< ind_clause >];


include_file_statement (MaxDB: C/C++ Precompiler Manual)

include_file_statement

< include_file_statement > ::=
  EXEC SQL INCLUDE < file_name >;


include_sqlca_statement (MaxDB: C/C++ Precompiler Manual)

include_sqlca_statement

<include_sqlca_statement> ::=
  EXEC SQL INCLUDE SQLCA;


include_statement (MaxDB: C/C++ Precompiler Manual)

include_statement

<include_statement> ::=
  < include_sqlca_statement >
| < include_file_statement >
| < include_declare_statement >


ind_clause (MaxDB: C/C++ Precompiler Manual)

ind_clause

<ind_clause> ::=
  IND [< ind_variable_declarator >] [< structure_tag >]


indicator_marker (MaxDB: C/C++ Precompiler Manual)

indicator_marker

<indicator_marker> ::=
  ?


indicator_variable (MaxDB: C/C++ Precompiler Manual)

indicator_variable

< indicator_variable > ::=
  < int_host_var >


ind_variable_declarator (MaxDB: C/C++ Precompiler Manual)

ind_variable_declarator

<ind_variable_declarator> ::=
  < simple_identifier >


int_host_var (MaxDB: C/C++ Precompiler Manual)

int_host_var

<int_host_var> ::=
  < hostvarprefix >< identifier >

(for variables of type intdecspec only)


key (MaxDB: C/C++ Precompiler Manual)

key

<key> :: =
  < simple_identifier >


label (MaxDB: C/C++ Precompiler Manual)

label

<label> :: =
  < identifier >


loop_parameter (MaxDB: C/C++ Precompiler Manual)

loop_parameter

<loop_parameter> ::=
  < unsigned_integer >
| < int_host_var >


open_cursor_statement (MaxDB: C/C++ Precompiler Manual)

open_cursor_statement

< open_cursor_statement > ::=
  EXEC SQL [< session_spec >] [< for_clause >] OPEN < cursor_name >
  [  USING < parameter_list >
   | USING DESCRIPTOR [< descriptor_name >] [KEEP]
   | INTO < parameter_list >]
   | INTO DESCRIPTOR [< descriptor_name >] [KEEP]];


os_command (MaxDB: C/C++ Precompiler Manual)

os_command

<os_command> ::=
  < os_command_async >
| < os_command_sync >


os_command_async (MaxDB: C/C++ Precompiler Manual)

os_command_async

<os_command_async> ::=
  ASYNC < os_command >


os_command_sync (MaxDB: C/C++ Precompiler Manual)

os_command_sync

<os_command_sync> ::=
  SYNC < os_command > RESULT < result_param >


parameter (MaxDB: C/C++ Precompiler Manual)

parameter

<parameter> ::=
  < host_variable > [< indicator_variable >]


parameter_list (MaxDB: C/C++ Precompiler Manual)

parameter_list

<parameter_list> ::=
  < parameter ,...>


parameter_marker (MaxDB: C/C++ Precompiler Manual)

parameter_marker

<parameter_marker> ::=
  ?


precom_version (MaxDB: C/C++ Precompiler Manual)

precom_version

<precom_version> ::=
  < char_host_var >


prepare_statement (MaxDB: C/C++ Precompiler Manual)

prepare_statement

< prepare_statement > ::=
  EXEC SQL [< session_spec >] PREPARE < statement_name >
  [INTO < descriptor_name > [USING < using_clause >]]
  FROM < statement_source >;


putval_statement (MaxDB: C/C++ Precompiler Manual)

putval_statement

< putval_statement > ::=
  PUTVAL INTO < table_name > [(< column_name >,...)]
  VALUES (< parameter_list >)

(For LONG columns only)


result_param (MaxDB: C/C++ Precompiler Manual)

result_param

<result_param> ::=
  < int_host_var >


rte_version (MaxDB: C/C++ Precompiler Manual)

rte_version

<rte_version> ::=
  < char_host_var >


session_name (MaxDB: C/C++ Precompiler Manual)

session_name

<session_name> ::=
  < string_constant >
| < char_host_var >


session_number (MaxDB: C/C++ Precompiler Manual)

session_number

<session_number> ::=
  1|2|3|4|5|6|7|8|9


session_spec (MaxDB: C/C++ Precompiler Manual)

session_spec

<session_spec> ::=
  < session_number > (SQL-Modus Internal)
| AT < session_name > (SQL-Modus ORACLE)


set_serverdb_statement (MaxDB: C/C++ Precompiler Manual)

set_serverdb_statement

< set_serverdb_statement > ::=
  EXEC SQL [< session number >]
  SET SERVERDB < database_name > [ON < database_server >];


sqlda_variable (MaxDB: C/C++ Precompiler Manual)

sqlda_variable

<sqlda_variable> ::=
  < simple_identifier >


statement_name (MaxDB: C/C++ Precompiler Manual)

statement_name

<statement_name> ::=
  < string_constant >
| < char_host_var >
| < unichar_host_var >


statement_source (MaxDB: C/C++ Precompiler Manual)

statement_source

<statement_source> ::=
  ‘< dml_statement >’
| ‘< ddl_statement >’
| < statement_name >


string_constant (MaxDB: C/C++ Precompiler Manual)

string_constant

<string_constant> ::=
  “< simple_identifier >”
| ‘< simple_identifier >’


structure_tag (MaxDB: C/C++ Precompiler Manual)

structure_tag

<structure_tag> ::=
  < simple_identifier >


table_clause (MaxDB: C/C++ Precompiler Manual)

table_clause

<table_clause> ::=
  TABLE < table_name >


trace_line (MaxDB: C/C++ Precompiler Manual)

trace_line

<trace_line> ::=
  < string_constant >
| < char_host_var >


trace_state (MaxDB: C/C++ Precompiler Manual)

trace_state

<trace_state> ::=
  TRACE ON
| TRACE LONG
| TRACE OFF
| TRACE LINE < trace_line >


trace_statement (MaxDB: C/C++ Precompiler Manual)

trace_statement

<trace_statement> ::=
  EXEC SQL SET TRACE < trace_state >;


type_declarator (MaxDB: C/C++ Precompiler Manual)

type_declarator

<type_declarator> ::=
  < simple_identifier >


uidpwd (MaxDB: C/C++ Precompiler Manual)

uidpwd

<uidpwd> ::=
  < user_name >/< password >


unichar_host_var (MaxDB: C/C++ Precompiler Manual)

unichar_host_var

<unichar_host_var> ::=
  < hostvarprefix >< identifier >

(for variables of type unichardecspec only)


using_clause (MaxDB: C/C++ Precompiler Manual)

using_clause

< using_clause > ::=
  USING < using_expr >
| INTO < using_expr >


using_expr (MaxDB: C/C++ Precompiler Manual)

using_expr

<using_expr> ::=
  < parameter_list >
| DESCRIPTOR [< descriptor_name >]


variable_declarator (MaxDB: C/C++ Precompiler Manual)

variable_declarator

<variable_declarator> ::=
  < simple_identifier >


variable_name (MaxDB: C/C++ Precompiler Manual)

variable_name

<variable_name> ::=
  < simple_identifier >


version_statement (MaxDB: C/C++ Precompiler Manual)

version_statement

<version_statement> ::=
  EXEC SQL VERSION < rte_version >, < precom_version >;


whenever_action (MaxDB: C/C++ Precompiler Manual)

whenever_action

<whenever_action> ::=
  CALL < c_function >
| CONTINUE
| GOTO < label >
| STOP


whenever_condition (MaxDB: C/C++ Precompiler Manual)

whenever_condition

<whenever_condition> ::=
  SQLWARNING
| SQLERROR
| SQLEXCEPTION
| NOT FOUND
| SQLBEGIN
| SQLEND


whenever_statement (MaxDB: C/C++ Precompiler Manual)

whenever_statement

< whenever_statement > ::=
  EXEC SQL WHENEVER < whenever_condition > < whenever_action >;


ODBC Manual

This manual describes the basics and features of the MaxDB ODBC driver. The explanations apply to database systems from version 7.3.01.

To understand this documentation, you require a basic knowledge of the C programming language, knowledge of SQL, and a general knowledge of database systems.

Use

The MaxDB ODBC driver allows access to the MaxDB database system. Data is accessed using the Structured Query Language (SQL).

Depending on the operating system, the MaxDB ODBC driver is both 32 bit- and 64 bit- compatible. It runs on Linux, Microsoft Windows as of Microsoft Windows 95 and all UNIX systems that are supported by the database system.

If the ODBC application is operated on the same host as the database instance, communication takes place using shared memory. Remote access of the ODBC application to the database instance is performed using TCP/IP.

You can download the MaxDB ODBC driver free of charge from the address http://www.mysql.com/products/maxdb/interfaces.html.

For a complete description of the ODBC functions and an ODBC syntax reference, see the Microsoft website (http://www.microsoft.com/data/ODBC) in the ODBC Software Development Kit (SDK) under ODBC Programmer’s Reference.

For general information on the database system, see the documentation Database Administration.


Supported ODBC Versions (MaxDB: ODBC Manual)

Supported ODBC Versions

The MaxDB ODBC driver fulfils the ODBC 3.51 interface specification.

When developing your own applications, note that these differentiate between ODBC 2.x and ODBC 3.x versions. Therefore, use the function SQLSetEnvAttr to set the SQL_ATTR_ODBC_VERSION before you request a connection handle with SQLAllocHandle.


Properties of the MaxDB ODBC driver (MaxDB: ODBC Manual)

Properties of the MaxDB ODBC driver

The functions of the MaxDB ODBC driver are described in more detail for selected areas:

Supported Data Types

Conversion of SQL and C Data Types

Processing SQL Statements

ODBC-API Compatibility

Unicode Support


Supported Data Types (MaxDB: ODBC Manual)

Supported Data Types

The ODBC interface differentiates between the data types made available by the database system (SQL data types) and the data types used in the ODBC application (C data types).

SQL Data Types

C Data Types


SQL Data Types (MaxDB: ODBC Manual)

SQL Data Types

Every database system defines its own SQL data types. An ODBC driver processes only those data types that are defined by the associated database system.

You can use the function SQLGetTypeInfo to determine how an ODBC driver maps the SQL data types of the database system to the ODBC supported data types and to its own driver-specific data types, as well as the specifications for length, decimal places (scale), and the number of valid digits (precision).

The data types defined for the MaxDB database system are in the Reference Manual, in the section Data Type.

MaxDB data types supported by the MaxDB ODBC driver

Character | CHAR, VARCHAR, LONG, CHAR BYTE, VARCHAR BYTE, LONG BYTE
Numeric | DECIMAL, FIXED, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION
Date | DATE, TIME, TIMESTAMP
Other | BOOLEAN, CHAR EBCDIC, VARCHAR EBCDIC


C Data Types (MaxDB: ODBC Manual)

C Data Types

ODBC C data types represent those data types of C variables in which the application data intended for communication with the database is processed.

Relationship Between SQL and C Data Types

fCType | ODBC C Typedef | C Type
SQL_C_CHAR | SQLCHAR * | unsigned char *
SQL_C_SSHORT | SQLSMALLINT | short int
SQL_C_SLONG | SQLINTEGER | long int (32 bit)
SQL_C_USHORT | SQLUSMALLINT | unsigned short int
SQL_C_ULONG | SQLUINTEGER | unsigned long int (32 bit)
SQL_C_FLOAT | SQLREAL | float
SQL_C_DOUBLE | SQLDOUBLE | double
SQL_C_BIGINT | SQLBIGINT | _int64, long (64 bit)
SQL_C_UBIGINT | SQLUBIGINT | unsigned _int64, unsigned long (64 bit)
SQL_C_BINARY | SQLCHAR* | unsigned char*
SQL_C_DATE | SQL_DATE_STRUCT | struct tagDATE_STRUCT { SQLSMALLINT year; SQLSMALLINT month; SQLSMALLINT day;}
SQL_C_TIME | SQL_TIME_STRUCT | struct tagTIME_STRUCT { SQLSMALLINT hour; SQLSMALLINT minute; SQLSMALLINT second;}
SQL_C_TIMESTAMP | SQL_TIMESTAMP_STRUCT | struct tagTIMESTAMP_STRUCT { SQLSMALLINT year; SQLSMALLINT month; SQLSMALLINT day; SQLSMALLINT hour; SQLSMALLINT minute; SQLSMALLINT second; SQLUINTEGER fraction;}
SQL_C_BIT | SQLCHAR | unsigned char


Conversion of SQL and C Data Types (MaxDB: ODBC Manual)

Conversion of SQL and C Data Types

The MaxDB ODBC driver allows conversions for all supported data types.

See also:

The Microsoft website (http://www.microsoft.com/data/ODBC) in the ODBC Software Development Kit (SDK) under ODBC Programmer‘s Reference, Converting Data from SQL to C Data Types and Converting Data from C to SQL Data Types sections.


Processing SQL Statements (MaxDB: ODBC Manual)

Processing SQL Statements

The MaxDB ODBC driver supports the complete ODBC SQL syntax.

For detailed information about the ODBC function calls, see the Microsoft website (http://www.microsoft.com/data/ODBC) in the ODBC Software Development Kit (SDK) under ODBC Programmer‘s Reference, Chapter 8: SQL Statements, Escape Sequences in ODBC, Scalar Functions section.

Numeric functions | ABS, ACOS, ASIN, ATAN, ATAN2, CEILING, COS, COT, DEGREES, EXP, FLOOR, LOG, MOD, SIGN, SIN, SQRT, TAN, TRUNCATE, PI, RADIANS, ROUND
String functions | CONCAT, LCASE, LEFT, LENGTH, LOCATE, LTRIM, REPLACE, RIGHT, RTRIM, SOUNDEX, SUBSTRING, UCASE,
System functions | DBNAME, IFNULL, USERNAME
Time and date functions | CURDATE, CURTIME, DAYNAME, DAYOFMONTH, DAYOFWEEK, DAYOFYEAR, HOUR, MINUTE, MONTH, MONTHNAME, NOW, SECOND, WEEK, YEAR

SELECT {fn MONTH(NOW())} FROM dual

The MaxDB ODBC driver has extensions to the usual SQL syntax in the following areas:

Database Procedures

Cursor Functions


Database Procedures (MaxDB: ODBC Manual)

Database Procedures

Database procedures can be processed as SQL statements.

See also: Reference Manual, section Database Procedure.

The ODBC syntax for procedures does not support return values of functions. Therefore, a specification in the format
{ ? = call ...}
is invalid.


Cursor Functions (MaxDB: ODBC Manual)

Cursor Functions

The MaxDB ODBC driver supports three types of positionable cursors: static, dynamic, and keyset-driven. These differ in the extent to which changes to the database data by the current session or the sessions of other users are visible.

Since MaxDB can lock row-by-row, a user can change data in a table even if another user has also opened parts of this table. The prerequisite for this is that the rows to be changed are outside the part of the table that the other user has opened.
Locks for individual pages or entire tables lead to significantly longer waits than row locks in operation with multiple concurrent users.

Using the function SQLSetPos, an application can execute positioning INSERT, UPDATE, and DELETE statements.


ODBC-API Compatibility (MaxDB: ODBC Manual)

ODBC-API Compatibility

In the MaxDB ODBC driver, all functions can be executed on both Microsoft Windows and UNIX/Linux.

The ODBC API is structured into the areas core, level 1, and level 2.

There is an overview of the functions that are defined for the individual API compatibility levels below.

Core API

Level 1 API

Level 2 API


Core API (MaxDB: ODBC Manual)

Core API

Overview of the functions that are defined in the MaxDB ODBC driver for the core API

Function

Remarks

SQLAllocConnect

-

SQLAllocEnv

-

SQLAllocStmt

-

SQLBindCol

If the length specification pcbValueMax is smaller than the length of a bound LONG column, the MaxDB ODBC driver returns the value SQL_NO_TOTAL for pcbValue. In all other cases, pcbValue specifies the length of the copied bytes.

You can then fetch other parts of this LONG column with the SQLGetData function.

SQLCancel

-

SQLColAttributes

-

SQLConnect

-

SQLDescribeCol

-

SQLDisconnect

-

SQLError

-

SQLExecDirect

-

SQLExecute

-

SQLFetch

-

SQLFreeConnect

-

SQLFreeEnv

-

SQLFreeStmt

-

SQLGetCursorName

Case-sensitive, maximum length 18 characters
Take this into account, for example, with the statement SELECT FOR UPDATE, as identifiers that are not enclosed in quotation marks are automatically converted into uppercase letters.

The MaxDB ODBC driver constructs default values for cursor names in accordance with the following schema:
SQL_CURSOR_nnnn, where nnnn is an internal counter.
SQL_CUR_nnnnnnn, if n >= 10000

SQLNumResultCols

-

SQLPrepare

-

SQLRowCount

Specifies the number of affected rows for all SELECT, INSERT, DELETE statements, and so on.

If no result set was created, the value -1 is displayed for the undeterminable number of affected rows.

SQLSetCursorName

-

SQLTransact

-


Level 1 API (MaxDB: ODBC Manual)

Level 1 API

Overview of the functions that are defined in the MaxDB ODBC driver for the Level 1 API

Function

Remark

SQLBindParameter

If you want to process more than one LONG column with an INSERT, UPDATE, or DELETE statement, and bind the parameters with the attribute SQL_DATA_AT_EXECUTE, note that, for the SQLPutData function, it is only possible to assign the NULL value to one LONG column, at most.
If you want to set more than one LONG column to the NULL value with only one statement, you must bind the columns in the length specification (pcbValue) using the attribute SQL_NULL_DATA. Otherwise, you receive the message
 szSqlState = S1000 SQLCODE =-22002.

SQLColumns

-

SQLDriverConnect

Keyword for the name of the database server: SERVERNODE
Keyword for the name of the database instance: SERVERDB

SQLGetConnectAttr

Remark

SQLGetData

-

SQLGetFunctions

Remark

SQLGetInfo

Remark

SQLGetStmtAttr

-

SQLGetTypeInfo

You can determine the data types supported by the MaxDB database system using the function SQLGetTypeInfo.

The following data types are supported:
CHAR, VARCHAR, DECIMAL, FIXED, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION, DATE, TIME, TIMESTAMP, LONG, CHAR() BYTE, VARCHAR() BYTE, LONG BYTE, BOOLEAN

If the database is configured so that UNICODE characters can be processed, MaxDB also supports the following data types:
CHAR() UNICODE, VARCHAR() UNICODE, LONG UNICODE

SQLParamData

For LONG columns that contain NULL values, see remark for SQLBindParameter

SQLPutData

For LONG columns that contain NULL values, see remark for SQLBindParameter

SQLSetConnectAttr

See SQLGetConnectAttr

SQLSetParam

-

SQLSetStmtAttr

-

SQLSpecialColumns

-

SQLStatistics

-

SQLTables

The MaxDB ODBC driver supports the following table types (szTableType):
ALIAS, RESULT, SNAPSHOT, SYSTEM, SYSTEM TABLE, TABLE, UNLOADED, VIEW


Remarks for SQLGetConnectAttr (MaxDB: ODBC Manual)

Remarks for SQLGetConnectAttr

List of all supported attributes and return codes of the MaxDB ODBC driver

Attributes | Return Codes
SQL_ ATTR_ACCESS_MODE | pvParam = SQL_MODE_READ_WRITE
SQL_ ATTR_AUTOCOMMIT | pvParam = SQL_AUTOCOMMIT_ON
SQL_ATTR_CONNECTION_DEAD |
SQL_ATTR_CURRENT_CATALOG |
SQL_ ATTR_LOGIN_TIMEOUT | pvParam = 15
SQL_ATTR_ODBC_CURSORS |
SQL_ATTR_QUIET_MODE |
SQL_ ATTR_OPT_TRACE | pvParam = SQL_OPT_TRACE_OFF =0
SQL_ ATTR_OPT_TRACEFILE | (The file name set with SQLSetConnectAttr, default value: \SQL.LOG)
SQL_ ATTR_TRANSLATE_LIB |
SQL_ ATTR_TRANSLATE_OPTION | pvParam = 0
SQL_ ATTR_TXN_ISOLATION | pvParam = SQL_TXN_REPEATABLE_READ
SQL_ MODE = SQL_CONNECT_OPT_START + 2 | pvParam = (1 = INTERNAL, 2 = DB2, 3 = ANSI, 4 = ORACLE)


Remark for SQLGetFunctions (MaxDB: ODBC Manual)

Remark for SQLGetFunctions

If the function ID SQL_API_ODBC3_ALL_FUNCTION is specified, the macro SQL_FUNC_EXISTS returns the result TRUE for the following values:

SQL_API_SQLALLOCCONNECT

SQL_API_SQLALLOCENV

SQL_API_SQLALLOCHANDLE

SQL_API_SQLALLOCHANDLESTD

SQL_API_SQLALLOCSTMT

SQL_API_SQLBINDCOL

SQL_API_SQLBINDPARAM

SQL_API_SQLBINDPARAMETER

SQL_API_SQLBROWSECONNECT

SQL_API_SQLBULKOPERATIONS

SQL_API_SQLCANCEL

SQL_API_SQLCLOSECURSOR

SQL_API_SQLCOLATTRIBUTES

SQL_API_SQLCOLUMNPRIVILEGES

SQL_API_SQLCOLUMNS

SQL_API_SQLCONNECT

SQL_API_SQLCOPYDESC

SQL_API_SQLDATASOURCES

SQL_API_SQLDESCRIBECOL

SQL_API_SQLDESCRIBEPARAM

SQL_API_SQLDISCONNECT

SQL_API_SQLDRIVERCONNECT

SQL_API_SQLDRIVERS

SQL_API_SQLENDTRAN

SQL_API_SQLERROR

SQL_API_SQLEXECDIRECT

SQL_API_SQLEXECUTE

SQL_API_SQLEXTENDEDFETCH

SQL_API_SQLFETCH

SQL_API_SQLFETCHSCROLL

SQL_API_SQLFOREIGNKEYS

SQL_API_SQLFREECONNECT

SQL_API_SQLFREEENV

SQL_API_SQLFREEHANDLE

SQL_API_SQLFREESTMT

SQL_API_SQLGETCONNECTATTR

SQL_API_SQLGETCONNECTOPTION

SQL_API_SQLGETCURSORNAME

SQL_API_SQLGETDATA

SQL_API_SQLGETDESCFIELD

SQL_API_SQLGETDESCREC

SQL_API_SQLGETDIAGFIELD

SQL_API_SQLGETDIAGREC

SQL_API_SQLGETENVATTR

SQL_API_SQLGETFUNCTIONS

SQL_API_SQLGETINFO

SQL_API_SQLGETSTMTATTR

SQL_API_SQLGETSTMTOPTION

SQL_API_SQLGETTYPEINFO

SQL_API_SQLMORERESULTS

SQL_API_SQLNATIVESQL

SQL_API_SQLNUMPARAMS

SQL_API_SQLNUMRESULTCOLS

SQL_API_SQLPARAMDATA

SQL_API_SQLPARAMOPTIONS

SQL_API_SQLPREPARE

SQL_API_SQLPRIMARYKEYS

SQL_API_SQLPROCEDURECOLUMNS

SQL_API_SQLPROCEDURES

SQL_API_SQLPUTDATA

SQL_API_SQLROWCOUNT

SQL_API_SQLSETCONNECTATTR

SQL_API_SQLSETCONNECTOPTION

SQL_API_SQLSETCURSORNAME

SQL_API_SQLSETDESCFIELD

SQL_API_SQLSETDESCREC

SQL_API_SQLSETENVATTR

SQL_API_SQLSETPARAM

SQL_API_SQLSETPOS

SQL_API_SQLSETSCROLLOPTIONS

SQL_API_SQLSETSTMTATTR

SQL_API_SQLSETSTMTOPTION

SQL_API_SQLSPECIALCOLUMNS

SQL_API_SQLSTATISTICS

SQL_API_SQLTABLEPRIVILEGES

SQL_API_SQLTABLES

SQL_API_SQLTRANSACT


Remarks for SQLGetInfo (MaxDB: ODBC Manual)

Remarks for SQLGetInfo

List of all attributes and return codes supported by the MaxDB ODBC driver

Attributes

Return Codes

SQL_ACCESSIBLE_PROCEDURES

rgbInfoValue = "N"

SQL_ACCESSIBLE_TABLES

rgbInfoValue = "N"

SQL_ACTIVE_CONNECTIONS

rgbInfoValue = 0

SQL_ACTIVE_STATEMENTS

rgbInfoValue = 32767

SQL_ALTER_TABLE

rgbInfoValue =
  SQL_AT_ADD_COLUMN
| SQL_AT_DROP_COLUMN
| SQL_AT_ADD_COLUMN_DEFAULT
| SQL_AT_ADD_CONSTRAINT
| SQL_AT_ADD_TABLE_CONSTRAINT
| SQL_AT_DROP_COLUMN_CASCADE
| SQL_AT_DROP_COLUMN_DEAFAULT
| SQL_AT_SET_COLUMN_DEFAULT

SQL_BOOKMARK_PERSISTENCE

rgbInfoValue =
  SQL_BP_SCROLL
| SQL_BP_UPDATE

SQL_CATALOG_LOCATION

rgbInfoValue = 1 (SQL_CL_START)

SQL_CATALOG_NAME_SEPARATOR

rgbInfoValue = "."

SQL_CATALOG_TERM

rgbInfoValue = "Qualifier"

SQL_CATALOG_USAGE

rgbInfoValue = 0x00000000

SQL_COLUMN_ALIAS

rgbInfoValue = "Y"

SQL_CONCAT_NULL_BEHAVIOR

rgbInfoValue = 0 (SQL_CB_NULL)

SQL_CONVERT_BIGINT

SQL_CONVERT_BINARY

SQL_CONVERT_BIT

SQL_CONVERT_CHAR

SQL_CONVERT_DATE

SQL_CONVERT_DECIMAL

SQL_CONVERT_DOUBLE

SQL_CONVERT_FLOAT

SQL_CONVERT_FUNCTIONS

rgbInfoValue = 0x00000000L

SQL_CONVERT_INTEGER

SQL_CONVERT_LONGVARBINARY

rgbInfoValue = 0x00000000L

SQL_CONVERT_LONGVARCHAR

SQL_CONVERT_NUMERIC

SQL_CONVERT_REAL

SQL_CONVERT_SMALLINT

SQL_CONVERT_TIME

SQL_CONVERT_TIMESTAMP

SQL_CONVERT_TINYINT

SQL_CONVERT_VARBINARY

SQL_CONVERT_VARCHAR

SQL_CORRELATION_NAME

rgbInfoValue = 2 (SQL_CN_ANY)

SQL_CURSOR_COMMIT_BEHAVIOR

rgbInfoValue =
SQL_CB_PRESERVE
| SQL_CB_DELETED (SQLMode = ANSI)

SQL_CURSOR_ROLLBACK_BEHAVIOR

rgbInfoValue =
SQL_CB_PRESERVE
| SQL_CB_DELETED (SQLMode = ANSI)

SQL_DATA_SOURCE_NAME

rgbInfoValue = (Name of the opened data source)

SQL_DATA_SOURCE_READ_ONLY

rgbInfoValue = "N"

SQL_DBMS_NAME

rgbInfoValue = "SAP DB"

SQL_DBMS_VER

rgbInfoValue = "/07.03.nnn"

SQL_DEFAULT_TXN_ISOLATION

rgbInfoValue = SQL_TXN_READ_COMMITTED

SQL_DRIVER_HDBC

rgbInfoValue = (Handle of the driver logon)

SQL_DRIVER_HENV

rgbInfoValue = (Handle of the driver environment)

SQL_DRIVER_HLIB

rgbInfoValue = (Handle of the library)

SQL_DRIVER_HSTMT

rgbInfoValue = (Handle of the driver statement)

SQL_DRIVER_NAME

rgbInfoValue = "sqlod32.dll", "libsqlod.so" (UNIX)

SQL_DRIVER_ODBC_VER

rgbInfoValue = " 03.51"

SQL_DRIVER_ODBC_VER

rgbInfoValue = (Version of the Driver Manager > 3.51)

SQL_DRIVER_VER

rgbInfoValue = "7.<minor_version>.<correction_level>"

SQL_EXPRESSIONS_IN_ORDERBY

rgbInfoValue = "N"

SQL_FETCH_DIRECTION

rgbInfoValue =
  SQL_FD_FETCH_NEXT
| SQL_FD_FETCH_FIRST
| SQL_FD_FETCH_LAST
| SQL_FD_FETCH_PRIOR
| SQL_FD_FETCH_ABSOLUTE
| SQL_FD_FETCH_RELATIVE
| SQL_FD_FETCH_BOOKMARK

SQL_FILE_USAGE

rgbInfoValue = 0 (SQL_FILE_NOT_SUPPORTED)

SQL_GETDATA_EXTENSIONS

rgbInfoValue =
  SQL_GD_ANY_COLUMN
| SQL_GD_ANY_ORDER
| SQL_GD_ANY_BOUND
| SQL_GD_ANY_BLOCK

SQL_GROUP_BY

rgbInfoValue = SQL_GB_GROUP_BY_CONTAINS_SELECT

SQL_IDENTIFIER_CASE

rgbInfoValue = 1 (SQL_IC_UPPER)

SQL_IDENTIFIER_QUOTE_CHAR

rgbInfoValue = "\""

SQL_INTEGRITY

rgbInfoValue = "N"

SQL_KEYWORDS

rgbInfoValue = (List of key words, dependent on SQLMode)

SQL_LIKE_ESCAPE_CLAUSE

rgbInfoValue = "Y"

SQL_LOCK_TYPES

rgbInfoValue = 1 SQL_LCK_NO_CHANGE

SQL_MAX_BINARY_LITERAL_LEN

rgbInfoValue = 0

SQL_MAX_CATALOG_NAME_LEN

rgbInfoValue = 0

SQL_MAX_CHAR_LITERAL_LEN

rgbInfoValue = 0

SQL_MAX_COLUMN_NAME_LEN

rgbInfoValue = 32

SQL_MAX_COLUMNS_IN_GROUP_BY

rgbInfoValue = 128

SQL_MAX_COLUMNS_IN_INDEX

rgbInfoValue = 16

SQL_MAX_COLUMNS_IN_ORDER_BY

rgbInfoValue = 128

SQL_MAX_COLUMNS_IN_SELECT

rgbInfoValue = 1023

SQL_MAX_COLUMNS_IN_TABLE

rgbInfoValue = 1023

SQL_MAX_CONCURRENT_ACTIVITIES

rgbInfoValue = 32767

SQL_MAX_CURSOR_NAME_LEN

rgbInfoValue = 32

SQL_MAX_DRIVER_CONNECTIONS

rgbInfoValue = 0

SQL_MAX_INDEX_SIZE

rgbInfoValue = 1024

SQL_MAX_OWNER_NAME_LEN

rgbInfoValue = 32

SQL_MAX_PROCEDURE_NAME_LEN

rgbInfoValue = 32

SQL_MAX_QUALIFIER_NAME_LEN

rgbInfoValue = 0

SQL_MAX_ROW_SIZE

rgbInfoValue = 0

SQL_MAX_ROW_SIZE_INCLUDES_LONG

rgbInfoValue = "N"

SQL_MAX_SCHEMA_NAME_LEN

rgbInfoValue = 32

SQL_MAX_STATEMENT_LEN

rgbInfoValue = 0

SQL_MAX_TABLE_NAME_LEN

rgbInfoValue = 32

SQL_MAX_TABLES_IN_SELECT

rgbInfoValue = 64

SQL_MAX_USER_NAME_LEN

rgbInfoValue = 32

SQL_MULT_RESULT_SETS

rgbInfoValue = "Y"

SQL_MULTIPLE_ACTIVE_TXN

rgbInfoValue = "Y"

SQL_NEED_LONG_DATA_LEN

rgbInfoValue = "N"

SQL_NON_NULLABLE_COLUMN

rgbInfoValue = 1 (SQL_NNC_NON_NULL)

SQL_NULL_COLLATION

rgbInfoValue = 1 (SQL_NC_LOW)

SQL_NUMERIC_FUNCTIONS

rgbInfoValue =
  SQL_FN_NUM_ABS
| SQL_FN_NUM_ACOS
| SQL_FN_NUM_ASIN
| SQL_FN_NUM_ATAN
| SQL_FN_NUM_ATAN2
| SQL_FN_NUM_CEILING
| SQL_FN_NUM_COS
| SQL_FN_NUM_COT
| SQL_FN_NUM_EXP
| SQL_FN_NUM_FLOOR
| SQL_FN_NUM_LOG
| SQL_FN_NUM_MOD
| SQL_FN_NUM_SIGN
| SQL_FN_NUM_SIN
| SQL_FN_NUM_SQRT
| SQL_FN_NUM_TAN
| SQL_FN_NUM_PI
| SQL_FN_NUM_DEGREES
| SQL_FN_NUM_RADIANS
| SQL_FN_NUM_ROUND

SQL_ODBC_API_CONFORMANCE

rgbInfoValue = 2 (SQL_OAC_LEVEL2)

SQL_ODBC_SAG_CLI_CONFORMANCE

rgbInfoValue = 1 (SQL_OSCC_COMPLIANT)

SQL_ODBC_SQL_CONFORMANCE

rgbInfoValue = 2 (SQL_OSC_EXTENDED)

SQL_ODBC_SQL_OPT_IEF

rgbInfoValue = "N"

SQL_ODBC_VER

rgbInfoValue = "03.520000"

SQL_ORDER_BY_COLUMNS_IN_SELECT

rgbInfoValue = "N"

SQL_OUTER_JOINS

rgbInfoValue = "Y"

SQL_OWNER_TERM

rgbInfoValue = "Owner"

SQL_OWNER_USAGE

rgbInfoValue =
  SQL_OU_DML_STATEMENTS
| SQL_OU_PROCEDURE_INVOCATION
| SQL_OU_TABLE_DEFINITION
| SQL_OU_INDEX_DEFINITION
| SQL_OU_PRIVILEGE_DEFINITION

SQL_POS_OPERATIONS

rgbInfoValue =
  SQL_POS_UPDATE
| SQL_POS_DELETE
| SQL_POS_ADD (only allowed with dynamic cursors)
| SQL_POS_POSITION
| SQL_POS_REFRESH

SQL_POSITIONED_STATEMENTS

rgbInfoValue =
  SQL_PS_POSITIONED_DELETE
| SQL_PS_POSITIONED_UPDATE
| SQL_PS_SELECT_FOR_UPDATE

SQL_PROCEDURE_TERM

rgbInfoValue = "stored procedure"

SQL_PROCEDURES

rgbInfoValue = "Y"

SQL_QUALIFIER_LOCATION

rgbInfoValue = 1 (SQL_CL_START)

SQL_QUALIFIER_NAME_SEPARATOR

rgbInfoValue = "."

SQL_QUALIFIER_TERM

rgbInfoValue = "Qualifier"

SQL_QUALIFIER_USAGE

rgbInfoValue = 0x00000000

SQL_QUOTED_IDENTIFIER_CASE

rgbInfoValue = 3 (SQL_IC_SENSITIVE)

SQL_ROW_UPDATES

rgbInfoValue = "Y"

SQL_SCHEMA_TERM

rgbInfoValue = "Owner"

SQL_SCHEMA_USAGE

rgbInfoValue =
  SQL_OU_DML_STATEMENTS
| SQL_OU_PROCEDURE_INVOCATION
| SQL_OU_TABLE_DEFINITION
| SQL_OU_INDEX_DEFINITION
| SQL_OU_PRIVILEGE_DEFINITION

SQL_SCROLL_CONCURRENCY

rgbInfoValue =
  SQL_SCCO_READ_ONLY
| SQL_SCCO_LOCK
| SQL_SCCO_OPT_ROWVER
| SQL_SCCO_OPT_VALUES

SQL_SCROLL_OPTIONS

rgbInfoValue =
  SQL_SO_FORWARD_ONLY
| SQL_SO_KEYSET_DRIVEN
| SQL_SO_DYNAMIC
| SQL_SO_STATIC

SQL_SEARCH_PATTERN_ESCAPE

rgbInfoValue = "\"

SQL_SERVER_NAME

rgbInfoValue = (Name of the database server)

SQL_SPECIAL_CHARACTERS

rgbInfoValue = "#@$"

SQL_STATIC_SENSITIVITY

rgbInfoValue = 0x00000000

SQL_STRING_FUNCTIONS

rgbInfoValue =
  SQL_FN_STR_LEFT
| SQL_FN_STR_LTRIM
| SQL_FN_STR_LENGTH
| SQL_FN_STR_LCASE
| SQL_FN_STR_REPLACE
| SQL_FN_STR_RIGHT
| SQL_FN_STR_RTRIM
| SQL_FN_STR_SUBSTRING
| SQL_FN_STR_UCASE
| SQL_FN_STR_SOUNDEX

SQL_SUBQUERIES

rgbInfoValue =
  SQL_SQ_COMPARISON
| SQL_SQ_EXISTS
| SQL_SQ_IN
| SQL_SQ_CORRELATED_SUBQUERIES

SQL_SYSTEM_FUNCTIONS

rgbInfoValue =
  SQL_FN_SYS_USERNAME
| SQL_FN_SYS_DBNAME
| SQL_FN_SYS_IFNULL

SQL_TABLE_TERM

rgbInfoValue = "Table"

SQL_TIMEDATE_ADD_INTERVALS

rgbInfoValue = 0x00000000

SQL_TIMEDATE_DIFF_INTERVALS

rgbInfoValue = 0x00000000

SQL_TIMEDATE_FUNCTIONS

rgbInfoValue =
  SQL_FN_TD_NOW
| SQL_FN_TD_CURDATE
| SQL_FN_TD_DAYOFMONTH
| SQL_FN_TD_DAYOFWEEK
| SQL_FN_TD_DAYOFYEAR
| SQL_FN_TD_MONTH
| SQL_FN_TD_WEEK
| SQL_FN_TD_YEAR
| SQL_FN_TD_CURTIME
| SQL_FN_TD_HOUR
| SQL_FN_TD_MINUTE
| SQL_FN_TD_SECOND
| SQL_FN_TD_DAYNAME
| SQL_FN_TD_MONTHNAME

SQL_TXN_CAPABLE

rgbInfoValue = 2 (SQL_TC_ALL)

SQL_TXN_ISOLATION_OPTION

rgbInfoValue =
  SQL_TXN_READ_UNCOMMITTED
| SQL_TXN_READ_COMMITTED
| SQL_TXN_REPEATABLE_READ
| SQL_TXN_SERIALIZABLE

SQL_UNION

rgbInfoValue =
  SQL_U_UNION
| SQL_U_UNION_ALL

SQL_USER_NAME

rgbInfoValue = (Name of the active user)


Level 2 API (MaxDB: ODBC Manual)

Level 2 API

Overview of the functions that are defined in the MaxDB ODBC driver for the Level 2 API

Function

Remark

SQLBrowseConnect

SQLColumnPrivileges

SQLDataSources (*)

SQLDescribeParam

SQLExtendedFetch

You can only insert rows using the function with the dynamic cursor model (SQL_CURSOR_DYNAMIC). This is not possible with any other cursor models.

UPDATE and DELETE statements are possible both with the static (SQL_CURSOR_STATIC) and with the keyset-driven cursor (SQL_CURSOR_KEYSETDRIVEN) models.

SQLFetchScroll

SQLForeignKeys

SQLMoreResults

The function calls SQLFreeStmt with the attribute SQL_CLOSE to close the previous result set and then returns SQL_NO_DATA_FOUND.

SQLNativeSql

SQLNumParams

SQLParamOptions

SQLPrimaryKeys

SQLProcedureColumns

SQLProcedures

SQLSetPos

All attributes are valid.
The attribute SQL_ADD is only possible in the dynamic cursor model (SQL_CURSOR_DYNAMIC).
Only the attribute SQL_LOCK_NO_CHANGE is permissible for the fLock argument.

SQLSetScrollOptions

SQLTablePrivileges


UNICODE Support (MaxDB: ODBC Manual)

UNICODE Support

The MaxDB ODBC driver supports UNICODE. This means that the functions listed below are also available, irrespective of whether the data source supports UNICODE or not.

On Microsoft Windows, the Driver Manager uses the UNICODE variants of the ODBC API. If, for example, the SQLConnect function is called within the application, SQLConnectW is called in the ODBC driver. The conversions between ASCII and UNICODE are performed by the Driver Manager.

Overview of the functions that are defined in the MaxDB ODBC driver for access to UNICODE data

SQLBrowseConnectW

SQLColAttributesW

SQLColAttributeW

SQLColumnPrivilegesW

SQLColumnsW

SQLConnectW

SQLDataSourcesW

SQLDescribeColW

SQLDriverConnectW

SQLDriversW

SQLErrorW

SQLExecDirectW

SQLForeignKeysW

SQLGetConnectAttrW

SQLGetConnectOptionW

SQLGetCursorNameW

SQLGetDescFieldW

SQLGetDescRecW

SQLGetDiagFieldW

SQLGetDiagRecW

SQLGetInfoW

SQLGetStmtAttrW

SQLGetTypeInfoW

SQLNativeSqlW

SQLPrepareW

SQLPrimaryKeysW

SQLProcedureColumnsW

SQLProceduresW

SQLSetConnectAttrW

SQLSetConnectOptionW

SQLSetCursorNameW

SQLSetDescFieldW

SQLSetStmtAttrW

SQLSpecialColumnsW

SQLStatisticsW

SQLTablePrivilegesW

SQLTablesW


The MaxDB ODBC Driver on Microsoft Windows (MaxDB: ODBC Manual)

The MaxDB ODBC Driver on Microsoft Windows

Installation on Microsoft Windows

Creating Data Sources on Microsoft Windows


Installation on Microsoft Windows (MaxDB: ODBC Manual)

Installation on Microsoft Windows

Use

You have various options for installing the MaxDB ODBC driver on Microsoft Windows:

· As part of the installation profile Server

· As the individual software component ODBC, for example, for client-only installations

These options differ only in the default value of the system for storing the installed software.

If you install the MaxDB ODBC driver as part of the installation profile Server, the system default value for the installation path up to database version 7.3 is the <dependent_data_path>, as of database version 7.4, the <independent_data_path>.

If you install the MaxDB ODBC driver as the separate software component ODBC, the default value for the system is the installation path C:\Program Files\SAP DB\ODBC7x, where x stands for the particular version of the MaxDB ODBC driver.

From Version 7.4, the ODBC software is included in the installation profiles Web Tools and DB Analyzer, as well as the installation profile Server. You can install the entire installation profile, including the ODBC software, or just select the software component ODBC during the installation.

Procedure

Check whether the installation profile Server is already installed on your server. If this is the case, the MaxDB ODBC driver is also already installed, and no further steps are necessary. Otherwise, proceed as follows:

Open the InstallShield Wizard for the MaxDB ODBC driver by double clicking the file odbc7x-setup.exe.

The default value for the installation path is C:\Program Files\SAPDB\ODBC7x. You can change this installation path.

Follow the instructions in the Wizard.

Result

Information about all installed ODBC drivers is stored by the system in the file HKEY_LOCAL_MACHINE/SOFTWARE/ODBC/ODBCINST.INI. A driver-specific key is also created for each ODBC driver, and is also stored in this file.

The following entries are made in the Registry for the MaxDB ODBC driver during the installation:

HKEY_LOCAL_MACHINE
     SOFTWARE\ODBC\ODBCINST.INI
          SAP DB
          SAP DB (Unicode)
          MaxDB
           MaxDB (Unicode)

The names of the ODBC driver DLLS and the name of the setup DLL are stored under each driver-specific key. The ODBC Administrator tool uses this information to load the corresponding DLL when creating new data sources.

The following entry is made under the MaxDB key:

HKEY_CURRENT_USER
     SOFTWARE\ODBC\ODBCINST.INI\MaxDB
        Driver=C:\SAP DB\pgm\sqlod32.dll
        Setup=C:\SAP DB\pgm\sqlsp32.dll


Creating Data Sources on Microsoft Windows (MaxDB: ODBC Manual)

Creating Data Sources on Microsoft Windows

Use

You can create data sources using the ODBC Administrator tool.

The specifications for the data sources are stored by the system in the file HKEY_CURRENT_USER/Software/ODBC/ODBC.INI.

Procedure

...

1. Choose Start ® Settings ® Control Panel ® Administrative Tools ®Data Sources (ODBC). This opens the ODBC Data Source Administrator.

2. Choose Add.

3. From the displayed list of the installed ODBC drivers, choose the entry MaxDB and confirm your choice by choosing Finish.

4. Make the following entries:

Data Source Name | Name of the data source. The data source is identified using this name. Use this name to simplify logging on to the database server. The name of the data source may not contain any special characters.
Description | Description of the data source
Database Name | Name of the database instance
Database Server | Name of the database server. If the database instance and the application are on the same server, you do not need to fill out this field.

5. If you want to specify options for the new data source, choose Settings.
Proceed with the entry of options for data sources.
If you do not want to specify any options, choose OK.
Your entries become effective when the next ODBC connection is created.


Options for Data Sources (Microsoft Windows) (MaxDB: ODBC Manual)

Options for Data Sources (Microsoft Windows)

You can specify various options to influence the way the MaxDB ODBC driver operates. These options become active the next time that you connect to the database server.

The following options are possible:

Option

Remarks

SQL Mode

Selects the database-specific SQL mode

Isolation Level

Overrides the default value of the MaxDB ODBC driver for the lock operation type (the default value is Committed).

Trace On

Activates or deactivates the driver log.
If you have set this option, the MaxDB ODBC driver creates a log of the database session. All SQL statements that the application transfers to the database system are recorded in the log.

 A large number of file operations are performed if you activate logging. This affects the execution speed of the application. You should therefore deactivate logging again after your analysis.

This driver logging is not identical to the Driver Manager log, which you can activate and deactivate in the ODBC Data Source Administrator on the Tracing tab page.


SQL Mode (Microsoft Windows) (MaxDB: ODBC Manual)

SQL Mode (Microsoft Windows)

Use

If you specify the option SQL Mode, you can use the MaxDB ODBC driver in a different SQL mode. This means that the driver can process not only the ODBC and MaxDB-specific SQL syntax, but also the ORACLE or DB2 syntax, for example.

Specifying this option can simplify the way SQL statements are customized during the migration from ODBC applications from other database systems.

For a description of the MaxDB-specific SQL mode INTERNAL, see the Reference Manual, in the section SQL Mode.

Procedure

...

1. Start the ODBC Data Source Administrator by choosing Start ® Settings ® Control Panel ®Administrative Tools ® Data Sources.

2. Choose Add.

3. Choose the MaxDB ODBC driver and then Finish.

4. Specify the name of the data source, the name of the database instance, and the name of the database server. Choose Options.

5. In the SQL Mode field, choose an SQL mode.

6. Confirm the windows until the ODBC Data Source Administrator closes.

r.

Result

The next time that you connect to the database server using this data source, the MaxDB ODBC driver operates in the selected SQL mode.


Isolation Level (Microsoft Windows) (MaxDB: ODBC Manual)

Isolation Level (Microsoft Windows)

Use

MaxDB allows concurrent transactions on database objects. To do this, it uses a lock concept that creates locks on rows and tables to contain individual transactions. The lock operation type plays an important role in this. This is determined by defining an isolation level.

Use the Isolation Level option if you want to change the system default value for the lock operation type (Committed). The value defined in this way then applies for all connections of the data source.

The set lock operation type can be overridden by the application using the function SQLSetConnectAttr and queried with SQLGetConnectAttr.

Overview of the possible lock operation types

 | Dirty Read | Non-Repeatable Read | Phantom Read
Uncommitted | x | x | x
Committed |  | x | x
Repeatable |  |  | x
Serializable |  |  |

The lock operation type Uncommitted corresponds to the weakest isolation level (0), while Serializable corresponds to the strongest isolation level (4).

Procedure

...

1. Start the ODBC Data Source Administrator by choosing Start ® Settings ® Control Panel ® Administrative Tools ® Data Sources.

2. Choose Add.

3. Choose the MaxDB ODBC driver and then Finish.

4. Specify the name of the data source, the name of the database instance, and the name of the database server. Choose Options.

5. In the Isolation Levelfield, select the required lock operation type.

6. Confirm the windows until the ODBC Data Source Administrator closes.

Result

The next time that you connect to the database server using this data source, the MaxDB ODBC driver runs with the selected lock operation type.


Logging SQL Statements (Microsoft Windows) (MaxDB: ODBC Manual)

Logging SQL Statements (Microsoft Windows)

Use

Select the Trace On option for a data source, if you want to log the SQL statements that are sent from the application to the database system. You can set this option for existing data sources or when creating a new data source.

The following data is recorded:

· SQL statement

· Execution time

· Start and end of a session

· CONNECT parameters

· Input and output parameters

Procedure

...

1. Start the ODBC Data Source Administrator by choosing Start ® Settings ® Control Panel ® Administrative Tools ® Data Sources.

2. Choose Add.

3. Choose the MaxDB ODBC driver and then Finish.

4. Specify the name of the data source, the name of the database instance, and the name of the database server, and choose Options.

5. Select the Trace On field or use Browse to choose a file to which you want the log to be written.

6. Confirm the windows until the ODBC Data Source Administrator closes.

Result

The next time that you connect to the database server using this data source, the system logs all SQL statements that are sent by the application to the database system.


Installed Files (Microsoft Windows) (MaxDB: ODBC Manual)

Installed Files (Microsoft Windows)

Overview of the files created during installation and their functions

The files are specified relative to the respective installation directory.
(See also: Installation on Microsoft Windows)

File Name | Description
sql*.dll | Libraries of the MaxDB ODBC driver
odbcreg.exe | Program for entering the driver information in the registry


MaxDB ODBC Driver on UNIX/Linux (MaxDB: ODBC Manual)

MaxDB ODBC Driver on UNIX/Linux

Installation on UNIX/Linux

Creating and Changing Data Sources on UNIX/Linux


Installation on UNIX/Linux (MaxDB: ODBC Manual)

Installation on UNIX/Linux

You have various options for installing the MaxDB ODBC driver:

As part of the installation profile Server

The software for the ODBC driver is stored under the <dependent_data_path> up to database version 7.3 and under the <independent_data_path> as of database version 7.4.

As part of the rpm package for the call interfaces (only for Linux)

The installation program creates the directory /opt/sdb/interfaces/odbc and stores the MaxDB ODBC driver files there.

As the individual software component ODBC (tgz packages)

You can decide the path under which the tgz package unpacks and the software is installed yourself.

From Version 7.4, the ODBC software is included in the installation profiles Web Tools and DB Analyzer, as well as the installation profile Server. You can install the entire installation profile, including the ODBC software, or just select the software component ODBC during the installation.

You can use the MaxDB ODBC driver on UNIX/Linux both with and without a Driver Manager (Integrating the MaxDB ODBC Driver).


Integration of the MaxDB ODBC driver (MaxDB: ODBC Manual)

Integration of the MaxDB ODBC driver

Use

You can use the MaxDB ODBC driver on UNIX/Linux both with and without a Driver Manager.

By entering link commands, you connect the static library libsqlod.a or the dynamic library libsqlod.so with the application. Ensure with dynamic links that the dynamic library libsqlod.so is found by the system at execution time (see, for example, Idconfig, LD_LIBRARY_PATH).

Procedure

Use with a Driver Manager

Using a Driver Manager, such as iODBC or unixODBC simplifies the exchange of ODBC drivers and allows the concurrent use of different ODBC drivers. The relevant documentation describes how you integrate an ODBC driver into the Driver Manager.

Use Without a Driver Manager

If you are not using a Driver Manager, you must use an editor to enter the data for the MaxDB ODBC driver manually, either in the file ~/. odbc.ini or the file /etc/odbc.ini.

Result

The system first uses the valid .odbc.ini file for the respective user from his or her home directory during the assignment of data sources. If no suitable data source is found there, the system evaluates the file /etc/odbc.ini.

Using the ODBC Driver without a Driver Manager

Compiler command:

Compile the ODBC application myapp.c with appropriate ODBC header files

cc –c myapp.c –I<ODBC_include>

Link command for static library:

Static linking of the application myapp

cc –o myapp myapp.o <ODBC_lib>/libsqlod.a

Link command for dynamic library:

Dynamic linking of the application myapp

cc –o myapp myapp.o –L<ODBC_lib> -lsqlod


Creating and Changing Data Sources on UNIX/Linux (MaxDB: ODBC Manual)

Creating and Changing Data Sources on UNIX/Linux

Use

On the UNIX and Linux operating systems, data sources are stored system-specifically in the directory /etc/ in the file odbc.ini or user-specifically in the file ~/ .odbc.ini. To create data sources, edit the required file appropriately.

Procedure

...

1. Open an editor.

2. Open the required file.
Specify the name of the data source, the database server, and the database instance in accordance with the following structure:
You can also specify Options for Data Sources, if you want to change the system default values.

 [<data_source_name>]
ServerDB=<database_name>
ServerNode=<name_of_database_server>
SQLMode=<INTERNAL|DB2|ANSI|ORACLE>
IsolationLevel=<Uncommitted|Committed|Repeatable|Serializable>
TraceFileName=<trace_file_path_and_name>

If you want to specify multiple data sources, repeat the group of specifications above in accordance with the number of data sources.

3. Save your entries.
Your entries become effective when the next ODBC connection is created.


Options for Data Sources (UNIX/Linux) (MaxDB: ODBC Manual)

Options for Data Sources (UNIX/Linux)

You can specify various options to influence the way the MaxDB ODBC driver operates. These options become active the next time that you connect to the database server.

The following options are possible:

Option

Remark

SQLMode

Selects the database-specific SQL mode (default value is INTERNAL)

IsolationLevel

Overrides the default value of the MaxDB ODBC driver for the isolation level (the default value is Committed).

TraceFileName

Activates or deactivates the driver log for logging the SQL statements (Default value: No log is written).

If you have set this option, the MaxDB ODBC driver creates a log of the database session. All SQL statements that the application sends to the database system are recorded in the log.

A large number of file operations are performed if you activate logging. This affects the execution speed of the application. You should therefore deactivate logging again after your analysis.


SQL Mode (UNIX/Linux) (MaxDB: ODBC Manual)

SQL Mode (UNIX/Linux)

Use

By changing the option SQLMode, you can use the MaxDB ODBC driver in a different SQL mode. This means that the driver can process not only the ODBC and MaxDB-specific SQL syntax, but also the ORACLE or DB2 syntax, for example.

The system default value is INTERNAL(see also the Reference Manual, in the section SQL Mode).

If you migrate ODBC applications from other database systems, specifying this option can simplify the way the SQL statements are customized.

Syntax

SQLMode =
  INTERNAL
| DB2
| ANSI
| ORACLE

For a description of the MaxDB-specific SQL mode INTERNAL, see the Reference Manual, in the section SQL Mode.

Procedure

To change the SQLMode option, follow the procedure described under Creating and Changing Data Sources on UNIX/Linux.

The value defined in this way then applies for all connections of the data source.


Isolation Level (UNIX/Linux) (MaxDB: ODBC Manual)

Isolation Level (UNIX/Linux)

Use

MaxDB allows concurrent transactions on database objects. To do this, it uses a lock concept that creates locks on rows and tables to contain individual transactions. The lock operation type plays an important role in this. This is determined by defining an isolation level.

The system default value for the lock operation type is Committed.

The set lock operation type can be overridden by the application using the function SQLSetConnectAttr and queried with SQLGetConnectAttr.

Syntax

IsolationLevel =
  Uncommitted
| Committed
| Repeatable
| Serializable

Overview of the possible lock operation types

 | Dirty Read | Non-Repeatable Read | Phantom Read
Uncommitted | x | x | x
Committed |  | x | x
Repeatable |  |  | x
Serializable |  |  |

The lock operation type Uncommitted corresponds to the weakest isolation level (0), while Serializable corresponds to the strongest isolation level (4).

Procedure

To change the IsolationLeveloption, follow the procedure described under Creating and Changing Data Sources on UNIX/Linux.

The value defined in this way then applies for all connections of the data source.


Logging SQL Statements (UNIX/Linux) (MaxDB: ODBC Manual)

Logging SQL Statements (UNIX/Linux)

Use

The SQL statements sent by the application to the database instance can be logged in a file. The following data is recorded:

· SQL statement

· Execution time

· Start and end of a session

· CONNECT parameters

· Input and output parameters

Only one application can write to a particular log file.

If this option is not set, no log is written (system default value).

Syntax

TraceFileName = <file_name>

<file_name> ::= [<path_name>/]file_identifier

Procedure

To change the TraceFileName option, follow the procedure described under Creating and Changing Data Sources on UNIX/Linux.


Installed Files (UNIX/Linux) (MaxDB: ODBC Manual)

Installed Files (UNIX/Linux)

Overview of the files created during installation and their functions

The files are specified relative to the respective installation directory.
(See also: Installation on UNIX/Linux)

File Name | Description
libsqlod.a, libsqlod.so | Library of the MaxDB ODBC driver
incl/sql.h | ODBC driver header file (Core API)
incl/sqlext.h | ODBC driver header file (Level 1 API and Level 2 API)
incl/sqltypes.h | ODBC driver header file (Data types)
incl/sqlucode.h | ODBC driver header file (UNICODE)
incl/WINDOWS.H | Header file for the UNIX/Linux platforms
demo/eng/ODBC/sqlexamp.c | C example program for an ODBC application
demo/eng/ODBC/sqladhoc.c | C example program for an ODBC application
demo/eng/ODBC/Makefile | Make file for generating a demo program


JDBC Manual

Purpose

This documentation describes the basics and the special features of the MaxDB JDBC driver.

The MaxDB JDBC driver enables you to access the MaxDB database system. Data queries are formulated with Structured Query Language (SQL).

The information in this guide is valid for database systems from Version 7.4. The MaxDB JDBC driver requires Java 1.2, or higher.

To use this documentation effectively, you require a thorough working knowledge of the Java programming language and the JDBC specification.

You can download the MaxDB JDBC driver free of charge from the address http://www.mysql.com/downloads.

For general information on the MaxDB database system, see the documentation Database Administration.

Constraints

This documentation does not provide a description of the JDBC interface. For information about this interface, see http://java.sun.com/products/jdbc.


Properties of the JDBC Driver (MaxDB: JDBC Manual)

Properties of the JDBC Driver

The JDBC driver of the MaxDB database system meets the following conditions:

· 100 Percent pure Java

· Supports JDK 1.2 and higher

· Supports JDBC 2.0 (with JDK 1.2)

· Supports JDBC 3.0 (with JDK 1.4)

· Supports JDBC 2.0 Standard Extension API (DataSource, XADataSource, and ConnectionPoolDataSource)

· Drivers with type 4. This means that the MaxDB-specific network protocol is used to connect to the database system.


Installing the JDBC Driver (MaxDB: JDBC Manual)

Installing the JDBC Driver

Use

You install the MaxDB JDBC driver to access the MaxDB database system. To enable this, you must store the file sapdbc.jar where it can be found by the Java VM.

Procedure

You have three ways of guaranteeing that the Jar file can be found:

· Add the complete path of the file sapdbc.jar to the environment variable CLASSPATH. Enter the following, according to your operating system:

On Microsoft Windows:

set CLASSPATH=%CLASSPATH%;<independent_program_path>\runtime\jar\sapdbc.jar

On UNIX (sh):

CLASSPATH=$CLASSPATH:<independent_program_path>/runtime/jar/sapdbc.jar; export CLASSPATH

· Specify the complete path of sapdbc.jar when you call the Java VM. To do this, use the option -cp:

On Microsoft Windows:

java -cp <independent_program_path>\runtime\jar\sapdbc.jar

On UNIX (sh):

java -cp <independent_program_path>/runtime/jar /sapdbc.jar

· Copy the file sapdbc.jar to the directory for Java libraries. For the Java VM from Sun, enter:
 <java_runtime_dir>/lib/ext


Registering the JDBC Driver (MaxDB: JDBC Manual)

Registering the JDBC Driver

Use

You want to register the MaxDB JDBC driver in the JDBC driver manager.

Procedure

Load the class com.sap.dbtech.jdbc.DriverSapDB.

Syntax

Class.forName ("com.sap.dbtech.jdbc.DriverSapDB");

If an exception of the class java.lang.ClassNotFoundException is raised, this indicates that the JDBC driver has not been installed correctly.

Install the driver again and proceed as described under Installing the JDBC Driver.


Connecting to the Database (MaxDB: JDBC Manual)

Connecting to the Database

Use

You can use JDBC to create a connection to the database by implementing the method java.sql.DriverManager.getConnection.

Here, the following information is essential:

· Database name

· Name and password of the database user

· Name of the database computer, if you are connecting to a remote computer

In addition, you can define other connection options by specifying various properties.

Procedure

Perform the following steps:

...

1. Define the connection URL. This URL contains the name of the database instance, and, if you are connecting to a remote computer, the name of this computer.

2. Specify any other connection options

3. Call the method java.sql.DriverManager.getConnection


Defining the Connection URL (MaxDB: JDBC Manual)

Defining the Connection URL

Use

You use the method java.sql.DriverManager.getConnection to connect to the database instance. You use the url parameter in this method to specify the name of the database computer and the database instance.

Procedure

Define the connection URL. Use the following format:

jdbc:sapdb://<database_server>[:<port>]/<database_name>[<options>]

Parameter | Description
database_server | Name of the database computer
port | Socket port to which you want to connect Specify this port only if the X Server has been configured with a port that is not the system default port.
database_name | Name of the database instance
options | Connection options

Definition of the parameter url for a connection to the database TST on the computer REMOTESERVER

jdbc:sapdb:// REMOTESERVER/TST

Definition of the parameter url for a connection to the database TST on the remote computer REMOTESERVER using the port 9876. (This definition requires the X Server to be configured with the same port.)

jdbc:sapdb://servermachine:9876/TST

Definition of the parameter url for a connection to the database TST on the local computer

jdbc:sapdb:///TST

Definition of the parameter url for a connection to the database TST on the local computer; the SQL mode is ORACLE and a command timeout of 120 seconds is defined:

jdbc:sapdb:///TST?sqlmode=ORACLE&timeout=120:

See also:

Examples for Connecting to the Database


Specifying Other Connection Options (MaxDB: JDBC Manual)

Specifying Other Connection Options

Use

You can use connection options to define the properties of a database instance connection.

Procedure

Usually, an instance of the class java.util.Properties is used to send the connection options to the method java.sql.DriverManager.getConnection.

However, you can also specify these options as part of the connection URL. In this case, you must specify them with the following format:

<name>=<value>[&<name>=<value>...]

You can define the following options:

Option

Description

user

Name of the database user

password

User password

sqlmode

SQL mode
Possible values are ORACLE | INTERNAL
The system default is INTERNAL.

cachelimit

Cache limit of the connection

timeout

Command timeout of the connection (in seconds)

isolation

Isolation level of the connection
In the Java method, you can specify the isolation level either as a character string or an integer, as declared in the class java.sql.Connection. The following character strings are possible: TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE

autocommit

AUTOCOMMIT mode

Possible values:
 on: A COMMIT is performed after every command.
 off: Transactions must be controlled with the methods commit () and rollback ().

The system default is on.

reconnect

RECONNECT mode
Possible values:
 on: The system connects to the database instance again automatically after a command timeout.
 off: There is no automatic new connection.

The system default is on.

trace

Name of the file for the debug output

tracesize

Maximum number of lines in the file for the debug output. If this number is exceeded, the content of the file is overwritten cyclically.

cache

The internal information used by objects in the class java.sql.PreparedStatement is saved in the connection object. If more objects are generated by the same SQL statement in the same class, then this internal information can be used again, and no new request needs to be sent to the database.

Possible values:
 all: All SQL statements are saved.
Or a combination of s (for SELECT), i (for INSERT), u (for UPDATE), d (for DELETE): Only SQL statements of the specified type are saved.

cache=iud

Only INSERT, UPDATE, and DELETE statements are saved.

unicode

The user name, password and SQL statements are sent to the database in UNICODE.

See also:

Examples for Connecting to the Database


Calling the Method java.sql.DriverManager.getConnection (MaxDB: JDBC Manual)

Calling the Method java.sql.DriverManager.getConnection

Use

You can call the method java.sql.DriverManager.getConnection with different parameters. The parameters you choose determine which of the three declarations for this method are used.

Procedures

· The connection options are specified as part of the connection URL:
getConnection (String url, String user, String password)

· The connection options, and the name and password of the database user, are specified as part of the connection URL:
getConnection (String url)

· The connection options, and the name and password of the database user, are specified in an object of the class java.util.Properties:
getConnection (String url)

See also:

Examples for Connecting to the Database


Examples for Connecting to the Database (MaxDB: JDBC Manual)

Examples for Connecting to the Database

The following connection data is used for the examples listed below:

String username = "TESTUSER";

String password = "TEST";

String database_name = "TST";

String server_name = "REMOTESERVER";

String sqlmode = "ORACLE";

Example 1:

Using getConnection (String url, String user, String password)

The connection options are specified as part of the connection URL.

...

Definition of the connection URL:
String url = "jdbc:sapdb://" + server_name + "/" + database_name + "?sqlmode=" + sqlmode;

Content of the variable url:
 "jdbc:sapdb://REMOTESERVER/TST?sqlmode=ORACLE"

Calling the method:
java.sql.Connection conn = java.sql.DriverManager.getConnection (url, username, password);

Example 2:

Using getConnection (String url)

The connection options, and the name and password of the database user, are specified as part of the connection URL.

...

Definition of the connection URL

String url = "jdbc:sapdb://" + server_name + "/" + database_name + "?sqlmode=" + sqlmode

+ "&user=" + username + "&password=" + password;

Content of the variable url:
 "dbc:sapdb://REMOTESERVER"/TST?sqlmode=ORACLE&user=TESTUSER&password=TEST"

Calling the method:

java.sql.Connection conn = java.sql.DriverManager.getConnection (url);

Example 3:

Using getConnection(String url, Properties info)

The connection options, and the name and password of the database user, are specified in an object of the class java.util.Properties.

...

Definition of the connection URL

String url = "jdbc:sapdb://" + server_name + "/" + database_name;

Content of the connection URL

"jdbc:sapdb://REMOTESERVER/TST"

Creating an object of the class java.util.Properties:

java.util.Properties properties = new java.util.Properties ();

Defining the connection options:

properties.setProperty ("user", username);

properties.setProperty ("password", password);

properties.setProperty ("sqlmode", sqlmode);

Calling the method:

java.sql.Connection conn = java.sql.DriverManager.getConnection (url, properties);


Exceptions (MaxDB: JDBC Manual)

Exceptions

Exceptions can be raised in the following classes when errors occur:

com.sap.dbtech.jdbc.exceptions.DatabaseException

Error when executing an SQL statement

com.sap.dbtech.jdbc.exceptions.PrepareException

Error when preparing an SQL statement

com.sap.dbtech.jdbc.translators.ConversionExceptionSapDB

Conversion between Java data types and SQL data types failed

com.sap.dbtech.jdbc.exceptions.JDBCDriverException

The JDBC driver detected an error

com.sap.dbtech.jdbc.exceptions.InvalidArgumentValue

Invalid parameter value sent to a method

com.sap.dbtech.jdbc.exceptions.InvalidColumnException

Invalid column of an object in the class ResultSet accessed

com.sap.dbtech.jdbc.exceptions.NotSupportedException

Feature not supported by current driver

com.sap.dbtech.jdbc.exceptions.ObjectIsClosedException

Object in the class Connection, Statement, or ResultSet accessed after method close called for this object.

com.sap.dbtech.jdbc.exceptions.InternalJDBCError

Error in the internal data of the JDBC driver

All these classes are subclasses of java.sql.SQLException.

This means that, if you want to write JDBC code that is independent of the database product, you do not need to query the above exceptions explicitly in a catch statement. Instead, you only need to query exceptions of the class java.sql.SQLException.


Example for a Database Query (MaxDB: JDBC Manual)

Example for a Database Query

Use the following example to find out how to connect to the database instance and then make simple database queries. The individual steps are listed in the comments in the example.

import java.sql.*;

public class HelloSapDB {

    public static void main (String [] args)

            throws ClassNotFoundException, SQLException

    {

        String dbm_user = "TESTUSER";

        String password = "TEST";

        String database_server = "LOCALSERVER";

        String database_name = "TST";

        /*

         * Register the JDBC driver

         */

        Class.forName ("com.sap.dbtech.jdbc.DriverSapDB");

        /*

         * Define the connection URL

         */

        String url = "jdbc:sapdb://" + database_server + "/" + database_name;

        /*

         * Call the method java.sql.DriverManager.getConnection

         */

        Connection connection = DriverManager.getConnection (url, dbm_user, password);

        /*

         * Make a database query

         */

        Statement stmt = connection.createStatement ();

        ResultSet resultSet = stmt.executeQuery ("SELECT 'hello world' FROM dual");

        resultSet.next ();

        String hello = resultSet.getString (1);

        System.out.println (hello);

        /*

         * Close all objects

         */

        resultSet.close ();

        stmt.close ();

        connection.close ()

    }

}


Database Administration with Java (MaxDB: JDBC Manual)

Database Administration with Java

Use

You can use Java programs for the administration of databases.

For administration purposes, the Java package com.sap.dbtech.powertoys provides you with the Java class com.sap.dbtech.powertoys.DBM. This Java package is included in the software of the JDBC driver.

You use the Java class com.sap.dbtech.powertoys.DBM to connect to the Database Manager program and to send one or more DBM commands to the Database Manager within this session. As a result, you get the return codes of the commands. You then end the connection to the Database Manager.

The return codes of the commands are provided as Java variables, which you can then format easily. When errors occur, exceptions are raised, which you can then catch and handle.

See also:

Connecting to the Database Manager with Java

Executing DBM Commands with Java

Ending the Connection to the Database Manager

Troubleshooting

Example for Querying the Operational State of a Database


Connecting to the Database Manager with Java (MaxDB: JDBC Manual)

Connecting to the Database Manager with Java

Use

For the administration of your database with Java, you first need to connect to the correct version of the DBM Server program of the Database Manager. To do this, you can use one of two different Java methods. The method you choose depends on whether you want to administer an existing database instance or create a new database instance.

If you want to administer an existing database instance, proceed as described under Connecting to the DBM Server of an Existing Database Instance.

If you want to create a new database instance, proceed as described under Connecting to the DBM Server of a Specific Software Version.


Connecting to the DBM Server of an Existing Database Instance (MaxDB: JDBC Manual)

Connecting to the DBM Server of an Existing Database Instance

Use

For the administration of an existing database instance with Java, you need to connect to the DBM Server that matches the software version of this database instance. To set up the connection, you use the Java method DBM.dbDBM.

This method corresponds to the procedure for opening a DBM Server session
( dbmcli -n <database_server> -d <database_name>).

See also: Connecting to the Database Manager

When you execute the DBM commands, proceed as described under Executing DBM Commands with Java.

Syntax

import com.sap.dbtech.powertoys.*;

…

<lvalue> = DBM.dbDBM (<database_server>, <database_name>);

Parameter | Description
lvalue | Expression of the class DBM (such as a variable) to which a value can be assigned
database_server | Name of the database computer
database_name | Name of the database instance

See also:

Example for Displaying the Operational State of a Database


Connecting to the DBM Server of a Specific Software Version (MaxDB: JDBC Manual)

Connecting to the DBM Server of a Specific Software Version

Use

To create a new database instance, you need to set up a connection between the Database Manager and the DBM Server. The DBM Server must have the software version for which you want to create this new database instance. To set up the connection, you use the Java method DBM.dbrootDBM.

This procedure corresponds to the procedure for logging on to the Database Manager with the option –R.
( dbmcli -n <database_server> -R <dependent_path>).

Enter dbmcli inst_enum in the command line to display the paths and version numbers of the software versions installed on your computer.

See also: Connecting to the Database Manager

Prerequisites

To execute the DBM command that creates a database instance, you need the rights of an operating system user for the computer on which you want to create the database instance.

To create a database instance on a remote computer with Microsoft Windows, you also need administration rights for the database computer, as well as the right log on as batch job. For information about the administration of operating system users, see your operating system documentation.

Syntax

import com.sap.dbtech.powertoys.*;

…

<lvalue> = DBM.dbrootDBM (<database_server>, <dependent_path>);

Parameter | Description
lvalue | Expression of the class DBM (such as a variable) to which a value can be assigned
database_server | Name of the database computer If you want to connect to a DBM Server on the local computer, you can specify the value null.
dependent_path | Installation path of the version-specific database software If you specify the value null, a connection is made to the DBM Server with the highest version number.


Executing DBM Commands with Java (MaxDB: JDBC Manual)

Executing DBM Commands with Java

Use

You can use the Java method cmd to execute DBM commands. The parameter cmdString must contain a valid DBM command.

The return code of the method contains the return code of the DBM command.

See also:

Connecting to the Database Manager with Java

Prerequisites

You can execute the majority of the DBM commands only if you have logged on as the DBM operator of the database instance that you want to administer (see Logging on to the Database Manager).

For information on whether the execution of a DBM command requires this logon, see the descriptions of the individual commands in the documentation Database Manager CLI.

Definition of the Method cmd

    public String cmd (String cmdString)

        throws

            com.sap.dbtech.rte.comm .RTEException,

            com.sap.dbtech.powertoys.DBMException;

Example

Using the method cmd to execute the DBM command user_logon (for logging on to the Database Manager) for the user DBMUSER with the password DBM:

String result = session.cmd ("user_logon DBMUSER,DBM");

See also:

Example for Displaying the Operational State of a Database


Ending the Connection to the Database Manager (MaxDB: JDBC Manual)

Ending the Connection to the Database Manager

Use

You want to end the connection to the Database Manager by calling the method release. This method is called implicitly if the Garbage Collector deletes an object in the class DBM.

Syntax

<object_of_class_DBM>.release ();

Example

session.release ();

See also:

Example for Displaying the Operational State of a Database


Troubleshooting (MaxDB: JDBC Manual)

Troubleshooting

Use

If an error occurs in the Database Manager, an exception of the class com.sap.dbtech.powertoys.DBMException is raised.

If you cannot connect to the Database Manager, or if an existing connection is broken, an exception of the class com.sap.dbtech.rte.comm.RTEException is raised.

Example

Using the method cmd to execute the DBM command for displaying the operational state of the database instance. An error message is sent if an exception of the class RTEException or DBMException is raised.

try {

    String result = session.cmd ("db_state");

}

catch (RTEException RTEExc) {

    System.out.println ("connection broken: " + rteExc.toString ());

}

catch (DBMException DBMExc) {

    System.out.println ("command failed: " + dbmExc.toString ());

}


Example for Displaying the Operational State of a Database (MaxDB: JDBC Manual)

Example for Displaying the Operational State of a Database

Use the following example to find out how to connect to the database instance with a Java interface. It then shows you how to execute the DBM command for displaying the operational state of the database instance, and how to end the connection to the Database Manager. The individual steps are listed in the comments in the example.

import com.sap.dbtech.powertoys.*;

import com.sap.dbtech.rte.comm.RTEException;

public class DBMDemo

{

    public

    DBMDemo ()

    {

    }

    public static void main (String [] args)

    {

        DBM session;

        try {

            // End the connection to Database Manager:

// Connect to the DBM Server of an existing database instance

            session = DBM.dbDBM (null, "TST");

        }

        catch (RTEException rteExc) {

            System.out.println ("connect failed: " + rteExc.toString ());

            return;

        }

        try {

            // Execute DBM commands

// Log on as a DBM operator

            session.cmd ("user_logon DBMUSER,DBM");

            // Display the operational state of the database instance

            String result = session.cmd ("db_state");

            System.out.println (result);

        }

        catch (RTEException rteExc) {

            System.out.println ("connection broken: " + rteExc.toString ());

        }

        catch (DBMException dbmExc) {

            System.out.println ("command failed: " + dbmExc.toString ());

        }

        finally {

            try {

                // End the connection to the Database Manager

                session.release ();

            }

            catch (RTEException rteExc) {

                // ignore

            }

        }

    }

}


Loading and Unloading Data with Java (MaxDB: JDBC Manual)

Loading and Unloading Data with Java

Use

You can use the Loader program to control the way you load and unload data with Java programs.

For this purpose, the Java package com.sap.dbtech.powertoys provides you with the Java class com.sap.dbtech.powertoys.Loader. This Java package is included in the software of the JDBC driver.

You can use the Java class com.sap.dbtech.powertoys.Loader to send Loader commands and SQL statements to the Loader program. As a result, you get the return codes of the Loader commands and SQL statements. You then end the connection to the Loader.

The return codes of the commands and statements are provided as Java variables, which you can then format easily. When errors occur, exceptions are raised, which you can then catch and handle.

See also:

Connecting to the Loader with Java

Executing Loader Commands with Java

Ending the Connection to the Loader

Troubleshooting

Example for Creating a Table with Java


Connecting to the Loader with Java (MaxDB: JDBC Manual)

Connecting to the Loader with Java

Use

To load and unload data with Java, first call the Loader Server program. To connect to the database, you then also need to execute the Loader commands USE SERVERDB and USE USER.

You can also call the Loader Server program on a remote computer. When you call the constructor Loader (<loader_server_name>), the Loader Server program is started on the remote computer.
If you specify file names in the Loader commands while connected to this remote computer, then these file names refer to the file system of this computer.

Finally, you can send Loader commands and SQL statements of your choice to the Loader.

Syntax

import com.sap.dbtech.powertoys.*;

…

<lvalue> = new Loader ();

<lvalue> = new Loader (<loader_server_name>);

Parameter | Description
lvalue | Expression of the class Loader (such as a variable) to which a value can be assigned
loader_server_name | Name of the computer on which you want to call the Loader Server program

See also:

Example for Creating a Table with Java


Executing Loader Commands and SQL Statements with Java (MaxDB: JDBC Manual)

Executing Loader Commands and SQL Statements with Java

Use

You can use the Java method cmd to execute Loader commands and SQL statements supported by the Loader. The parameter cmdString must contain a valid Loader command or a valid SQL statement.

The return code of the method contains the return code of the Loader command or SQL statement.

See also:

Connecting to the Loader with Java

Prerequisites

You can execute the commands and SQL statements for loading and unloading data only after setting up a database session successfully. For the prerequisites that you must meet before you can execute Loader commands or SQL statements, see the appropriate descriptions of the commands and statements in the Loader documentation.

Definition of the Method cmd

    public String cmd (String cmdString)

        throws

            com.sap.dbtech.rte.comm .RTEException,

            com.sap.dbtech.powertoys.LoaderException;

Example

Using the method cmd to execute the CREATE TABLE statement for creating the table LOADERTEST:

String result = session.cmd ("CREATE TABLE LOADERTEST ("+ "TESTCOL VARCHAR(20) )");

System.out.println (result);

See also:

Example for Creating a Table with Java (a complete procedure)


Ending the Connection to the Loader (MaxDB: JDBC Manual)

Ending the Connection to the Loader

Use

You want to end the connection to the Loader Server by calling the method release. This method is called implicitly if the Garbage Collector deletes an object in the class Loader.

Syntax

<object_of_class_Loader>.release ();

Example

session.release ();

See also:

Example for Creating a Table with Java


Troubleshooting (MaxDB: JDBC Manual)

Troubleshooting

Use

If an error occurs in the Loader program, an exception of the class com.sap.dbtech.powertoys.LoaderException is raised.

If you cannot connect to the Loader, or if an existing connection is broken, an exception of the class com.sap.dbtech.rte.comm.RTEException is raised.

Example

Executing the SET command with Java
An error message is sent if an exception of the class RTEException or LoaderException is raised.

try {

    String result = session.cmd ("SET MAXERRORCOUNT 0");

}

catch (RTEException rteExc) {

    System.out.println ("connection broken: " + rteExc.toString ());

}

catch (LoaderException loaderExc) {

    System.out.println ("command failed: " + loaderExc.toString ());

}


Example for Creating a Table with Java (MaxDB: JDBC Manual)

Example for Creating a Table with Java

Use the following example to find out how to connect to the database system with the Java interface. It then shows you how to use an SQL statement supported by the Loader to create a table, and how to end the connection with the Loader. The individual steps are listed in the comments in the example.

import com.sap.dbtech.powertoys.*;

import com.sap.dbtech.rte.comm.RTEException;

public class LoaderDemo

{

    public

    LoaderDemo ()

    {

    }

    public static void main (String [] args)

    {

        Loader session;

        try {

            // Connect to the Loader

            session = Loader.dbLoader (null, null);

        }

        catch (RTEException rteExc) {

            System.out.println ("connect failed: " + rteExc.toString ());

            return;

        }

        try {

              // Execute Loader commands:

// Log on to the database instance

            session.cmd ("use serverdb TST");

            session.cmd ("use user TESTUSER TEST");

              // Create a table with Java

            String result = session.cmd ("CREATE TABLE LOADERTEST ("

                + "TESTCOL VARCHAR (20) )");

            System.out.println (result);

        }

        catch (RTEException rteExc) {

            System.out.println ("connection broken: " + rteExc.toString ());

        }

        catch (LoaderException LoaderExc) {

            System.out.println ("command failed: " + LoaderExc.toString ());

        }

        finally {

try {

              // End the connection to the Loader

                session.release ();

            }

            catch (RTEException rteExc) {

                // ignore

            }

        }

    }

}


Perl Manual

This documentation describes the programming interfaces included in the MaxDB database system for the programming of database applications using Perl scripts.

Programming Interface | Available Module | Use
SQL | DBD::ODBC | Freely available module Enables SQL queries to be sent by a program to the database and the processing of results Can be used with the MaxDB ODBC Driver on UNIX and Microsoft Windows See also: http://search.cpan.org/dist/DBD-ODBC/
Database Manager | SAP::DBTech::dbm | Automation of program actions for creating new database instances and administering existing database instances
Loader | SAP::DBTech::loader | Automation of program actions for loading and unloading database schemata and data

This information applies to database systems with Version 7.4 and higher.

To make the best use of this documentation, you require fundamental knowledge of the Perl programming language.

You can download the Perl modules SAP::DBTech::dbm and SAP::DBTech::loader free of charge from the address http://www.mysql.com/downloads/maxdb.html.

Libraries usually exist for other programming languages. These libraries enable the database to be accessed by the MaxDB ODBC driver.

For general information on the MaxDB database system and the database tools Database Manager and Loader, see the documentation Database Administration.


Module SAP::DBTech::dbm (MaxDB: Perl Manual)

Module SAP::DBTech::dbm

Syntax

use SAP::DBTech::dbm;

Use

SAP::DBTech::dbm is a module developed in the Perl programming language for the MaxDB database system. You can use this module in Perl scripts to create new database instances and manage existing database instances.

The module SAP::DBTech::dbm enables you to execute all DBM commands. Unlike executing these commands with the Database Manager CLI, you can handle any errors and generate the DBM commands dynamically at runtime.

Module Content

Class DBM

See also:

Examples for the Module SAP::DBTech::dbm

Troubleshooting for the Module SAP::DBTech::dbm


Class DBM (MaxDB: Perl Manual)

Class DBM

Use

DBM is a class of the module SAP::DBTech::dbm . A single instance of this class corresponds to one connection to a DBM Server .

Class Content

The class DBM contains the following methods:

cmd (cmd_string)

rawCmd (cmd_string)

release ()

Using the Constructor

$session = new DBM ($database_server, $database_name, $dependent_path, $user_info);

Parameter | Description
$database_server | Network name of the server to which you want to connect The system default is the local server.
$database_name | Name of the database instance to which you want to connect This information is optional.
$dependent_path | Installation path of the database software (see also: Variables) This information is optional.
$user_info | A string with the form <user name>,<password> The specified user connects to the program DBM Server. This information is optional.

If there are multiple installations of the database software on your server, you can use the $database_name and $dependent_path parameters to control which version of the DBM Server program is started.

Case 1 – You want to create a new database instance with the latest software installation or you want to display information about the existing database instances and software versions.

Do not specify $database_name or $dependent_path.

The system then starts the DBM Server of the software installation with the highest version number.

Case 2 – You want to administer a specific database instance.

Specify $database_name, but not $dependent_path.

The system then starts the DBM Server that matches the specified database instance.

Case 3 – You want to create a new database instance with a specific software version.

Specify $dependent_path, but not $database_name.

This system then starts the DBM Server of the specified software installation.

Generating a connection object $session to database TST on the current server:

$session = new DBM ('', 'TST', '', 'DBM,DBM');


Method cmd (MaxDB: Perl Manual)

Method cmd

Use

$result = $session->cmd ($cmd_string);

cmd is a method of the class DBM. You use this method to send the DBM command specified under $cmd_stringto the program DBM Server.

Result

The result of the DBM command is returned.

If the DBM Server program registers an error, an exception of the class DBMServError is raised.

Specifying a valid DBM command

$result = session->cmd

('db_state');
print "$result\n";

Output:

State

OFFLINE

Specifying an invalid DBM command

$result = $session->cmd ('invalid command');
print "$result\n";

Output:

Error DBM Server: -24977 ERR_COMMAND: unknown command "invalid" at /opt/sapdb/misc/SAP/DBTech/dbm.pm line 89.

(See also: Method rawCmd)


Method rawCmd (MaxDB: Perl Manual)

Method rawCmd

Use

$result = $session->rawCmd ($cmd_string);

rawCmd is a method of the class DBM. You use this method to send the DBM command specified under $cmd_string to the program DBM Server.

Any errors in the DBM Server do not raise an exception. The return code starts with OK if the command was executed successfully; it starts with ERR if the command failed.

(See also: Method cmd)

Result

The result of the DBM command is returned.

Specifying a valid DBM command

$result = session->rawCmd ('db_state');
print "$result\n";

Output:

OK

State

OFFLINE

Specifying an invalid DBM command

$result = $session->rawCmd ('invalid command');
print "result\n";)

Output:

ERR

-24977,ERR_COMMAND: unknown command "invalid"


Method release (MaxDB: Perl Manual)

Method release

Use

$session->release ();

release is a method of the class DBM. It ends the connection to the program DBM Server.


Examples for the Module SAP::DBTech::dbm (MaxDB: Perl Manual)

Examples for the Module SAP::DBTech::dbm

Generating a connection:

#

# testdbm.pl – Test connection to DBM Server

#

import

SAP::DBTech::dbm;
$session = new DBM ('', '');
$version = $session->cmd ("dbm_version")
print "$version\n";

Starting the database instance:

#

# dbup.pl – Start database instance

#

import SAP::DBTech::dbm;

$database_name = $ARGV

[0];
$session = new DBM ('', database_name, '', 'DBMUSER,DBM');
$session->cmd ('db_online');


Troubleshooting for the Module SAP::DBTech::dbm (MaxDB: Perl Manual)

Troubleshooting for the Module SAP::DBTech::dbm

When errors occur, the methods of the module SAP::DBTech::dbm raise one of the following exceptions:

Exception CommunicationError

Exception DBMServError


Exception CommunicationError (MaxDB: Perl Manual)

Exception CommunicationError

Exceptions of the type CommunicationError are raised if no connection can be made to the DBM Server, or if an existing connection has been broken.

They have the following format:

Communication Error: $message

$message

Text of the error message

You can determine the CommunicationError type of an exception by comparing it with the regular expression Communication Error: (.*).

The DBM Server to which you are trying to connect does not exist:

eval { $session = new DBM

('unknownhost', '');}
if ($@) {
print "$@\n";
}

Output:

Communication Error: unknown host name


Exception DBMServError (MaxDB: Perl Manual)

Exception DBMServError

Exceptions of the type DBMServError are raised if the DBM Server registers an error.

They have the following format:

Error DBM Server: $errorCode $errorSymbol: $message

$errorCode | Number of the error message (see also: the documentation Messages)
$errorSymbol | Short text of the error message
$message | Long text of the error message

You can determine the DBMServError type of an exception by comparing it with the regular expression Error DBM Server: (-?[0-9]+) ([A-Z_]+): (.*).


Module SAP::DBTech::loader (MaxDB: Perl Manual)

Module SAP::DBTech::loader

Syntax

use SAP::DBTech::dbm;

Use

SAP::DBTech::loader is a module developed in the Perl programming language for the MaxDB database system. You can use this module in Perl scripts to load data about the Loader.

The module SAP::DBTech::loader enables you to execute all Loader commands that you can also execute with the Loader tool. It also enables you to react flexibly to errors and generate commands dynamically at runtime.

Module Content

Class Loader

See also:

Examples for the Module SAP::DBTech::loader

Troubleshooting for the Module SAP::DBTech::loader


Class Loader (MaxDB: Perl Manual)

Class Loader

Use

Loader is a class of the module SAP::DBTech::loader. All file names in the Loader commands must be specified for the server on which the Loader Server was started.

A single instance of the class Loader corresponds to one connection to a Loader Server.

However, this does not connect the Loader Server to the database.

To connect the Loader Server to the database, execute the Loader commands USE SERVERDB and USE USER.

Class Content

The class Loader contains the following methods:

cmd (cmd_string)

rawCmd (cmd_string)

sql (cmd_string)

release ()

Using the Constructor

$session = new Loader ($database_server);

Parameter | Description
database_server | Network name of the server to which you want to connect If you do not specify a database_server, a connection is made to the local server.

Generating a connection session to the program Loader Server on the current server:

$session = new Loader ();

Generating a connection session to the program Loader Server on the server remoteserver:

$session =new Loader ('remoteserver');


Method cmd (MaxDB: Perl Manual)

Method cmd

Use

$result = $session->cmd ($cmd_string);

cmd is a method of the class Loader. You use this method to send the Loader command specified under $cmd_string to the program Loader Server.

Result

The result of the Loader command is returned.

If the Loader Server program registers an error, an exception of the type LoaderError is raised.

Specifying a valid Loader command

$result = $session->cmd ('CREATE TABLE testtable1 (colname INTEGER)')
print "result: '$result'\n";

Output:

result: ''

Specifying an invalid Loader command

$result = $session->cmd ('invalid command')
 print "result: '$result'\n";

Output:

Error Loader Server: SQL error -3005 = Invalid SQL statement error position: 1) at /opt/sdb/misc/SAP/DBTech/loader.pm line 89.

(See also: Method rawCmd)


Method rawCmd (MaxDB: Perl Manual)

Method rawCmd

Use

$result = $session->rawCmd ($cmd_string);

rawCmd is a method of the class Loader. You use this method to send the Loader command specified under $cmd_string to the program Loader Server.

Any errors in the Loader Server do not raise an exception. The return code starts with OK if the command was executed successfully; it starts with ERR if the command failed.

(See also: Method cmd)

Result

The result of the Loader command is returned.

Specifying a valid Loader command

$result = $session->cmd ('CREATE TABLE testtable2 (colname INTEGER)')
print "result: '$result'\n";

Output:

result: 'OK

'

Specifying an invalid Loader command

$result = $session->cmd ('invalid command')
print "result: '$result'\n";

Output:

result: 'ERR
-25010
SQL error -3005 = Invalid SQL statement (error position: 1)'


Method sql (MaxDB: Perl Manual)

Method sql

Use

$sqlrc = $session->sql ($cmd_string);

sql is a method of the class Loader. You use this method to send the SQL statement specified under $cmd_string to the program Loader Server.

You can also use the methods cmd or rawCmd to execute SQL statements. However, if exceptions are raised when you do this, you must recognize them yourself, and find the error code in the text of the exception.

Result

If the statement is executed successfully, the value of the result is 0.

If the execution of the statement causes an SQL error, the number of the error message of the SQL statement is returned.

If the execution of the statement causes a Loader error, an exception of the type LoaderError is raised.

Executing a valid SQL statement

print $session->cmd ('CREATE TABLE testtable3 (a integer)');

Output:

0

Executing an invalid SQL statement

print $session->cmd ('invalid command');

The output is the error code of the SQL statement:

3005

Executing an invalid Loader command

print $session->cmd ('dataload invalid spec')

The output is the exception of the Loader Server:

Error Loader Server: Syntax error at position 10 (Unexpected token: invalid). at /opt/sdb/programs/misc/SAP/DBTech/loader.pm line 89.


Method release (MaxDB: Perl Manual)

Method release

Use

$session->release ();

release is a method of the class Loader. It ends the current connection to the program Loader Server.


Examples for the Module SAP::DBTech::loader (MaxDB: Perl Manual)

Examples for the Module SAP::DBTech::loader

Generating a connection

#
 # testloader.pl – Test connection to Loader Server.
 #
 use SAP::DBTech::loader;
$session = new Loader ('', '');
$session->cmd ('use serverdb TST');
$session->cmd ('use user TEST TEST');


Troubleshooting for the Module SAP::DBTech::loader (MaxDB: Perl Manual)

Troubleshooting for the Module SAP::DBTech::loader

When errors occur, the methods of the module SAP::DBTech::loader raise one of the following exceptions:

Exception CommunicationError

Exception LoaderError


Exception CommunicationError (MaxDB: Perl Manual)

Exception CommunicationError

Exceptions of the type CommunicationError are raised if no connection can be made to the Loader Server, or if an existing connection has been broken.

They have the following format:

Communication Error: $message

message

Text of the error message

You can determine the CommunicationError type of an exception by comparing it with the regular expression Communication Error: (.*).

The Loader Server to which you are trying to connect does not exist:

eval { $session = new

Loader ('unknownhost', '');}
if ($@) {
print "$@\n";
}

Output:

Communication Error: unknown host name


Exception LoaderError (MaxDB: Perl Manual)

Exception LoaderError

Exceptions of the type LoaderError are raised if the Loader Server program registers an error.

They have the following format:

Error Loader Server: $message

message

Long text of the error message

You can determine the LoaderErrortype of an exception by comparing it with the regular expression Error Loader Server: (.*).


Python Manual

This documentation describes the programming interfaces included in the MaxDB database system for the programming of database applications using Python scripts.

Programming Interface | Available Module | Use
SQL | sapdb.sql | SQL queries sent by a program to the database; processing of results
Database Manager | sapdb.dbm | Automation by programs of actions for creating new database instances and administering existing database instances
Loader | sapdb.loader | Automation by programs of actions for loading and unloading database schemata and data

This information applies to database systems with Version 7.4 and higher.

To make the best use of this documentation, you require fundamental knowledge of the Python programming language.

You can download the Python modules sapdb.sql, sapdb.dbm and sapdb.loader free of charge from the address http://www.mysql.com/downloads/maxdb.html.

For general information on the MaxDB database system and the database tools Database Manager and Loader, see the documentation Database Administration.

This documentation also contains information on other programming interfaces.


Module sapdb.sql (MaxDB: Python Manual)

Module sapdb.sql

Syntax

import sapdb.sql

Use

You can use the Python module sapdb.sql to access the database system. The data is accessed using Structured Query Language (SQL).

Module Content

Method connect

Class SapDB_Session

Class SapDB_ResultSet

Class SapDB_Prepared

Class SapDB_Result

Troubleshooting for the Module sql


Method connect (MaxDB: Python Manual)

Method connect

Use

connect is a method of the module sapdb.sql. You use this method to generate a database connection.

Definition

connect(database_user, password, database_name [, host [, config]])

Parameter | Description
database_user | Name of the database user (case-sensitive)
password | User password
database_name | Name of the database instance
host | Name of the database host
config | String with additional connection options; has the format keyword=value[&keyword=value]... You can specify the following connection options:
 | Key Word | Value
 | sqlmode | SQL mode INTERNAL | ORACLE The default is INTERNAL.
 | isolation | Isolation level
 | timeout | Maximum period of inactivity for a database session in seconds (see also: Timeout Value)
 | cachelimit | The cache limit of the database session in KB
 | autocommit | Autocommit mode ON | OFF The default value is OFF ON: After each SQL statement, the transaction is ended with a COMMIT. OFF: The user must control the transaction manually with the methods rollback and commit.
 | genericResults | ON | OFF The default value is OFF ON: The methods sql and sqlX of the class SapDB_Session, and the method execute of the class SapDB_Prepared get an object of the class SapDB_Result as a result. This can be useful, for example, for applications where the type of executed SQL is unknown. OFF: The SQL results can differ according to the SQL statement that is executed.
 | component | ODBC | CPC ODBC: The database chooses the SQL variant that is valid for ODBC. CPC: The database chooses the SQL variant that is valid for the Precompiler.

Result

The result is an object of the class SapDB_Session.

The database user TESTUSER with the password TEST generates a connection to the database TST on the current server:

session=sapdb.sql.connect ('TESTUSER', 'TEST', 'TST')

The database user TESTUSER with the password TEST generates a connection to the database TST on the server remoteserver:

session=sapdb.sql.connect ('TESTUSER', 'TEST', 'TST','remoteserver')

The database user TESTUSER with the password TEST generates a connection to the database TST on the server with the IP address 127.0.0.1:

session=sapdb.sql.connect ('TESTUSER', 'TEST', 'TST','127.0.0.1')

The database user TESTUSER with the password TEST generates a connection to the database TST on the current server. The SQL mode is ORACLE and the command timeout is 60 seconds:

session=sapdb.sql.connect ('TESTUSER', 'TEST', 'TST','', 'sqlmode=oracle&timeout=60')


Class SapDB_Session (MaxDB: Python Manual)

Class SapDB_Session

Use

SapDB-Session is a class of the module sapdb.sql. Objects of this class are generated by calling the method connect of the module sapdb.sql. You can use these objects to execute SQL statements.

An object in this class corresponds to a database connection. Once the last connection to this object is deleted, the database connection is ended by a ROLLBACK of the transaction.

Class Content

The class SapDB-Session contains the following methods:

sql (cmd)

sqlX (cmd, parms)

prepare (cmd)

release (withCommit=0)

commit ()

rollback ()


Method sql (MaxDB: Python Manual)

Method sql

Definition

sql (cmd)

Use

sql is a method of the class SapDB_Session. When this method is called, the SQL statement cmd is executed.

Result

The type of the result depends on the content of the SQL statement (see Possible SQL Results).

Executing a data query (for example, SELECT statement)

cursor = session.sql ('SELECT * FROM messages')

The variable cursor contains an object of the class SapDB_ResultSet. You can use this object to access the data records in the results set.

Executing a data manipulation action (for example, a DELETE statement)

rowsDeleted = session.sql ('DELETE FROM testtable WHERE column = 3')

The variable rowsDeleted contains the number of lines deleted by the DELETE statement.


Method sqlX (MaxDB: Python Manual)

Method sqlX

Definition

sqlX (cmd parms = [])

Use

sqlX is a method of the class SapDB_Session. When this method is called, the SQL statement cmd is executed.

The SQL statement cmd can contain the placeholders ? or :<varname> for parameters that the system replaces with values from the parameter list parms.

The method sqlX enables you to execute SQL statements with parameters, without requiring you to create an object of the class SapDB_Prepared first.

Result

The type of the result depends on the content of the SQL statement (see Possible SQL Results).

Executing a data query (for example, SELECT statement)

cursor = session.sql ('SELECT * FROM messages WHERE msgno>?',[0])

The variable cursor contains an object of the class SapDB_ResultSet. You can use this object to access the data records in the results set.

Executing a data manipulation action (for example, a DELETE statement)

rowsDeleted = session.sql ('DELETE FROM testtable WHERE column = ?', [3])

The variable rowsDeleted contains the number of lines deleted by the DELETE statement.


Method prepare (MaxDB: Python Manual)

Method prepare

Definition

prepare (cmd)

Use

prepare is a method of the class SapDB_Session. When you call this method, you send the SQL statement cmd to the database to be checked.

Result

The result is an object of the class SapDB_Prepared.

You can use this object to execute the same SQL statement more than once and with different parameters, without making the database check the syntax and privileges every time. To do this, you use the method execute.

Generating an INSERT statement for inserting data in the table TESTTABLE

insert = session.prepare ('INSERT INTO testtable VALUES (?,?)')

The variable insert contains an object of the class SapDB_Prepared. You can use this object to execute the INSERT statement with different parameters.


Method release (MaxDB: Python Manual)

Method release

Definition

release (with_commit = 0)

Use

release is a method of the class SapDB_Session. When you call this method, you end the current connection to the database instance.

If you specify True for the optional parameter with_commit, the transaction is ended with a COMMIT; otherwise, it is ended with a ROLLBACK.

You can then no longer access the object of the class SapDB_Session.


Method commit (MaxDB: Python Manual)

Method commit

Definition

commit ()

Use

commit is a method of the class SapDB_Session. It ends the current transaction with a COMMIT and starts a new transaction.


Method rollback (MaxDB: Python Manual)

Method rollback

Definition

rollback ()

Use

rollback is a method of the class SapDB_Session. It ends the current transaction with a ROLLBACK and starts a new transaction.


Class SapDB_ResultSet (MaxDB: Python Manual)

Class SapDB_ResultSet

Use

SapDB-ResultSet is a class of the module sapdb.sql. You can use this class to navigate within a results set, and to extract the data from the set.

Class Content

The class SapDB-ResultSet contains the following methods:

next ()

previous ()

relative (offset)

absolute (pos)

first ()

last ()

current ()

__getitem__ (pos)

getDescription ()

Examples for SapDB_ResultSet


Method next (MaxDB: Python Manual)

Method next

Definition

next ()

Use

next is a method of the class SapDB_ResultSet. You use this method to position the cursor on the next record within a results set, to extract this record.

Result

The record is extracted.

If you are at the end of the results set, the value of the result is None.

row = cursor.next ()

See also: Examples for SapDB_ResultSet


Method previous (MaxDB: Python Manual)

Method previous

Definition

previous ()

Use

previous is a method of the class SapDB_ResultSet. You use this method to position the cursor on the previous record within a results set, to extract this record.

Result

The record is extracted.

If you are at the beginning of the results set, the value of the result is None.

row = cursor.previous ()

See also: Examples for SapDB_ResultSet


Method relative (MaxDB: Python Manual)

Method relative

Definition

relative (offset)

Use

relative is a method of the class SapDB_ResultSet. You position the cursor offset records ahead, to extract the record at this position.

relative (1) matches next ().

If you give offset a negative value, the cursor moves back in the results set. In this way, relative (-1) matches previous ().

Result

The record is extracted.

If you specify a value for offset that exceeds the number of records before or after the current cursor position, then the value of the result is None.

row = cursor.relative (5)

row = cursor.relative (-1)

See also: Examples for SapDB_ResultSet


Method absolute (MaxDB: Python Manual)

Method absolute

Definition

absolute (pos)

Use

absolute is a method of the class SapDB_ResultSet. You use this method to position the cursor on the record with the position pos in the results set, to extract the record.

The first record has the position 1.

A negative pos refers to the end of the results set. This means that when you specify absolute (-1), you get the last record in the results set.

Result

The record is extracted.

If you specify a value for pos that exceeds the number of records in the results set, then the value of the result is None.

row = cursor.absolute (3)

See also: Examples for SapDB_ResultSet


Method first (MaxDB: Python Manual)

Method first

Definition

first ()

Use

first is a method of the class SapDB_ResultSet. You use this method to position the cursor on the first record of the results set, to extract the record.

Result

The record is extracted.

If the results set is empty, the value of the result is None.

row = cursor.first ()

See also: Examples for SapDB_ResultSet


Method last (MaxDB: Python Manual)

Method last

Definition

last ()

Use

last is a method of the class SapDB_ResultSet. You use this method to position the cursor on the last record of the results set, to extract the record.

Result

The record is extracted.

If the results set is empty, the value of the result is None.

row = cursor.last ()

See also: Examples for SapDB_ResultSet


Method current (MaxDB: Python Manual)

Method current

Definition

current ()

Use

current is a method of the class SapDB_ResultSet. You use this method to extract the record at the current cursor position in the results set.

Result

The record is extracted.

If the cursor is positioned before the first record, or after the last record, then the value of the result is None.

row = cursor.current ()

See also: Examples for SapDB_ResultSet


Method __getitem__ (MaxDB: Python Manual)

Method __getitem__

Definition

__getitem__ (pos)

Use

getitem is a method of the class SapDB_ResultSet. You use this method to position the cursor on the record at position pos in the results set, and extract the record. The first record has the position 0.

This method enables you to iterate across all records of a result set in a for loop.

Result

The record is extracted.

If you specify a value for pos that exceeds the number or records in the results set, then the value of the result is None.

You iterate across the entire results set:

for msgno, language, message in session.sql ('SELECT * FROM messages'):
    print msgno, language, message


Method getDescription (MaxDB: Python Manual)

Method getDescription

Definition

getDescription ()

Use

getDescription is a method of the class SapDB_ResultSet. You can use this method to extract information about the columns of a results set.

Result

This method gets a description of the results set.

Each tuple of the result contains the following values:

· Name of the column

· Type of the column as a string

· Type of the column as an integer

These figures have the same meaning as they do in the ODBC specification.

· Logical size of the column

· Number of decimal places

· Indicator that specifies whether the column can contain NULL

· String OUT

Generating a results set and the formatted output of the column descriptions

cursor = session.sql ("SELECT * FROM messages")
print "colname    typename   code length frac  null? in/out"
print "===================================================="
for columnDescription in cursor.getDescription ():
    print "%-10s %-10s %4d %6d   %2d  %5s %s" % columnDescription

colname    typename   code length frac  null? in/out
====================================================
MSGNO      Fixed         3      5    0   None OUT
LANGUAGE   Char          1      3    0   None OUT
MSGTEXT    Unicode       1     80    0      1 OUT


Examples for SapDB_ResultSet (MaxDB: Python Manual)

Examples for SapDB_ResultSet

Generating a table and filling the table with data

session.sql ('CREATE TABLE cursortest (A INT KEY)')

insert = session.prepare ('INSERT INTO cursortest (A) VALUES (?)')

for i in xrange (1, 11):

    insert.execute ([i])

Generating a results set

cursor = session.sql ('SELECT A FROM cursortest ORDER BY A')

The cursor is positioned before the first record.

You position the cursor on the next record (the first record, initially), and display this record:

>>> cursor.next ()

(1,)

You position the cursor on the next record and display this record:

>>>cursor.next ()

(2,)

You position the cursor on the previous record and display this record:

>>> cursor.previous ()

(1,)

You move the cursor five records ahead and display this record:

>>> cursor.relative (5)

(6,)

You move the cursor one record back and display this record:

>>>cursor.relative (-1)

(5,)

You position the cursor on the third record of the results set and display this record:

>>> cursor.absolute (3)

(3,)

You position the cursor on the third last record of the results set and display this record:

>>>cursor.absolute (-3)

(8,)

You position the cursor on the first record of the results set and display this record:

>>> cursor.first ()

(1,)

You position the cursor on the last record of the results set and display this record:

>>> cursor.last ()

(10,)

You display the record on which the cursor is currently positioned:

>>> cursor.current ()

(10,)

You iterate across the entire results set:

>>> for row in cursor: print row,

(1,) (2,) (3,) (4,) (5,) (6,) (7,) (8,) (9,) (10,)


Class SapDB_Prepared (MaxDB: Python Manual)

Class SapDB_Prepared

Use

SapDB-Prepared is a class of the module sapdb.sql. You can use this class to execute an SQL statement multiple times with different parameters. This has the following advantages:

· The database only needs to check the syntax and privileges once.

· The application does not need to convert the parameters into a format that matches the SQL syntax. This means that any special characters do not need special handling.

You use the method prepare (of the class SapDB_Session) to generate objects of this class

Class Content

The class SapDB_Prepared contains the following methods:

execute (sqlParms = [])

getDescription ()


Method execute (MaxDB: Python Manual)

Method execute

Definition

execute (sqlParms = [])

Use

execute is a method of the class SapDB_Prepared. This method executes the statement with the parameters specified in parameterlist.

In the parameter list, enter only input parameters. If the executed statement gets output parameters, then the method returns them as a tuple.

Result

The type of the result depends on the content of the SQL statement (see Possible SQL Results).

Example 1: Executing a data query

select = session.prepare ('SELECT * FROM messages WHERE msgno = ?')
select.execute ([300])

Result

<SapDB_ResultSet object at …>

Example 2: Calling a stored procedure

Generating a stored procedure

session.sql ("""CREATE DBPROC paramdemo (
IN    p1 FIXED (5),
INOUT p2 FIXED,
OUT   p3 FLOAT)
AS BEGIN
SET p2 = 2;
SET p3 = 3.0;
END;""")

Generating an object of the class SapDB_Prepared for calling a stored procedure

call = session.prepare ('call paramdemo (?, ?, ?)')
in1 = 1    # sets p1
in2 = 2    # set p2

Calling the stored procedure and getting the output parameters

out2, out3 = call.execute ([in1, in2])
print 'value p2:', out2
print 'value p3:', out3

Result

value p2: 2
value p3: 3.0


Method getDescription (MaxDB: Python Manual)

Method getDescription

Definition

getDescription ()

Use

getDescription is a method of the class SapDB_Prepared. You can use this method to extract information about the parameters of an SQL statement.

Result

Each tuple of the result contains the following values:

· Empty string as a placeholder for the name of the parameter

· Type of the parameter as a string

· Type of the parameter as an integer (as with ODBC)

These figures have the same meaning as they do in the ODBC specification.

· Logical size of the parameter

· Number of decimal places

· Indicator that specifies whether the parameter can be NULL

· String 'IN' | 'OUT' | 'IN/OUT'

Generating a stored procedure

session.sql ("""CREATE DBPROC paramdemo (
IN    p1 FIXED (5),
INOUT p2 FIXED,
OUT   p3 FLOAT)
AS BEGIN
SET p2 = 2;
SET p3 = 3.0;
END;""")

Generating an object of the class SapDB_Prepared for calling a stored procedure

call = session.prepare ('call paramdemo (?, ?, ?)')

Formatting of the output of the parameter description

print "colname    typename   code length frac  null? in/out"
print "===================================================="
for parameterDescription in call.getDescription ():
    print "%-10s %-10s %4d %6d   %2d  %5s %s" % parameterDescription

colname    typename   code length frac  null? in/out
====================================================
           Fixed         3      5    0      1 IN
           Fixed         3      5    0      1 IN/OUT
           Float         6     16    0      1 OUT


Class SapDB_Result (MaxDB: Python Manual)

Class SapDB_Result

Use

SapDB-Result is a class of the module sapdb.sql.

SQL statements can deliver varying results (see also: Possible SQL Results). You can use the methods in this class to send targeted queries about the type of the results.

Class Content

The class SapDB-Result contains the following methods:

getResultSet()

getOutputParameters()

getRowsAffected()

getLastSerial()

getFirstSerial()


Method getResultSet (MaxDB: Python Manual)

Method getResultSet

Definition

getResultSet ()

Use

getResultSet is a method of the class SapDB_Result. You call this method to extract the results set generated by an SQL statement.

Result

If the statement generated a results set, the method returns an object of the class SapDB_ResultSet. Otherwise, the value of the result is None.


Method getOutputParameters (MaxDB: Python Manual)

Method getOutputParameters

Definition

getOutputParameters ()

Use

getOutputParameters is a method of the class SapDB_Result. You call this method to extract the output parameters of an SQL statement.

Result

If output parameters are generated, this method returns a tuple with these output parameters. Otherwise, the value of the result is None.


Method getRowsAffected (MaxDB: Python Manual)

Method getRowsAffected

Definition

getRowsAffected ()

Use

getRowsAffected is a method of the class SapDB_Result.

You can use this method to query how many rows have been changed by an SQL statement.

Result

The method returns the number of modified rows.


Method getLastSerial (MaxDB: Python Manual)

Method getLastSerial

Definition

getLastSerial ()

Use

getLastSerial is a method of the class SapDB_Result.

You can use an SQL statement to enter multiple records in a table. If a table contains a column with the data type SERIAL, you can use this method to query the last value generated for this column.

Result

You get the queried value.

If no value with the data type SERIAL is generated, the value of the result is None.


Method getFirstSerial (MaxDB: Python Manual)

Method getFirstSerial

Definition

getFirstSerial ()

Use

getFirstSerial is a method of the class SapDB_Result.

You can use an SQL statement to enter multiple records in a table. If the table contains a column with the data type SERIAL, you can use this statement to generate multiple values for this column. You can query the first of these values with the method getFirstSerial.

(See also: Method getLastSerial)

Result

You get the queried value.

If no value with the data type SERIAL is generated, the value of the result is None.


Class SapDB_LongReader (MaxDB: Python Manual)

Class SapDB_LongReader

Use

SapDB-LongReader is a class of the module sapdb.sql. You can use this class to read the content of a LONG column sequentially.

Objects of the class SapDB_LongReader are generated by results sets that contain one or more columns of the type LONG.

Class Content

The class SapDB-LongReader contains the following method:

read (count = -1)


Method read (MaxDB: Python Manual)

Method read

Definition

read (count = -1)

Use

read is a method of the class SapDB_LongReader. It returns the next count character of the LONG value.

If you call this method without parameters, you get the remainder of the LONG value.

When the end of a LONG value is reached, you get an empty string.

For this reason, objects of the class SapDB_LongReader can be used like file objects.


Troubleshooting for the Module sapdb.sql (MaxDB: Python Manual)

Troubleshooting for the Module sapdb.sql

When errors occur, the methods of the module sapdb.sql raise one of the following exceptions:

Class CommunicationError

Class SQLError


Class CommunicationError (MaxDB: Python Manual)

Class CommunicationError

Exceptions of the class CommunicationError are raised if no connection can be made to the database instance, or if an existing connection has been broken.

Instances of the class CommunicationError have the following attributes:

Attribute | Description
errorCode | Error code
message | Text of the error message


Class SQLError (MaxDB: Python Manual)

Class SQLError

Exceptions of the class SQLError are raised if an error occurs when an SQL statement is executed.

Instances of the class SQLError have the following attributes:

Attribute | Description
errorCode | Number of the database-specific error message (see also: the documentation Messages)
sqlState | Standardized error code
message | Text of the error message
errorPos | For an error in the SQL statement: Position of the error in the SQL statement For an error in the execution of the SQL statement: Position number of the parameter with the error (first parameter = 0)


Possible SQL Results (MaxDB: Python Manual)

Possible SQL Results

Depending on the content of the SQL statement, you get different results when you execute the methods of the module sapdb.sql.

SQL Statement | Result
SELECT | An object of the class SapDB_ResultSet
UPDATE, DELETE | The number of modified or deleted records (an integer)
INSERT | An object of the class SapDB_Result, if the table in which records are being inserted contains a column with the type SERIAL Otherwise, the number of inserted records (an integer)
CALL | Output parameters, if the stored procedure gets output parameters, or an object of the class SapDB_ResultSet, if the stored procedure gets a results set, or an object of the class SapDB_Result, if the stored procedure gets both output parameters and a results set
DDL | None


Module sapdb.dbm (MaxDB: Python Manual)

Module sapdb.dbm

Syntax

import sapdb.dbm

Use

You can use the Python module sapdb.dbm to create new database instances or to manage existing database instances with DBM commands.

Module Content

Class DBM

Troubleshooting for the Module dbm


Class DBM (MaxDB: Python Manual)

Class DBM

Use

DBM is a class of the module sapdb.dbm. A single instance of this class corresponds to one connection to a DBM Server.

Class Content

The class DBM contains the following methods:

cmd (cmd_string)

rawCmd (cmd_string)

release ()

Definition of the Constructor

DBM (database_server = '', database_name = '', dependent_path = '', user_info = '')

Parameter | Description
database_server | Network name of the server to which you want to connect The system default is the local server.
database_name | Name of the database instance to which you want to connect This information is optional.
dependent_path | Installation path of the database software (see also: Variables) This information is optional.
user_info | A string with the form <user name>,<password> The specified user connects to the program DBM Server.

If there are multiple installations of the database software on your server, you can use the database_name and dependent_path parameters to control which version of the DBM Server program is started.

Case 1 – You want to create a new database instance with the latest software installation or you want to display information about the existing database instances and software versions.

Do not specify database_name or dependent_path.

The system then starts the DBM Server of the software installation with the highest version number.

Case 2 – You want to administer a specific database instance.

Specify database_name, but not dependent_path.

The system then starts the DBM Server that matches the specified database instance.

Case 3 – You want to create a new database instance with a specific software version.

Specify dependent_path, but not database_name.

The system then starts the DBM Server of the specified software installation.

Generating a connection object session to database TST on the current server:

session = sapdb.dbm.DBM ('', 'TST', '', 'DBM,DBM')

Generating a connection object session to the server remoteserver and selecting the DBM Server from the software installation in the directory /usr/local/sdb/7500:

session = sapdb.dbm.DBM ('remoteserver', '', '/usr/local/sdb/7500')

Generating a connection object session to the DBM Server of the latest software installation on the current server:

session = sapdb.dbm.DBM ('', '')


Method cmd (MaxDB: Python Manual)

Method cmd

Definition

cmd (cmd_string)

Use

cmd is a method of the class DBM. You use this method to send the DBM command specified under cmd_string to the program DBM Server.

Result

The result of the DBM command is returned.

If the DBM Server program returns an error, an exception of the class DBMServError is raised.

Specifying a valid DBM command

result = session.cmd ('db_state')
print repr (result)

Output:

'State\nOFFLINE\n'

Specifying an invalid DBM command

result = session.cmd ('invalid command')
print repr (result)

Output:

Traceback (innermost last):
dbm.DBMServError: [-24977] unknown command "invalid"

(See also: Method rawCMD)


Method rawCmd (MaxDB: Python Manual)

Method rawCmd

Definition

rawCmd (cmd_string)

Use

rawCmd is a method of the class DBM. You use this method to send the DBM command specified under cmd_string to the program DBM Server.

Errors returned by the DBM Server do not raise an exception. The return code starts with OK if the command was executed successfully; it starts with ERR if the command failed.

(See also: Method cmd)

Result

The result of the DBM command is returned.

Specifying a valid DBM command

result = session.rawCmd ('db_state')
print repr (result)

Output:

'OK\nState\nOFFLINE\n'

Specifying an invalid DBM command

result = session.rawCmd ('invalid command')
print repr (result)

Output:

'ERR\n-24977,ERR_COMMAND: unknown command "invalid"\n'


Method release (MaxDB: Python Manual)

Method release

Definition

release ()

Use

release is a method of the class DBM. It ends the connection to the program DBM Server.


Examples for the Module sapdb.dbm (MaxDB: Python Manual)

Examples for the Module sapdb.dbm

Generating a connection

#

# testdbm.py – Test connection to DBM Server

#

import sapdb.dbm
session = sapdb.dbm.DBM ('', '')
version = session.cmd ("dbm_version")
print version

Starting the database instance

#

# dbup.py – Start the database instance

#

import sys
import sapdb.dbm
_database_name = sys.argv [1]
session = sapdb.dbm.DBM ('', _database_name, '', 'DBM,DBM')
session.cmd ('db_online')


Troubleshooting for the Module sapdb.dbm (MaxDB: Python Manual)

Troubleshooting for the Module sapdb.dbm

When errors occur, the methods of the module sapdb.dbm raise one of the following exceptions:

Class CommunicationError

Class DBMServError


Class CommunicationError (MaxDB: Python Manual)

Class CommunicationError

Exceptions of the class CommunicationError are raised if no connection can be made to the DBM Server, or if an existing connection has been broken.

Instances of the class CommunicationError have the following attributes:

Attribute | Description
errorCode | Error code
message | Text of the error message

The DBM Server to which you are trying to connect does not exist:

try:
    session = sapdb.dbm.DBM ('unknownhost', '')
except sapdb.dbm.CommunicationError, err:
    print err
    print err.message

Output:

dbm.CommunicationError: [-4] unknown host name
unknown host name


Class DBMServError (MaxDB: Python Manual)

Class DBMServError

Exceptions of the class DBMServError are raised if the DBM Server registers an error.

Instances of the class DBMServError have the following attributes:

Attribute | Description
errorCode | Number of the error message (see also: the documentation Messages)
errorSymbol | Short text of the error message
message | Long text of the error message
additionalInfo | Text with additional information
cmd | DBM command that caused the error


Module sapdb.loader (MaxDB: Python Manual)

Module sapdb.loader

Syntax

import sapdb.loader

Use

You can use the Python module loader to load database schemata and data into the database, or unload them from the database.

Module Content

Class Loader

Troubleshooting for the Module sapdb.loader


Class Loader (MaxDB: Python Manual)

Class Loader

Use

Loader is a class of the module sapdb.loader. All file names in the Loader commands must be specified for the server on which the Loader Server was started.

A single instance of the class Loader corresponds to one connection to a Loader Server.

However, this does not connect the Loader Server to the database.

To connect the Loader Server to the database, execute the Loader commands USE SERVERDB and USE USER.

Class Content

The class Loader contains the following methods:

cmd (cmd_string)

rawCmd (cmd_string)

sql (cmd_string)

release ()

Definition of the Constructor

Loader (database_server = '')

Parameter | Description
database_server | Network name of the server to which you want to connect If you do not specify a database_server, a connection is made to the local server.

Generating a connection session to the program Loader Server on the current server:

session = sapdb.loader.Loader ()

Generating a connection session to the program Loader Server on the server remoteserver:

session = sapdb.loader.Loader('remoteserver')


Method cmd (MaxDB: Python Manual)

Method cmd

Definition

cmd (cmd_string)

Use

cmd is a method of the class Loader. You use this method to send the Loader command specified under cmd_string to the program Loader Server.

Result

The result of the Loader command is returned.

If the Loader Server program returns an error, an exception of the class LoaderError is raised.

Specifying a valid Loader command

result = session.cmd ('CREATE TABLE testtable (colname INTEGER)')
print repr (result)

Output:

''

Specifying an invalid Loader command

result = session.cmd ('invalid command')
print repr (result)

Output:

Traceback (innermost last):
loader.LoaderError: loader.LoaderError: [-25010] SQL [-3005] Invalid SQL Statement (error position: 1)

(See also: Method rawCmd)


Method rawCmd (MaxDB: Python Manual)

Method rawCmd

Definition

rawCmd (cmd_string)

Use

rawCmd is a method of the class Loader. You use this method to send the Loader command specified under cmd_string to the program Loader Server.

Errors returned by the Loader Server do not raise an exception. The return code starts with OK if the command was executed successfully; it starts with ERR if the command failed.

(See also: Method cmd)

Result

The result of the Loader command is returned.

Specifying a valid Loader command

result = session.rawCmd ('CREATE TABLE testtable2 (colname INTEGER)')
print repr (result)

Output:

'OK \012'

Specifying an invalid Loader command

result = session.rawCmd ('invalid command')
print repr (result)

Output:

' ERR\012-25010\012SQL error -3005 = Invalid SQL statement (error position: 1)'


Method sql (MaxDB: Python Manual)

Method sql

Definition

sql (cmd_string)

Use

sql is a method of the class Loader. You use this method to send the Loader command specified under cmd_string to the program Loader Server.

Result

If the statement is executed successfully, the value of the result is 0.

If the execution of the statement causes an SQL error, the number of the error message of the SQL statement is returned.

If the execution of the statement causes a Loader error, the exception LoaderError is raised.

Executing a valid SQL statement

session.cmd ('CREATE TABLE testtable3 (a integer)')

Output:

0

Executing an invalid SQL statement

session.cmd ('invalid command')

The output is the error code of the SQL statement:

3005

Executing an invalid Loader command

session.cmd ('DATALOAD invalid spec')

The output is the exception of the Loader Server:

Traceback (innermost last):
loader.LoaderError: loader.LoaderError: [-25281] Syntax error at position 10 (Unexpected token: invalid)


Method release (MaxDB: Python Manual)

Method release

Definition

release ()

Use

release is a method of the class Loader. It ends the current connection to the program Loader Server.


Example for the Module sapdb.loader (MaxDB: Python Manual)

Example for the Module sapdb.loader

Generating a connection

#
# testloader.py   Test the connection between the database instance
#                 tst and the Loader server for the user testuser
#                 with the password test.

import sapdb.loader
session = sapdb.loader.Loader ('', '')
session.cmd ('USE SERVERDB tst')
session.cmd ('USE USER testuser test')


Troubleshooting for the Module sapdb.loader (MaxDB: Python Manual)

Troubleshooting for the Module sapdb.loader

When errors occur, the methods of the module sapdb.loader raise one of the following exceptions:

Class CommunicationError

Class LoaderError


Class CommunicationError (MaxDB: Python Manual)

Class CommunicationError

Exceptions of the class CommunicationError are raised if no connection can be made to the Loader Server, or if an existing connection has been broken.

Instances of the class CommunicationError have the following attributes:

Attribute | Description
errorCode | Error code
message | Text of the error message

The Loader Server to which you are trying to connect does not exist:

try:
    session = sapdb.loader.Loader ('unknownhost', '')
except sapdb.loader.CommunicationError, err:
    print err
    print err.message

Output:

loader.CommunicationError: [-4] unknown host name
unknown host name


Class LoaderError (MaxDB: Python Manual)

Class LoaderError

Exceptions of the class LoaderError are raised if the Loader Server program registers an error.

Instances of the class LoaderError have the following attributes:

Attribute | Description
errorCode | Number of the error message (see also: the documentation Messages)
message | Long text of the error message
sqlCode | Number of the error message of the SQL statement (if the execution of the statement caused an SQL error), or 0 (if the execution of the statement caused a Loader error)
sqlMessage | Text of the SQL error message
cmd | Loader command that caused the error


Backint for MaxDB

Purpose

The implementation of a Backint for MaxDB interface enables the use of external backup tools to back up and restore MaxDB database systems. The database tool and the external backup tools communicate through an open interface.

This document describes which properties any implementation of Backint for MaxDB must have.

Since SAP has already created the open interface BACKINT for integrating common client/server backup programs in the ORACLE backup and restore program SAPDBA, the Backint for MaxDB interface is defined in the same way as BACKINT.

Backint for MaxDB is designed so that it can be implemented together with BACKINT (for Oracle) in a single program.

For general information on the MaxDB database system, see the documentation Database Administration.

See also:

Supported Operating Systems and Platforms from database version 7.5

Supported Operating Systems and Platforms in Database Version 7.4

Supported Operating Systems and Platforms in Database Version 7.3


Backing Up and Restoring Data with MaxDB Programs (MaxDB: Backint for MaxDB)

Backing Up and Restoring Data with MaxDB Programs

MaxDB database systems can be backed up and restored with MaxDB programs.

MaxDB programs enable both complete and incremental data backups to be made to tapes, files, named pipes, autoloaders, and external backup tools. Backups can be performed in both the ONLINE and OFFLINE operational states of the database system.

Actions for backing up and restoring data are controlled with the Database Manager tool, which is shipped together with the MaxDB software package.

The Database Manager consists of a server part (the DBM Server) and a client part.
The DBM Server creates the connection to the database instance and can access its environment using operating system resources.
There are three different clients: Database Manager GUI, Database Manager CLI and Web DBM. They create a connection to the DBM Server and exchange data with the DBM Server using a request-response mechanism.

The Database Manager GUI is downwards-compatible, which means that you can use it to manage older database versions.


Backing Up and Restoring Data with External Backup Programs (MaxDB: Backint for MaxDB)

Backing Up and Restoring Data with External Backup Programs

Use

You can implement external backup tools to back up and restore MaxDB database systems. Data is transferred through named pipes, using the Database Manager.

There are two possible implementations:

· The external backup tool is controlled by the DBM Server.

When data is backed up, the DBM Server initiates the data transfer from the database instance to one or more pipes, and calls the external backup tool to back up the data in the pipes. If the database system or the external backup tool causes an error, the DBM Server ends the data transfer and informs the data transfer partner.

When data is restored, the client queries the available backups from the external backup tool through the DBM Server. It then displays the result of this query to the user, and initiates and controls the transfer of the required backups from the external backup tool to the database through one or more pipes.

See also: Documentation Connecting External Backup Tools, section Block Diagram: Backup and Restore

· The external backup tool uses the client application Database Manager CLI to control the database.


Functional Description for Backint for Max DB (MaxDB: Backint for MaxDB)

Functional Description for Backint for Max DB

Backint for MaxDB backs up and restores data with the appropriate MaxDB database tool and searches for older backups. The program is the connection between the DBM Server and the external backup tool.

If the external backup tool has a client/server architecture, then Backint for MaxDB communicates with the client. Otherwise, it implements the client that is running on the database server. In this way, the MaxDB database tool is able to make standardized use of different external backup tools.

See also: Documentation Connecting External Backup Tools, section Block Diagram: Backup and Restore

Backint for MaxDB supports the following functions:

· Backup

· Restore

· Inquire

· Delete

For all functions, the user ID (UID) is used as the ID of the MaxDB database. Once a function has been performed, Backint for MaxDB sends a return code that indicates whether it has been successful.


Backup Function (MaxDB: Backint for MaxDB)

Backup Function

General Function Description

The backup function defines a backup request for a list of files or pipes, and sends this request to Backint for MaxDB. Backint for MaxDB backs up these files or pipes, and generates a backup ID for each backup object as a response. Here, the combination of user ID, backup ID and backup object name is guaranteed as being unique for each backup object.

Backint for MaxDB informs the user which files or pipes have been backed up successfully and which have not, which backup ID was assigned to each file and to each pipe, and how many bytes were saved for each pipe.

The order in which the files and/or pipes in the list are backed up is freely determined by the external backup tool.

Type of Backup Objects

The input list for the backup function indicates whether an object is a file or a pipe. You can combine files and pipes in the input list.

Backint for MaxDB and BACKINT (for Oracle) differ in the objects they allow to be backed up:

BACKINT (for Oracle) allows files, directories, and raw devices.

Backint for MaxDB allows only files and pipes.

Data Transfer

If the input list contains files, then they are backed up by the external backup tool, however, the backup can be made in a random order and degree of parallelism.

The following rules apply when pipes are restored:

The software (DBM server) or user that called Backint for MaxDB, ensures that every pipe in the list is opened and closed at least once. Backint for MaxDB returns an error for every pipe that has not been opened. To enable a data transfer, both sides of a pipe must be opened; one side by the database software or user, and the other side by Backint for MaxDB. If pipes listed in the input file do not exist, Backint for MaxDB either creates them or checks periodically to see whether they exist.

The pipes are opened for read access only. The data transfer through a pipe ends when one side of the pipe is closed.

If a database version lower than 7.4.03 is used and more than one pipe is specified in the input file, they must all be processed in parallel and in real time to avoid deadlocks. This means that Backint for MaxDB must process all pipes simultaneously, but independently of each other.

When one pipe is opened or read, this action must not block any other pipes listed in the input file from being opened, or any data from being transferred. This is why Backint for MaxDB checks every pipe periodically to make sure that it can be opened or that data can be read from the pipe. This can be achieved by starting one child process or thread for each pipe and by avoiding any synchronization between these processes and/or threads. In this way, the processes or threads can open and read the pipes with normal blocking operations, since the operating system switches periodically to the processes or threads of the other pipes.

If a database version from 7.4.03 is being used, and multiple pipes are specified in the input file, then Backint for MaxDB processes at least some of these pipes in parallel. Otherwise, there would be no advantage in being able to make parallel backups. Interdependencies between the pipes or the processes/threads that process these pipes do not need to be avoided during the backup, since the database itself processes the pipes independently of each other.

MaxDB can support parallel backups with pipes, but this is not mandatory. You can also configure MaxDB for database version 7.4.03 only, or for all database versions covered by this documentation.


Restore Function (MaxDB: Backint for MaxDB)

Restore Function

The restore function is used to send a request to Backint for MaxDB to restore backups. This request consists of the user ID (see also Variables) and a list of the files and/or pipes that need to be restored.

For files, the information consists of the backup ID, its name, and the directory to which the file is to be restored. For pipes, the information consists of the backup ID, its name, and the name of the current pipe to which the content of the backup pipe is to be restored. The name of the directory for the new file and the name of the current pipe are optional pieces of information. If no backup ID is specified, then the last backup of the file or pipe is restored. Information is returned that indicates which files or pipes have been restored successfully and which backups have been used.

The order in which the files in the list are restored is freely determined by Backint for MaxDB.

Type of Backup Medium

For the restore function, Backint for MaxDB uses its own information or information from the backup tool to decide whether an object is a file or a pipe. Files and pipes can be combined in the input list.

Data Transfer

If the input list contains files, these are restored in the file system.

The software (DBM Server) or user that called Backint for MaxDB, ensures that every pipe in the list is opened and closed at least once. Backint for MaxDB returns an error for every pipe that has not been opened. It restores the data in a pipe in the order in which it was read from the original pipe backup. To enable a data transfer, both sides of a pipe must be opened; one side by the database software or user, and the other side by Backint for MaxDB. If pipes listed in the input file do not exist, Backint for MaxDB either creates them or checks periodically to see whether they exist.

The pipes are opened for write access only. The data transfer through a pipe ends when one side of the pipe is closed.

If a database version lower than 7.4.03 is used and more than one pipe is specified in the input file, they must all be processed in parallel and in real time to avoid deadlocks. This means that Backint for MaxDB must process all pipes simultaneously, but independently of each other.

When one pipe is opened or written, this action must not block any other pipes listed in the input file from being opened, or any data from being transferred. This is why Backint for MaxDB checks every pipe periodically to make sure that it can be opened or that data can be written to the pipe. This can be achieved by starting one child process or thread for each pipe and by avoiding any synchronization between these processes and/or threads. In this way, the processes or threads can open and write to the pipes with normal blocking operations, since the operating system switches periodically to the processes or threads of the other pipes.

If a database version from 7.4.03 is being used, and multiple pipes are specified in the input file, then Backint for MaxDB processes a maximum number of these pipes in parallel. This minimizes restore times. Interdependencies between the pipes or the processes/threads that process these pipes do not need to be avoided while data is being restored, since the database itself processes the pipes independently of each other.

MaxDB can support parallel restores with pipes, but this is not mandatory. You can also configure MaxDB for database version 7.4.03 only, or for all database versions covered by this documentation.

However, the supported type of parallel restore must match the parallel backup type.


Inquire Function (MaxDB: Backint for MaxDB)

Inquire Function

You can use the inquire function to query information about any backups managed by the external backup tool.

This function is called with the user ID, the backup ID, and the file name or pipe name. The user ID must be specified, but the backup ID and file name or pipe name are optional. The content of the output file for this function depends on the information specified in the request.

If the input list contains multiple entries, Backint for MaxDB generates the output for the individual entries, and displays it in the order they were entered.

There are four possible cases:

Entries in the Input File

Entries in the Output File

Neither backup ID nor file name or pipe name specified
 #NULL

List of backup IDs for a user ID sorted by the date the backup was created (latest backup first)
One list entry consists of one backup ID.
 #BACKUP <backup_id>

If no backup IDs exist for the specified user ID, Backint for MaxDB does not create any output.

Backup ID specified, file name or pipe name not specified:
 <backup_id>

List of files or pipes that belong to the backup ID
Each list entry consists of the specified backup ID and a file name or pipe name.
 #BACKUP <backup_id> <file_name>
|#BACKUP <backup_id> <pipe_name>

If no files and/or pipes exist for the specified backup ID, Backint for MaxDB does not create any output.

File name or pipe name specified,
backup ID not specified:
 #NULL <file_name> |#NULL <pipe_name>

List of backup IDs that belong to the specified file or pipe, sorted by the date the backup was created (latest backup first)
Each list entry consists of a backup ID and the specified file name or pipe name.

( #BACKUP <backup_id> <file_name>
|#BACKUP <backup_id> <pipe_name>)

If no backup exists for the specified file or pipe, MaxDB generates output that contains the keyword #NOTFOUND.

(#NOTFOUND <file_name>)
(#NOTFOUND <pipe_name>)

Both backup ID and file name or pipe name specified:
 <backup_id> <file_name>
|<backup_id> <pipe_name>

The backup specified by the backup ID and the file name or pipe name:
 #BACKUP <backup_id> <file_name>
|#BACKUP <backup_id> <pipe_name>

If no backup with the specified backup ID exists for the specified file or pipe, MaxDB generates output that contains the keyword #NOTFOUND.

(#NOTFOUND <file_name>)
(#NOTFOUND <pipe_name>)


Delete Function (MaxDB: Backint for MaxDB)

Delete Function

The delete function tells Backint for MaxDB which backed up files or pipes are no longer needed. Backint for MaxDB is allowed to ignore a delete request.

If, for example, a backup action has been only partially successful, the delete function informs Backint for MaxDB. The files or pipes that are no longer needed are specified by their user ID, backup ID, and name.


Program Definition for Backint for Max DB (MaxDB: Backint for MaxDB)

Program Definition for Backint for Max DB

Variables

Calling Backint for MaxDB

Options

Content of the Input File

Content of the Output File

Return Codes


Variables (MaxDB: Backint for MaxDB)

Variables

Variables

In this documentation, all variables have the following meanings and definitions:

Variable | Description | Type (Maximum Length)
<backup_id> | Backup ID (BID) | CHAR(16)
<backup_vol> | Backup volume (for example, tape label) | CHAR(10)
<dest_dir> | Absolute directory and name to which a backed up file is restored | CHAR(255)
<dest_name> | Absolute name of the current pipe to which a backed up pipe is restored | CHAR(255)
<file_name> | Absolute directory and name of the file | CHAR(255)
<in_file> | Name of the input file | CHAR(255)
<out_file> | Name of the output file | CHAR(255)
<par_file> | Name of the parameter file | CHAR(255)
<pipe_name> | Absolute name of the pipe | CHAR(255)
<size> | File size or pipe size | CHAR(16)
<user_id> | User ID (UID) | CHAR(16)


Backup ID (BID) (MaxDB: Backint for MaxDB)

Backup ID (BID)

The Backint for SAP DB implementation generates a backup ID when a file or pipe is backed up, and writes this ID to the output file. This ID is then used by the functions restore, inquire, and delete.

A backup ID is not necessarily unique since it can be assigned both to the backup of a single file or pipe and to the backups of multiple files and/or pipes. However, any backup of a file is identified by a unique combination of user ID, backup ID, and file name or pipe name.


Calling Backint for MaxDB (MaxDB: Backint for MaxDB)

Calling Backint for MaxDB

It must be guaranteed that Backint for MaxDB can be called with the following syntax at the command line level:

backint -u <user_id> [-f <function>] [-t <type>] [-c] [-p <par_file>] [-i <in_file>] [-o <out_file>]

For a description of the options, see Options.

For a description of the variables, see Variables.

In addition to the options, the interface also supports several environment variables. These variables are set by the DBM Server before you call Backint for MaxDB.

Environment Variable | Value | Description
BI_CALLER | DBMSRV | Backint for MaxDB is called by the DBM Server
BI_BACKUP | FULL | PARTIAL | ARCHIVE | Complete or incremental data backup or log backup
BI_REQUEST | NEW | OLD | First or subsequent call of Backint for MaxDB within a running backup

Since the DBM Server sets the environment dynamically (putenv), Backint for MaxDB, as a process started by the DBM Server, can inherit these variables (getenv), and use their values to control its further actions.


Options (MaxDB: Backint for MaxDB)

Options

It must be guaranteed that the following options can be set for Backint for MaxDB:

Option | Description | Default
-u <user_id> | User ID (UID) User of the backup tool (for example, the name the database instance) | None
-f <function> | <function>::= backup | restore | inquire | delete Type of operation | backup
-t <type> | <type>::= file Backup type; file is the only possible type for handling files or pipes. This backup type is the equivalent of the file backup type of BACKINT (for Oracle). | file
-c | Unattended mode (no action by operator possible) | Attended mode
-p <par_file> | Name of the parameter file, text file for the external backup tool with parameters that specify the backup procedure; specific to the backup tool The MaxDB database tools get the location of this file from their own parameter file. However, they do not analyze its content. | None
-i <in_file> | Name of the input file Text file with the objects of the function (backup, restore, inquire, or delete). See also Content of the Input File | If this option is not set, the data is read from the standard input.
-o <out_file> | Name of the output file Text file where processing messages and the results of functions are saved See also Content of the Output File | If this option is not set, the messages are written to the standard output.

See also: Variables


Content of the Input File (MaxDB: Backint for MaxDB)

Content of the Input File

The input file consists of a list of objects that need to be backed up. The entries must comply with the syntax rules indicated below.

The information that needs to be processed by Backint for MaxDB depends on the function that has been used.

See also: Functional Description for Backint for MaxDB

Function

Content of the Input File

Syntax

Backup

Names of the files or pipes that you want to back up
Pipes are indicated by the keyword #PIPE

<file_name> | <pipe_name> #PIPE

Restore

Backup ID(s) and/or names of the files or pipes that you want to restore

If you want to restore the newest version of the files or pipes, you can replace some or all of the backup IDs with the keyword #NULL.
If you want to restore the file to a directory other than the one where it was backed up, then you can add the absolute name of a target directory to the combination of backup ID and name of a file.
If you want to restore the content of the pipe to a pipe other than the one where it was backed up, then you can add the absolute name of a target pipe to the combination of backup ID and name of a pipe.

<backup_id> <file_name> [<dest_dir>]
| #NULL <file_name> [<dest_dir>]
| <backup_id> <pipe_name> [<dest_name>]
| #NULL <pipe_name> [<dest_name>]

Inquire

Backup ID(s) and/or names of the files or pipes whose information you want to query

#NULL
| <backup_id>
| #NULL <file_name>
| #NULL <pipe_name>
| <backup_id> <file_name>
| <backup_id> <pipe_name>

Delete

Backup IDs and names of files or pipes that can be deleted

<backup_id> <file_name>
| <backup_id> <pipe_name>

See also: Variables


Content of the Output File (MaxDB: Backint for MaxDB)

Content of the Output File

The output file contains the messages about the processing of the functions, and their results. In addition to the success messages and error messages in their defined formats, the file can also contain other messages.

The content of a message depends on the function that has been executed.

See also: Functional Description for Backint for MaxDB

Function

Success Message

Error Message

Backup

#SAVED <backup_id> <file_name> [<backup_vol>]

| #SAVED <backup_id> <pipe_name> <size> [<backup_vol>]

#ERROR <file_name>
| #ERROR <pipe_name>

Restore

#RESTORED <backup_id> <file_name>
| #RESTORED <backup_id> <pipe_name>

#NOTFOUND <file_name>
| #NOTFOUND <pipe_name>
| #ERROR <file_name>
| #ERROR <pipe_name>

Inquire

#BACKUP <backup_id>
| #BACKUP <backup_id> <file_name>
| #BACKUP <backup_id> <pipe_name>

#NOTFOUND <file_name>
| #NOTFOUND <pipe_name>
| #ERROR <file_name>
| #ERROR <pipe_name>

Delete

#DELETED <backup_id> <file_name>
| #DELETED <backup_id> <pipe_name>

#NOTFOUND <file_name>
| #NOTFOUND <pipe_name>
| #ERROR <file_name>
| #ERROR <pipe_name>
| #NOTDELETED <file_name>
| #NOTDELETED <pipe_name>

See also: Variables


Return Codes (MaxDB: Backint for MaxDB)

Return Codes

Backint for MaxDB is called by the software (the DBM Server) or a user. Both the software and the user expect Backint for MaxDB to return one of the codes described below:

Return Code | Description
0 | OK – All files and pipes were processed successfully without warnings.
1 | WARNING – However, all files and pipes were processed successfully.
2 | ERROR – Some or all files or pipes were not processed successfully.


Supported Operating Systems and Platforms (Version 7.4) (MaxDB: Backint for MaxDB)

Supported Operating Systems and Platforms (Version 7.4)

Version 7.4 of the database system supports the following operating systems and platforms:

· Compaq Tru64 Unix (Alpha)

· HP-UX (HP-PA)

· IBM AIX (PowerPC)

· Linux (i386, ia64)

· SUN Solaris (SPARC)

· Microsoft Windows 2000 (i386)

· Microsoft Windows XP (i386)

· Microsoft Windows Server 2003 (i386, ia64)


Supported Operating Systems and Platforms (Version 7.3) (MaxDB: Backint for MaxDB)

Supported Operating Systems and Platforms (Version 7.3)

Version 7.3 of the database system supports the following operating systems and platforms:

· Compaq True64 Unix / Alpha

· IBM AIX / PowerPC

· SUN Solaris / SPARC

· HP-UX / HP-PA

· Linux / Intel

· Siemens Reliant Unix / MIPS

· Windows NT / Intel


Development

Title of the Documentation | Contents
Development Environment | Using the development environment
Source Code for Tools | Creating source code
Web Based Problem Tracking System | Web interface for internal MaxDB program PTS (Problem Tracking System) for documenting problem messages about MaxDB software


Development Environment

General Directory Structure of the Development Environment

Development Hierarchy

Environment Variables

Tools of the Development Hierarchy

Working with the Development Environment: Examples


General Directory Structure of the MySQL MaxDB Development Envir (MaxDB: Development Environment)

General Directory Structure of the MySQL MaxDB Development Environment

The development environment for the MySQL MaxDB database system uses a fixed directory structure.

The top node ( MaxDB_DEV) corresponds to the environment variable $OWN.

The system creates the following directory structure when you call VMAKE for the first time.

The top MaxDB_DEV node is divided into 3 areas:

· Development area: sys

· Temporary area: tmp

· Directory for created software components: usr

Development Area

The development area is divided into the subdirectories desc, src, and wrk.

The development area is not always necessary. Using the development hierarchy, the system accesses the sources from the next hierarchy level when the software is created.

· All types of description files are stored in the descdirectory, which can also have subdirectories.

· The src directory contains all the module files in separate directories or layers.

· The actual software creation process takes place in the wrk directory. All of the intermediate products (object files, include files) and logs are also stored here.

· A separate directory ( fast, quick, slow) with a standard structure exists for each of the three VMAKE versions. Each of these directories has a tmpsubdirectory. This is the temporary work area that is used during the MAKE operation.

· All of the object files and static libraries created are stored in the obj subdirectory.

· The date files are stored in the datessubdirectory.

· The psrc and csrc directories can be used as buffers for module files if the VMAKE_OPTION parameters have been set accordingly.

· The module files that were translated in debug mode are stored in the debugdirectory.

· Since include files are independent of the VMAKE version, they are stored directly below the wrk directory in the incl directory.

· The associated date files are stored directly below the wrk directory in the dates directory.

Temporary Area

This is a temporary area that allows the iview.pl tool to use the development environment. When the tool is called, the specified module and/or description files are copied to the tmp file. These files, however, cannot be modified in this directory.

Directory for Created Software Components

The usr directory for the created software components is the future DBROOT directory of the MaxDB software. All of the components that are required to operate the database are copied here.


Development Hierarchy (MaxDB: Development Environment)

Development Hierarchy

VMAKE provides access to module and description files across several levels. Several development states can be logically superimposed on one another in different directories (also from other computers). This provides an overview of a complete software version.

Each hierarchy level does not have to contain all the module and description files. For the translation process, the module and description files are usually taken from the top level in the hierarchy. The sequence in the hierarchy is defined by the environment variable VMAKE_PATH.

A two-level hierarchy is implemented with the standard installation of the MaxDB development environment. This ensures that the original module and description files are always retained.

Example of a two-level hierarchy

Directory 1 ( C:\OWN\MaxDB_ORG) | Contains the original MaxDB sources; these are located in the subdirectories sys/desc and sys/src (General Directory Structure) OWN must always be changed to the name of the release used.
Directory 2 ( C:\OWN\MaxDB_DEV) | Directory for creating and developing MaxDB software. OWN must always be adjusted to the name of the release used.


Working with the MaxDB Development Hierarchy (MaxDB: Development Environment)

Working with the MaxDB Development Hierarchy

If you want to modify files, use the icp.pl tool to copy them from the MaxDB_ORGdirectory to the MaxDB_DEVdirectory in the development hierarchy.

The MaxDB_ORG directory is located under the following path: C:\OWN\MaxDB_ORG

The MaxDB_DEV directory is located under the following path: C:\OWN\MaxDB_DEV

In this case, the environment variable $VMAKE_PATH must contain the following entry:

VMAKE_PATH= C:\OWN\MaxDB_DEV,C:\OWN\MaxDB_ORG

OWN must always be changed to the name of the release used.

In a MAKE operation, MaxDB_DEV would now be searched for a module or description file. VMAKE only searches the next level if it cannot find the file here.

If a path in the VMAKE_PATH does not end with two slashes, it is also searched for current object files in the wrk directory. The files are copied if they match the current development status. The relevant module files do not need to be translated.

You can use the idiff.pl tool to compare the modified and original module or description files.

The iview.pl tool enables you to display a module or description file.


Environment Variables (MaxDB: Development Environment)

Environment Variables

The VMAKE initialization process is based on environment variables.

On Microsoft Windows, environment variables must be encapsulated in percentage symbols.

On UNIX systems, environment variables are prefixed with a $. This is also the selected notation in this documentation.

All of the environment variables listed here, with the exception of $NOQUIET, can be set with the initDev_MaxDB.bat (Microsoft Windows) or initDev_MaxDB (UNIX) initialization script. This script is stored in the MaxDB_DEV directory when the development environment is installed.

$VMAKE_VERSION

$VMAKE_DEFAULT

$VMAKE_OPTION

$INSTROOT

$VMAKE_PATH

$SHELL

$TOOLSHELL

$TOOLOPT

$TOOL

$TOOLEXT

$DLL_TYPE

$ARC_TYPE

$OWN

$WRK

$PATH

%INCLUDE%

$RELVER

$CORRECTION_LEVEL

$BUILD_PRAEFIX

$PYTHONPATH

$PERL5LIB

$EDITOR

$DBROOT

$NOQUIET

$TOOLVARS


$VMAKE_VERSION (MaxDB: Development Environment)

$VMAKE_VERSION

This variable defines the system default for the VMAKE version .

VMAKE only evaluates the first letter of the set variable.

set VMAKE_VERSION=fast


$VMAKE_DEFAULT (MaxDB: Development Environment)

$VMAKE_DEFAULT

This variable is optional. If this variable is not set, VMAKE uses the entry for the $VMAKE_VERSION variable. VMAKE only evaluates the first letter of the set variable.

It defines the system default for translating module files that are listed in description files.

set VMAKE_DEFAULT=fast

If translation is carried out with the slow VMAKE version and the $VMAKE_DEFAULT set to fast , only the module files in the description files are translated with the fast method; all other files are translated using the slow method.


$VMAKE_OPTION (MaxDB: Development Environment)

$VMAKE_OPTION

You use the parameters for the $VMAKE_OPTION environment variable to define the VMAKE mode of operation.

You can override some of the $VMAKE_OPTION parameters by entering options for the VMAKE call.

If you want to specify several parameters, do not enter a blank space between the individual parameters.

set VMAKE_OPTION=DISOhvWMLRg


Parameters for $VMAKE_OPTION (MaxDB: Development Environment)

Parameters for $VMAKE_OPTION

Different parameters can be set for the $VMAKE_OPTION variable.

If you want to specify several parameters, do not enter a blank space between the individual parameters.

Parameters for Searching for Source Code

Parameters for Searching for Object Files

General Parameters for $VMAKE_OPTION

A | Object files are also copied to the first hierarchy level of $VMAKE_PATH if they can be found in an integrated file system.
a | A warning is output instead of an error message for differences regarding upper and lower-case notation of a target in the hierarchy. Discrepancies regarding upper and lower-case letters in the targets within the hierarchy are usually regarded as an error.
b | Normally, C module files are not allowed to use PASCAL include files . If this option is set, the C header files generated from the PASCAL include file are used.
C | c | C Level: The same rules apply as with the Pascal level, with the exception that no PASCAL module files are allowed to exist here. If PASCAL and C Level are used, non-PASCAL files are copied from the PASCAL Level to the C Level during the translation process . C | c, therefore, implies that a C Port is to be carried out. PASCAL files are translated into C files. C requires that source code be managed at this level. If you use c, this is optional. In other words, the source text from this level is used if it exists.
D | Date files are used to flag the date of a module file that was used to create a program.
e | All object files are assigned debug information.
g | global make: If objects are found in the path hierarchy that are younger than the those in the first hierarchy, they are copied to the first hierarchy (standard behavior).
h | If you specify a description file without an extension in the command line, VMAKE attempts to find a description file with a file name that matches the one entered in the command line. The system follows a specific search sequence. With the h option, you can assign description files the following order in accordance with their file extension: the system first searches for a file with this name and the extension shm, then with the extension lnk, then with the extension shr, and finally with the file extension rel.
H | PASCAL include files are not automatically converted to C header files.
I | i | Include Level: Include files are assigned a frame. This must be removed, and the include file must be transferred to the include directory . If neither the i nor the I option is set, include files are not interdependent. If i is specified, include files are subject to the standard dependency rules. If I is specified, include files are generated with size information for PASCAL. Include files are only considered if one of the S | s options is set.
l | local make: Object files whose module files are located in the first path are regarded as being up to date. This means that object files from the path hierarchy are never used.
L | Libraries are like relocatables: The contents of libraries are not analyzed. The date of the library is checked against the timestamp of the object files. The library is rebuilt by linking all of the relevant object files.
M | Modules are independent: Object files are stored in the file system, as they cannot be accessed otherwise. Alternatively, object files from programs that have already been linked can be used.
O | o | Object Level: This level contains object files that can be linked to generate programs. If O is set, these files are used accordingly. If o is specified, program generation ends once all of the object files have been created.
P | p | PASCAL Level: The frame is missing from all module files. PASCAL Level, since most module files are written in PASCAL and, therefore, PASCAL module files exist at this level. Files in different languages are stored here. If P is specified, PASCAL Level files remain in the PASCAL Level directory. P requires that source code be managed at this level; with p, this is optional, in other words, the source code from this level is used if it exists.
R | The shrglob and noshrglob options for description files are ignored.
S | s | Source Level: Many module files have a frame that has to be removed before they are translated. If S is specified, all of the module files have to be present. If s is set, these files are only used if they exist. Dependent files are only processed if the source code is present.
t | timestamp the start of bigger targets If description files are translated, a timestamp is output.
T | A timestamp is always output before a module file is translated.
X | Specify this option if write-protected source code (for example, from CD) is to be accessed.
Z | The system searches for module files, whose name does not contain a coded layer and which ends in .rc, .ico, .def, .mc, .dlg, .idl, .ycc, .lex or .rgs, in the Resource layer.


$VMAKE_OPTION Parameters for Searching for Source Code (MaxDB: Development Environment)

$VMAKE_OPTION Parameters for Searching for Source Code

Different parameters can be set for the $VMAKE_OPTION variable.

If you want to specify several parameters, do not enter a blank space between the individual parameters.

Parameters for Searching for Source Code

(No parameter set) | The first item of source code found is used.
v | The first item of source code found is used. The system outputs a warning if a more recent file is found in the remaining path hierarchy.
V | The most recent source code in the hierarchy is used and, if necessary, copied to the local source area.
vV | The most recent source code in the hierarchy is used and a warning is output.


$VMAKE_OPTION Parameters for Searching for Object Files (MaxDB: Development Environment)

$VMAKE_OPTION Parameters for Searching for Object Files

Different parameters can be set for the $VMAKE_OPTION variable.

If you want to specify several parameters, do not enter a blank space between the individual parameters.

Parameters for Searching for Object Files

(No parameter set) | The first object file found is used.
w | The first object file found is used. The system outputs a warning if a more recent object file is found in the remaining path hierarchy.
W | The most recent object file in the hierarchy is used.
wW | The most recent object file in the hierarchy is used and a warning is output.


$INSTROOT (MaxDB: Development Environment)

$INSTROOT

This variable contains an absolute path specification within the current file system. This describes where VMAKE is to store linked software components.

VMAKE decides, on the basis of the software component, under which relative path under $INSTROOT the component will be stored.

set INSTROOT=D:\V72


$VMAKE_PATH (MaxDB: Development Environment)

$VMAKE_PATH

This variable lists paths under which VMAKE can search for files .

The individual path specifications are separated by a comma. The paths can be absolute paths in the file system of the local computer, or of other computers that are integrated in the file system.

If a file system that is not integrated is to be used, the VMAKE Server program is required on the computer with this file system.

The path must then be specified as follows:

<server_name>:<absolute_path>

<server_name> | Name of the other computer
<absolute_path> | Absolute path on the file system of the other computer

If you enter two slashes at the end of a path specification, the system will ignore this path when searching for object files .

set VMAKE_PATH=D:\V72,P26326:F:\Develop//,\\P26208\share\tools


$SHELL (MaxDB: Development Environment)

$SHELL

Description files can contain operating system commands.

You use this variable to specify that a certain command shell is to be used to process these OS commands.

set SHELL=C:\MyTools\4dos.exe


$TOOLSHELL (MaxDB: Development Environment)

$TOOLSHELL

This variable defines the shell that executes the scripts used by VMAKE ( VMAKE Tools ).

set TOOLSHELL=D:\Perl\5.00502\bin\MSWin32-x86-object\perl5.00502.exe


$TOOLOPT (MaxDB: Development Environment)

$TOOLOPT

You can use this variable to transfer additional options to the shell specified in the $TOOLSHELL variable.

set TOOLOPT=-d


$TOOL (MaxDB: Development Environment)

$TOOL

The relative path containing the scripts and programs used by VMAKE is specified in this variable.

set TOOL=D:\DevTool


$TOOLEXT (MaxDB: Development Environment)

$TOOLEXT

The file extension of the scripts ( VMAKE Tools ) is defined in this variable.

VMAKE only recognizes the first part of the script file names. VMAKE uses this variable to determine the file extension.

set TOOLEXT=.pl


$DLL_TYPE (MaxDB: Development Environment)

$DLL_TYPE

The file extension for dynamic libraries is defined in this variable.

This variable is optional.

VMAKE has the following default settings:

Win32 | .dll
UNIX | without file extension


$ARC_TYPE (MaxDB: Development Environment)

$ARC_TYPE

The file extension for static libraries is defined in this variable.

This variable is optional.

Default settings:

Win32 | .lib
UNIX | .a


$OWN (MaxDB: Development Environment)

$OWN

The environment variable OWN corresponds to the absolute path for the directory MAXDB_DEV (General Directory Structure of the MySQL MaxDB Development Environment).

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$WRK (MaxDB: Development Environment)

$WRK

The environment variable $WRK is used by various description files. It refers to the sys/wrk directory below the directory MaxDB_DEV (General Directory Structure of the MySQL MaxDB Development Environment).

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$PATH (MaxDB: Development Environment)

$PATH

The $PATH variable must be adapted to include the following directories:

$DBROOT/bin

$DBROOT/pgm (Microsoft Windows)

$TOOL/Posix

$TOOL/bin

$TOOL/pgm (Microsoft Windows)

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


%INCLUDE% (MaxDB: Development Environment)

%INCLUDE%

This environment variable only applies to Microsoft Windows.

The compiler uses this environment variable to locate all of the MaxDB-internal include files.

The following entries must be listed here:

%DBROOT%\incl

%TOOL%\incl

%OWN%\sys\wrk\incl

%OWN%\sys\wrk\incl\SAPDB

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$RELVER (MaxDB: Development Environment)

$RELVER

This environment variable specifies the current software version. It generates the build information in the program components, and is used by the link tools.

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$CORRECTION_LEVEL (MaxDB: Development Environment)

$CORRECTION_LEVEL

This environment variable specifies the number of the correction level for the build information. This information is also used by the link tools.

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$BUILD_PRAEFIX (MaxDB: Development Environment)

$BUILD_PRAEFIX

This environment variable specifies the patch level number of the current software version. This information is also used by the link tools.

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$PYTHONPATH (MaxDB: Development Environment)

$PYTHONPATH

This environment variable must be set so that the Python scripts in the tools can be executed.

It should contain the following entries:

$TOOL\Lib\Python

$INSTROOT/lib

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$PERL5LIB (MaxDB: Development Environment)

$PERL5LIB

This environment variable must be set so that the Perl scripts in the tools can be executed.

It should contain the following entries:

$INSTROOT/misc

$TOOL/bin

$TOOL/Lib/Perl

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$EDITOR (MaxDB: Development Environment)

$EDITOR

This environment variable specifies the program that is used to display and edit files using the development environment operating tool iview.pl.

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$DBROOT (MaxDB: Development Environment)

$DBROOT

This environment variable is an obsolete name for the $INSTROOT variable. As a result, it should be set in the same way as $INSTROOT.

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


$NOQUIET (MaxDB: Development Environment)

$NOQUIET

If this environment variable is set, every call of the compiler is output during the creation process.


$TOOLVARS (MaxDB: Development Environment)

$TOOLVARS

The path specification in this environment variable refers to the central initialization file toolvars.pl for most Perl scripts. The default storage location for this file is the $TOOL/bin directory.

A large part of the platform-specific adjustments is made in this Perl file. This includes the definition of the various platform-specific compiler, link, and other programs, as well as the associated options. Certain additional environment variables that are required for the creation process are also initialized in this file.

This environment variable is set by the initialization script initDev_MaxDB(.bat) (Environment Variables).


Tools in the MaxDB Development Enviroment (MaxDB: Development Environment)

Tools in the MaxDB Development Enviroment

The development tools consist of the following components:

· Tools for Operating the Development Environment

· VMAKE, as a software creation tool

· Various auxiliary programs

The various tools in the MaxDB development environment are essentially Perl scripts. These can be called with various options. You can use the -h option to display a list of the available options.


Tools for Operating the Development Environment (MaxDB: Development Environment)

Tools for Operating the Development Environment

ims.pl; imq.pl; imf.pl

idiff.pl

ils.pl

ips.pl, ipq.pl und ipf.pl

iview.pl

icp.pl


ims.pl; imq.pl; imf.pl (MaxDB: Development Environment)

ims.pl; imq.pl; imf.pl

These commands are tools for operating the development environment and are used to create MaxDB software components. A distinction is made here between the three VMAKE versions. At least the name of a processing list, a link description, or a module file is expected as a parameter. You can also specify several names as parameters.

Once a defined environment has been initialized, these scripts call the VMAKE program.

All of the available options for calling VMAKE are also available for these scripts and are passed on directly to VMAKE.

Specify the name of the file (and not the complete path) in accordance with the naming conventions for files for all of the file names transferred as parameters.

Example


idiff.pl (MaxDB: Development Environment)

idiff.pl

This command is a tool for operating the development environment and compares the file specified as a parameter in the local development area ( General Directory Structure ) with an older version of the same file within the development hierarchy.

You can also use the –l option to compare the same files at different levels in the development hierarchy.

Specify the name of the file (and not the complete path) in accordance with the naming conventions for files for all of the file names transferred as parameters.


ils.pl (MaxDB: Development Environment)

ils.pl

This command is a tool for operating the development environment , and is similar to the commands dir or ls in other operating systems. The module or description files specified as parameters within the development hierarchy are displayed.

Specify the name of the file (and not the complete path) in accordance with the naming conventions for files for all of the file names transferred as parameters.


ips.pl, ipq.pl und ipf.pl (MaxDB: Development Environment)

ips.pl, ipq.pl and ipf.pl

These commands are tools for operating the development environment , and are used to display both of the VMAKE logs of the translation process .

There are three different commands for the three VMAKE versions . The logs from a creation process started with imf.pl can be displayed with the ipf.pl tool. The file name used with the imf.pl command must be specified as a parameter here:

imf.pl dbmcli

ipf.pl dbmcli


iview.pl (MaxDB: Development Environment)

iview.pl

This command is a tool for operating the development environment, and is used to display and edit module and decription files.

If the files are located in the src or desc subdirectory below the MaxDB_DEV directory (General Directory Structure), they are opened directly and can be modified accordingly.

If the are not located in these subdirectories, the system searches for their first occurrence in the development hierarchy and copies them to the tmp subdirectory below the MaxDB_DEV directory so that they can be displayed.

The files are displayed with the program that is referred to by the environment variable $EDITOR.

iview vcn12.cpp

iview dbmcli.lnk

You can also use the -l option to access all of the versions of a file within the development hierarchy, even though they are also located in the MaxDB_DEV directory.

iview –l1 co.com

Specify the name of the file (and not the complete path) in accordance with the naming conventions for files for all of the file names transferred as parameters.

Changes to the files that are relevant for translation can only be carried out if the files are directly located in the development area. You can copy these files with icp.pl.


icp.pl (MaxDB: Development Environment)

icp.pl

This command is a tool for operating the development environment , and is used to copy a module file or description file from the development hierarchy to the development area in the MAXDB_DEV directory. As a result, this file is used instead of the file in the development hierarchy the next time a MAKE operation is carried out.

You can use the iview.pl command to display the copied file, an then edit it.

This command can only be used to copy one file. If you specify a second file name as a parameter in addition to the file name, the name of the copied file is changed to the one in the second parameter.

Specify the name of the file (and not the complete path) in accordance with the naming conventions for files for all of the file names transferred as parameters.


VMAKE (MaxDB: Development Environment)

VMAKE

This document is designed as a reference guide for creating or maintaining programs, libraries, and so on with the VMAKE tool.

The VMAKE tool supports all version of the MaxDB software.

To develop the MaxDB software, or parts thereof, enter the command for the required VMAKE version.

Various options are provided for modifying the call for the VMAKE tool.


Terms (MaxDB: Development Environment)

Terms

Files

Layer

Target

Debug Mode


Files (MaxDB: Development Environment)

Files

When software is created, module files are translated using description files .

The resulting files are called object files .

The <file_name> of a file is preserved across the various phases of the MAKE operation. The file extension <ext> changes.


Module File (MaxDB: Development Environment)

Module File

Source code comprises individual files. These files are referred to as module files.

Module files can be combined in module groups.

Module files are stored separately from description files in the file system of the OS (Storage System).

Module files can be written in any programming language. VMAKE features a complete set of tools for unpacking and translating module files for all of the programming languages supported by MaxDB.


Module File Directory (MaxDB: Development Environment)

Module File Directory

The module file directory is used to store the module files .

The structure of this directory is identical to that of the object directory (General Directory Structure of the MaxDB Development Environment).


Include Files (MaxDB: Development Environment)

Include Files

An include file is a module file that is included in a different module file.

When the source code of an include file changes, both the file and the file, in which this include file is integrated, must be retranslated ( Translation Process ) as part of the software creation process.

Include files are independent of VMAKE versions .


Include Directory (MaxDB: Development Environment)

Include Directory

Unlike module files, include files are independent of the called VMAKE version ( VMAKE Call Versions ) and, therefore, are always stored in the same directory.

This directory is called incl and is created by the VMAKE tool ( General Directory Structure ).


Description Files (MaxDB: Development Environment)

Description Files

Description files contain information on how the software is created, and which module files are used to do so. This information includes:

  • Link descriptions
  • Compilation descriptions
  • Processing lists


Link Descriptions (MaxDB: Development Environment)

Link Descriptions

Link descriptions specify how the module files are to be linked to form a program.

Essentially, link files consist of a list of references to module files and other description files that are processed sequentially by the system. You can also specify the options that are to be used during the link operation .

The file extension of the link description is used to distinguish between the resulting software components ( Using VMAKE ).

File Extension of Link Description | Type of Software Component Created
lnk | Program
shm | Program that facilitates shared memory access
lib | Static library
dld | Dynamic library
rel | Program that can be linked to other programs (relocatable)
shr | Program that can be linked to other programs (relocatable) and facilitates shared memory access
mac | Other types of object files


Compilation Descriptions (MaxDB: Development Environment)

Compilation Descriptions

Use

Compilation description specify how module files are to be translated. Essentially, a compilation description contains a list of module files and their interdependencies, as well as translation-specific options . These interdependencies include:

  • Include dependencies ( include file )
  • Dependencies, such as certain auxiliary files that must be located in the same directory as the module file to be translated ( demand=<list> ) during the translation process
  • Logical dependencies – if, for example, the module file X links to a file Z that is created as a by-product of the translation of the module file Y ( extdep=<list> )

Compilation descriptions are created for groups of module files, and not for individual module files. The compilation description has the same name as the layer . Compilation descriptions have the file extension .com

If the layer ak exists in the directory containing the module files (src), the directory with the description files (desc) must contain the compilation description ak.com .

If a layer (subdirectory) under the directory with the module files (src) contains further sublayers, the hierarchy must be recreated up to the second last level in the directory containing the description files (desc). The name of the compilation description is then formed from the last sublayer and the file extension .com

The compilation description for module files in the SAPDB/DBM/Cli layer has the name Cli.com and is located in the directory containing the description files (desc) under SAPDB/DBM.

Compilation descriptions are not processed sequentially. The processing points of a description of this kind are addressed selectively.


Processing Lists (MaxDB: Development Environment)

Processing Lists

Use

A processing list is a list of description files and module files to be processed, as well as OS commands to be executed. A processing list can also contain other processing lists. In addition, options can be specified.

The entries in a processing list are processed by VMAKE from top to bottom. All of the listed files, as well as any other files listed as links, are first checked down to the lowest level to determine whether they have been changed with respect to a target created previously. Only if this is the case does VMAKE recreate (update) the targets.


Object Files (MaxDB: Development Environment)

Object Files

Module files are unpacked and translated. The files created as a result are called object files.

These files are usually stored in the directories that correspond to the VMAKE version (VMAKE Call Versions), that is, under fast, quick or slow (see General Directory Structure of the MaxDB Development Environment).

If the noversion option is specified in the compiler description for a module file, the object file is stored directly in the wrk/obj directory.

Object files have the file extension .o


Object Directory (MaxDB: Development Environment)

Object Directory

The object files are stored in the object directory.

The object directory has the same structure as the source code directory (General Directory Structure of the MaxDB Development Environment).


Initialization Files (MaxDB: Development Environment)

Initialization Files

VMAKE uses the following initialization files:

Langextinfo | Contains the assignments between the module files and the translation tools, based on the file extension or the last character in the file name.
Langinfo | Contains assignments between the programming languages and certain tools for unpacking and translating module files.
EXTRA | Contains assignments between files that do not require translation and their storage location.
DirectoryMapping | This file is used to assign module files to a layer, on the basis of the first part of their file name (directory mapping function).

These files can be modified.

The files are stored in the descdirectory (General Directory Structure of the MaxDB Development Environment).


Langextinfo (MaxDB: Development Environment)

Langextinfo

Use

Langextinfo is an initialization file of the VMAKE tool. This file is used to assign file extensions to a programming language. Each programming language is identified by a letter.

VMAKE uses certain default settings for each language.

If you want to change the existing assignments, create a file with the name Langextinfo in the desc directory. You can also assign new letters, programs, and file extensions. In this case, however, you must create an appropriate Langinfo file. All further changes are then made in this file.

If VMAKE finds a Langextinfo file, the information contained in the file overrides the system defaults.

Syntax

<langextinfo_line> = <comment_line> | (<lang_id><comment><token_sep><token>{<token_sep>,<token_sep><token>}<new_line>)

General Rules

<comment> must not contain <token_sep>

Lines can contain the comment character #. The subsequent text in this line is treated as a comment.

System Default in VMAKE

Assigned letter (program) | File extension(s)
x(C++) | cpp, hpp
c(C) | c, h
t(PASCAL) | t
a(Assembler) | s
r(Resources) | rc, ico, def, mc, dlg, idl, ycc, lex, rgs


Langinfo (MaxDB: Development Environment)

Langinfo

Use

Langinfo is an initialization file of the VMAKE tool. The file is used to assign certain tools for unpacking and translating module files to programming languages. The relevant programming language is specified by a letter (Langextinfo).

VMAKE uses certain default settings for each language.

If you want to change the existing assignments, create a file with the name Langinfo in the desc directory. All further changes are then made in this file.

If VMAKE finds a Langinfo file, the information contained in the file overrides the system defaults.

Syntax

<langinfo_line> = <comment_line> | (<lang_id><token_sep><unpack_inc_tool><token_sep><unpack exp tool><tokensep><unpack mod tool><tokensep><extension><tokensep><option prefix><tokensep>
<compiler tool>)

<unpack inc tool> = <token>

<unpack exp tool> = <token>

<unpack mod tool> = <token>

<extension> = „.“<token>

<option prefix> = <ext character><letter>

<compiler tool>  = <token>

General Rules

Lines can contain the comment character #. The subsequent text in this line is treated as a comment.

The scripts for unpacking a module file use the table entry under extension as the file extension.

System Default in VMAKE

# | last char | unpack include | unpack exports | unpack module | extension | option prefix | compiler |
 | t | mfpinc | mfpexp | mfp | . p | %T | comppc | # PASCAL
 | p | mfpinc | mfpexp | mfp | .p | %P | compp | # PASCAL
 | c | mfcinc | mfcexp | mfc | .c | %C | compc | # C
 | x | mfcinc | mfcexp | mfc | .cpp | %X | compc | # C++
 | a | mfainc | mfaexp | mfa | .s | %A | compa | # Assembler
 | r | mfcinc | mfcexp | mfrc | .rc | %R | comprc | # Resources


Extra (MaxDB: Development Environment)

Extra

Extra is an initialization file of the VMAKE tool.

This file contains assignments between files that do not require translation and their storage location.

Syntax

<extra_line> = <comment_line> | (<extension><token_sep><layer><token_sep><dest_dir><token_sep><option><new_line>)

# | Extension | Layer | Destination directory | Options
 | .ino | xx | usr/env | unpack=no
 | .mp | px | usr/bin | unpack=no nodot
 | .dm | px | tmp | exec

Explanation:

Module files with the file extension .ino belong to the xx layer . They must be copied to the usr/env directory in $INSTROOT . The module file does not contain any textual frame (option unpack=no ).

Module files with the file extension .mp belong to the px layer. These must be copied to the usr/bin directory (relative to $INSTROOT ). The module file does not contain any textual frame. Once the files have been copied, the extension .mp must be removed (option unpack=no dot ).

Module files with the file extension .dm belong to the px layer. These must be copied to the tmp directory (relative to $INSTROOT ). The module file contains a textual frame that must be removed. Once the frame has been removed, the file is identified as executable ( exec option, only relevant for UNIX).

General Rule

Lines can contain the comment character # . The subsequent text in this line is treated as a comment.


DirectoryMapping (MaxDB: Development Environment)

DirectoryMapping

Use

DirectoryMapping is an initialization file of the VMAKE tool. This file is stored in the <path>/sys/desc directory.

VMAKE uses the second and third letters of the file name to assign module files to a layer . An alternative method of assigning module files to a layer is to use the DirectoryMapping function. This method also allows you to use longer and more meaningful file names.

File names specified with the DirectoryMapping function consist of two parts, which are linked by an underscore. The first part specifies the layer in short. The second part specifies the name of the module file.

<file_name> = <short_layer>_<module_file>

The short form is mapped to the corresponding layer in the DirectoryMapping file.

Syntax

<extra_line> = <comment_line> | (<short_layer>, <full_layer><new_line>)

General Rules

  1. The <full_layer> expression stands for the layers below <path>/sys/src/SAPDB .
  2. Lines can contain the comment character # . The subsequent text in this line is treated as a comment.
  3. The layer requires a compilation description, in which the structure of the layers, including the second last layer, is specified.

The <path>/sys/src/DirectoryMapping file contains the following entries:

# <short_layer>, <directory>
# Component SQLStudio
StudioTD, SQLStudio/TableDefinition # Table Definition

If the StudioTD_TableDef.cpp and StudioTD_Wrapper.cpp files are to be created, the compilation description TableDefinition.com must be stored under <path>/sys/desc/SAPDB/SQLStudio/ .

VMAKE searches for the StudioTD_TableDef.cpp and StudioTD_Wrapper.cpp files in the <path>/sys/src/SAPDB/SQLStudio/TableDefinition layer.


Files That do not Require Translation (MaxDB: Development Environment)

Files That do not Require Translation

Certain files contain source code that is already in the required text or binary format. These files do not need to be translated. They should simply be copied to the object directory , but can be manipulated, if necessary, using the mfextra tool ( VMAKE Tools ).

Use the ascii or binary options to prevent these files from being translated by VMAKE.

Alternatively, you can add an entry in the EXTRA initialization file.


Date Files (MaxDB: Development Environment)

Date Files

A date file is created for every target that is to be generated.

The name of the date file comprises the name of the processed file and the file extension .dat: <file_name>.dat

The timestamp is identical to the timestamp of the corresponding module file or link description.

Use

The date file is used during the MAKE operation to determine whether the local targets correspond to the module files/link descriptions that are currently being used. If the two files do not have the same timestamp, the target is regarded as not up to date and is regenerated.

Storing the Date Files

Date files for include files are stored in the $WRK/datesdirectory within their layer irrespective of the VMAKE version used in the MAKE operation, since include files are not version specific.

Date files for all other module files are stored in the version-specific $WRK/<version>/dates directory, under the relevant subdirectories for the layer in question.

Date files for link descriptions are stored directly in the version-specific $WRK/<version>/dates directory.


Layer (MaxDB: Development Environment)

Layer

Layers are logical units that represent subdirectories in the module file directory .

Module files are stored in various layers and subordinate layers. In addition to providing a clearer overview, this enables a logical distinction to be drawn between the individual database areas.


Target (MaxDB: Development Environment)

Target

Targets are all types of output files that are created during the entire software development process.

These can be individual object files , link descriptions , or output files of files that do not require translation .


Debug Mode (MaxDB: Development Environment)

Debug Mode

If debug mode is activated, all of the module files with a debug option are compiled so that the resulting object files contain additional debugging information. The relevant module files are copied to the version-specific debug directory $WRK/<version>/debug, from where they can be used for subsequent troubleshooting.

You can use the following methods to set a debug option for module files:

  • -e Option for Calling VMAKE
  • VMAKE_OPTION Parameter e
  • with the option for description files debug|d


File Storage (MaxDB: Development Environment)

File Storage

The module files and description files are stored in the file system of the OS.

The files required to create a program can be stored at different locations in a file system, in different file systems, and on different computers.

The potential paths are specified in the $VMAKE_PATH environment variable. This variable must be adapted accordingly to be able to access older file versions.

There is a separate directory for description files, and a separate directory for module files.

Each of these directories has at least one subdirectory that reflects the logical hierarchy of the files. Files are only stored at the lowest directory level.

The files can also be stored in a database. As a rule, however, databases do not provide adequate support for search operations, with the result that the files cannot be accessed efficiently.


Naming Conventions for Files (MaxDB: Development Environment)

Naming Conventions for Files

The names of module files and description files are subject to certain conventions.

Basic Elements

<digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<letter> = A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | | u | v | w | x | y | z

<extended letter> = all other printable characters, apart from hyphen and period

<character> = <digit> | <letter> | <extended letter>

<token> = <character>{<character>}

Naming Conventions for Module Files

Naming Conventions for Description Files


Naming Conventions for Module Files (MaxDB: Development Environment)

Naming Conventions for Module Files

<source_spec> = <qual_source> | <std_source> | <ext_std_source> | <map_source>

<qual_source> = :<ext_layer><source>

<std_source> = <source_id><layer><digit><digit>{<digit>}[{<letter>}<lang_id>][<variant>]

<ext_std_source> = <std_source>[<primary_lang_id>]

<map_source> = <shortform>_<specification>

<source> = <token>[<variant>]<primary_lang_id>

<source_id> = g | h | i | v

<ext_layer> = [<ext_layer>]<character><character>{< character >}/

<shortform> = <letter>{<letter>}

<specification> = <letter>{<letter>}[<variant>][<primary_lang_id>]

<lang_id> = <letter>

<layer> = <letter><letter>{<letter>}

<primary_lang_id> = .<token>

<variant> = -<token>

General Rules

  1. <layer> and <ext_layer> can contain a maximum of 256 characters
  2. <source_spec> can contain a maximum of 512 characters

<qual_source> Þ :Demo/Test/demo.cpp

<std_source> Þ hak33c | vbd23x | vkb00

<ext_std_source> Þ hak33.h | vbd23x.cpp | vkb00.hxx

<map_source> Þ StudioTD_TableDef.hpp | StudioTD_Wrapper.cpp


Naming Conventions for Description Files (MaxDB: Development Environment)

Naming Conventions for Description Files

<desc_spec> = <qual_desc> | <std_desc>

<qual_desc> = ::[<ext_layer>]<std_desc>

<std_desc> = <character>{<character>}<desc_ext>

<desc_ext> = .(mac | prj | shm | lnk | dld | shr | rel | lib | com)

General Rule

<desc_spec> can contain a maximum of 512 characters

<qual_desc> Þ ::x_demo.lnk | ::Kern/diagnose.lnk

<std_desc> Þ ak1.lib | kernel.shm | ak.com


Using VMAKE (MaxDB: Development Environment)

Using VMAKE

Use

The procedure for creating MaxDB software with VMAKE is divided into two phases:

· Translation Process

· Link Operation

The following software components can be generated:

· Program

· Program that facilitates shared memory access

· Static library

· Dynamic library

· Program that can be linked to other programs (relocatable)

· Program that can be linked to other programs (relocatable) and facilitates shared memory access


MAKE Operation (MaxDB: Development Environment)

MAKE Operation

The MAKE operation is divided into a collection phase and a make phase.

The individual steps carried out by VMAKE during the MAKE operation are described in the section entitled Process Flow of the MAKE Operation.

Collection Phase

In the collection phase, the description files of a target are collected and analyzed. The interdependencies between all of the files are collected at the same time. The system does not yet search for the module files in the hierarchy.

If errors occur during this phase, VMAKE terminates without starting the MAKE phase.

MAKE Phase

The MAKE phase marks the actual beginning of the creation process for the MaxDB software. During this phase, the module files are created in the order of their interdependency.

If a module file vak10 is dependent on vak00 ( vak10 inc=vak00), vak00 is handled first. vak10 cannot be created until this file has been successfully generated.

If an error occurs while a module file is being created, all the targets that are dependent on this module file will not be created either. This applies across all dependency levels.

If an error occurs while vak00 is being created, vak10will not be processed, as well as other dependent files:
since vak10 is contained in ak1lib.lib, ak1lib.lib is not linked. Since ak1lib.lib is contained in the kernel.shm kernel, the kernel is also not linked in the result.


Process Flow of the MAKE Operation (MaxDB: Development Environment)

Process Flow of the MAKE Operation

At the beginning of a MAKE operation, VMAKE uses the date files to determine the targets that have to be recreated. The system then searches for all of the relevant module files in the hierarchy (1) and copies them to the temporary working directory tmp (General Directory Structure) (2).

The files are then further processed in this directory with VMAKE tools. These tools are essentially Perl scripts (3). VMAKE selects the appropriate Perl scripts on the basis of the programming language in the module files (Selecting the Translation Tools). The Perl scripts are platform specific, and call the respective compilers, translators, and unpackers.

The output files produced as a result (object files and include files) are initially also stored in the temporary working directory (4). VMAKE then copies the object files to the respective obj directory and the include files to the incl-directory for the relevant layer (5).

If VMAKE is operating in debug mode, the module files are also copied to the corresponding debug directory.

A date file is stored for every module file that is used to create a target.

The relevant tools also perform the link operations the temporary directory, based on the applicable link descriptions. The output files are also stored here. Following this, VMAKE copies the targets in the relevant directories (6).

The files located in the temporary working directory are deleted once the targets have been successfully created. If an error occurs while the targets are being created, the files are not deleted from the temporary directory.

VMAKE also logs the entire software creation process.

Defining the MAKE Operation

VMAKE Logs

Translation Process

Link Operation


Defining the MAKE Operation (MaxDB: Development Environment)

Defining the MAKE Operation

VMAKE Versions

Grammar for the VMAKE Call

VMAKE Tools

Creating Description Files


VMAKE Versions (MaxDB: Development Environment)

VMAKE Versions

There are three VMAKE versions:

  • fast
  • quick
  • slow

The versions relate to the various trace and check levels in the software created.

You specify the required version when you call VMAKE:

If the VMAKE version in the description files for the module groups is different to the one you specified when you called VMAKE, the call version is overridden by the version specified in the validity range of the description file.


fast VMAKE Version (MaxDB: Development Environment)

fast VMAKE Version

Syntax

imf.pl

Use

When you call VMAKE as a fast version ( VMAKE versions ), the software created in the result does not carry out any additional internal error checks, and does not log any information other than the standard trace output of the database.


quick VMAKE Version (MaxDB: Development Environment)

quick VMAKE Version

Syntax

imq.pl

Use

When you call VMAKE as a quick version, the software created as a result does carries out additional internal error checks.


slow VMAKE Version (MaxDB: Development Environment)

slow VMAKE Version

Syntax

ims.pl

Use

When you call VMAKE as a slow version, the software created as a result carries out additional internal error checks, and logs information in addition to the standard trace output of the database.


Grammar for the VMAKE Call (MaxDB: Development Environment)

Grammar for the VMAKE Call

The VMAKE call is based on the general grammar for description files , the naming conventions for module files , and the naming conventions for description files .

<usage> = vmake<space>{<vmake_opt_list>}<target>[//<ext_option>]{<space><target><ext_option>}

<target> = <source_spec> | <desc_spec>

<vmake_optlist> = [-<vmake_opt>{<vmake_opt>}] [+e]

<vmake_opt> = b | c | d | D<digit> | F | g | i | I | k | K | l | L | m | M | n | p | r | S | u | U | w | x

General Rules

  1. In <ext_option>, <token_sep> = /
  2. <desc_ext> can be omitted in <desc_spec>

vmake -D4i vzz34x//debug/profile

vmake -D4 -l -p demo.mac

vmake demo

Explanation:

You can specify additional Options for Description Files in the VMAKE call for the translation of module files using VMAKE. Where applicable, these options are combined with the options that are specified in the description files used at the same time. The options specified for description files in the VMAKE call must be separated from <target> with two slashes.

The options for description files are separated from each other with one slash.


Options for Calling VMAKE (MaxDB: Development Environment)

Options for Calling VMAKE

Option | Description
D<digit> | Information on internal data and program runs is output. The larger <digit> is, the more information is output.
i | interactive VMAKE is executed interactively (default setting for Microsoft Windows). In UNIX systems, VMAKE creates a new process that assumes all of the tasks. The parent process shows all of the messages from the child process, and waits for termination signals. If you use the i option, a new process is not started, and the standard signal handlers are used.
w | This option corresponds to the default setting for UNIX systems, with the exception that the parent process is terminated by a termination signal without a query. Normally, this signal leads to a query asking you to confirm whether you want to terminate or continue.
b | background This option terminates the parent process once the child process has been successfully generated. Note: the child process is generated once all of the descriptions have been collected. Normally, the first child process message is <date> start of <target>. VMAKE is executed interactively before this message, that is, the standard signal handlers are used.
c | print collection only Once all of the description files have been collected, all of the description information is displayed, and VMAKE is terminated. This can be used to check the description files (or the VMAKE tool).
m | print module list only Once all of the description information has been collected, all of the required module files are output.
x | print commands before execution All of the file system commands executed by VMAKE are first displayed.
n | no execution VMAKE functions as normal, but no file system or OS commands are executed. VMAKE assumes that all of these operations have been successfully carried out.
r | unpack module frames only ('retrieve') Normally, module files are 'freed' from their frame and then translated. This option suppresses translation and linking. The unpacked module files remain in the working directory. No further operations are executed.
L | lint This option analyzes C module files using Lint. No further operations are executed.
S | sizeof Size information for types and variables is extracted from PASCAL module files. No further operations are executed.
d | do not make dependencies Only the targets listed in the command line are created (if they are not up to date). Dependent module files are assumed to be up to date. For test purposes, therefore, you can avoid having to update all of the dependent module files.
u | unconditionally make named targets All named module files are explicitly retranslated and linked. All dependent module files are translated and linked as standard, depending on whether they are up to date. All named description files are explicitly relinked.
U | unconditionally make ALL targets (except includes) All named module files, and files that are dependent on them, are translated and linked (exception: include files).
I | unconditionally make includes too (with -U) When this option is used with the - U option, include files are regenerated.
k | keep temporary files Temporary files created by VMAKE are not deleted. These are unpacked module files, object files, and others.
K | keep temporary files Temporary files created by VMAKE are not deleted. In addition, all scripts are assigned the –k option, with the result that they also do not delete their temporary files.
p | include profiling calls into all targets You use this option to specify profiling for all module files.
M | more information (print manual entry) You use this option to display the vmakman file.
l | local make This option prevents object files from smaller path hierarchies from being used. VMAKE only translates module files that originate from the lowest path hierarchy. This option overrides the $VMAKE_OPTION parameter g.
g | global make Use of the complete path hierarchy $VMAKE_PATH for finding object files is initiated. This option overrides the $VMAKE_OPTION parameter I.
R | require To speed up the creation process, the ? require : <source> option in the description files is not evaluated (default setting in VMAKE). If you use the R option, the ? require : <source> option is taken into account.
F | file list for release You use this option to create a distribution list; any obsolete targets, however, are not updated. All files from the called target that have been assigned the distrib or distribute option for description files are entered in a list. This list is saved in a file in the $INSTROOT/etc directory. The name of the file is the same as the name of the called target. The file is given the extension .lst. The all.lst file is created when you enter imf -F all .
+e | If you have specified software creation in debug mode using the $VMAKE_OPTION parameter, you can deactivate debug mode with the +e option.

Integration

Grammar for the VMAKE Call


VMAKE Tools (MaxDB: Development Environment)

VMAKE Tools

The tools used by VMAKE are essentially scripts . These can be written in any script or prototyping language. The shell used to execute the scripts is defined in the environment variable $TOOLSHELL .

The VMAKE tools accept both absolute and relative path specifications for module files and description files . The targets are created in the current run directory specified by VMAKE and are then stored in the specified target directory.


Storage Location of the VMAKE Tools (MaxDB: Development Environment)

Storage Location of the VMAKE Tools

VMAKE initially assumes that the VMAKE tools are stored in the $TOOL/bin directory. If this is not the case, VMAKE searches every local <path> along the <path>/sys/tool/bin path.


Scripts for the VMAKE Tools (MaxDB: Development Environment)

Scripts for the VMAKE Tools

Script Name | Description
mfainc [-<token>=<value>] source | Extracts the include code from an Assembler include file and writes it to the file < file_name >.h. Further options define conditional compilation
mfcinc [-<token>=<value>] source | Extracts the include code from a C/C++ include file and writes it to the file <file_name>.h. Further options define conditional compilation
mfpinc [-<token>=<value>] source | Extracts the include file from a C/C++ include file. Extracted CONST definitions are written to the file <file_name>.con; extracted TYPE definitions are written to the file <file_name>.typ. Further options define conditional compilation
mfcexp [-<token>=<value>] source | Writes the exported interface (define section of the text frame) to the file <file_name>.h. Further options define conditional compilation
mfa [-trace=<procedure>] [-check=no] [-<token>=<value>] source [includes] | Extracts the code section of an Assembler module file and writes it to the file <file_name>.s. If include files are required, they must be specified in the correct order. The -trace=... and -check=... options are inserted to ensure compatibility with mfp scripts, and are ignored by the mfa script. Further options define conditional compilation
mfc [-trace=<procedure>] [-check=no] [-<token>=<value>] source [includes] | Extracts the code section of a C/C++ module file and writes it to <file_name>(.c |.cpp). If include files are required, they must be specified in the correct order. If $VMAKE_VERSION is defined as slow , #define DEBUG is used as a prefix for the file name. The -trace=... and -check=... options are inserted to ensure compatibility with mfp scripts, and are ignored by the mfc script. Further options define conditional compilation
mfp [-trace=<procedure>] [-check=no] [-<token>=<value>] source [includes] | Extracts the defined section, use section, and code section of a PASCAL module file and writes them to the file <file_name>.p. If include files are required, they must be specified in the correct order. The -trace=<procedure> option specifies the name of the trace procedure, whose call is inserted at the start of every function and procedure. The -check=no option defines whether the name prefixes of exported procedures are to be checked. Further options define conditional compilation
mfsize [include-list] module | Creates a file <file_name>.siz that contains size information on the types of module file used. If include files are required, they must be specified in the correct order.
mfextra [-<token>=<value>] source destination [includes] | Creates files that do not require translation . Further options define conditional compilation and attributes of the files that do not require translation.
compa [as-flags] source | Translates an Assembler module file. The file <file_name>.o is created.
compc [cc-flags] source | Translates a C/C++ module file. The file <file_name>.o is created.
compp [pc-flags] source | Translates a PASCAL module file. The file <file_name>.o is created.
comppc [pc-flags] source | Translates a PASCAL module file into a C module file.
complint [cc-flags] source | Uses LINT to check a C module file.
archive [ar-flags] library objects | Writes object files to the library.
linkrel [ld-flags] relocatable objects | Writes object files to a relocatable object . The name of the created relocatable object is relocatable.
linkshr [ld-flags] relocatable objects | Writes object files to a relocatable object, the global variables of which must be stored in the shared memory. The name of the created relocatable object is relocatable.
linkdll [ld-flags] dll archive objects | Links object files to a dynamic library dll and generates a static library archive.
linklnk [ld-flags] [-o program] objects | Links a program with the name program.
linkshm [ld-flags] [-o program] objects | Links a program with the name program, the global variables of which must be stored in the shared memory.

VMAKE completes the names of the scripts using the $TOOLEXT variable (if available), which defines the file extension of the scripts. If additional parameters are to be sent to $TOOLSHELL , they must be defined in the environment variable $TOOLOPT .


Selecting the Translation Tools (MaxDB: Development Environment)

Selecting the Translation Tools

Module files can be written in different programming languages.

Special VMAKE tools are provided for translating PASCAL, C/C++, and Assembler, as well as a tool for translating a group of various description languages, such as IDL, Resource, Yak, Lex, and so on.

Names of the Available Tools

 |  | Assembler | PASCAL | C / C++ | Description Language Group
Phase 1 | Unpack imported interface | mfainc | mfpinc | mfcinc | mfcinc
 | Unpack exported interface | mfaexp | mfpexp | mfcexp | mfcexp
 | Unpack module | mfa | mfp | mfc | mfrc
Phase 2 | Translate | compa | comppc | compc | comprc

Each tool consists of a set of scripts that can be modified in the Langinfo initialization file .

Assignment Between File Extension or Last Character and Translation Tool

VMAKE assigns module files to a specific tool on the basis of the file extension. If the file does not have an extension, it is assigned on the basis of the last character in the file name.

 | Assembler | PASCAL | C / C++ | Description Language Class
File extension | s | p, t | c, h / cpp, hpp | rc, ico, def, mc, dlg, idl, ycc, lex, rgs
Last character | a | p, t or a number | c / x | r

The assignment of the translation tools on the basis of the file extension or last character in the file name can be modified in the Langextinfo initialization file .


Options for VMAKE Tools (MaxDB: Development Environment)

Options for VMAKE Tools

The following options are transferred by VMAKE

-language=<lang id>

Abbreviation for the programming language of the source code.

The following options can be transferred by VMAKE

-k | Temporary files are not deleted
-p | Profiling is activated (for at least one module file)
-g | Debug mode is activated (for at least one module file)
-Y | Shared global data, PTOC pointer conversion
-unpack=no | The source code does not contain a frame (mf* scripts only)

Depending on the tool in question, these options are either used or ignored.

The specified options for calling VMAKE and options for description files also apply here.


Creating Description Files (MaxDB: Development Environment)

Creating Description Files

General Grammar for Description Files

Options for Description Files


General Grammar for Description Files (MaxDB: Development Environment)

General Grammar for Description Files

<debug_opt> = debug | d

<digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<letter> = A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | r | u | v | w | x | y | z

<new_line> = explicit line break

<profile_opt> = profile | p

<sign> = + | -

<tabulator> = tab

<vmake_default> = f | q | s

<vmake_version> = f | q | s

<extended_letter> = all other printable characters

<character> = <digit> | <letter> | <extended_ letter>

<identifier> = <token>

<space> = [<space>] | [<space>]<tabulator>

<token_sep> = {<token_sep>}<space>

<token> = <character>{<character>}

<list> = [<list>,],{<character>}<token_sep>

<ext_list> = [<ext_list>,],[<sign>]{<character>}<token_sep>

<comment> = [<comment><token_sep>]<token>

<compile_option> = <extended_letter><token>

<demand_spec> = demand[{<layer>{<layer>}}]

<dep_list> = (obj | inc | dep | <demand spec>)=(<list> | <ext_list> | EMPTY)

<expr> = <character>{<character>} | (<expr>) | not<space><expr> | ![<space>]<expr> | <expr><space>[(not | !)<space> ]in<space>[[<space>]<expr>{[<space>] ,[<space>]<expr>}[<space>]] | <expr>=[=]<expr> | <expr>!=<expr> | <expr>&&<expr> | <expr>||<expr>

<layer> = <letter><letter>{<letter>}

<mf_option> = <token>[=<value>]

<option> = [<option><token_sep>](<dep_list> | <mf_option> | <compile_option> | <target_option>)

<option_block> = ([f | [q | [s) <option> {<option>} (f] | q] | s])

<ext_option> = <option_block> | <option> | EMPTY

<target_option> = uncond | remake | <debug opt> | binary | ascii | exec | definition | interface | <profile opt> | shrglob | noshrglob | noobjcopy | (<vmake_version>[<vmake_default>]) | -><token> | <ext_target_option> | <ext_target_option_list>

<ext_target_option> = ?<token_sep>(default_layer | default_version | require | -><token> | propagate)<token_sep>(: | ([<character>]))<token_sep><token>

<ext_target_option_list> = ?<token_sep>(output | link_with | link_option | tool_option)<token_sep>(: | ([<character>]))<token_sep><token>{<token_sep>,<token_sep><token>}

<ext_target_option_line> = (<ext_target_option> | <ext_target_option_list>) <new_line>

<value> = <character>{<character>}

<def line> = &define | &undef <identifier> [<value>]<new_line>

<comment_line> = #<comment><new_line>

<block> = <instance_block> | <sub_block>

<instance_block> = (<instance_block_start>{<sub_block>}<instance_block_end>) | EMPTY

<instance_block_start> = (&fast | &quick | &slow) <comment><new_line>

<instance_block_end> = (&endfast | &endquick | &endslow) <comment><new_line>

<sub_block> = {<line>} | <sub_block_start>{<line>}<sub_block_end>

<sub_block_start> = &if <expr>{<space>}<new_line> | &ifdef | &ifndef | &ifvar | &ifnvar) <identifier>{<space>}<new_line>

<sub_block_end> = &endif <comment><new_line> | &else <comment><new_line> | &elif <comment><new_line>

<line> Line

For more details, see Grammar for Link Descriptions , Grammar for Compilation Descriptions , or Grammar for Processing Lists .

General Rules

  1. <token> can contain a maximum of 512 characters
  2. <token> must not contain a <space>
  3. If <instance_block_start> contains the string &xxx , <instance_block_stop> must contain the character string &endxxx .
  4. If the <option_block> expression starts with [x , it must end with x] .
  5. In <mf_option> , <token> must start with <letter> or <character> .


Grammar for Link Descriptions (MaxDB: Development Environment)

Grammar for Link Descriptions

Link descriptions are based on the general grammar for description files , the naming conventions for module files , and the naming conventions for description files .

<link_description> = {<block>} | EMPTY

<line> = <link_desc_line>

<link_desc_line> = <comment_line> | <link_line> | <def_line> | <ext_target_option_line> | <tool_option_line> | <file> | EMPTY

<tool_option_line> = <extended_letter><token><new_line>

<file> = (/ | $)<token>

<link_line> = [<source_spec>|<desc_spec>]<new_line>

General Rule

In <tool_option_line> , <ext_character> must not begin with / | $ | !


Grammar for Compilation Descriptions (MaxDB: Development Environment)

Grammar for Compilation Descriptions

Compilation descriptions are based on the general grammar for description files and the naming conventions for module files .

<compile_description> = {<block>} | EMPTY

<line> = <comp_desc_line>

<comp_desc_line> = <comment_line> | <comp_line> | <def_line> | <option_line> | EMPTY

<comp_line> = (<source_spec> | <reg_source>)<token_sep>{<option>}<new_line>

<reg_source> = regex(<regex>) | ([<source_id>]*[<lang_id>][<variant>])

<source_id> = g | h | i | v

<regex> = regular expression (GNU)


Grammar for Processing Lists (MaxDB: Development Environment)

Grammar for Processing Lists

Processing lists are based on the general grammar for description files , the naming conventions for module files , and the naming conventions for description files .

<macro_description> = {<block>} | EMPTY

<line> = <macro_desc_line>

<macro_desc_line> = <comment_line> | <macro_line> | <def_line> | <ext_target_option_line>

| <command_line> | EMPTY

<command_line> = ![! | ?]<command>

<command> = {<character>}

<macro_line> = [<source_spec>|<desc_spec>]<new_line>

General Rule

In <tool_option_line> , <ext_character> must not begin with / | $ | !


Options for Description Files (MaxDB: Development Environment)

Options for Description Files

By specifying options in description files, you can influence the translation process and link operation , as well as modify the system default for certain processes.

Some of these options differ depending on the type of description file.

Options for Link Descriptions

Options for Compilation Descriptions

Options for Processing Lists


Options for Link Descriptions (MaxDB: Development Environment)

Options for Link Descriptions

The following options are available for link descriptions :

? defaultlayer : <layer>

? defaultlayer :

? defaultversion : <vmake_version>

? defaultversion :

? distribute : <list>

? link with : <list>

? linkoption : <list>

? output : <list>

? propagate : <variable>[=<value>]

? require : <target>

? tooloption : <list>

-><output>

ascii

binary

debug|d

definition

demand

demandŒ <relative_path>

demand=<list>

demandŒ <relative_path> =<list>

dep=<list>

distrib

extdep=<list>

inc=<list>

interface

nobind

nodistrib

noobjcopy

noshrglob

obj=<list>

profile|p

remake

shrglob

uncond


Options for Compilation Descriptions (MaxDB: Development Environment)

Options for Compilation Descriptions

The following options are available for compilation descriptions :

? defaultlayer : <layer>

? defaultlayer :

ascii

binary

debug|d

definition

demand=<list>

demandŒ <relative_path> =<list>

dep=<list>

exec

extdep=<list>

inc=<list>

interface

noobjcopy

noshrglob

noversion

obj=<list>

profile|p

remake

shrglob

uncond


Options for Processing Lists (MaxDB: Development Environment)

Options for Processing Lists

Options

The following options are available for processing lists :

!! <command>

!? <command>

! <command>

? defaultlayer : <layer>

? defaultlayer :

? defaultversion : <vmake_version>

? defaultversion :

? distribute : <list>

? propagate : <variable>[=<value>]

? require : <target>

ascii

binary

debug|d

distrib

nodistrib

remake

shrglob

uncond


! <command> (MaxDB: Development Environment)

! <command>

You can only use this option in processing lists .

VMAKE processes a processing list from top to bottom. When the tool reaches this option, and if VMAKE has updated targets up to this point, the OS command <command> is executed.

If no targets have been updated, this command is ignored.


!! <command> (MaxDB: Development Environment)

!! <command>

You can only use this option in processing lists .

VMAKE processes a processing list from top to bottom. When the tool reaches this option, the operating system command <command> is executed.

Unlike the ! <command> option, the command is executed irrespective of whether targets have been updated up to this point.


!? <command> (MaxDB: Development Environment)

!? <command>

You can only use this option in processing lists .

VMAKE processes a processing list from top to bottom. When the tool reaches this option, the operating system command <command> is only executed if all of the preceding targets have been successfully updated.


? defaultlayer : <layer> (MaxDB: Development Environment)

? defaultlayer : <layer>

You can use this option in processing lists , link descriptions , and compilation descriptions .

If the name of a module file does not follow the naming conventions , and if the system cannot determine the corresponding layer as a result, the layer specified in <layer> is accessed.

This option can be repeated several times in a description file.


? defaultlayer : (MaxDB: Development Environment)

? defaultlayer :

You can use this option in processing lists , link descriptions , and compilation descriptions .

If the name of a module file does not follow the naming conventions , and if the system cannot determine the corresponding layer as a result, the layer specified with the ? defaultlayer : <layer> option is accessed.

Use the ? defaultlayer : option if you want to delete the default value for a layer.


? defaultversion : <vmake_version> (MaxDB: Development Environment)

? defaultversion : <vmake_version>

You can use this option in processing lists and link descriptions .

This option defines the VMAKE version to be used to process the following listed files.

To specify a different version subsequently, use the ? defaultversion : <vmake_version> option. This option, therefore, can be used repeatedly in a description file.

To reset VMAKE to the VMAKE version specified in the call, use the ? defaultversion : option.


? defaultversion : (MaxDB: Development Environment)

? defaultversion :

You can use this option in processing lists and link descriptions .

You use this option to delete a VMAKE version that was set with ? defaultversion : <vmake_version> .

The system then uses the VMAKE version specified when VMAKE is called.


? distribute : <list> (MaxDB: Development Environment)

? distribute : <list>

You can use this option in processing lists and link descriptions .

This option can be used to create distribution lists ( -F option for calling VMAKE ). Enter the list of files to be included in the distribution list in <list> .

Specify the file paths in <list> , relative to the $INSTROOT directory (for example pgm/kernel ) .

We recommend that you use the distrib option, if possible, for this purpose.


? link with : <list> (MaxDB: Development Environment)

? link with : <list>

You can only use this option in link descriptions .

If a target requires additional libraries, these can be included in the link description with the ? link with : <list> option.


? linkoption : <list> (MaxDB: Development Environment)

? linkoption : <list>

You can only use this option in link descriptions .

You use this option to transfer the list of options specified in <list> to the tool used for the link operation .


? output : <list> (MaxDB: Development Environment)

? output : <list>

You can only use this option in link descriptions.

Targets of link descriptions are given the name of the link description and are stored in a path specified by VMAKE.

Changing Names and Paths

If you use the ? output : <list> option, you can change the name and/or path of several output files, or create copies of individual files. To do so, you create a list <list>, in which you assign one or more paths to one or more targets. VMAKE then changes the name and path definition specified for this target by the system.

If you specify a directory in the list or end an entry with a slash, the file retains the name assigned by the system and is copied to the specified directory.

If you want to change the name and/or path for one individual output file, use the
-><output> option.

Output Files for Different Platforms

An output file can have different file extensions on different platforms. In this case, specify the file extension * for the target. By doing so, you can avoid having to define individual output files for each platform.

Dynamic libraries have the file extension dll on Microsoft Windows and so or sl (HP-UX) on UNIX. In this case, the option should read:
? output : $DBROOT/misc/libtest.*


? propagate : <variable>[=<value>] (MaxDB: Development Environment)

? propagate : <variable>[=<value>]

You use this option in processing lists and link descriptions to set an environment variable.

The system deletes this variable once the relevant list or link description has been processed.


? require : <target> (MaxDB: Development Environment)

? require : <target>

You can use this option in processing lists and link descriptions . It is only effective with the -R option for calling VMAKE .

You use this option to specify whether a link description requires certain targets to be created.

A tool for forwarding a file to the pre-compiler is to be called in a processing list. In this case, you can use this option to ensure that the pre-compiler is generated first.


? tooloption : <list> (MaxDB: Development Environment)

? tooloption : <list>

You can only use this option in link descriptions .

The options in the <list> are forwarded to the tool that is responsible for the link operation .


-><output> (MaxDB: Development Environment)

-><output>

You can use this option in link descriptions and compilation descriptions.

Targets of link descriptions are given the name of the link description and are stored in a path specified by VMAKE.

Use

Changing Names and Paths

If you want to change the name and/or path for one individual output file, use the
-><output> option.

If you use the ? output: <list> option, you can change the name and/or path of several output files, or create copies of individual files. To do so, you create a list <list>, in which you assign one or more paths to one or more targets. VMAKE then changes the name and path definition specified for this target by the system.

If you specify a directory in the list or end an entry with a slash, the file retains the name assigned by the system and is copied to the specified directory.

Output Files for Different Platforms

An output file can have different file extensions on different platforms. In this case, specify the file extension * for the target. By doing so, you can avoid having to define individual output files for each platform.

Dynamic libraries have the file extension dll on Microsoft Windows and so or sl (HP-UX) on UNIX. In this case, the option should read:
->$DBROOT/misc/libtest.*


ascii (MaxDB: Development Environment)

ascii

You can use this option in processing lists , link descriptions , and compilation descriptions .

The option prevents module files from being translated. VMAKE creates the corresponding target by copying the module file only to the object directory . In contrast to the binary option, the file is treated as a text file.

If you want to store the file in a different location, use the -><output> option.


binary (MaxDB: Development Environment)

binary

You can use this option in processing lists , link descriptions , and compilation descriptions .

The option prevents module files from being unpacked and translated. VMAKE creates the corresponding target by copying the module file only to the object directory . In contrast to the ascii option, the file is treated as a binary file.

If you want to store the file in a different location, use the ->output option.


debug|d (MaxDB: Development Environment)

debug|d

You can use this option in processing lists , link descriptions , and compilation descriptions .

Module files are translated in debug mode .


definition (MaxDB: Development Environment)

definition

You can use this option in link descriptions and compilation descriptions.

The definition option identifies a module file as a definition file for dynamic libraries on Microsoft Windows. Semantically speaking, this option has the same effect as a combination of the options binary and demand .

When this option is assigned to a module file, the file is copied as a binary file to the current working directory tmp before the link operation takes place.


demand (MaxDB: Development Environment)

demand

You can only use this option in link descriptions .

An object file is copied to the tmp directory before the link operation takes place.

If you assign this option to a module file , the resulting object file is requested for the link operation; in other words, it is copied to the working directory specified by VMAKE. Expression of physical dependency.


demand{<relative path>} (MaxDB: Development Environment)

demand{<relative path>}

You can only use this option in link descriptions .

The object file of the identified module file is requested in a specific path for the link operation ; in other words, it is copied to the specified path relative to the working directory. Expression of physical dependency.


demand=<list> (MaxDB: Development Environment)

demand=<list>

You can use this option in link descriptions and compilation descriptions.

The object files (see also "binary") of the listed files are requested when translation is carried out; in other words, they are copied to the relevant working directory. Expression of physical dependency.


demand{<relative path>}=<list> (MaxDB: Development Environment)

demand{<relative path>}=<list>

You can use this option in link descriptions and compilation descriptions.

The object files (see also "binary") of the listed files are requested to a specific path when translation is carried out; in other words, they are copied to the path relative to the working directory. Expression of physical dependency.


dep=<list> (MaxDB: Development Environment)

dep=<list>

You can use this option in link descriptions and compilation descriptions .

Lists the module files on which the specified module file is dependent, that is,

vco01.idl dep=vco03.idl


distrib (MaxDB: Development Environment)

distrib

You can use this option in processing lists and link descriptions .

This option is required to create distribution lists ( -F option for Calling VMAKE ). The files resulting from the target listed directly above this option are included in the distribution list, provided that they are located in the $INSTROOT directory.


exec (MaxDB: Development Environment)

exec

You can only use this option in compilation descriptions . It is only evaluated on UNIX and in conjunction with the ascii or binary options.

When you specify this option, the corresponding target is assigned the execute access authorization.


extdep=<list> (MaxDB: Development Environment)

extdep=<list>

You can use this option in link descriptions and compilation descriptions .

You use this option to define a logical dependency between targets and/or files.

Translating module file X results in the by-product Y. You can use this option to specify that X should be retranslated as soon as Y no longer exists.


inc=<list> (MaxDB: Development Environment)

inc=<list>

You can use this option in link descriptions and compilation descriptions . You list include files that are used by the module file.

The files in <list> must be identifiable as include files.

Files not identifiable as an include file by the extension .h or 00 , or by the letter h as the first letter in the file name, can be identified as such by appending an (i) .

inc=vma18(i)


interface (MaxDB: Development Environment)

interface

You can use this option in link descriptions and compilation descriptions .

By specifying this option, you can ensure that a module file cannot be updated once it has been translated (for example, a defined interface). For this purpose, a file with the extension .i is created on the computer, on which module files with this option are translated.

This module file can only be translated again when VMAKE no longer finds a file of this name with the extension .i in the path hierarchy ( VMAKE_PATH ).


nobind (MaxDB: Development Environment)

nobind

You can only use this option in link descriptions .

The target that has been assigned this option is created but not linked during the link operation .


nodistrib (MaxDB: Development Environment)

nodistrib

You can use this option in processing lists and link descriptions .

This option is specified after the Target nodistrib or directly after the output file in brackets (nodistrib). In this way, you can exclude individual components or files, that would usually be created during the make run, from the delivery list.


noobjcopy (MaxDB: Development Environment)

noobjcopy

You can use this option in link descriptions and compilation descriptions .

Object files that result from module files with this option are not copied. You use this option, for example, if the object contains information that is computer specific or unique across all departments.


noshrglob (MaxDB: Development Environment)

noshrglob

You can use this option in link descriptions and compilation descriptions .

By specifying this option, you explicitly suppress the calculation of size specifications for global variables in the source code. These size specifications are required to use the shared memory.


noversion (MaxDB: Development Environment)

noversion

You can use this option in compilation descriptions .

If you want to create modules used by the header files in such a way that they are version-independent ( VMAKE Versions ), you must use noversion for these modules. The object files and the date files are then copied directly under the $WRK directory in the obj and date directories. In this way, these files are only created once for all versions (fast, quick, slow).


obj=<list> (MaxDB: Development Environment)

obj=<list>

You can use this option in link descriptions and compilation descriptions .

Normally, the translation process with VMAKE generates exactly one object file . The name of this file comprises the name of the module file and the file extension .o .
You use this option if object files other than those that are normally created are generated. <list> can be empty if no object file is created.


profile|p (MaxDB: Development Environment)

profile|p

You can use this option in link descriptions and compilation descriptions .

You can use this option to insert source code for measuring performance (profiling) in a module file.


remake (MaxDB: Development Environment)

remake

You can use this option in processing lists , link descriptions , and compilation descriptions .

When object files are no longer up to date and the target is to be recreated, you can use this option to force a retranslation of the corresponding module files.


shrglob (MaxDB: Development Environment)

shrglob

You can use this option in processing lists , link descriptions , and compilation descriptions .

With this option, you specify that a file is to be created containing the size specifications for the global variables used in the source code. These size specifications are required to use the shared memory.


uncond (MaxDB: Development Environment)

uncond

You can use this option in processing lists , link descriptions , and compilation descriptions .

You use this option if a module file is to be retranslated with every make operation.


VMAKE Logs (MaxDB: Development Environment)

VMAKE Logs

The entire MAKE operation is logged by VMAKE. In doing so, VMAKE generates two output logs and stores them in the prot directory ( General Directory Structure ).

These logs are named after the file name specified as a parameter when the required VMAKE version was called. The files have the extension .p0 or .x0.

File extension | Log
.p0 | Normal log; corresponds to the screen outputs during the creation process
.x0 | Contains detailed information on the individual files as well as the options used to call the VMAKE tools

When these logs are created, older logs with the same name are renamed (the last digit is incremented by 1). A log history comprising up to 10 logs ( .p0 - .p9 ) is, therefore, possible.

You can display the current logs in the editor ( $EDITOR ) using the development environment tool ipf.pl .


Translation Process (MaxDB: Development Environment)

Translation Process

The translation process is divided into two phases:

Unpacking the Module Files

Translating the Module Files


Unpacking the Module Files (MaxDB: Development Environment)

Unpacking the Module Files

VMAKE uses the options in the compilation descriptions to determine where to unpack the module files . The following additional steps can be carried out:

The parts of the frame that are not relevant for translation are removed

Conditional compilation


Removing Frame Parts that are not Relevant for Translation (MaxDB: Development Environment)

Removing Frame Parts that are not Relevant for Translation

Module files that have to be unpacked have a text frame that contains the following information:

  • Name of the module
  • Module specification
  • Author, version, release
  • Exported interface
  • Imported interface
  • Source code
  • Control characters

Since some of the text frame does not have to be translated, those parts of the frame that are not relevant for translation are removed when the file is unpacked.


Conditional Compilation (MaxDB: Development Environment)

Conditional Compilation

VMAKE hides those parts of the source code that are not required under the current conditions, such as unnecessary network connections (UNIX or Microsoft).

The system copies the include files that are to be used to the start of the module file that is awaiting translation.


Translating the Module Files (MaxDB: Development Environment)

Translating the Module Files

VMAKE translates the module files in the temporary tmp directory.

The system stores the resulting object files in an object directory and deletes the files from the temporary directory.


Link Operation (MaxDB: Development Environment)

Link Operation

Object files are linked to form a software component in the tmp directory. VMAKE then stores this component in a predefined (see below) directory, or in a target directory specified in the link description. The component is then deleted from the tmp directory.

For the link operation, VMAKE is equipped with various tools ( VMAKE tools ) for each type of object file that can result from the translation process . VMAKE uses the file extension of the description file to decide which tool to use to link the respective object files.

The tool takes the object files and the relevant options to be used from the link description .

Software Component to be Created | Link Script | Target Directory
Program | linklnk | $DBROOT/pgm
Program that facilitates shared memory access | linkshm | $DBROOT/pgm
Static library | archive | $WRK/fast/obj or $WRK/quick/obj or $WRK/slow/obj
Dynamic library | linkdll | $DBROOT/lib(32 bit) $DBROOT/lib/lib64 (64 bit)
Program that can be linked to other programs | linkrel | $WRK/fast/obj or $WRK/quick/obj or $WRK/slow/obj
Program that can be linked to other programs and facilitates shared memory access | linkshr | $WRK/fast/obj or $WRK/quick/obj or $WRK/slow/obj


Working with the MaxDB Development Environment: Examples (MaxDB: Development Environment)

Working with the MaxDB Development Environment: Examples

Operating the Development Environment

Creating DBMCLI with the MaxDB Development Environment


Operating the Development Environment (MaxDB: Development Environment)

Operating the Development Environment

The operation of the development environment can be explained using an example (objective).

Process Flow

Explanation of the Process Flow

Logs

Further Options

Further Information on Dependencies

Comparison Between the MaxDB VMAKE Program and a Conventional Make Program


Objective (MaxDB: Development Environment)

Objective

· The file sys/src/SAPDB/HelloWorld.c is to be translated.

· The include file sys/src/SAPDB/HelloWorld.h is required for this purpose.

· The result is linked to an executable program:
usr/pgm/hello (or usr\pgm\hello.exe on Microsoft Windows).


Process Flow (MaxDB: Development Environment)

Process Flow

imf.pl hello.lnk

Build: 40283

vmake 9.8.5 28-11-2000

VMAKE_PATH=d:\V73\develop,d:\SAPSRC

17-01-01 13:33:46 start of collection phase

17-01-01 13:33:54 end of collection phase

17-01-01 13:33:54 start of hello.lnk fast

HelloWorld.h

HelloWorld.c fast

hello.lnk fast

s100buildnumber_PID854.c

17-01-01 13:33:55 end of hello.lnk fast


Explanation of the Process Flow (MaxDB: Development Environment)

Explanation of the Process Flow

First, all of the required files are determined.

The description file sys/desc/hello.lnk is recognized as the description of an executable program from the file extension .lnk. This description contains only one file:

:SAPDB/HelloWorld.c

The colon stands for the directory with the module files sys/src.

The system recognizes from the file extension .c that the module file sys/src/SAPDB/HelloWorld.c is a module file that has to be translated with the C compiler. The include files required by this module file are listed in the description file sys/desc/SAPDB.com:

HelloWorld.c    inc=:SAPDB/HelloWorld.h

This line can contain further compiler options.

The include file sys/src/SAPDB/HelloWorld.h does not require any further files. Otherwise, these dependencies would also have to be entered in SAPDB.com.

Once the required files have been determined, each of these files is updated.

· Include Files

HelloWorld.h

HelloWorld.c fast

hello.lnk fast

These files are copied from the development area (General Directory Structure) to a suitable subdirectory sys/wrk/incl, in this case, to sys/wrk/inl/SAPDB/HelloWorld.h.

File names in #include statements, therefore, must always be specified relative to sys/wrk/incl.

· C sources

HelloWorld.h

HelloWorld.c fast

hello.lnk fast

These are converted to object files using the C compiler.

Object files can be created in three different versions (VMAKE versions):

* fast: with optimization

* quick: with assertions

* slow: with assertions and trace outputs

In this case, the file created is written to sys/wrk/fast/obj/SAPDB/HelloWorld.o.

Object files are also assigned the file extension .o on Microsoft Windows.

The source file is copied to the sys/wrk/fast/tmp directory for translation. All of the intermediate results (this is particularly relevant for PASCAL sources) are created in this directory, and can be viewed in the event of an error.

· Executable programs

HelloWorld.h

HelloWorld.c fast

hello.lnk fast

These are linked and copied to usr/pgm.

On UNIX systems, usr/pgm/hello.f is created and a link to it is entered in the file system, under usr/pgm/hello.

On Microsoft Windows, the file usr\pgm\hello.exe.f is created and copied to usr\pgm\hello.exe.


Logs (MaxDB: Development Environment)

Logs

Using the ipf.pl hello.lnk command, you can display two VMAKE logs .

hello.lnk.p0 is a copy of the information displayed on the screen.

hello.lnk.x0 lists all of the relevant timestamps, as well as the actions that were carried out.

...

HelloWorld.c:

17-01-01 18:27:05 dependencies (d:\V73\develop/sys/wrk/incl/SAPDB/HelloWorld.h)

17-01-01 12:29:20 d:\V73\develop/sys/src/SAPDB/HelloWorld.c

17-01-01 12:29:20 d:\V73\develop/sys/wrk/fast/dates/SAPDB/HelloWorld.c.dat

17-01-01 18:27:07 d:\V73\develop/sys/wrk/fast/obj/SAPDB/HelloWorld.o

unconditional     HelloWorld.c

rm d:\V73\develop/sys/wrk/fast/obj/SAPDB/HelloWorld.o

HelloWorld.c fast  debug

D:\SAPDevelop\Devtool\Perl\bin\perl.exe D:\SAPDevelop\Devtool/bin/mfc.pl \

   -f \

   -debug=1 \

   -language=c \

   -unpack=no \

   d:\V73\develop/sys/src/SAPDB/HelloWorld.c \

   d:\V73\develop/sys/wrk/incl/SAPDB/HelloWorld.h

touch HelloWorld.c

D:\SAPDevelop\Devtool\Perl\bin\perl.exe D:\SAPDevelop\Devtool/bin/compc.pl \

   -g \

   -language=c \

   HelloWorld.c

HelloWorld.c

touch HelloWorld.o

mv HelloWorld.o d:\V73\develop/sys/wrk/fast/obj/SAPDB/HelloWorld.o

touch d:\V73\develop/sys/wrk/fast/dates/SAPDB/HelloWorld.c.dat (from HelloWorld.c)

17-01-01 18:30:53 d:\V73\develop/sys/wrk/fast/obj/SAPDB/HelloWorld.o

...

If you want to know exactly which options were used to call the compilers or linkers, set the environment variable NOQUIET.

UNIX: NOQUIET=1; export NOQUIET

Microsoft Windows: set NOQUIET=1

imf -u :SAPDB/HelloWorld.c

HelloWorld.c fast

cl -DREL30 -DWIN32 -DI386 -DSAG -Id:\V73\develop\sys\wrk/incl/SAPDB -DDU

MP_ENABLED -D_WIN32 -G6 -D_X86_=1 -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nol

ogo -Gy -W2 -MT -DFAST=FAST -Ox -ID:/SAPDevelop/Devtool/incl -FoHelloWor

ld.o -c HelloWorld.c


Further Options (MaxDB: Development Environment)

Further Options

Forced Translation

Working with Debug Information


Forced Translation (MaxDB: Development Environment)

Forced Translation

  • -u option

Creates the specified target as a new target. A new link is created to an executable program.

imf.pl -u hello.lnk

hello.lnk fast

A module file is retranslated.

imf.pl -u :SAPDB/HelloWorld.c

HelloWorld.c fast

  • -U option

Recreates the specified target and all of the necessary module files .

imf.pl -U hello.lnk

HelloWorld.c fast

hello.lnk fast

  • -U –I option

Recreates the specified target, all of the necessary modules, and all of the required include files .

imf.pl -U -I hello.lnk

HelloWorld.h

HelloWorld.c fast

hello.lnk fast


Working with Debug Information (MaxDB: Development Environment)

Working with Debug Information

The -e option instructs VMAKE to generate all targets with debug information ( Debug Mode ).

imf.pl -U -e hello.lnk

HelloWorld.c fast debug

hello.lnk fast debug

usr/pgm/hello can then be started in the debugger. The source files are copied to sys/wrk/fast/debug after the translation process . This is particularly important for PASCAL module files , since these can only be debugged using the generated C file, and not in the source code itself.


Further Information on Dependencies (MaxDB: Development Environment)

Further Information on Dependencies

Displaying the New Targets to be Created

Displaying the Module and Description Files Used

Displaying the Module and Description Files Used, and their Dependencies


Displaying the New Targets to be Generated (MaxDB: Development Environment)

Displaying the New Targets to be Generated

imf.pl -u -n hello.lnk

vmake 9.8.5 28-11-2000

VMAKE_PATH=d:\V73\develop,d:\SAPSRC

17-01-01 04:50:40 PM start of collection phase

17-01-01 04:50:48 PM end of collection phase

17-01-01 04:50:48 PM start of hello.lnk fast

HelloWorld.c fast

hello.lnk fast

17-01-01 04:50:48 PM end of hello.lnk fast

statistics:

macros: 0

programs: 1

dynlinklibs: 0

relocs: 0

libraries: 0

modules: 1

includes: 1

files: 0

commands: 0

extras: 0


Displaying the Module and Description Files Used (MaxDB: Development Environment)

Displaying the Module and Description Files Used

imf.pl -m hello.lnk

desc/Langextinfo

desc/SAPDB.com

desc/hello.lnk

src/SAPDB/HelloWorld.h

src/SAPDB/HelloWorld.c


Displaying the Module and Description Files Used, and Their Depe (MaxDB: Development Environment)

Displaying the Module and Description Files Used, and Their Dependencies

imf.pl -C hello.lnk

program

name 'hello.lnk'

type TT_PGM

version 'f'

language ' '

layer ''

level_i 2

level_s 2

level_p 0

level_c 0

level_o 2

shrglob 0

debug 0

profile 0

uncond 0

forcemake 0

binary 0

ascii 0

definition 0

noobject 0

noobjcopy 0

deptype 0

nodebug 0

file

descriptions

options

dependencies

'HelloWorld.c' 'f'

demands

external dependencies

callers

...


Comparison Between MAXDB VMAKE and a Conventional Make Program (MaxDB: Development Environment)

Comparison Between MAXDB VMAKE and a Conventional Make Program

To those who are familiar with the traditional UNIX make or Microsoft nmake programs, some of the features of VMAKE might seem a little surprising.

· Since all of the include files are copied to sys/wrk/incl and all of the source files are copied to a temporary directory before translation, file names in the error messages output by the compiler never point to the actual source file.

· The program always attempts to generate as much as possible, and does not stop after the first error. This is equivalent to the -k option in make.

· Each object file has a date file (for example, sys/wrk/fast/dates/SAPDB/HelloWorld.c.dat). An new object file is created:

· If the existing object file is older than the source file (as in make)

· If the timestamp of the date file differs from that of the source file.


Creating DBMCLI with the MaxDB Development Environment (MaxDB: Development Environment)

Creating DBMCLI with the MaxDB Development Environment

Database Manager CLI

The Database Manager CLI (Database Manager Command Line Interface, DBMCLI) communicates with the DBM server, and can therefore be used to administrate a MaxDB instance. The behavior of the Database Manager CLI depends on the call parameters and user entries. For more information about the Database Manager CLI, see the Database Manager CLI documentation.

Database Manager CLI tasks:

The Database Manager CLI establishes the connection to the DBM server, and transfers one or more commands to it.

The Database Manager CLI accepts and outputs the DBM server response(s).

When the Database Manager CLI has been terminated, the connection to the DBM server is closed.

See also:

Structure of the Database Manager CLI

Creating the Database Manager CLI

...

1. Follow the instructions in Creating the Database Manager CLI.

2. Perform a function check.


Structure of the Database Manager CLI (MaxDB: Development Environment)

Structure of the Database Manager CLI

The Database Manager CLI consists of the following components:

· Main Components

· Communication Components

· DBM Server

Main Components

Tasks of the main components:

· Accept and evaluate the call parameters and user entries.

· Transfer the dbm commands to the communication components.

· Receive the DBM server responses from the communication components.

· Evaluate and output the DBM server responses.

Communication Components

Tasks of the communication components:

· Communication with the local DBM server.

· Communication with a DBM server on a remote host.

The communication components are components of the database system runtime environment.

DBM Server

A DBM server is integrated in the Database Manager CLI.

If the user requires, this integrated DBM server can be used. In this case, the components required to connect to a separate DBM server are not used.


Creating the Database Manager CLI (MaxDB: Development Environment)

Creating the Database Manager CLI

The Database Manager CLI is created in the MaxDB development environment by processing information from a link description . This link description is a file of the lnk file type, and is called dbmcli.lnk ( $OWN /sys/desc/dbmcli.lnk, see also General Directory Structure of the MySQL MaxDB Development Environment ).

Processing this link description leads to the creation of an executable program. The file dbmcli.lnk also defines where the executable program is stored:

· Microsoft Windows: The executable program is stored in the directory $OWN\usr\pgm.

· UNIX: The line ->$INSTROOT /bin/dbmcli is inserted in the link description dbmcli.lnk. As a result, the executable program is stored in the directory $OWN/usr/bin.

Procedure

Enter the following command:

imf dbmcli

For information about the command imf, see ims.pl; imq.pl; imf.pl.

This command instructs the development environment to process the link description dbmcli.lnk .

The link description file does not have to be specified with its type ( lnk), since its name is unique. The development environment automatically determines the type of the link description file, and, therefore, the type of processing.

Result

The DBMCLI (Database Manager CLI) software component is created:

· UNIX: $OWN/usr/bin/dbmcli

· Microsoft Windows: $OWN\usr\pgm\dbmcli.exe

Perform a function check.

Integration

Creating DBMCLI with the MaxDB Development Environment


Link Description dbmcli.lnk (MaxDB: Development Environment)

Link Description dbmcli.lnk

The following extract from the link description dbmcli.lnk contains the main commands required for Creating the Database Manager CLI. Special commands and switches, which may be needed for the link operation on the individual platforms, have been omitted from this example.

To create the Database Manager CLI, you must always use the complete link description file dbmcli.lnkin the source directory (see General Directory Structure of the MySQL axDB Development Environment).

&if $OS in [ WIN32, OS2 ]
    :Resource/dbmcli.rc remake
&endif

vcn12.cpp
vcn13.cpp
vcn14.c

cservlib

splib
eoxlib

&if $OS in [ WIN32, OS2 ]
    sqlusr
&else

    enalib
    enblib

&endif

Further Information

Explanation of the Link Description dbmcli.lnk

Components of DBMCLI


Explanation of the Link Description dbmcli.lnk (MaxDB: Development Environment)

Explanation of the Link Description dbmcli.lnk

The link description dbmcli.lnk contains references to module files and link descriptions .

  • References to module files cause these module files to be translated. The translation tools are assigned on the basis of the file extension of the module files.
    Module files in this example link description:
    dbmcli.rc, vcn12.cpp, vcn13.cpp, vcn14.c
  • References to link descriptions cause these descriptions to be processed in accordance with their description type.
    Link descriptions in this example:
    cservlib, splib, eoxlib, sqlusr, enalib, enblib

You can find explanations of the module files and link descriptions in the section Components of DBMCLI .


Components of DBMCLI (MaxDB: Development Environment)

Components of DBMCLI

The Database Manager CLI consists of the following components:

  • Module file dbmcli.rc
  • Module file vcn12.cpp
  • Module file vcn13.cpp
  • Module file vcn14.c
  • Link description cservlib
  • Link description splib
  • Link description eoxlib
  • Link description sqlusr
  • Link description enalib
  • Link description enblib

Other Dependencies

Integration

Link description dbmcli.lnk


dbmcli.rc (MaxDB: Development Environment)

dbmcli.rc

The module file dbmcli.rc in the link description dbmcli.lnk is only relevant under Microsoft Windows. For this reason, the module is encapsulated in a condition in the link description file dbmcli.lnk.

The module file dbmcli.rc is a resource file and is stored in the subdirectory $OWN \sys\src\Resource (General Directory Structure of the MySQL MaxDB Development Environment). If the module file dbmcli.rc is specified in the link description file dbmcli.lnk, the Resource directory must also be specified explicitly:

:Resource/dbmcli.rc

The module file dbmcli.rc contains source code that is specific to Microsoft Windows. When this file is specified in the link description file, the relevant resources are integrated in the Database Manager CLI.

Integration

Components of DBMCLI


vcn12.cpp, vcn13.cpp, vcn14.c (MaxDB: Development Environment)

vcn12.cpp, vcn13.cpp, vcn14.c

The module files vcn12.cpp, vcn13.cpp, and vcn14.c from the link description dbmcli.lnk are stored in the directory $OWN /sys/src/cn. This directory name is determined implicitly from the module file name.

These module files are the main components (see Structure of the Database Manager CLI )of the Database Manager CLI, and contain C or C++ source codes.

  • The main function is stored in module file vcn12.cpp.
  • The module file vcn13.cpp contains certain functions required for file access and character set conversion.
  • The module file vcn14.c is used to connect main components with communication components.

In the module files vcn12.cpp, vcn13.cpp and vcn14.c, #include instructions are used to refer to include files .

The dependency of a module file on an include file is described in the compilation description .

Integration

Components of DBMCLI


Compilation Description (MaxDB: Development Environment)

Compilation Description

In the module files vcn12.cpp, vcn13.cpp, and vcn14.c of the link description dbmcli.lnk , #include instructions are used to refer to include files.

The dependency of a module file on an include file is described in the compilation description . The compilation description appropriate to the module file is determined and evaluated implicitly using the directory in which the module file to be translated is stored.

In addition to the dependency of a module file on include files, the compilation description specifies further properties of the module files that control how they are translated by the development environment.

Further Information

Include Files of the module files vcn12.cpp, vcn13.cpp, and vcn14.c


Include Files (MaxDB: Development Environment)

Include Files

The dependencies of a module file on include files is explained in the following example of a module file of the link description dbmcli.lnk .

The dependencies for the module file vcn12.cpp in the directory $OWN /sys/src/cn are contained in compilation description $OWN/sys/desc/cn.com. These are described by the following lines in the compilation description:

vcn12.cpp inc=gsp09.h,heo02.h,hcn13.h,hcn14.h,hcn90.h,...

This example only contains the keyword inc. The keyword inc refers to the required include files.

The include files listed after the keyword inc are created by the development environment in include directory $OWN/wrk/incl before the module file is translated. In doing so, the development environment processes the include files according to their file type.

Only type h include files are shown in the example above. Type h include files are copied from the relevant subdirectory under $OWN/sys/src to a subdirectory of the include directory. The name of this subdirectory is determined implicitly by the development environment from the name of the include file.


cservlib (MaxDB: Development Environment)

cservlib

The link description cservlib ($OWN /sys/desc/cservlib.lib) is of the type lib. The link description type libgenerates a static library.

A lib type link description consists of several module files that are grouped after translation to form the appropriate library. The dependencies and properties of the individual module files are stored in the directory-specific compilation descriptions.

If cservlib is entered in link description dbmcli.lnk, the cservliblibrary is integrated in the Database Manager CLI.

The cservlib library contains the functionality of the DBM server integrated in the Database Manager CLI (see Structure of the Database Manager CLI).

Integration

Components of DBMCLI


splib (MaxDB: Development Environment)

splib

The link description splib ( $OWN /sys/desc/splib.lib) in the link description dbmcli.lnk is of the type lib.

The splib library contains modules with functions that can be used generally.

Integration

Components of DBMCLI


eoxlib (MaxDB: Development Environment)

eoxlib

The link description eoxlib ($OWN /sys/desc/eoxlib.lib) in the link description dbmcli.lnk is of the type lib.

The library eoxlib contains communication components of the database system runtime environment (see Structure of the Database Manager CLI).

Integration

Components of DBMCLI


sqlusr, enalib, enblib (MaxDB: Development Environment)

sqlusr, enalib, enblib

The link descriptions sqlusr, enalib, enblib ($OWN /sys/desc/sqlusr.lib, $OWN/sys/desc/enalib.lib, $OWN/sys/desc/enblib.lib) are of the type lib.

The libraries sqlusr, enalib, enblib contain communication components of the MaxDB runtime environment (see Structure of the Database Manager CLI). Because the MaxDB runtime environment is platform-specific, different libraries are used for UNIX than those used for Microsoft Windows. For this reason, the link descriptions are encapsulated in a condition in the Link description dbmcli.lnk.

Integration

Components of DBMCLI


Further Dependencies (MaxDB: Development Environment)

Further Dependencies

If you are using Microsoft Windows, note that the Database Manager CLI requires a dynamic library. This library must be created explicitly.

To do so, enter the following command:

imf sqltcp

For information about the command imf, see ims.pl; imq.pl; imf.pl.

Integration

Components of DBMCLI


Function Check (MaxDB: Development Environment)

Function Check

You can check the function of the Database Manager CLI by executing a dbm command.

Prerequisites

Creating the Database Manager CLI

Procedure

...

1. Check whether you are actually accessing the software component you have just created, the Database Manager CLI ($OWN /usr/bin/dbmcli, Microsoft Windows: $OWN\usr\pgm\dbmcli.exe).

2. Enter the dbm command for displaying the Database Manager version:

dbmcli [-n <server_node>] -d <database_name> -u <dbm_userid>,<dbm_password> dbm_version

dbmcli -d TST -u dbm,dbm dbm_version

For more information on the DBM commands, see the Database Manager CLI documentation.

Result

The output should roughly be as follows:

OK

VERSION    = 7.2.4

BUILD      = DBMServer 7.2.4    Build 009-000-220-192

OS         = UNIX

INSTROOT   = /usr/sapdb-srv

LOGON      = False

CODE       = ASCII

SWAP       = full


Source Code for Tools

The database tools Database Manager GUI and SQL Studio were developed using Microsoft Visual Basic 6.0.

This document describes how you install the source code for each of the tools and for the development environment VBMAKE and then create the software for it.

Source Code for the Database Manager GUI

Source Code for SQL Studio

For a detailed description of how to use these tools, see also: Database Manager GUI and SQL Studio.


Source Code for the Database Manager GUI (MaxDB: Source Code for Tools)

Source Code for the Database Manager GUI

The Database Manager GUI is a database management tool. The Database Manager GUI is used to control and monitor the database instance and to execute of backups. The Database Manager allows you to access remote database servers.

The Database Manager GUI was developed exclusively using Microsoft Visual Basic 6.0. The components of the Database Manager GUI are ActiveX libraries and ActiveX control elements.

Note which software is required for installing the source code and creating the Database Manager GUI software .

In our experience, it is difficult to work with group projects in the development environment of Microsoft Visual Basic because of the very complex structure of the Database Manager GUI program. For this reason, SAP recommends that you use the VBMAKE tool to create the Database Manager GUI, and that you follow the procedure described under Creating the Database Manager GUI Software.


Components of the Database Manager GUI (MaxDB: Source Code for Tools)

Components of the Database Manager GUI

The Database Manager GUI was developed exclusively with Microsoft Visual Basic 6.0.

Name of Component | Function | Description
DBMGUI | Client | Main Database Manager GUI program
DBMLIB | Object Library | Extensive object hierarchy for functionality of Database Manager GUI
DBMSOB | Server Object | Object for Database Manager API (dbmapi.dll)
DBMEVE | Event Handler | Global event manager
DBMAPP | Application Server | ActiveX Server that manages a registered database instance
DBMDOC | Documents | Contains a control element for each main function of the Database Manager GUI
DBMRES | Resource Library | All images (images and icons) that are used
DBMCMD | Command Control | Manages command lists from which the menus and toolbars are created
DBMINP | Input Control | Date and time entry
DBMSPL | SplitterBox Control | Manages ActiveX control elements so that the split/size can be changed using a resize bar
DBMREG | Registry Library | Functions for managing the registry
DBMSCR | ScrollBox Control | Manages an ActiveX control element so that you can change the position using a scroll bar
DBMDRT | DrawText Control | Displays text using the Windows API function of the same name
DBMFLB | FloodBar Control | Flood bar to display the fill levels of a database instance
DBMINF | InfoPanel Control | Control element for displaying various information
DBMSEP | SepLine Control | 3D separator
DBMWIZ | Database Creation Wizard | Main program of the wizard to create database instances
DBMTIB | TitleBar Control | Title bar with image, title, time and close button
DBMPWD | Password Library | Encryption and decryption of the user password stored in the registry for a registered database instance (not available as source code).
DBMDBG | Debug Server | Utility for correction (debug). To do so, select database instance, choose Ctrl-D, click the right mouse button on the desired database instance and then choose Trace
DBMINS | Installer | Utility for registration and deregistration of all components of the Database Manager GUI


Software for the Database Manager GUI (MaxDB: Source Code for Tools)

Software for the Database Manager GUI

You must install the following software on your computer before installing the source code and creating the Database Manager GUI software:

· Microsoft Windows NT 4.0 Service Pack 5 or higher

· Microsoft Visual Basic 6.0 Service Pack 3 or higher

You also require the file

· sapdb-tools-source-7.4.zip

This contains all of the necessary components for the installation of the source code and for creating the Database Manager GUI software.


Installing the Source Code (MaxDB: Source Code for Tools)

Installing the Source Code

Prerequisites

You have the software required for the installation (see Software for the Database Manager GUI, Software for SQL Studio).

Procedure

1. Unpack the file sapdb-tools-source-7.4.zip in a location of your choice on your hard disk.

This operation creates the following directory structure:

-\SAPDBTools | Main directory
..\bin | Created components and programs
..\licence | Licence texts
..\src | Source code
..\DBM | Source code of the Database Manager GUI
..\SQLStudio | Source code of SQL Studio
..\Tools | Source code of programs required for translating DBM and SQLStudio
..\VBMAKE | Source code of VBMAKE

2. Enter the TCPIP Port
 sql6  7210/tcp # MaxDB
in the list of known Services ( filename services), in order to be able to access databases over the network.

You can find this file in the Microsoft Windows system directory using the following path: ..\system32\drivers\etc .


Creating the Database Manager GUI Software (MaxDB: Source Code for Tools)

Creating the Database Manager GUI Software

Prerequisites

You have the required software for creating the Database Manager GUI software.

You have installed the source code on your computer (see Installing the Source Code).

Procedure

First of all, register the program files copied to the hard disk during the installation of the source code.

· To do this, open the bin directory in the Microsoft Windows Explorer

· Open the DBMIns.exe program contained there by double clicking it (Database Manager Installer).
This program opens the file DBMIns.ini and displays all of the data contained there

· Choose Register to register all ActiveX programs, libraries and control elements.

Now run the VBMAKE program (see Executing the VBMAKE Program).


Runtime Environment (MaxDB: Source Code for Tools)

Runtime Environment

Before you can execute the client program, a MaxDB client runtime environment must be available. You can find a current version of the runtime environment in the bin directory.


Executing the Database Manager GUI Program (MaxDB: Source Code for Tools)

Executing the Database Manager GUI Program

Prerequisites

If you want to start the Database Manager Project (Name: DBMGUI) program in the Microsoft Visual Basic development environment, the runtime environment must be accessible.

There are a number of ways in which you can do this:

· By entering the bin directory in the system variable Path

· By calling the Microsoft Visual Basic development environment with the Database Manager project DBMGUI in an environment in which you have temporarily added the bindirectory to the path.

· By copying the following runtime environment files to the ...\src\DBM\DBMGUI directory

Database Manager GUI Files in the MaxDB Client Runtime Environment

dbmapi.dll

sqltcp.dll

sqltcp1.dll

sqltcp2.dll

sqltcpn.dll

sqluser73.dll

sapni.dll


VBMAKE (MaxDB: Source Code for Tools)

VBMAKE

VBMAKE is a tool developed by MaxDB which you can use to manage complex projects in Microsoft Visual Basic. It was created in connection with the development of the tools Database Manager GUI and SQL Studio.

Executing the VBMAKE Program


Execution of the VBMAKE Program (MaxDB: Source Code for Tools)

Execution of the VBMAKE Program

Calling the Program

The program file vbmake.exe is in the bin directory.

Open this file by double clicking it, if you want to work with VBMAKE.
VBMAKE read the file VBMake.ini , in which all of the main components to be managed are listed. Among the project files listed there (file extension . vbp ), there may be a file in the project file directory with the name vbmake.dep . In this file all projects that are dependent on the corresponding project are listed.

After calling the VBMAKE program, you will see a directory structure on the left side of the screen with all projects and their dependent projects as subnodes.
When you choose a project, various information about the project is displayed on the right side of the screen.

Available Functions

Use the toolbar to call the VBMAKE functions.

Function | Description
Open | Open a new input file
Open VB | Open the Microsoft Visual Basic development environment with the chosen project
Edit vbp | Open the project file in the Notepad program
Options | Define options for creating the software Check project file date Takes the project file date into consideration when deciding if a component should be updated (recompiled). Ignore read only attributes on targets Ignore the read only attribute of files to be created Make typelib compatible before compilation Create a project file before compilation in which the type lib information of ActiveX components is reconciled with the information in the registry. This file is then called during compilation. Make winrunner support file before compilation Create a project file before compilation that contains the required information for the WinRunner tool (Mercury Interactive Corporation). This file is then called during compilation.
Make | Compile the selected project Possibility to decide exactly what should be compiled: Make current and all dependent projects Compile all dependent projects and then the selected project Make current projects only Compile only the selected project Make dependent projects only Compile only the dependent projects
Execute | Run the selected project if it is an executable program
Register | Register the selected project (or the created components)
Set | Define selected properties of a project file, for example for Debug purposes
Touch | Set the current time stamp for the selected project file
Cancel | Terminate the current action
Info | General Public Licence Info


Source Code for SQL Studio (MaxDB: Source Code for Tools)

Source Code for SQL Studio

SQL Studio is a tool for creating and changing database objects such as tables, views, and so on, and for creating and executing SQL statements.

SQL Studio was developed using Microsoft Visual Basic 6.0, Microsoft Visual C++ 6.0 and the MaxDB development environment. The components of SQL Studio are ActiveX libraries, ActiveX control elements and dynamic run time libraries (DLLs).

Note which software is required for installing the source code and creating the SQL Studio software.

SAP recommends that you use the VBMAKE tool to create the SQL Studio software, and that you follow the procedure described under Creating the SQL Studio Software.

You can, however, also use the Microsoft Visual Basic development environment and use the group file SQLStudio.vbg in the ...\SQLStudio\Main directory with it.


Components of SQL Studio (MaxDB: Source Code for Tools)

Components of SQL Studio

The SQL Studio query tool was developed using Microsoft Visual Basic 6.0, Microsoft Visual C++ 6.0 and the MaxDB development environment.

If you want to gain an overview of the dependencies between the individual components of SQL Studio, we recommend that you use the VBMAKE tool.

Name of Component | Function | Description | Development Environment
SQLStudioUtil | Various help functions | ActiveX library, contains functions encapsulated in classes, such as access to registration database of Microsoft Windows Sets SQL Studio position pointer Manages history of SQL statements | VB 6.0
SQLStudioDBLayer | Encapsulation of database access | ActiveX library in which the SQL Studio accesses the database using ODBC and VB classes (classes creating a database connection, execution of SQL statements, scrolling in a result set) | VB 6.0
SQLStudioMan | SQL Studio Objects | ActiveX library that contains classes with which specific SQL Studio information is stored (such as user profile, program settings, stored SQL Studio objects, predicates for the den form dialog) | VB 6.0
SQLStudioCt | User password | Encryption and decryption of the user password stored in the registry for a database instance (not available as source code). | VB 6.0
SQLStudioCCon | General control elements | ActiveX component that contains various control elements: · Table window for the Visual Query dialog · Navigation bar for the form dialog · Navigation bar for the result window · Proposal list for the SQL dialog | VB 6.0
SQLStudioQCon | Control elements for creating a database query | ActiveX component for dialogs for executing SQL statements and their results: SQL dialog Form dialog Visual Query dialog Result dialog Zoom window for the result | VB 6.0
SQLStudioCDCon | Control elements for creating database objects | TableDefinition, ViewDefinition, IndexDefinition, SynonymDefinition, SequenceDefinition | VB 6.0
CatalogView | Representation of the database catalog | Among other things, provides navigation through the database catalog, calls dialogs for creating database objects and SQL Studio objects (such as specified SQL statements) | VB 6.0
SQLStudio | Main program | Main SQL Studio program | VB 6.0
DSQLControl | Input window of the SQL dialog | Allows, among other things, the setting of different fonts and colors for SQL statements and SQL keywords | VC 6.0
StudioUtil | Utility functions implemented in C | Conversion from UTF8 to UCS2 Representation of ASCII characters as Hex values | MaxDB development environment
TableDefC | Utility functions implemented in C | Functions for SQLStudioCDCon | MaxDB development environment


Software for SQL Studio (MaxDB: Source Code for Tools)

Software for SQL Studio

You must install the following software on your computer before installing the source code and creating the SQL Studio software:

· Microsoft Windows NT 4.0 Service Pack 5 or higher

· Microsoft Visual Basic 6.0 Service Pack 3 or higher

· Microsoft Visual C++ 6.0 Service Pack 3 or higher

· Microsoft ODBC 3.51

· riched20.dll 5.30.11.2110 (Richedit Version 3.0) or higher

You also require the following files:

· sapdb-sqlstudio-src-7.4.03.28.zip

This file contains all components required for installing the SQL Studio source code. The following directory structure is created when this file is unpacked:

sapdb-sqlstudio-src-7.4.03.28  // main directory

bin                       // created components

src                       // SQL Studio source code

· sapdb-tools-source-7.4.zip

This file contains all tools required for creating SQL Studio.


Creating the SQL Studio Software (MaxDB: Source Code for Tools)

Creating the SQL Studio Software

Prerequisites

You have the required software for creating the SQL Studio software.

You have installed the source code on your computer (see Installing the Source Code).

Procedure

1. First of all, register the program files copied to the hard disk during the installation of the source code.

2. Execute the file SQLSTDREG.bat without making modifications.

3. Open the command line.

4. An operating system-specific command must now be executed in each of the directories ~\SAPDBTools\src\SQLStudio and
sapdb-sqlstudio-src-7.4.03.28\src\SQLStudio.

For Microsoft Windows 9x, execute:
regsvr32 .\DSQLControl\Debug\SQLStudioDSQL.dll

For all other Microsoft Windows versions, execute:
regsvr32 .\DSQLControl\DebugU\SQLStudioDSQL.dll

The SQL Studio program can now be called or created.

The components of SQL Studio are created in various development environments (see SQL Studio Components).

To create the component DSQLControl, your require the include file Tom.h and the library riched20.dll 5.3011.2110 (or higher).
The file Tom.h is part of the Microsoft Platform Software Development Kit (SDK).

If the library riched20.dll 5.3011.2110 is not available to you, copy it from the bin directory to the corresponding Windows directory (for example: ../Winnt/System32 for Windows NT).


Executing the SQL Studio Program (MaxDB: Source Code for Tools)

Executing the SQL Studio Program

Prerequisites

If you want to start the SQL Studio program in the Microsoft Visual Basic development environment, the runtime environment must be accessible.

You should therefore copy the following runtime environment files to the group file directory ...\SQLStudio\Main.

SQL Studio Files in the MaxDB Client Runtime Environment

sqlod32.dll

sqluser73dll

sapni.dll

sqlsp32.dll

sqltcp2.dll

sqltcp1.dll

sqltcp.dll

sqltcpn.dll

sqlodext.dll

libsqlcls.dll

wapi.dll

dbfsapi.dll

odcompr.dll

StudioUtil.dll

TableDefC.dll


Web Based Problem Tracking System

The Web-Based Problem Tracking System (Web PTS) is the Web interface to the internal MaxDB program PTS for documenting problem messages for database software. The individual settlements from creation of the problem message to solution of the problem are documented here.

With this program, you have only read access to the problem messages recorded in the internal MaxDB program PTS.

An external developer, such as a member of the Open Source Community, sends a problem message to the MaxDB development team. This is recorded in the internal program PTS. The URL of this problem message is then sent to the external developer. In this way, the external developer has the possibility to follow the settlement at any time and inform himself or herself about which change in which database version is planned.

System Requirements

Terms

How the Web PTS Works

You can access the Web-Based Problem Tracking System (Web PTS) program free of charge from the address http://www.sapdb.org/webpts.


System Requirements (MaxDB: Web Based Problem Tracking System)

System Requirements

The minimum prerequisite for the use of the Web Based Problem Tracking System program is a browser that supports frames, JavaScript, and Cascading Style Sheets (CSS).

If your browser does not support CSS, the display of the program will be impaired. With some browsers (such as Konqueror 2.9.2 with activated Accessibility Stylesheets), it can also mean that the program becomes unusable.

Tests with Microsoft Internet Explorer 6, Netscape 4.74, Mozilla 1.1, Netscape 6.1, Netscape 7 (all on Microsoft Windows 2000), and Konqueror 3.0.3 (on Linux SuSE 8.0) produced good results.


Terms (MaxDB: Web Based Problem Tracking System)

Terms

Affected OS

Change Request

Completed

Component

Created

Delivered

Description

Error

Evaluate

Feature

Header Data

Keywords

Message Data

Message Texts

Message Type

Modules

Number

Patch Information

Planned/Delivered

Processed

Rejected

Release Note

Reported

Settlement

Solution

To be done

Waiting


Message Data (MaxDB: Web Based Problem Tracking System)

Message Data

The following message data is recorded for every problem message:

Header Data

Settlement

The content of the problem message is in the message text.


Header Data (MaxDB: Web Based Problem Tracking System)

Header Data

Header data is part of the message data.

The following header data is recorded for every problem message:

Number | Current number of the problem message
Message Type | Type of the problem message Error: The software does not function as intended Change Request: The reported deficiency makes the intended use of the software difficult
Component | MaxDB component
Reported | Database version to which the problem message refers
Settlement | Settlement
Planned/Delivered | Database version in which the problem is/is to be solved
Created | Date on which the message was created
Processed | Date on which the message was processed
Completed | Date on which the processing was completed
Affected OS | Affected operating systems
Keywords | Keywords They correspond to indexes that can be assigned to a problem message when it is created.


Settlement (MaxDB: Web Based Problem Tracking System)

Settlement

Specifications about the settlement of a problem message are part of the message data.

The following settlements are possible:

Waiting | The problem message has been created, but not yet processed.
Evaluate | A developer is evaluating the problem message with respect to relevance, work required, and time required.
To be done | The problem message is being processed
Delivered | The result of the work is included in a database version that has been delivered
Rejected | The problem message is not processed


Message Texts (MaxDB: Web Based Problem Tracking System)

Message Texts

Message texts are texts created in the individual phases of the processing of a problem message.
The following types of text can be created:

Description | Description of the problem
Solution | Description of the solution for the problem
Patch Information | Description of the new status after an error has been corrected (Release Note for message type error)
Modules | Software modules affected by the solution to the problem
Feature | Description of the new feature (Release Note for message type change request)


Functions of the Web PTS (MaxDB: Web Based Problem Tracking System)

How the Web PTS Works

Use

The Web-Based Problem Tracking System (Web PTS) program allows you to search for problem messages created in this program.There are various search templates for doing this, with selection lists and search functions for the message data and message texts.

Available Search Templates

Simple Search | Restrict the search result using free entries
Advanced Search | Restrict the search result using entries that you select from the system proposals
My Release Notes | Restrict the search result to only those messages that contain relevant information for the end customer If you specify the version of your installed software and of a newer version, you restrict the result list to the information relevant to your software installation that was issued up to the specified newer version.


Simple Search (MaxDB: Web Based Problem Tracking System)

Simple Search

Use

You can use the Simple Search to display the problem messages recorded in the internal MaxDB program PTS, together with the available information for them. You can restrict the search result by entering suitable freely definable search terms.

The search is performed for the message texts and keywords but not for the message data.

The system displays a maximum of 25 results.

Input Rules

You can enter any combination of letters and numbers. However, you must adhere to the following input rules when doing so:

· Place search strings that consist of several words in quotation marks (such as: “backup history”)

· Place search strings that begin with a minus sign in quotation marks (such as: “-8000”).

· To exclude problem messages from the result list, start the search string with a minus sign as a negation operator (such as: -logging, -"-8000", -"backup history").

Procedure

Choose Simple Search.

...

1. Enter search strings in accordance with the above input rules.

2. Choose the rule that is to be used for the search:

All Words | Every message in the result list is to contain all of the entered search strings.
Any Word | Every message in the result list is to contain at least one of the entered search strings.
Exact Phrase | Every message in the result list is to contain exactly the entered search string.

3. If you want to reset your entries, choose Clear.

When you want to start the search, choose Search.

A negation operator before a search string is most useful in combination with the All Words search rule, as you restrict the result table in this way.

On the other hand, a negation operator before a search string in combination with the search rule Any Words significantly increases the size of the result list.

Result List of the Simple Search


Result List of the Simple Search (MaxDB: Web Based Problem Tracking System)

Result List of the Simple Search

Use

You can display the search criteria used for the search; underneath this you can display the total number of hits for the search, and the result list. A maximum of 25 hits are displayed in the list. If the number of hits exceeds 25, we recommend that you restrict the search further.

The system displays the most important message data for every result, as well as the first 160 characters of the description created for the problem message.

Procedure

If you want to display a detailed view for an entry in the result list, click the current number (Number) of the relevant message. By doing this, you display all of the information available for a selected message; that is, all available message data and message texts.
You can save the detailed view as a URL. To do this, click the displayed link with the right mouse button.

If you want to change the search, change the displayed search criteria. Then choose Search.

If you want to start a new search, choose Clear and follow the procedure described under Simple Search.


Advanced Search (MaxDB: Web Based Problem Tracking System)

Advanced Search

Use

You can use the Advanced Search to display the problem messages recorded in the internal MaxDB program PTS, together with the available information for them. You can restrict the search result by selecting values for the input fields.

The system informs you how many problem messages were found.

You can define the number of problem messages that are displayed in the result list.

You can save the result table as a URL.

Procedure

...

Choose Advanced Search.

Restrict the search result by selecting values from the displayed lists and options or by free input for searching in the message texts:
Header Data

¡ To see a list of all the available keywords, click Keywords. To add a keyword to the list of keywords, click the keyword once. You can specify up to 25 keywords. To copy the selected keywords into the search template, choose Apply.

Settlement
Message Texts

Define the display of the result list. You can choose between various combinations of columns and specify the number of problem messages that are to be displayed.

¡ Choose whether the system should display a maximum number of rows (Max Rows) or all rows of the result list (All Rows). If you want to restrict the number of rows, specify the desired number. The number of rows corresponds to the number of problem messages displayed.

¡ Choose which columns are displayed in the result list under Result Column Set. You can choose between three predefined combinations of columns:

Minimum | Number, Message Type, Component, Reported, Created
Standard | as Minimum plus the columns Settlement and Planned/Delivered
Maximum | as Standard plus the columns Processed, Completed, and Affected OS

If you want to reset your entries, choose Clear.

When you want to start the search, choose Search.

Result List of the Advanced Search


Result List of the Advanced Search (MaxDB: Web Based Problem Tracking System)

Result List of the Advanced Search

Use

The system displays all problem messages that match the defined search criteria. You can call a detailed view for every problem message.

You can save both the result list and the detailed view for a problem message as a URL.

Procedure

If you want to save the displayed result list as a URL, choose the link displayed at the top of the page with the right mouse button.
If you call up this URL later, the system displays exactly this result list. Choose Refresh to update the output.

If you want to display a detailed view for an entry in the result list, click the current number (Number) of the relevant message. By doing this, you display all of the information available for a selected message; that is, all available message data and message texts.
You can also save the detailed view as a URL. To do this, click the link displayed at the top of the page with the right mouse button.

If you want to modify the search for the displayed result list, choose Modify Search.

If you want to define a new search, choose New Search and follow the procedure described under Advanced Search.


My Release Notes (MaxDB: Web Based Problem Tracking System)

My Release Notes

Use

With this function, you can determine which errors/change requests reported for a version are corrected/implemented in a particular succeeding version.

In the result list, the system displays the Release Notes prepared for the processed problem messages. Release Notes for corrected errors are called Patch Information. Release Notes for implemented change requests are called Feature.

The system informs you how many Release Notes were found. The display is sorted.

Procedure

...

1. Choose My Release Notes.

2. Restrict the search by selecting values from the displayed lists:

My Version | Version from which the search should be performed
Newer Version | Version to which the search should be performed
Component | MaxDB component

3. If you want to reset your entries, choose Clear.

When you want to start the search, choose Search.

Result List of My Release Notes


Result List of My Release Notes (MaxDB: Web Based Problem Tracking System)

Result List of My Release Notes

Use

This list displays all of the Release Notes that match the defined search criteria.

The system displays the most important message data for each Release Note. Among other things, you can find out from this information whether the version in which the problem is solved is still being planned (Planned) or has already been delivered (Delivered), from the point of view of the specified Newer Version.

All Release Notes that the system finds are displayed in the result list, sorted by component. The system differentiates between Patch Information and Feature for each component.

For a particular component, the Release Notes for delivered versions are displayed first (first Features and then Patch Information), and then the Release Notes for planned versions (first Features and then Patch Information).

Procedure

If you want to modify the search for the displayed result list, choose Modify Search.

If you want to define a new search, choose New Search and follow the procedure described under Comparing Versions.


Icons and Typographic Conventions

Icons in Body Text

Icon | Meaning
 | Caution
 | Example
 | Note
 | Recommendation
 | Syntax

Typographic Conventions

Format | Description
Example text | Words or characters quoted from the screen. These include field names, screen titles, pushbutton labels, menu names, menu paths, and menu options. Cross-references to other documentation.
Example text | Emphasized words or phrases in body text, graphic titles, and table titles.
EXAMPLE TEXT | Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE.
Example text | Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.
Example text | Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.
<Example text> | Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.
Example text | Keys on the keyboard, for example, F2 or ENTER.


MySQL MaxDB Library

MySQL MaxDB is a mature and reliable database system that combines extremely high levels of performance and availability with a low cost of ownership. It offers absolute ease of use and almost unsupervised operation. MaxDB can handle a wide range of different types of information, which makes it a suitable server for diverse application scenarios. MaxDB works with all SAP applications.

For more information, and free software downloads, go to http://www.mysql.com/downloads.

MaxDB documentation is organized into the following areas:

Installation

Basic Information

Tools

Interfaces

Development

Various symbols and typographic conventions are used to flag different types of text in the documentation.