Query

Reference Manual

AVEVA Solutions Ltd

Disclaimer
Information of a technical nature, and particulars of the product and its use, is given by AVEVA
Solutions Ltd and its subsidiaries without warranty. AVEVA Solutions Ltd and its subsidiaries disclaim
any and all warranties and conditions, expressed or implied, to the fullest extent permitted by law.
Neither the author nor AVEVA Solutions Ltd, or any of its subsidiaries, shall be liable to any person or
entity for any actions, claims, loss or damage arising from the use or possession of any information,
particulars, or errors in this publication, or any incorrect use of the product, whatsoever.

Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every
part of it (including source code, object code, any data contained in it, the manual and any other
documentation supplied with it) belongs to AVEVA Solutions Ltd or its subsidiaries.
All other rights are reserved to AVEVA Solutions Ltd and its subsidiaries. The information contained in
this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval
system, or transmitted without the prior written permission of AVEVA Solutions Ltd. Where such
permission is granted, it expressly requires that this Disclaimer and Copyright notice is prominently
displayed at the beginning of every copy that is made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material
or electronic form, without the prior written permission of AVEVA Solutions Ltd. The user may also not
reverse engineer, decompile, copy, or adapt the associated software. Neither the whole, nor part of the
product described in this publication may be incorporated into any third-party software, product,
machine, or system without the prior written permission of AVEVA Solutions Ltd, save as permitted by
law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal
prosecution.
The AVEVA products described in this guide are to be installed and operated strictly in accordance with
the terms and conditions of the respective license agreements, and in accordance with the relevant
User Documentation. Unauthorised or unlicensed use of the product is strictly prohibited.
First published September 2007
AVEVA Solutions Ltd, and its subsidiaries
AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom

Trademarks
AVEVA and Tribon are registered trademarks of AVEVA Solutions Ltd or its subsidiaries. Unauthorised
use of the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product names are trademarks or registered trademarks of AVEVA Solutions Ltd or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trade mark rights, or other intellectual property rights in any other product, its name or
logo belongs to its respective owner.

Query NT Reference Manual

Query NT Reference Manual

Contents

Page

Reference Manual
Introducing QUERY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
What QUERY Does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Who this Manual is Meant For . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
How the Manual is Set Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:2
Conventions used in the Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:2

Communicating Using QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

Using QUERY to Communicate with Data Servers . . . . . . . . . . . . . . . . . . . . . . . 2:1
Directing Commands to the Data Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Connecting QUERY to a Data Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Sending Commands to a Data Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Setting Variables from the Data Server Responses . . . . . . . . . . . . . . . . . . . . . . 2:4
Specifying the Data Field Delimiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:6
Handling Returned Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:6
Toggling Server Daemon Tracing Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1

Command Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
CLOSE
DELIMIT
END

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3

12.0

Query NT Reference Manual

EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
GET
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
OPEN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
SEND
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
START
TOGGLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7

QUERY and Server Daemons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A:1

Server Daemon Architecture on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:1
Some Environmental Setup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:1

QUERY and ODBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B:1

ODBC Architecture on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:1
Some Environmental Setup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:2
Connection Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:3
Special Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:3
SQL Escape Sequences in ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:4

Application Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C:1

What the Application Sample Does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C:1
Form Definition Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C:3
Form Apply Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C:4

ii

12.0

Query Reference Manual

Introducing QUERY

Introducing QUERY

1.1

What QUERY Does

QUERY is a flexible way to access and manipulating the contents of outside databases from
within its products. It provides for a two-way flow of data between application programs and
local or remote databases using Structured QUERY Language (SQL) as its database
access language. SQL became an ANSI standard in 1986 and an ISO standard in 1987; it is
used today in a great many database application programs management systems.
QUERY is essentially a programming toolkit which allows enables you to create your own
macros to carry out functions such as these:

Reading additional attribute data from local or remote databases

Adding object and attribute data to external databases

Adding functionality to existing user interfaces

The addition of QUERY to an application program forms a powerful programmable

engineering database system.
The underlying functionality for QUERY has different system architectures on UNIX and
Windows.
On UNIX there is a server daemon which contains the interface to each database type. Bidirectional communication takes place with this server daemon, allowing it to be on the
local machine or remote.
On Windows QUERY supports Open Database Connectivity, an interface standard for
database access. All components necessary to provide the ODBC interface, such as
communications, are internal to ODBC.
A user of QUERY commands is presented with the same interface and need not be aware
of the different ways in which the functionality is provided, except of course when QUERY or
the database is configured.

1.2

Who this Manual is Meant For

This manual describes the QUERY command syntax which you can use to set up links
between PDMS or REVIEW products and an external database. It is intended for those who
need to write application macros for use from within those products, the principal purpose of
such macros being to allow users to interrogate a database and to use the results to control
PDMS or REVIEW operations in a user-friendly manner. This manual does not attempt to
define rules for writing such macros, nor does it tell you how you should document the ways
in which end-users should use your macros and their controlling interfaces.
The manual assumes that you have some prior experience of programming and that you are
already familiar with the following aspects:

1:1

12.0

Query Reference Manual

Introducing QUERY

1.3

The functions of PDMS or REVIEW and the ways in which these are controlled via the
standard user interface, as detailed in the user documentation (including online help)
for those products.

The data server commands necessary to insert, delete, query and protect data in your
chosen database.

The concepts of writing and running macro command files, including the use of
Programmable Macro Language (PML), as detailed in the Software Customisation
Guide.

The design and implementation of a forms and menus graphical user interface, as
detailed in the User Interface Customisation Reference Manual.

How the Manual is Set Out

This manual is organised in the following way:

1.4

Communicating Using QUERY describes the basic principles of using QUERY,

including some top-level commands which apply during its use.

Command Syntax is the commands reference section and describes the command
syntax which you can use to control PDMS from within QUERY.

QUERY and Server Daemons describes the server daemon architecture used by
QUERY on UNIX machines and environment and other setup requirements.

QUERY and ODBC describes the ODBC architecture used by QUERY on Windows
machines and its setup requirements and special features.

Application Sample contains a sample application.

Conventions used in the Text

The following conventions are used throughout this manual to highlight certain features of
the text:

Command words are shown as a combination of uppercase and lowercase characters,

using a different typeface from that used for normal text; for example, COMMandword.
The uppercase part of the word (COMM in the preceding example) is the minimum
permissible abbreviation. Where a command word is first introduced, or where its use
is defined, it will usually be shown in bold type, thus
COMMandword

Command arguments are shown in lowercase italic type; for example, argument.

Parts of the command enclosed between square brackets are optional; for example, ...
[ignore this part of the command if not relevant]

Examples of interactive input and output sequences are shown in a different typeface,
thus

Example of Input/Output Sequence Typeface

Character strings which begin with the slash character / are either names of elements
in the databases or the names of files in the operating system directories. For example,
/ELEMENT or /filename.

Character strings enclosed between angled brackets are the names of individual command
syntax diagrams. For example, <diagram_name>.

1:2

12.0

Query Reference Manual

Communicating Using QUERY

Communicating Using QUERY

2.1

Using QUERY to Communicate with Data Servers

This chapter explains the commands available within QUERY for accessing an external
database, such as a remote source on a data sever. Data settings can be read from, or
written to the data server. It also explains how you can store and manipulate the results of
querying such data within QUERY.

2.2

Directing Commands to the Data Server

In order to direct any command line from QUERY to a data server, prefix the line with the
word

EXTERnal
The remaining part of the line may comprise either:

A command to create a connection between QUERY and the data server

A command sequence for reading from or writing to the data server

This prefix in incorporated into all commands described in the remainder of this chapter.

2.3

Connecting QUERY to a Data Server

Before commands can be sent from QUERY to any data server, a link must be set up
between the two.
To connect QUERY to a data server which is installed on the same machine, use one of the
commands:

EXTERnal OPEn synonym token_var

EXTERnal OPEn synonym token_var [AS connect_string]
where synonym is a text string which identifies the server daemon through which
communication is to be channelled (and which therefore identifies the data server required);
token_var is the name of a PML variable into which a token for the connection is to be
written; and (if your data server requires login data) connect_string is a text string which
confirms your access rights (such as your username and password).

2:1

12.0

Query Reference Manual

Communicating Using QUERY

Example:

EXTERNAL OPEN MAINTENANCE !!MAINT AS bull/robert

or

EXTERNAL OPEN ODBC !!MAINT AS DSN=MAINTDAT;

To connect QUERY to a data server which is installed on a different machine, use the
extended form of the command

EXTERnal OPEn synonym token_var ON host [AS connect_string]

where synonym, token_var and connect_string are as above and host is a text string which
identifies the node on the network on which the server daemon. For example, to connect to
a data server on a machine called sg35, enter

EXTERNAL OPEN MAINTENANCE !!MAINT ON sg35 AS bull/

robert
or, alternatively, a generalised version such as

EXTERNAL OPEN MAINTENANCE !!MAINT ON sqlnet AS bull/

robert
where the alias sqlnet has been defined so as to point to the current host for, say, an SQL
database server.
To disconnect QUERY from a data server to which it is currently connected, use the
command

EXTERnal CLOse token

where token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable).
Example:

EXTERnal CLOse $!!MAINT

Note: The $ prefix used to expand the variable !!MAINT to give the token value.

2.4

Sending Commands to a Data Server

Note: It is assumed that you are already familiar with the commands for communicating
with your data server; for example, the SQL commands needed to interact with an
SQL database.
You may send commands to the data server in one of two ways:

As individual command lines, each of which is sent as soon as the newline character is
entered to terminate the command line.

2:2

12.0

Query Reference Manual

Communicating Using QUERY

In continuous mode, such that a sequence of command lines is concatenated and sent
as a single command string. The maximum length for an individual command line is
120 characters; continuous mode allows you to send longer command sequences.

To send an individual command line to the data server, simply prefix the command text thus:

EXTERnal SENd

token

command_text

where token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable) and command_text is
the command string to be sent to the data server.
Example:

EXTERNAL SEND $!!MAINT commit

To send a continuous command sequence to the data server, use the syntax

EXTERnal SENd token

command_text_1
command_text_2
...
END

STArt

where token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable) and command_text_1
etc. are the command strings to be sent to the data server.
Example:

EXTERNAL SEND $!!MAINT START

select refno, description, datedue
from maintdata
where datedue<sysdate+7
END
where each line of command text is terminated by a newline character.
When the END command is reached, all text lines entered since START are concatenated,
with a space separator between each, and sent to the data server as a single command.
Note: Command texts may include references to PML variables.
The maximum length for a single text line is 120 characters.
The maximum total length for the overall text string (that is, all lines between the
START and END commands) is 4095 characters., including the separating spaces.

2:3

12.0

Query Reference Manual

Communicating Using QUERY

2.5

Setting Variables from the Data Server Responses

All of the standard syntax for setting variables is available for use within QUERY. In addition,
QUERY incorporates extra syntax for setting variables to data values returned from a data
server.
To set a variable to the next row of data resulting from a data server query, use the syntax

VAR varname EXTERnal GET token NEXT

where token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable). The variable varname
will be interpreted automatically as an array variable and each data item will be stored in a
separate element of the array. (The PML SPLIT command is not required here; splitting is
carried out automatically.)
Note: No data field should be longer than 120 characters, since this is the maximum
permitted length that can be stored in a variable. If a data field exceeds 120
characters, nothing will be returned by the query.
As an example, the querying command

EXTERNAL SEND $!!MAINT select refno, servint, lastserv

from maintdata VAR !datarow EXTERNAL GET $!!MAINT NEXT
might return the following results:

$!datarow[1]

C1101

(first value of field refno)

$!datarow[2]

182

(first value of field servint)

$!datarow[3]

22-AUG-94

(first value of field lastserv)

Repeating the command

VAR !datarow EXTERNAL GET $!!MAINT NEXT

will retrieve the next data record, which will progressively overwrite the current settings of
the array element elements. For example,

$!datarow[1]

E1201

(second value of field refno)

$!datarow[2]

31

(second value of field servint)

$!datarow[3]

07-JUL-94

(second value of field lastserv)

and so on for subsequent data records. If the newly read record has less completed fields
than the preceding record, some elements of the array variable will remain with their
previous settings unchanged.
You can control the writing of data to an array variable explicitly by using the variable-setting
syntax. For example, to read in a record such that its first field is stored in element 10 of the
array variable, rather than starting from element 1 by default, you could use the syntax

VAR !datarow[10] EXTERNAL GET $!!MAINT NEXT

2:4

12.0

Query Reference Manual

Communicating Using QUERY

To read a record and append the resulting data to the array variable, rather than overwriting
the current settings of the array elements, you could use the syntax

VAR !datarow APPEND EXTERNAL GET $!!MAINT NEXT

and so on.
The most convenient way to retrieve multiple data records is usually to incorporate the
NEXT command into a PML infinite DO loop construct, reading one data record during
each cycle of the loop. When the last record has been read in, the next cycle of the loop will
generate the message

(79, 10) No more data

which can be dealt with by using the PML HANDLE facility. For example:

EXTERNAL SEND $!!MAINT select * from maintdata

DO
VAR !datarow EXTERNAL GET $!!MAINT NEXT
HANDLE (79, 10)
BREAK
ENDHANDLE
PML commands
...
ENDDO
To set the column headings returned by a data server query in an array variable, use either
version of the following syntax:

VAR varname
VAR varname

EXTERnal GET token RESult

EXTERnal GET token HEADer

These commands always return the first row of the result of the last request sent to the data
server identified by token (typically, but not necessarily, header information resulting from an
SQL database SELECT command).
For example, the querying command

EXTERNAL SEND $!!MAINT select * from maintdata

VAR !header EXTERNAL GET $!!MAINT RESULT
might return the following results:

$!header[1]

refno

$!header[2]

servint

$!header[3]

lastserv

Note: As with the data fields, no heading should be longer than 120 characters. If a
heading exceeds 120 characters, nothing will be returned by the query.

2:5

12.0

Query Reference Manual

Communicating Using QUERY

2.6

Specifying the Data Field Delimiter

When data is sent from a data server to QUERY, it is sent as a single data block. Each data
field within the block is delimited by a special character; by default, this is the ~ (tilde)
character. When QUERY receives the block, it uses the delimiter character to determine the
points at which to split the data into individual fields. If your data includes the delimiter
character within a text field, QUERY will split the data block at the wrong point.
For example, the data stored in the following fields:

Area

Catalytic Cracker

Plant

Reflux~Heater

Code

DES21142

would be received by QUERY, using the default ~ delimiter, as the data block

Catalytic Cracker~Reflux~Heater~DES21142
and would be split, incorrectly, into the fields

$!a[1]

Catalytic Cracker

$!a[2]

Reflux

$!a[3]

Heater

$!a[4]

DES21142

To prevent this effect, you can redefine the delimiter character to be any single character
which is not used within any database field. To do so, use the command

EXTERnal DELImit

token

text_char

where token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable) and text_char is the
required data field delimiter character.
For example, the specification

EXTERNAL DELIMIT $!!MAINT &

would cause the data block from the preceding example to be received as

Catalytic Cracker&Reflux~Heater&DES21142
which would be correctly split at the points identified by the & characters.

2.7

Handling Returned Errors

Errors which can be trapped and handled specifically by QUERY may result in one of the
following error messages (where info represents any supplementary information about the
error which is generated by the data server or the communications software).

2:6

12.0

Query Reference Manual

Communicating Using QUERY

Server Daemon Messages:

(79, 3)

Cannot initialise server daemon: info

For example, the server daemon executable cannot be found via
any of the expected directory paths

(79, 4)

Cannot connect to data server: info

For example, an invalid password has been used

(79, 5)

Cannot send request to data server: info

For example, a networking problem has interrupted
communications (info will show the request that has failed)

(79, 6)

Error returned: info

Reason appended to the message by the data server

(79, 7)

Request failed: info

For example, an invalid data server command has been entered

(79, 8)

Cannot fetch next row: info

For example, a network interruption or a data server error has
occurred while waiting for the result of an EXTERNAL GET ...
NEXT request (see Setting Variables from the Data Server
Responses)

(79, 9)

Command is too long

The command has exceeded the limit of 4095 characters (dont
forget the separating spaces when summing the lengths of the
individual command strings)

(79, 10)

No more data
For example, the most recent EXTERNAL GET ...NEXT
command has failed because there are no more rows of data to
retrieve. This is a very useful error number to trap, since it allows
you to use an infinite DO loop to retrieve consecutive rows from a
table of any length and then to escape when all the rows have
been read; you will find an example of the syntax for doing this in
Section Setting Variables from the Data Server Responses.

The text of a data server error message is usually explicit, since it is generated from the
database, and so its meaning, and the method of resolving it, should be clear. For example,
if you are communicating with an ORACLE database, the command

EXTERNAL SEND $!!MAINT select * from emp

could result in the error

(79, 7) Request failed: ORA-00942: table or view does not

exist
Similarly, the command

2:7

12.0

Query Reference Manual

Communicating Using QUERY

EXTERNAL SEND $!!MAINT select * from emp

could result in the error

(79, 7) Request failed: ORA-00904: invalid SQL statement

Communications Software Messages:
Note: These are most likely to be caused by general network problems rather than by
QUERY itself.

(79, 51)

Cannot initialise remote process query

(79, 52)

Connected to data server (for information only cannot be released)

(79, 53)

Data server released (for information only cannot be released)

(79, 54)

Cannot set delimiter character: info

(79, 55)

Cannot terminate server daemon: info

(79, 56)

Daemon file incorrect or missing

(79, 57)

Unknown daemon synonym: info

Check that you have entered the required synonym correctly and
that it is included in the daemon_file

(79, 58)

Cannot toggle tracing in server daemon: info

(79, 59)

No licenses available for remote process query

The maximum number of communication channels (daemons)
permitted by your license are already open. Close an unwanted
channel if possible

(79, 60)

Remote process query security error: info

Contact AVEVA Support for advice

(79, 63)

2.8

Server daemon has shut down because a FATAL error

was detected

Toggling Server Daemon Tracing Facilities

To toggle on or off any tracing facilities built into a server daemon, use the command

EXTERnal TOGgle token TRAce

where token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable).

EXTERNAL TOGGLE $!!MAINT TRACE

(This facility is provided as an aid for developers using the QUERY Daemon Toolkit.)

2:8

12.0

Query Reference Manual

Command Syntax

Command Syntax
This section gives detailed information on how to use the relevant commands for using
QUERY to communicate with other data servers.
The commands described in the main part of this appendix have their legal command and
interrogation options presented in the form of syntax diagrams. These diagrams formalise
the precise command sequences which may be used and supplement the explanations
given in the appropriate sections of this manual.
The following conventions apply to the syntax diagrams in this appendix:

Names written in lowercase letters enclosed in angled brackets (e.g. <direction>)

represent subsidiary syntax diagrams. Such names are used for cross-reference
purposes within other syntax diagrams.

Commands to be input from the terminal are shown in a combination of uppercase and
lowercase letters. In general, these commands can be abbreviated; the capital letters
indicate the minimum permissible abbreviation. (NOTE: This convention does not
mean that the second part of the command must be typed in lowercase letters;
commands may be entered in any combination of uppercase and lowercase letters.)

For example, the command

CONnect
may be input in any of the following forms:

CON
CONN
CONNE
CONNEC
CONNECT
Commands shown wholly in uppercase letters cannot be abbreviated.

Names written in lowercase italics are command arguments.

Syntax diagrams are generally read from top left to bottom right.

Points marked with a plus sign (+) are option junctions which allow you to input any
one of the commands to the right of the junction. Thus

>---+--- ABC -----.

|
|
|--- PQR -----|
|
|
|--- <dia> ---|
|
|
--------------+--->
means you may type in ABC or PQR or any command allowed by the syntax given in
subsidiary syntax diagram <dia> or just press RETURN to get the default option.

3:1

12.0

Query Reference Manual

Command Syntax

points marked with an asterisk (*) are loop back junctions. Command options
following these may be repeated as required. Thus

.-----<-------.
/
|
>---*--- option1 ---|
|
|
|--- option2 ---|
|
|
--- option3 ---+--->
permits any combination of option1 and/or option2 and/or option3 to be used (where
the options may define commands, other syntax diagrams, or command arguments).
This may form an exception to the rule of reading from top left to bottom right.
The simplified format

.----<-----.
/
|
>---*--- name ---+--->
means that you may type in a list of PDMS names, separated from each other by at
least one space.
Note: The need to press the Return (or Enter or
) key to complete each command line
is implicit in all syntax diagrams and is not usually shown. Only in cases where the
need to press Return/Enter/
has some particular significance is this indicated
specifically by the abbreviation nl.

3.1

Command Arguments
These are inputs which are necessary to qualify command words. They are distinguished by
appearing in italics.

3.2

Name

Definition

Example

filename

The pathname of a file

/DATLISTS/SITE1

int

A positive integer

0, 3

name

An element name

/ABCD

nodeid

A host machine identifier

sg36

text

An alphanumeric string

Enclose between quote marks

val

A positive or negative number

3.142, -23.66, -34

varid

A variable identifier

3, !NAME

nl

New line

Press Return or Enter or

(depending on your keyboard

key

Commands
The information is given under the following headings:

3:2

12.0

Query Reference Manual

Command Syntax

Description:
A brief explanation of what the command enables you to do and when you might use it.
Example:
Examples of the permitted command variations. (Examples are omitted in trivial cases.)
Syntax:
The full command syntax, given in diagrammatic form.

3.2.1

CLOSE
Description:
Disconnects QUERY from a specified data server (to which it is currently connected as a
result of an OPEN command).
Example:

EXTERNAL CLOSE !!MAINT

Syntax:

>-- EXTERnal -- CLOse -- token -->

where:
token is the token for the communication channel which was supplied by a successful
OPEN command and which is stored in a variable.

3.2.2

DELIMIT
Description:
Allows you to specify the delimiting character which separates the individual data fields
when querying a specified data server. The default delimiter is the ~ (tilde) character.
Example:

EXTERNAL DELIMIT $!!TOK_VAR &

Syntax:

>-- EXTERnal DELImit server_token text_char -->

where:
server_token is an integer identifying the required data server channel and text is a
single character only.
Note: You must choose a delimiting character which does not occur within any data,
otherwise QUERY will split the incoming data string in the wrong place.

3.2.3

END
Description:
Terminates the sending of a long command string to a data server.

3:3

12.0

Query Reference Manual

Command Syntax

All command lines following a START entry will be concatenated to form a composite
command of any required length until terminated by a corresponding END entry.
The maximum length for a single query line is 120 characters.
The maximum total length for the overall query string (i.e. all lines between the START and
END commands) is 4095 characters.
Example:

EXTERNAL SEND $!!MAINT START

select refno, servint, lastserv from maintdata
where elementtype = EQUIPMENT
END
Note: The use of multiple delimiting characters for nesting text within text in this example.
You could, alternatively, write the example using vertical bar text delimiters, thus:

EXTERNAL SEND $!!MAINT START

|select refno, servint, lastserv from maintdata|
|where elementtype = EQUIPMENT|
END
Syntax:

.----<----.
|

>-- EXTERnal SENd server_token START --*-- text nl --+-- END -->

where:
server_token is an integer identifying the required data server channel.

3.2.4

EXTERNAL
Description:
Allows you to send to a specified data server any valid text string which represents a
command to read from, or write to, a database.
For details of subsidiary commands relevant to EXTERNAL mode, see under the following
headings:
CLOSE
DELIMIT
END
GET
OPEN
SEND
START
TOGGLE
Example:

EXTERNAL SEND $!!MAINT select * from maintdata

This sends the specified text string to the data server whose channel token is stored in
the variable !!MAINT.

3:4

12.0

Query Reference Manual

Command Syntax

Syntax:

>-- EXTERnal ... -->

3.2.5

GET
Description:
Allows you to set to data values returned from a data server (using NEXT). Note that all of
the standard syntax for setting is available for use within QUERY.
Also allows you to store the column headings returned by a data server query in an array
variable (using RESULT or HEADER).
Example:

VAR !datarow EXTERNAL GET $!!MAINT NEXT

VAR !header EXTERNAL GET $!!MAINT RESULT
Syntax:
>- VAR varname EXTERnal GET token -+- NEXT -------.
|
|
|- RESult -----|
|
|
- HEADer -----+--->
where:
token is the token for the communication channel which was supplied by a successful
EXTERNAL OPEN command (and stored in the token_var variable).
varname will be interpreted automatically as an array variable and each data item will
be stored in a separate element of the array. (The PML SPLIT command is not
required here; splitting is carried out automatically.)
Note: RESULT and HEADER commands always return the first row of the result of the last
request sent to the data server identified by token (typically, but not necessarily,
header information resulting from an SQL database SELECT command).
As with the data fields, no heading should be longer than 120 characters. If a
heading exceeds 120 characters, nothing will be returned by the query.

3.2.6

OPEN
Description:
Connects QUERY to a specified data server (via a server daemon).
Many communication channels may be open concurrently, each being identified by a token
(an integer) which is returned by the server and stored in a named variable for subsequent
reference.
Example:

EXTERNAL OPEN MAINTENANCE !!MAINT AS bull/robert

EXTERNAL OPEN MAINTENANCE !!MAINT ON sg35 AS bull/
robert

3:5

12.0

Query Reference Manual

Command Syntax

Syntax:
>- EXTERnal OPEn synonym token_var -+- ON hostid-.
|
|
------------+- AS connect_string -.
|
|
--------------------+->

where:
synonym is a text string which identifies the server daemon through which
communication is to be channelled. The synonyms must be defined in the
daemon_file - see Appendix A or B.
token_var identifies a variable to be used to store the integer token returned by the
server when the communication channel is successfully opened. You use the setting
of this variable for all subsequent references to that server daemon.
hostid is a text string which identifies the node on which the server daemon resides
(not required if the daemon is running on the same node as QUERY).
connect_string is any text string needed to allow you to connect/login to the data
server (typically contents and database name, username and password).

3.2.7

SEND
Description:
Allows you to send a command string to a specified data server.
You can send short command strings (up to 120 characters) within the SEND command
line, or you can concatenate multiple command strings by using the START and END
commands (q.v.).
Example:

EXTERNAL SEND $!!MAINT commit

Syntax:

>-- EXTERnal SENd server_token text -->

3.2.8

START
Description:
Allows you to send a long command string to a specified data server (by extending the
SEND command).
All command lines following a START entry will be concatenated to form a composite
command of any required length until terminated by a corresponding END entry.
The maximum length for a single query line is 120 characters.
The maximum total length for the overall query string (i.e. all lines between the START and
END commands) is 4095 characters.
Example:

EXTERNAL SEND $!!MAINT START

select refno, servint, lastserv from maintdata
where elementtype = EQUIPMENT

3:6

12.0

Query Reference Manual

Command Syntax

END
Note: the use of multiple delimiting characters for nesting text within text in this example.
You could, alternatively, write the example using vertical bar text delimiters, thus:

EXTERNAL SEND $!!MAINT START

|select refno, servint, lastserv from maintdata|
|where elementtype = EQUIPMENT|
END
Syntax:
.-------------.
/
|
>-- EXTERnal SENd server_token START --*-- text - nl --+-- END -->
where:
server_token is an integer identifying the required data server channel.

3.2.9

TOGGLE
Description:
Allows you to toggle on or off any tracing facilities built into a server daemon.
(This facility is particularly useful to developers using the QUERY Daemon Toolkit.)

Example:
EXTERNAL TOGGLE $!!MAINT TRACE
Syntax:

>-- EXTERnal TOGgle server_token TRAce -->

3:7

12.0

Query Reference Manual

Command Syntax

3:8

12.0

Query Reference Manual

QUERY and Server Daemons

QUERY and Server Daemons

A.1

Server Daemon Architecture on UNIX

All of those AVEVA products that incorporate QUERY functionality have the potential to
access data controlled by external systems. To do so on UNIX machines, the QUERY
products must communicate with the remote data servers via specially written server
daemons. These daemons act as interpreting interfaces between the standard QUERY
functions and the specific requirements of the individual types of data server.

The control of the server daemons and the communication between the QUERY product s
and the daemons are managed the AVEVA product. However, the communication between
the sever daemon and the data server are managed by the user supplied part of the sever
daemons. Server daemons are built using a special server daemon toolkit.

A.2

Some Environmental Setup Requirements

All QUERY products must have access to a file named daemon_file and have the
environment variable CADC_IPCDIR defined.
daemon_file
This is a text file and is a table containing the pathnames for all server daemon executables
and gives cross-references to the synonyms used to identify them in the EXTERNAL OPEN
command. This file is held either in the current directory in which Query is running from or in
a directory whose pathname is stored in the environment variable CADC_IPCDIR.
The format of each of the records in the daemon_file is:
daemon_synonym delimiter daemon_executable_path

A:1

12.0

Query Reference Manual

QUERY and Server Daemons

where daemon_synonym is the name (maximum length 30 characters) used to reference

the target data server, delimiter is white space (space or tab characters), and
daemon_executable_path is the full pathname of the daemon server executable.
For example:

MAINTENANCE

/net/cadsys/rpq/pdora

Oracle

/net/cadsys/rpq/pdora

daemon_tester

/net/cadsys/rpq/daemon_tester

With daemon_file set up this way the connection to the daemon server would be made with
a Query command such as:

EXTERNAL OPEN MAINTENANCE !!MAINT ON sg35 AS bull/

robert
CADC_IPCDIR
This environment variable must be set before Query can be used. It is set to the full
pathname of the directory containing the executables and data files needed by Query.
These include the following:
daemon_file

table of synonyms and server daemon pathnames

areyouthere

IPC daemon executable

communicator

IPC daemon executable

fatc

IPC controller executable

You may also need to check the settings of the following environment variables:
DAEMON_LOG_DIR
If this environment variable is set to a directory pathname, the stderr and stdout
streams from any subsequent server daemon process will be redirected to files in that
directory. Note that this directory must be visible to the server daemon on its host
machine.
This environment variable must be set if you intend to toggle daemon tracing,
otherwise your trace output may be lost.
TIMEOUT_FOR_CONNECT
If this environment variable is set to a number, this will determine the number of
seconds that QUERY will allow for the server daemon to connect/login to the data
server before timing out. The default is 60 seconds, and you should not normally need
to change this.
TIMEOUT_FOR_GETRESULT
If this environment variable is set to a number, this will determine the number of
seconds that QUERY will allow for the server daemon to return the result of the last
request to the data server before timing out. The default is 30 seconds, and you
should not normally need to change this.
This facility is provided because the server daemon acknowledges receipt of a request
before passing it on to the data server in case the request requires a lot of processing
on the server. QUERY may, however, demand the result of the request before the
server has finished its processing.

A:2

12.0

Query Reference Manual

QUERY and ODBC

QUERY and ODBC

B.1

ODBC Architecture on Windows NT

All of those AVEVA products that incorporate QUERY functionality have the potential to
access data controlled by external systems. To do so on Windows NT machines, the
QUERY products communicate with the data servers via the ODBC interface.

B:1

12.0

Query Reference Manual

QUERY and ODBC

In the figure overleaf:

QUERY processes macro commands and submits Structured QUERY Language

(SQL) commands for direct execution and retrieves results. The SQL commands are
expressed in the dialect of the particular ODBC driver but with the option of using driver
independent ODBC escape sequences for some values and syntax elements.

ODBC Driver Manager loads and unloads drivers on behalf of QUERY and processes
ODBC requests or passes them to an ODBC driver.

ODBC Driver processes ODBC requests, submits SQL requests to a specific data
source, and returns results to QUERY. If necessary, the driver modifies an applications
request so that the request conforms to syntax supported by the associated database.

Data source consists of the data the user wants to access and its associated
management system and network communications (if any) used to access it.

When making a connection to a database, ODBC uses a Data Source Name (DSN). Each
DSN fully specifies the database including the identity of the ODBC driver and whatever
driver specific information it requires.
The ODBC Administrator is a Windows desktop program that configures and manages data
sources. The user can run it to create a DSN and either select an existing database file or
create a new one. The ODBC Administrator prompts the user for the driver to use and then
uses it while prompting for driver specific information and completing its operations.
The DSN forms part of a connection string which may include other optional parameters
such as user name and password. Note that for all ODBC connections that the ON hostid
clause of the EXTERNAL OPEN command is not used. All the information it needs is
supplied by the DSN any other parts of the connection string.
In the following sections there are some general details of ODBC, its components and
facilities. For more information, refer to the appropriate ODBC document or help file.

B.2

Some Environmental Setup Requirements

All QUERY products must have access to a file named daemon_file, either locally or in a
directory whose pathname is stored in the environment variable CADC_IPCDIR. This file
provides extra information that may be needed by the EXTERNAL OPEN command.
The format of each record in the daemon_file is:

synonym

delimiter

information

where synonym is the name of the of the target server, delimiter is white space(space or tab
characters), and information gives details of the target server. Unlike other QUERY
architectures, the ODBC target server is completely described by its connection string and
the information is always set to ODBC.
Example:

MAINTENANCE
ENGINEERING
ODBC
...

ODBC
ODBC
ODBC

With daemon_file set up this way the connection to the daemon server would be made with
a Query command such as:

B:2

12.0

Query Reference Manual

QUERY and ODBC

EXTERNAL OPEN MAINTENANCE !!MAINT AS DSN=MAINTDAT;

You may also need to set the following environment variables:

ODBC_DRIVER_TRACE_FILE
If this environment variable is set to a pathname, the trace output produced by ODBC
drivers will be set to this log file instead of the ODBC default filename. Trace output is
switched on and off with the EXTERNAL TRACE command. Note that the ODBC Data
Source Administrator also provides control over this logging.

B.3

Connection Strings
A connection string consists of a number of parameter definitions, each of which has a
keyword, an = character and a value. A semicolon separates each parameter definition
from the next and is also placed at the end of the string. For example:

DSN=MyDB;UID=myname;PWD=mypassword;
Usually, the DSN, UID and PWD keywords are the only keywords that are needed.
The following table describes the attribute values of all the common keywords:

B.4

Keyword

Attribute value description

DSN

Name of a data source.

FILEDSN

Name of a .DSN file from which a connection string will be built for the data
source.

DRIVER

Description of the driver. For example, Rdb or SQL Server.

UID

A user ID.

PWD

The password corresponding to the user ID or an empty string if there is

none (PWD=;).

SAVEFILE

The file name of a .DSN file in which the attribute values of keywords used
in making the present, successful connection should be saved.

Special Facilities
QUERY includes some general enquiry facilities for DSN's and ODBC driver names and
provides access to them using the same method used for tables of an ODBC data source.
The DSN to use to access this information is AdminSpecial and the table names are DSN
and Drivers. They make it possible for a user interface designer to create a selection of
available DSN's from which to make a connection. Here are the main QUERY commands
for AdminSpecial and the only supported SQL commands:

external
external
external
external

open |synonym| !!TOK as |DSN=AdminSpecial;|

send $!!TOK |select * from DSN|
send $!!TOK |select * from Drivers|
close $!TOK

The external open command requires a valid synonym for ODBC.

Here is an example of a macro to read all of the available DSNs into a list gadget:

B:3

12.0

Query Reference Manual

QUERY and ODBC

Example:
$* clear the user interface gadgets
var _PARA1 ||
$* clear the user interface gadgets
var _PARA1 ||
var list _TABLE1 clear
exit
$* connect to the AdminSpecial DSN
external open |ODBC| !TOK as |DSN=AdminSpecial;|
handle any
error |$!!ERROR.TEXT|
endhandle
$* select all of the records from the DSN table
external send $!TOK |select * from DSN|
handle any
error |$!!ERROR.TEXT|
endhandle
$* fetch the first column header to the paragraph gadget
var !HEAD delete
var !HEAD external get $!TOK HEADER
handle any
error |$!!ERROR.TEXT|
endhandle
var _PARA1 (trim(vtext(!HEAD[1])))
do
var !INFO delete
var !INFO external get $!TOK NEXT
handle ( 79, 10 )
break
$* end of data
endhandle
var list _TABLE1 add (trim(vtext(!INFO[1])))
exit
enddo
$* close the connection
external close $!TOK
handle any
error |$!!ERROR.TEXT|
endhandle
return

Important: It is important to remember that these facilities are not based on the system
ODBC libraries and that the commands that are shown are the only ones that
are supported.

B.5

SQL Escape Sequences in ODBC

A number of SQL language features, such as outer joins and scalar function calls, tend to be
implemented by providers in a database-specific form. This can happen even where

B:4

12.0

Query Reference Manual

QUERY and ODBC

standards bodies have defined standard syntaxes. For that reason, ODBC has defined its
own escape sequences for some standard syntaxes. These language features are:

Date, time, timestamp, and datetime interval literals

Scalar functions such as numeric, string, and data type conversion functions

LIKE predicate escape character

Outer joins

Procedure calls

The escape sequence is recognised and parsed by ODBC drivers, which replace the
escape sequences with the correct database-specific grammar. Note however, that the
drivers only support those escape sequences that they can map to underlying language
features. For example, if the data source does not support outer joins, neither will the driver.
It is thus possible to choose to use either the ODBC escape sequence or the databasespecific syntax. However, applications that use the database-specific syntax will not be
interoperable.
ODBC escape sequences are enclosed in braces, eg {extension}. Examples of some types
of escape sequence are as follows:
Date, time, and timestamp escape sequence literals are:

{literal-type 'value'}
e.g. {d '1997-06-30'}
where literal-type is one of the following:
literal-type

Meaning

Format of value

Date

yyyy-mm-dd

Time

hh:mm:ss

ts

Timestamp

yyyy-mm-dd hh:mm:ss[.f...]

B:5

12.0

Query Reference Manual

QUERY and ODBC

B:6

12.0

Query Reference Manual

Application Sample

Application Sample

C.1

What the Application Sample Does

This application sample deals with different types of plant elements that require
maintenance at different time intervals. Maintenance activities can then be selected for
further data analysis and highlighting within the main AVEVA application product.
The types of element recognised by the application sample are:

Vessels

Exchangers

Mechanical

Instruments

All

For each element type, the maintenance interval, specified in terms of the date when
maintenance is next due, may be any of the following:

Overdue

Due today

Due next week

Due next month

When the type of element and the maintenance interval are applied, all available data will be
displayed to show which elements require maintenance and when. Further selection from
these elements can then make further maintenance enquiries with the following options:

Maintenance Schedule

Maintenance History

Parts Inventory

Isolation List

This example concentrates on two macros:

The form definition macro FMAINTAIN for creating and displaying a maintenance form.

The application macro MMAINTAIN which when run from the maintenance form reads
the specified records from the external database, displays them and prepares to make
further enquiries on them.

The other macros which would complete this example are not listed here.

C:1

12.0

Query Reference Manual

Application Sample

The connection to the external database will have been established earlier with the
commands:
$* Connect to the database driver
var !!DBCONSTR |DSN=MAINTDB;|
external open |MAINTENANCE| !!MAINT as |$!!DBCONSTR|
handle any
error |Cannot connect to database as $!!DBCONSTR|
var !!MAINT ||
return
endhandle
The form which is displayed by when FMAINTAIN has been run looks as follows:

To access data for items needing maintenance within the specified periods, the form would
be used as follows:
1. Use the two option gadgets at the top of the form to set the combination of item Type
(e.g. Vessels) and the time when the next maintenance operation is due, shown ad
Due When (e.g. Due in next week).
2. Click Apply to display elements meeting the selection criteria.
3. The Name, Description and Inspection Date for each item will be listed on the form
under the corresponding headers.
Although not shown in this example, the element names obtained (e.g. /C1101) could be
used at this point to select or highlight the corresponding in the main application program.
To obtain detailed maintenance data for any item, select the item in the scrollable list and
click the appropriate button under Further data for selected item.

C:2

12.0

Query Reference Manual

Application Sample

C.2

Form Definition Macro

$*---------------------------------------------------------------------$* (c) Copyright CADCENTRE Ltd 1997
$* This is part of the ODBC Test Suite and also serves as an example
$* for QUERY application writers.
$*
$* Macro:
FMAINTAIN
$Revision$
$* Form definition for the maintenance data
$*---------------------------------------------------------------------$* Kill existing form definition
kill _CDQ.MAINTAIN
$* Define form
setup form _CDQ.MAINTAIN
title
|Maintenance|
init
|CALLQM IMAINTAIN|
iconti
|Maintenance|
revision | $$Revision: $ |
$* Discipline to be maintained
option _DISC |Type | width 12
var list _DISC add |Vessels| |Exchangers| |Mechanical| |Instruments| |All|
exit
$* Over what period
option _DUE at xmax+2 ymin |Due When | width 18
var list _DUE pairs
|Overdue|
|0|
|Due today|
|1|
|Due in next week|
|7|
|Due in next month| |30|
exit
$* List of items to be maintained
list _LIST at xmin_DISC ymax+0.5 $
|Name
Description
Inspection Date| $
single width 64 length 6
$* Child forms
para _HDR at xmin ymax text |Further data for selected item|
button _MSCH at xmin ymax |Maintenance Schedule...| call |CALLQM UMSHOW SC
HEDULE|
button _MHIS at xmin ymax |Maintenance History... | call |CALLQM UMSHOW HI
STORY|
button _MINV at xmin ymax |Parts Inventory...
| call |CALLQM UMSHOW IN
VENT|
button _MISO at xmin ymax |Isolation List...
| call |CALLQM UMSHOW IS
OLATE|
$* Control buttons
button _APPLY at xmin_LIST ymax_MISO+0.5 | Apply | call |CALLQM MMAINTAIN|
button _RESET at xmax_LIST-19 ymin | Reset | call |CALLQM IMAINTAIN| reset
button _DISMISS at xmax_LIST-9 ymin |Dismiss| ok
$* End of form definition
exit
show _CDQ.MAINTAIN
$* End of Code
return

C:3

12.0

Query Reference Manual

Application Sample

C.3

Form Apply Macro

$*---------------------------------------------------------------------$* (c) Copyright CADCENTRE Ltd 1997
$* This is part of the ODBC Test Suite and also serves as an example
$* for QUERY application writers.
$*
$* Macro:
MMAINTAIN
$Revision$
$* Take the current selection data from the maintenance form and
$* use it to select records from the database and display them on
$* the form.
$*---------------------------------------------------------------------$* Send query to data server
if ( |$_DISC| eq |All| ) then
external send $!!MAINT start
|select pdmsname, description, datedue from MAINTDATA|
|where ((datedue<($!!TODAY+$_DUE)))|
|order by datedue|
end
else
external send $!!MAINT start
|select pdmsname, description, datedue from MAINTDATA|
|where discipline = '$_DISC'|
|and ((datedue<($!!TODAY+$_DUE)))|
|order by datedue|
end
endif
$* Loop through documents, adding to list
var list _LIST clear
exit
var !ITEMS (0)
do
var !REPLY external get $!!MAINT next
handle (79, 10)
break
endhandle
var !ITEMS ( $!ITEMS + 1 )
var !REPLY[1] (substr( |$!REPLY[1]
|, 1, 16 ))
var !REPLY[2] (substr( |$!REPLY[2]
|, 1, 32 ))
$* Display text is name, description, date due
$* Replacement text is name
var list _LIST pairs
|$!REPLY[1]$!REPLY[2]$!REPLY[3]| |$!REPLY[1]|
exit
$* Highlight the element
PEGS 'TOP'
handle any
endhandle
PEGS 'EDIT E $!DATA[2]'
handle any
endhandle
PEGS 'BRIGHT COL 11'
handle any
endhandle
enddo
if ( $!ITEMS eq 0 ) then
error |No maintenance data found for $_DISC|
endif
$* End of Code
return

C:4

12.0

Query NT Reference Manual

Index

AS command . . . . . . . . . . . . . . . . . . . . . 3:5
AS command . . . . . . . . . . . . . . . . . 2:1, 2:2

NEXT command . . . . . . . . . . . . . . . . 2:4, 3:5

O
C
CLOSE command . . . . . . . . . . . . . . . . . . 3:3
CLOSE command . . . . . . . . . . . . . . . . . . 2:2
Command abbreviations . . . . . . . . . . . . . 3:1

ON command . . . . . . . . . . . . . . . . . . . . .
ON command . . . . . . . . . . . . . . . . . . . . .
OPEN command . . . . . . . . . . . . . . . . . .
OPEN command . . . . . . . . . . . . . . . 2:1,

Daemon_file . . . . . . . . . . . . . . . . . . . . . . A:1
DELIMIT command . . . . . . . . . . . . . . . . . 3:3
DELIMIT command . . . . . . . . . . . . . . . . . 2:6

RESULT command . . . . . . . . . . . . . 2:5, 3:5

SEND command . . . . . . . . . . . . . . . 3:3, 3:6

SEND command . . . . . . . . . . . . . . . 2:3, 3:6
START command . . . . . . . . . . . . . . . 2:3, 3:6
Synonym (data server) . . . . . . . 2:1, 3:5, A:1

END command . . . . . . . . . . . . . . . . . . . . 3:3

END command . . . . . . . . . . . . . . . . . . . . 2:3
Error messages:Server daemon . . . . . . . 2:7
EXTERNAL
command . . . . . . . . . . . . . . . . . . . . . 2:1
EXTERNAL command . . . . . . . . . . . . . . 3:4

3:5
2:2
3:5
2:2

GET command . . . . . . . . . . . . . 2:4, 2:5, 3:5

TOGGLE command . . . . . . . . . . . . . . . .
TOGGLE command . . . . . . . . . . . . . . . .
token . . . . . . . . . . . . . . . . . . . . . . . . . . .
Token (data server) . . . . . . . . . . . . . 2:1,
TRACE command . . . . . . . . . . . . . . . . .

HEADER command . . . . . . . . . . . . 2:5, 3:5

Variables:Setting from data server . . . . . 2:4

Index page i

3:7
2:8
3:5
3:5
2:8

12.0