RIS SQL Users Guide

for 32-Bit Applications

August 1996
DNA111660
Version 5.4

Warranties and Liabilities

All warranties given by Intergraph Corporation about equipment or software are set forth in your purchase contract,
and nothing stated in, or implied by, this document or its contents shall be considered or deemed a modification or
amendment of such warranties.
The information and the software discussed in this document are subject to change without notice and should not be
considered commitments by Intergraph Corporation. Intergraph Corporation assumes no responsibility for any
error that may appear in this document.
The software discussed in this document is furnished under a license and may be used or copied only in accordance
with the terms of this license.
No responsibility is assumed by Intergraph for the use or reliability of software on equipment that is not supplied by
Intergraph or its affiliated companies.

Trademarks
InterAct, Intergraph, and RIS are registered trademarks of Intergraph Corporation. DIALOG, InterServe, and TD1
are trademarks of Intergraph Corporation. All other brands and product names are trademarks of their respective
owners.

Copyright
1996 Intergraph Corporation
All Rights Reserved
Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license
agreement; contains confidential and proprietary information of Intergraph and/or third parties which is protected
by copyright and trade secret law and may not be provided or otherwise made available without proper
authorization.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of
The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c) (1) and
(2) of Commercial Computer Software Restricted Rights at 48 CFR 52.227-19, as applicable.
Unpublished rights reserved under the copyright laws of the United States.
Intergraph Corporation
Huntsville, Alabama 35894-0001

Table of Contents

__________________________________________________________________________________________________________________________________________________

Table of Contents

__________________________________________________________________________________________________________________________________________________

1.

2.

3.

Before You Begin ..................................................................................................

1-3

1.1
1.2
1.3
1.4
1.5

Document Purpose .......................................................................................

Audience .......................................................................................................
Document Prerequisites ..............................................................................
Related Documentation ...............................................................................
Using On-line Help ......................................................................................

1-3
1-3
1-3
1-3
1-6

1.5.1

Parts of the Help Window ................................................................

1-6

Introduction to RIS ...............................................................................................

2-3

2.1
2.2
2.3
2.4
2.5
2.6

Features of RIS ............................................................................................

Application Support .....................................................................................
Network Support ..........................................................................................
Performance .................................................................................................
Hardware and Software Platforms .............................................................
RIS Installation for Windows NT ................................................................

2-3
2-4
2-4
2-4
2-5
2-5

RIS Overview ........................................................................................................

3-3

3.1

Databases .....................................................................................................

3-3

3.1.1

Database Users .................................................................................

3-3

RIS Dictionary ..............................................................................................

Schemas ........................................................................................................

3-4
3-5

3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6

Standard Schema .............................................................................

Secure Schema ..................................................................................
Schema Names .................................................................................
Default Schema ................................................................................
Declare Schema ................................................................................
Relating Databases, Users, and Schemas .......................................

3-5
3-6
3-7
3-8
3-8
3-9

Tables ...........................................................................................................

3 - 10

3.4.1

Creating Tables ................................................................................

3 - 11

3.4.1.1
3.4.1.2
3.4.1.3

3 - 11
3 - 13
3 - 13

3.2
3.3

3.4

Data Types .........................................................................

not null Clause ...................................................................
extern Clause .....................................................................

3.4.2
3.4.3
3.4.4
3.4.5
3.4.6

Altering Tables .................................................................................

Dropping Tables ...............................................................................
Selecting Tables ................................................................................
Joining Tables ...................................................................................
Inserting Rows ..................................................................................

3 - 14
3 - 14
3 - 15
3 - 15
3 - 17

3.4.6.1
3.4.6.2

Inserting a Single Row ......................................................

Inserting Rows Using a Select Statement ........................

3 - 17
3 - 18

Updating Rows .................................................................................

Deleting Rows ...................................................................................

3 - 18
3 - 19

Views ............................................................................................................

3 - 19

3.5.1
3.5.2
3.5.3

Creating Views .................................................................................

Dropping Views ................................................................................
Manipulating View Data ..................................................................

3 - 20
3 - 20
3 - 21

3.5.3.1
3.5.3.2
3.5.3.3

Inserting View Data ..........................................................

Updating View Data ..........................................................
Deleting View Data ............................................................

3 - 21
3 - 22
3 - 23

Privileges ......................................................................................................

3 - 23

3.6.1
3.6.2
3.6.3

Database Privileges ..........................................................................

Relation Privileges ...........................................................................
Using Privileges ................................................................................

3 - 23
3 - 23
3 - 24

3.6.3.1
3.6.3.2
3.6.3.3
3.6.3.4

Creating the Employee Table ............................................

Creating the Maintenance Schema ...................................
Creating a Supervisor Schema ..........................................
Creating an Employee Schema .........................................

3 - 24
3 - 25
3 - 25
3 - 26

The Grant Option .............................................................................

3 - 27

Transactions .................................................................................................

3 - 28

3.7.1
3.7.2
3.7.3
3.7.4
3.7.5
3.7.6
3.7.7
3.7.8
3.7.9

Data Definition Language (DDL) Statements ................................

Data Manipulation Language (DML) Statements ..........................
Miscellaneous Statements ...............................................................
Enabling and Disabling Transaction Autocommit ..........................
Starting and Ending Transactions ..................................................
Committing Transactions ................................................................
Rolling Back Transactions ...............................................................
Locking Tables ..................................................................................
Using Multiple Transactions ...........................................................

3 - 29
3 - 29
3 - 30
3 - 30
3 - 30
3 - 31
3 - 32
3 - 34
3 - 35

3.8 Set Network Verification .............................................................................

3.9 Indexes .........................................................................................................
3.10 Examples ....................................................................................................

3 - 35
3 - 36
3 - 37

3.4.7
3.4.8
3.5

3.6

3.6.4
3.7

3.10.1
3.10.2
3.10.3
4.

Using a Secure Schema ................................................................

Using a Shared Dictionary ...........................................................
Using External Objects ................................................................

3 - 37
3 - 39
3 - 39

SQL Database Language Reference ....................................................................

4-3

4.1
4.2

4-3
4-6

List of Identifiers ..........................................................................................

Supported SQL Statements .........................................................................
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6

alter schema ......................................................................................

alter table ..........................................................................................
close schema .....................................................................................
commit ...............................................................................................
create index .......................................................................................
create schema ...................................................................................

4-7
4 - 10
4 - 12
4 - 13
4 - 15
4 - 17

4.2.6.1
4.2.6.2
4.2.6.3
4.2.6.4
4.2.6.5

4 - 21
4 - 24
4 - 26
4 - 29

create schema (INFORMIX Database Descriptor) ...........

create schema (ORACLE Database Descriptor) ...............
create schema (DB2 Database Descriptor) .......................
create schema (SYBASE Database Descriptor) ................
create schema (Microsoft SQL Server Database
Descriptor) ..........................................................................

4 - 31

4.2.7 create table .......................................................................................

4.2.8 create view ........................................................................................
4.2.9 declare schema ..................................................................................
4.2.10 declare table ....................................................................................
4.2.11 declare view ....................................................................................
4.2.12 default schema ................................................................................
4.2.13 delete ...............................................................................................
4.2.14 drop index .......................................................................................
4.2.15 drop schema ....................................................................................
4.2.16 drop table ........................................................................................
4.2.17 drop view .........................................................................................
4.2.18 exec ..................................................................................................
4.2.19 grant ................................................................................................

4 - 33
4 - 35
4 - 37
4 - 40
4 - 42
4 - 44
4 - 45
4 - 47
4 - 48
4 - 50
4 - 51
4 - 52
4 - 54

4.2.19.1
4.2.19.2
4.2.20
4.2.21
4.2.22
4.2.23

4.2.24
4.2.25

grant (to schema) ...........................................................

grant (to user) ................................................................

4 - 55
4 - 57

insert ...............................................................................................
lock tables .......................................................................................
open schema ....................................................................................
revoke ..............................................................................................

4 - 59
4 - 61
4 - 63
4 - 65

4.2.23.1
4.2.23.2

revoke (from schema) .....................................................

revoke (from user) ..........................................................

4 - 66
4 - 68

rollback ...........................................................................................
select ...............................................................................................

4 - 70
4 - 72

4.2.26
4.2.27
4.2.28
4.2.29
4.2.30
4.2.31
4.2.32
4.2.33
4.2.34
4.2.35

set database ....................................................................................

set mode ..........................................................................................
set network verification ..................................................................
set transaction ................................................................................
undeclare schema ...........................................................................
undeclare table ...............................................................................
undeclare view ................................................................................
union ...............................................................................................
update .............................................................................................
where ...............................................................................................

4 - 74
4 - 75
4 - 77
4 - 80
4 - 81
4 - 82
4 - 83
4 - 84
4 - 86
4 - 88

Nested Query ...............................................................................................

SQL Functions .............................................................................................

4 - 92
4 - 94

Troubleshooting ....................................................................................................

5-3

4.3
4.4
5.

Appendix A:
A.1
A.2
A.3
A.4
A.5
A.6

RIS and Vendor DBMS Reserved Words ............................................

A-3

RIS Reserved Words ..........................................................................................

DB2 Reserved Words .........................................................................................
INFORMIX Reserved Words .............................................................................
ORACLE Reserved Words .................................................................................
SYBASE Reserved Words ..................................................................................
Microsoft SQL Reserved Words .........................................................................

A-3
A-5
A-5
A-9
A - 11
A - 12

Appendix B:

RIS Data Types ...................................................................................

B-3

Appendix C:

RIS Dictionary Views ..........................................................................

C-3

RIS-Supported Dictionary Views ......................................................................

C-4

C.1

C.1.1
C.1.2
C.1.3
C.1.4
C.1.5
C.1.6
C.1.7
C.1.8
C.1.9
C.1.10
C.1.11
C.1.12
C.1.13
C.1.14
C.1.15
C.1.16
C.2

RIS5COLUMN_PRIVS ..........................................................................
RIS5COLUMNS .....................................................................................
RIS5DBMS_COLUMNS ........................................................................
RIS5DBMS_INDEXES ..........................................................................
RIS5DBMS_TABLES ............................................................................
RIS5DBMS_USERS ...............................................................................
RIS5DBMS_VIEWS ...............................................................................
RIS5DBS ................................................................................................
RIS5INDEX_COLUMNS .......................................................................
RIS5INDEXES .....................................................................................
RIS5SCHEMAS ...................................................................................
RIS5SCHPRIV .....................................................................................
RIS5TABLE_PRIVS ............................................................................
RIS5TABLES .......................................................................................
RIS5USERS .........................................................................................
RIS5VIEWS ..........................................................................................

C-4
C-5
C-7
C-8
C-9
C-9
C - 10
C - 11
C - 14
C - 15
C - 16
C - 17
C - 17
C - 18
C - 19
C - 20

RIS V5 Schema and Dictionary Converter .......................................................

C - 22

Appendix D:

Vendor-Specific Information ...............................................................

D-3

General Notes on Data Types ...........................................................................

D-3

D.1.1

Data type Mappings ..............................................................................

D-4

DB2 .....................................................................................................................

D-5

D.2.1
D.2.2

RIS-To-DB2 Mapping ............................................................................

DB2-To-RIS Mapping ............................................................................

D-5
D-6

INFORMIX .........................................................................................................

D-7

D.3.1
D.3.2
D.3.3
D.3.4
D.3.5

Schemas and Unique Identifiers ..........................................................

Transactions ..........................................................................................
Moving Databases .................................................................................
RIS-To-INFORMIX Mapping ................................................................
INFORMIX-To-RIS Mapping ................................................................

D-7
D-7
D-7
D-8
D-8

ORACLE .............................................................................................................

D-9

D.4.1
D.4.2

RIS-To-ORACLE Mapping ....................................................................

ORACLE-To-RIS Mapping ....................................................................

D-9
D-9

SYBASE .............................................................................................................

D - 11

D.5.1
D.5.2

RIS-To-SYBASE Mapping .....................................................................

SYBASE-To-RIS Mapping .....................................................................

D - 11
D - 12

MSSQL ...............................................................................................................

D - 13

D.6.1
D.6.2

RIS-To-MSSQL Mapping ......................................................................

MSSQL-To-RIS Mapping ......................................................................

D - 13
D - 14

Appendix E:

RIS Limits ............................................................................................

E-3

Appendix F:

Parameters File ...................................................................................

F-3

SHARED_MEMORY ..........................................................................................
MAX_LOCAL_SERVERS ..................................................................................
MAX_ROWS .......................................................................................................
MAX_BUFFER_SIZE .........................................................................................
MAX_STATIC_STMTS ......................................................................................
MAX_USER_STMTS ..........................................................................................
MAX_SECONDARY_SCHEMAS ......................................................................
MAX_TRANSACTIONS .....................................................................................
MAX_TABLES_IN_MEM ..................................................................................
Network Verification Parameters ...................................................................
Schema Definition File Location .....................................................................
LOCK_FILE_RETRY .......................................................................................

F-5
F-6
F-6
F-6
F-7
F-7
F-7
F-7
F-8
F-8
F - 10
F - 11

D.1

D.2

D.3

D.4

D.5

D.6

F.1
F.2
F.3
F.4
F.5
F.6
F.7
F.8
F.9
F.10
F.11
F.12

F.13

Client Process Location ....................................................................................

Appendix G:

F - 11

Schema Definition File .......................................................................

G-3

Appendix H: Language Configuration File .............................................................

H-3

Appendix I:

Changes to This Version of RIS ...........................................................

I-3

RDBMS Versions .................................................................................................

UNION and UNION ALL Supported .................................................................
Objects of Different Owners Within a Schema ..................................................
Object Aliases ......................................................................................................
Multi-User/Secure Schemas ...............................................................................
Shared Dictionaries .............................................................................................
Dictionary Objects ...............................................................................................
Dictionary Views .................................................................................................
RIS_BLOB/RIS_TEXT ........................................................................................
Interoperability .................................................................................................
Upgrade Utility .................................................................................................
Utilities ..............................................................................................................
Parameters ........................................................................................................
Internationalization ..........................................................................................

I-3
I-3
I-3
I-4
I-5
I-6
I-6
I-7
I-8
I - 11
I - 12
I - 12
I - 12
I - 13

Glossary .......................................................................................................................

GL - 3

Index ............................................................................................................................

IN - 3

I.1
I.2
I.3
I.4
I.5
I.6
I.7
I.8
I.9
I.10
I.11
I.12
I.13
I.14

Before You Begin 1 - 1

Before You Begin

__________________________________________________________________________________________________________________________________________________

1-2

Before You Begin

Before You Begin 1 - 3

1.

__________________________________________________________________________________________________________________________________________________

Before You Begin

1.1 Document Purpose
The RIS for Windows NT SQL Users Guide gives RIS users an explanation of Relational
Database concepts and descriptions of all Structured Query Language (SQL) statements
supported by RIS.
If you are currently using a version of RIS earlier than Version 5.0, you should
read the section Changes to This Version of RIS before using RIS Version 5.
Important changes have been made to the software.

1.2 Audience
This document was written for application users, application designers, and computer
software specialists.

1.3 Document Prerequisites

This document assumes a basic understanding of Windows NT, PC operations, and relational
database management system (RDBMS) software.

1.4 Related Documentation

DNA1151
DNA1190
DNA1117
DNA1003
DNA1009

RIS Installation Guide for 32-Bit Applications

RIS Programmers Guide for 32-Bit Applications
RIS Utilities Guide for 32-Bit Applications
RIS SQL Commands Quick Reference
RIS Programmers Quick Reference

For information on SQL terms and database structure, refer to documents related to specific
relational database management systems (INFORMIX, ORACLE, DB2, SYBASE, or
Microsoft SQL Server).
For a description of relational theory and implementation, refer to a textbook and/or user and
reference manuals for the vendor database management system. The following is a list of
references:

1-4

Before You Begin

Introduction to Database Systems

C.J. Date
ISBN: 0-201-14474-3
Database: Structured Techniques for Design, Performance, and
Management.
Shaku Atre
ISBN: 0-471-85251-1
Managing the Database Environment
James Martin
ISBN: 0-13-550582-8

Document Conventions
Filenames and directory paths appear in italic typeface. However, the italic typeface is
also used for emphasis of new words or important phrases. For example:
c:\windows
Command names, menu names, tools, system prompts and messages, and keys may
appear in boldface type. For example:
File menu
OR
Press Enter
The word mouse refers to the 2-button or 3-button mouse.
The word select means to select a command by pressing the left mouse button over a
menu command or by pressing the Alt key and the underlined character
simultaneously.
The word choose means to choose a button or icon by pressing the left mouse button
over a Toolbar button, or application icon.
The word reset means to terminate a command initiated with the mouse. Reset by
pressing the right mouse button.
The word identify means to define an area or place graphic elements in a graphics file.
For PCs, identify with the left mouse button.
The phrase key in generally means to enter data into a field on a dialog box. To
advance to the next field, use the Tab key.
Do not use the Enter key to advance to the next field. This key is mostly
used as the default key to accept a dialog box instead of pressing the OK
button.

Before You Begin 1 - 5

System key-ins, keywords, and programming code segments, appear in monospaced

type. For example:
main ( )

OR
commit
In actual usage, keywords can be in either upper or lowercase.
Words that appear in angle brackets, < >, are identifiers or names that you must
supply, or dynamic information that can change for each error message. For example:
ERROR: Error opening the file <filename>
Phrases in square brackets, [ ], are optional phrases.
Curly braces contain several options (used in conjunction with a logical OR symbol ( | ))
or phrases that can be repeated (used in conjunction with [, ...]). A comma followed by a
series of three periods in square brackets ([, ...]) indicates that the last phrase contained
within curly braces ({}), or the last item, can be repeated numerous times (separated by
commas).
For example: { <column> <data type> } [, ...] means that numerous column names and
associated data types can be specified (separated by commas).
The logical or symbol ( | ) separates phrases or keywords within curly braces ({}) that
can be used alone but not together.
For example: { user | database } means that either the user keyword or the
database keyword can be specified, but not both.
This symbol notes important information.

This symbol cautions about operations that can cause limited damage.

This symbol warns about operations that can cause severe damage.

1-6

Before You Begin

Additional Information
For additional information on RIS, see the file called README.TXT delivered with the RIS
software. The default location for this file is in the c:\Program Files\Common
Files\Intergraph\ris05.nn directory. The README.TXT file provides product information
and describes changes and additions to the product since the last release.
There is also a PROD.INI file delivered in the same directory that lists all dependencies and
related parts for the product.
There is also a MANIFEST.TXT file delivered in the same directory that contains a list of all
the files delivered with the product.

1.5 Using On-line Help

On-line Help is an on-line reference tool accessible at any time the application is in use. The
on-line Help contains a description for each command and tool and step-by-step procedures
for common tasks. For example, if you need to perform a certain task, search and display the
topic. You can move or resize your application and Help windows so that they are next to
each other. This lets you follow the procedures without having to search for the pages in the
documentation.

Before You Begin 1 - 7

1.5.1 Parts of the Help Window

To view the on-line Help, select Contents from the Help menu. To get more specific
information, select one of the major topics or perform a search on a specific topic.

1-8

Before You Begin

Use

To

Contents

Display a listing of the table of contents for

the on-line Help file.

Search

Locate information about a certain topic that

you enter in the Search box.

Back

Take you back to the previous Help topics you

have already viewed.

History

Display a sequential list of every Help topic

you have viewed during your current Windows
session.

Find

Display a dialog box used to retrieve partial or

full text strings in the help file. Use the
Hints button for information on constructing
your search query.

<<

View the previous topic in a series of related

topics. The button is dimmed when you reach
the first topic in the series.

>>

View the next topic in a series of related

topics. The button is dimmed when you reach
the last topic in the series.
If the graphics in the on-line Help appear distorted, check your graphics driver.
If you are using an Intergraph TD1 machine, the S3 1024x768 256 color (Large
Font) distorts the graphics slightly. Changing to the (Small Font) version
corrects the display. If you are using other drivers, check with your PC manual
for information about available graphics drivers.

Introduction to RIS 2 - 1

Introduction to RIS

__________________________________________________________________________________________________________________________________________________

2-2

Introduction to RIS

Introduction to RIS 2 - 3

2.

__________________________________________________________________________________________________________________________________________________

Introduction to RIS
RIS is an acronym for Relational Interface System. RIS is Intergraph Corporations generic
relational database interface. It isolates applications and users from the differences in
specific vendors relational database management systems (RDBMSs). It also permits
network access to popular RDBMSs using various network protocols.
With the availability of numerous relational database management systems on Intergraph
machines, application developers are faced with the choice of which RDBMS to use with their
application. RIS is a good long-term solution for any group requiring relational database
flexibility. It provides a low cost interface to popular RDBMSs, while freeing the user from
the details of supporting and understanding the subtle and not so subtle differences in each
of these systems.
RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.

2.1 Features of RIS

The following are features of RIS:
RIS permits developers to develop applications that are independent of the relational
database they use. This means that they do not have to maintain multiple copies of the
source code for interfacing with different databases.
RIS supports multiple databases on the network.
RIS supports multiple communication protocols.
RIS reduces the number and cost of database runtime licenses required.
RIS provides protection of any previous investment in a relational database
management system.
RIS permits design flexibility, providing for possible future interfacing to other popular
relational databases.

2-4

Introduction to RIS

RIS includes an interactive query utility.

RIS includes a schema manager based on the Intergraph/User Interface Development
Toolkit, Shamrock.
RIS includes a bulk data loader.

2.2 Application Support

If there is a requirement for an application to run on any of the available commercial
RDBMSs, application developers are faced with the high cost of developing and maintaining
separate versions of code to interface with each of those database systems. This is due to the
great differences in the user interfaces, as well as differences in dialects of the Structured
Query Language (SQL) supported by the different relational database systems. All of these
variables add to the complexity of supporting each database system.
RIS is a generic relational database interface that isolates an application from the RDBMS.
RIS lets application developers concentrate on the application, not on writing and supporting
multiple versions of code for every brand of RDBMS. The RIS interface is based on the
American National Standards Institute (ANSI) SQL Standard and is therefore compatible
with all RDBMSs that are compatible with the standard.

2.3 Network Support

RIS provides networking capabilities that let applications spread their data across network
nodes or isolate all their data on one central node. Isolating the data and using RIS as a
database server can enhance an applications data management capabilities and reduce an
applications cost by reducing the number of database licenses required. The application can
run on one machine while the database actually exists on another node. This is especially
useful in a networked environment where the database is on a central server node accessed
by numerous applications running on machines that must access the same data. Only one
copy of the RDBMS is needed for the server.
RIS currently supports the TCP/IP and LU6.2 networks.

2.4 Performance
As with any additional software layer, there is some performance degradation when using
RIS. RIS stores some dictionary information in memory, resulting in some initialization
overhead. This overhead varies directly with the number of relational database tables used
in the application. SQL statement processing is slightly slower than when directly issuing
the SQL statement on the vendor database. However, by storing and precompiling the SQL
statements, RIS minimizes the amount of SQL statement degradation. Typical query
degradation is less than five percent (5%).

Introduction to RIS 2 - 5

2.5 Hardware and Software Platforms

RIS currently supports INFORMIX, ORACLE, DB2, SYBASE, and Microsoft SQL Server.
RIS is fully supported on Intergraph machines, Intel-based PC machines. Both the
application using RIS and the databases accessed by the application can reside on these
machines. See the RDBMS table in the RIS Installation Guide for 32-bit Applications for
more information.
Programs linked with RIS can run on PCs running MS-DOS or Windows NT and remotely
access databases on machines with a RIS server.
Contact Intergraph for information regarding the current hardware and software platforms
and relational database management systems supported by RIS as they are continuing to
expand.

2.6 RIS Installation for Windows NT

RIS installation on Microsoft NT or Windows 95 is accomplished using standard Windows
setup procedures. Double click on the setup.exe for the desired product and respond to any
prompts. Be sure to have your serial number available.
The following lists the RIS products, when they are required, and where they can be located.
The RIS Shared Component is the basic RIS product needed for any application to use
RIS on Windows NT. Any Intergraph-developed application automatically loads the
Shared Component if it is required by the application. Customers who develop RISbased applications will have to distribute copies of the Shared Component as required
by their applications.
The setup utility places the Shared Component in the c:\Program Files\Common
Files\Intergraph\ris05.nn directory and nn.nn is the product version number.
The product RISDP only needs to be loaded if you are planning to develop applications
that need to use embedded RIS SQL statements. The shared component is
automatically loaded with the RISDP product.
By default, the setup utility places RISDP in the c:\Program Files\risdp directory.
All of the RIS Data Server products are used in conjunction with a specific DBMS.
These products must be loaded on the machine where the DBMS is located. The Shared
Component is automatically loaded with the RIS Data Servers. Select only the
products associated with the DBMS you intend to use.
RIS Data Server products are located, by default, in the c:\Program Files\risdp
directory.

2-6

Introduction to RIS

The products and their associated DBMSs are:

32-Bit RIS Product

DBMS

RISINFDS, RISINFNS

INFORMIX

RISORADS, RISORANS

ORACLE

RISDB2DS

IBM,DB2

RISSYBDS

SYBASE System
10

RISMSFDS

Microsoft SQL
Server

The RIS**NET products include all the functionality of the non-NET products and
additional networking capability for communicating with databases residing on nonIntergraph platforms (in conjunction with additional software DBMS).

RIS Overview 3 - 1

RIS Overview

__________________________________________________________________________________________________________________________________________________

3-2

RIS Overview

RIS Overview 3 - 3

3.

__________________________________________________________________________________________________________________________________________________

RIS Overview
The following sections provide an overview of RIS and database concepts.

3.1 Databases
RIS lets applications build and manipulate a body of information specific to the application.
This body of information is called a database. A database is actually a collection of data
which may or may not be related. The data is usually stored in one or more data files or disk
partitions in such a way that it can be recalled at any time in a variety of ways. Databases
are usually created immediately after the installation of the RDBMS.
The software that performs the organization, storage, and manipulation of data in a
database is called a Database Management System (DBMS). DBMSs differ in many ways,
the most important of which is in the way the data is organized. One of the most popular
DBMSs is the Relational Database Management System (RDBMS).

As its name implies, RIS is an interface to RDBMSs. RIS uses ANSI Standard SQL as its
interface language to the relational database systems.

3.1.1 Database Users

The RDBMS controls access to a database through a concept known as the user. A database
user is similar to an operating system (OS) user. An OS user is recognized by a unique
username and possibly a password. OS users have a home directory, file ownership, and
have file access privileges defined for them.
Like operating system users, database users are recognized by a username and possibly a
password. Database users do not necessarily have a home directory, but they do have
ownership of and access privileges to the data in the database.

3-4

RIS Overview

In the following figure, database A has two users defined on it: Joe and Sally.

The concept of a user is not always the same to the different vendor RDBMSs.
For example, a user in an INFORMIX database must also be a valid operating
system user; this is not necessary for ORACLE.

3.2 RIS Dictionary

A RIS dictionary is a set of tables and views created by RIS for a particular database. It
serves the same purpose as the data dictionary of the underlying database, but is consistent
from one brand of RDBMS to another. The RIS dictionary provides information about the
schema - table names, column names, data types, and so forth. (Schemas are described in
detail in the next section.)
For each database known to RIS, there is at least one RIS dictionary created when the first
schema is created on the database. The user who creates the first schema becomes the
dictionary owner. Subsequent schemas can be created that share this dictionary. This is
called a shared dictionary. The using clause in a create schema statement creates a
schema with a shared dictionary.
All schemas that share a dictionary should be on the same database.

A dictionary that is associated with only one schema is called an exclusive dictionary. In this
case, there is a RIS dictionary for each schema. Shared dictionaries and exclusive
dictionaries can be used on the same database (as long as the underlying RDBMS lets
different users have tables of the same name).
All RIS users must have a RIS schema and all RIS schemas must have access to a RIS
dictionary created for the database they want to manipulate. The figure following shows two
dictionaries created on a database. Dictionary1 is a shared dictionary and Dictionary2 is an
exclusive dictionary. Note that UserC both owns one dictionary and shares another through
different schemas.

RIS Overview 3 - 5

Before a dictionary can be shared, the dictionary owner must grant adequate privileges to
valid database users.
The grant schema statement grants all the necessary database level privileges on the
dictionary tables to let the grantee share the dictionary. Users with schema privilege can
create other schemas that can share the same RIS dictionary.
A shared dictionary minimizes table creation in environments where there are many
schemas.

3.3 Schemas
As defined by the ANSI SQL standard, a schema is a collection (or group) of tables, views,
and privileges. However, most RDBMSs do not implement schemas at all.
RIS defines a schema as a named collection of tables, views, and indexes on a particular
database associated with a RIS dictionary. There are two types of RIS schemas, a standard
schema and a secure schema. Information about schemas is maintained in the RIS
dictionary.

3.3.1 Standard Schema

A standard schema is a collection of tables, views, and privileges owned or shared by a user
on a database. A standard schema is associated with one database user and every connection
to this schema appears to the underlying database as a connection by the same user. Within
RIS, the tables, views, and privileges are contained in, created by, and owned by the schema.
Since most RDBMSs do not implement schemas at all, database users create and own all
tables and views. This is particularly important if the database is accessed outside RIS
(using the vendor supplied query program, for example). At the level of the RDBMS users
create and own the tables and views. The RDBMS knows nothing of the schemas

3-6

RIS Overview

created within, or by, RIS. However, the RDBMS is aware of the tables and views that
constitute the RIS dictionary.
In the following figure, the database has four users, UserA, UserB, UserC, and UserD. All
four schemas are standard schemas since there is one user per schema. Schema1, Schema2,
and Schema3, share the dictionary owned by UserA. Schema4 has an exclusive dictionary.

3.3.2 Secure Schema

A secure schema is a multiuser schema. A secure schema requires a username and password
before RIS can connect to the schemas database. The username and password are valid for
the underlying RDBMS and are not stored by RIS. Though connected to the same schema,
users appear distinct to the underlying database.
Before a user can be added to a secure schema, (with the create schema statement)
adequate privileges must be granted to the user with either the grant connect or grant
resource statement. The privileges are granted by the schema owner; that is, the database
user specified in the create schema statement. The following defines the two types of
privileges:
connect Users with connect privilege can connect to a schema and manipulate data but
cannot issue data definition language (DDL) statements to modify the structure of the
database.
resource Users with resource privilege assume connect privilege and can issue DDL
statements on the database.
In the following figure, Schema1 is a secure schema used by UserA, UserB, and UserC. Two
standard schemas, Schema2, and Schema3 also appear in the figure. Schema2 shares a
dictionary with the secure schema and Schema3 is a standard schema with an exclusive
dictionary. All schemas access the same database.

RIS Overview 3 - 7

3.3.3 Schema Names

Schema names must be 1-18 characters in length in ANSI mode, (up to 31 characters in
other modes, depending on the underlying DBMS) consisting of alphabetic characters,
digits, and the underscore character ( _ ).
Schema names must begin with an alphabetic character, but the remaining characters
can be any combination of the above.
RIS is not case sensitive, although schema names appear in all lower case characters in
the dictionary tables.
Schemas may also have an associated password, having the same length and content
requirements as schema names.
Furthermore, schema names must be unique to RIS. The following schema names are
incorrect:
Name

Incorrect because...

_schema1

A schema name cannot begin with the underscore ( _ ) character.

1_schema

A schema name cannot begin with a digit.

schema-1

The dash ( - ) character is not allowed in a schema name. Only

alphabetic characters, digits, and the underscore ( _ ) character
are allowed.

3-8

RIS Overview

3.3.4 Default Schema

Requests to read from or write to a database are made using SQL statements. Except where
noted, SQL statements are executed on the default schema. The default schema is the
user/database combination that is said to be active at any given time. Most of the SQL and
Embedded SQL statements read from or write to relations in the default schema.
The default schema can be changed with the default schema statement. For example:
default schema my_schema;
The default schema statement also opens the schema. Opening a schema causes RIS to
read in information about it and permits it to be accessed. You cannot access a closed
schema (including its relations).
You can work on relations created in other schemas by explicitly identifying the schema in
which the relation was created. This is done by preceding the relation name with the schema
name and a period (.) (for example: schemaOne.tableOne). However, the default schema
must have privilege to work on the target relation and the target schema must be open. RIS
automatically opens schemas when they are referenced. For more information on accessing
relations in schemas other than the default schema, see the sections Tables and Views. For
more information on privileges, see the section Privileges.
Relations can be created only in the default schema. These relations are associated with the
schema in which they were created until deleted. Other schemas must be granted specific
privileges to access these relations. A relation can also be included in schemas through the
alter schema statement. Then the relations become accessible in those schemas subject to
RDBMS level privileges. For more information on granting privileges, see the section
Privileges or the grant statement description in the section SQL Database Language
Reference.

3.3.5 Declare Schema

Before you connect to a secure schema, you must supply a database username and password
and, for some RDBMSs, an OS username and password. This must be done with the
declare schema statement. For example:
declare schema my_secure user john.passwd1;

This statement associates the user john with the schema my_secure so that a subsequent
default schema statement cannot use this information to open the schema. The declare
schema statement specifies schema parameters before the schema is created or opened. This
is valid for both standard and secure schemas, although it is only required for secure
schemas.

RIS Overview 3 - 9

3.3.6 Relating Databases, Users, and Schemas

Relationships between databases, user definitions, and schemas in RIS are established
through the create schema statement. Databases are associated with new schemas using
the create schema statement. Databases and users must exist to create schemas.
Schemas can be deleted with the drop schema statement.

The create schema statement associates existing databases with new schema definitions.
The database can be local (on the same machine as the application using RIS) or remote (on
an Intergraph system, a VAX/VMS machine, a Sun SPARC or SUNOS, an HP, an ISMP, or
on an IBM mainframe).
In this document, the terms local and remote refer to the location of the server
with respect to the client.
For example, to create a new schema, issue the following statements:
create schema new_schema
on database
( oracle, dbname ORCL, dir c:\orant,
osuser Ed [.passwd], ostype nt, remote (tcp oracnode) )
user Ed.pass [.passwd];

This statement creates a new standard schema, new_schema, on an ORACLE database

named ORCL and is located on the node oracnode.
The following statement creates a new local secure schema named local_stuff:
create secure schema local_stuff
on database ( oracle, dir c:\orant, osuser Keith.pass,
ostype nt, dbname ORCL )
user Bob.pass;

This statement creates a schema, local_stuff, on an ORACLE database on the local node.
The following statement creates a schema with access to a remote database named ORA7:
create schema good_stuff
on database
( oracle, dbname ORA7, dir /usr/oracle,
osuser Harper.passwd, ostype unix, remote (tcp stuffnode) )
user bonnie.pass;
This statement creates a new schema, good_stuff, on an ORACLE database named
lots_o_stuff and is located on the node stuffnode.
See the create schema statement description for more information on creating schemas
and the various options.
Multiple schemas can be created, opened, and accessed concurrently from an
application, but only one schema can be accessed within a single SQL
statement.

3 - 10

RIS Overview

For Example:
Whenever a schema is successfully created, the default schema is set to the schema created.
Any tables or views created are created in that schema, and any tables or views referenced in
other SQL statements reference tables or views in that schema. For example: if there are
two schemas, schema1 and schema2 which both have a table, table1, in them and the default
schema is set to schema1, any select, insert, update, delete, or drop statement
referencing table1 refers to schema1.table1. Schema2.table1 is not affected.

If Table1 in both schemas refers to the same table in the underlying database,
then the changes to Schema1.Table1 would affect Schema2.Table1.

3.4 Tables
The basic unit in which RDBMSs group information and the basic result of many SQL
statements is the table, also referred to as a relation. The table is a collection of rows and
columns of data. Each row represents a unit of related information sometimes referred to as
a record or tuple. Each row is made up of one or more columns representing a part of the
record. The columns are sometimes referred to as fields or attributes.
For example, a table could consist of names and phone numbers. The rows would be the
name and number combination associated with each person represented. Also, the table
would consist of two columns: name and phone. The following figure shows the table phones
with some sample data.

At the level of the RDBMS, a user creates a table in a database. The user then owns the
table, and access to that table by other users is restricted. The following figure shows the
users, Joe and Sally, on database A each with several relations. The RDBMS considers the
relations to be owned by the users who created them.

RIS Overview 3 - 11

Certain SQL statements let users work with tables. These statements include create, alter,
drop, select, insert, update, and delete.

3.4.1 Creating Tables

Tables are created with the create table statement. The table is created in the default
schema. The user must specify the name of the table and the name of each column along
with its data type. For example, the following statement creates the phones table previously
mentioned.
create table phones ( name char(25), phone char(12) );
This statement creates a table named phones in the default schema. The table is created
with two columns: the name column and the phone column. The data type of the name
column is defined as a character string with a length of 25. A maximum of 25 characters can
be inserted into this column. The phone column is defined as a character string of length 12
which means that a maximum of 12 characters can be inserted into this column.

3.4.1.1 Data Types

The data type of a column specifies the type of information that a column stores. A column
can only store data of the type for which it is defined. Therefore, a row or record can contain
several data types, but a column can contain only one data type.

3 - 12

RIS Overview

RIS recognizes the following ANSI SQL data types:

Data Type

Description

char[acter](n)

Stores one or more bytes of data. Each byte usually

represents an ASCII character, but is not limited to ASCII.
The number of characters that a column can store is defined,
when the table is created, by a length specified in parentheses
after the keyword char. Trailing blanks are dropped.

int[eger]

Stores an integer value in the range of -2,147,483,648 to

2,147,483,647 (The minimum value for INFORMIX integer is
-2,147,483,647).

smallint

Stores an integer value in the range of 32767 to -32768 (The

minimum value for INFORMIX smallint is -32767).

double [precision]

Stores a floating point value in double precision format.

real

Stores a floating point value in single precision format.

timestamp

Stores a timestamp consisting of year, month, day, hour,

minute, second as in yyyy-mm-dd:hh:mm:ss. A timestamp
literal must be specified with the syntax: timestamp yyyymm-dd:hh:mm:ss or current_timestamp to specify the current
system time. For example,
insert into <table>
values(timestamp 1995-08-12:16:24:15);
insert into <table>
values(current_timestamp);

decimal

Stores a fixed point decimal number with precision and scale.

Maximum precision is 15. The scale must be less than the
precision. The default precision is 8 and the default scale is 0.

ris_blob(n)

This data type can store up to 2 gigabytes of binary data. The

size in bytes is specified in parentheses after the keyword.
The default is zero. The ris_blob data is not interpreted. For
more information on this data type refer to the section Using
Binary and Text Data in the RIS Programmers Guide.

ris_text(n)

This data type can store up to 2 gigabytes of variable length

character data. The size in bytes is specified in parentheses
after the keyword. The default is zero. The ris_text data is
interpreted by RIS when moving between different systems.
For more information on this data type refer to the section
Using Binary and Text Data in the RIS Programmers Guide.

RIS Overview 3 - 13

The following statement creates a table to store employee information:

create table employee_info ( name char(25), id int, wage real );
The statement creates the table employee_info in the default schema with three columns: a
name column of data type char, an id column of data type int, and a wage column of data
type real.

3.4.1.2 not null Clause

The absence of data in the field of a record is a NULL value. When a row or record is
displayed by the RIS interactive program, a NULL value is displayed as NULL.
NULL is not the same as a zero for numeric data types or blanks in a character
column.
By default, RIS lets data be inserted into one, more than one, or all of the fields of a record.
If values are placed in one or more (but not all) of the fields, NULL values are inserted into
the remaining fields. Many times it is necessary to create tables in which certain fields are
required if a record is to be valid; therefore, the default can be omitted on a per-column basis.
This is accomplished by creating the table with the not null clause for specific fields.
For example, in the sample phones table, it would be worthless to have a record that
contained only a name or number. The following statement is used to create the phones table
and to specify that the name and phone columns cannot contain NULL values.
create table phones ( name char(25) not null, phone char(12) not null );

3.4.1.3 extern Clause

RIS lets users specify external names for tables and columns with the extern clause. The
external names used by the underlying RDBMS may be different from the name used by RIS.
For example:

create table phone (name char(25) not null, phone char(12) not null )
extern tab1 (col1, col2);

In this statement, phone is a RIS table name, and name and phone are RIS column names.
The external names are tab1 for the table and col1 and col2 for the columns.

3 - 14

RIS Overview

An external name, external to RIS, is the name in the underlying database.

The name used by RIS is an alias. This lets RIS-based applications use names
different from the underlying database, as well as longer names than are
permitted by the underlying database.
By default, when there is no extern clause, both RIS names and external names are the
same.

3.4.2 Altering Tables

Currently, you can change tables only by adding columns using the alter table
statement. The alter table statement adds one column to a table. If you want to add
more than one column, alter table must be issued once for every column.
To add a column, alter table requires the table name, the name of the column to be
added, and the data type of the column to be added. Also, the not null clause can be used
to specify that RIS does not allow NULL values in the column.
The following statement adds a column ext to the phones table:
alter table phones add ext char(4);
Since the not null clause was not specified, RIS allows NULL values in that column.
The phones table now contains the following rows and columns:

The not null clause in an alter table statement can only be used if the table does not
contain any data at the time the statement is issued.

3.4.3 Dropping Tables

You can drop tables from a database with the drop table statement. After you drop a
table it no longer exists in the database, nor does it exist to RIS. For example, the following
statement drops the employee_info table defined previously:
drop table employee_info;
If a table is referenced by one or more views, the views may not be dropped and
the underlying DBMS may issue an error when the views are referenced.
Whether an error is issued is dependent upon the type of DBMS. For more
information on views, see the section Views. For more information on errors
and error handling, see the section Error Reporting.

RIS Overview 3 - 15

3.4.4 Selecting Tables

You can extract data from tables by selecting rows and columns from the table according to
some criteria. Selecting is accomplished with the select statement. Columns are selected
by a list of column names. Any column whose name appears in the list is in the resulting
table. Rows are selected by setting conditions. If the data in a row meets that condition, it is
included in the resulting table. For example: Suppose the phones table mentioned
previously contained the following rows and columns:

A select statement to extract the row containing the name John is as follows:
select * from phones where name = John;
The asterisk (*) specifies that all columns from the phones table should be included in the
result. The selection criteria appears in the where clause. Any row in which the name
column contains John should be included in the result. Since only one row in the phones
table matches the criteria, the result table appears as follows:

3.4.5 Joining Tables

Relational database systems can relate the data in two or more tables. This is done by
merging the tables to temporarily form a virtual table and is called joining. For example,
consider a database with two tables: the phones table and the addresses table. The phones
table consists of two columns: name and phone. The addresses table consists of two columns
also: name and address. The two tables are related by the name column. It would be a
simple matter to join the tables into a table with the name, phone, and address columns by
using a select statement to extract rows and columns from both tables.
Each row from each table is tested independently for the condition. Because of
this, the data in each table does not have to be in the same order. The proper
select condition relates the rows from each table.

3 - 16

RIS Overview

For example: Suppose the phones and addresses tables contained the following data:

To join the two tables and relate the rows containing the same name, you would specify a
select statement similar to the following:
select * from phones, addresses where phones.name = addresses.name;
The select condition is phones.name = addresses.name. This condition relates the
names in the phones table (and the corresponding phone numbers) to the names in the
addresses table (and the corresponding address). The resulting table contains the following
data:

Notice that the resulting table contains two name columns. In the previous select statement,
the column list is specified as an asterisk (*). This specifies that all columns from each of the
tables be included. To select only specific columns, the select statement could be changed
similar to this:
select phones.name, phones.phone, addresses.address where ...

RIS Overview 3 - 17

This specifies that both columns from the phones table and only the address column from the
addresses table be included. The resulting table would appear as follows:

3.4.6 Inserting Rows

You can insert a single row or multiple rows using SQL statements.

3.4.6.1 Inserting a Single Row

The insert statement adds one row to a table. The values to be placed in the columns can
be specified in a values list or derived from a select statement. In either case, if the
number of values (specified or derived) does not equal the number of columns in the relation,
a column list must be specified. The following insert statement adds a new entry to the
example phones table.
insert into phones values ( Jerry, 555-4000 );

Notice that no column list is specified in the previous example. The list is not necessary
because the number of columns in the phones table is equal to the number of values in the
values list, and they are in the same order. The phones table now contains the following
rows and columns:

3 - 18

RIS Overview

If the ordering of the values is not the same as the ordering of the columns, a column list
must be specified. The column list must specify a column name for each value and must be
in the same order as the values.
insert into phones (phone, name) values (555-5000, Joe) ;

3.4.6.2 Inserting Rows Using a Select Statement

The following statement uses a select statement to insert values into a table.
insert into addresses (name)
select name from phones where phones.phone = 555-4000;
The select statement returns the name Jerry since that row contains the phone number.
The insert statement then adds a new row to the addresses table with the name Jerry.
Notice that the select statement only returns the name column; the number of values that
are to be inserted into the addresses table is not equal to the number of columns. Therefore,
the column list must be specified. In this example, only the name value is inserted. The
address column is set to NULL. The addresses table now contains the following rows and
columns:

RIS lets you insert multiple rows. In the previous example, if the where clause is left out, the
select statement would return all the names from the phones table and insert them into
the addresses table.
insert into addresses (name)
select name from phones;

3.4.7 Updating Rows

The update statement changes the data in one or more columns in one or more rows. The
rows affected are limited by a where clause much like selecting. The following statement
updates the address column of the row whose name column contains Jerry:
update addresses set address = Louisville, KY
where name = Jerry;

RIS Overview 3 - 19

The addresses table now contains the following rows and columns:

3.4.8 Deleting Rows

The delete statement removes one or more rows from a table. The following statement
removes the row from the phones table where the name column contains Jack:
delete from phones where name = Jack;

The phones table now contains the following rows and columns:

3.5 Views
A view is a window into tables and is sometimes called a virtual table. Through the view,
you can select data to look at or to perform other operations. When a table appears in a view,
the view is said to reference the table. A view can reference one or more tables and can
reference all or selected columns from each table.
There are two uses for views:
1.

Views can be used to logically combine tables to make them appear as one.

2.

Views can be used to limit the columns selected from one or more tables to restrict
access to sensitive data.

3 - 20

RIS Overview

3.5.1 Creating Views

Views are created with the create view statement. The tables and columns that are to be
referenced by the view are chosen in a regular select statement. The columns in the view
can optionally be given names different from the columns they reference. If virtual names
are given to the columns, the original names of the columns can no longer be used when
referencing the view. The column names in the physical tables do not change.
The create view statement also lets you use the extern clause to specify external
names for the views and columns.
The view only references the selected tables. The view does not actually contain
the data. If the data is changed in the physical table, then the view reflects
that change.
A view can be defined in terms of another view.
The following statement creates a view from the sample phones and addresses tables:
create view infoview as
select phones.name, phones.phone, addresses.address
from phones, addresses
where phones.name = addresses.name;
The statement creates a view called infoview that references the name and phone columns of
the phones table and the address column of the addresses table. The view infoview would
now display the following rows and columns:

3.5.2 Dropping Views

Views can be removed using the drop view statement. Dropping a view does not affect the
data that it references; it only removes the view definition from the data dictionary.
For example, the following statement removes the view infoview:
drop view infoview;

RIS Overview 3 - 21

The following statement creates a view called dbview.

create view dbview (phone_num, extension) as
select (phone, ext) from phones;
The following statement removes the view dbview:
drop view dbview;

3.5.3 Manipulating View Data

Manipulating data referenced by a view is more restrictive than manipulating data in tables.
The following rules apply when issuing the insert, update, and delete statements on a
view:
1.

The insert, update, and delete statements can be issued only on views that
reference one table. If a view references more than one table, the data referenced by
the view cannot be changed through the view.

2.

The insert, update, and delete statements cannot be issued on views that contain
an order by, a group by, a having clause, or a nested query in the view definition.

3.

If the table that a view references contains a column defined with the not null
clause, and the view does not reference that column, there is no way to insert a record
through that view. This is due to the fact that, through the view, no value can be
specified for the column defined as not null and therefore, a valid record cannot be
inserted.

3.5.3.1 Inserting View Data

Consider the following statements:
create table cars ( number int, make char(15),
model char(15), color char(10), year int );
This statement creates a table named cars with the following rows and columns:

create view models (number, model) as

select number, model from cars;
This statement creates a view named models which references the following columns in the
cars table.

3 - 22

RIS Overview

The following statement inserts a car number and model into the cars table through the
models view:
insert into models (number,model) values ( 10145, Badcar LX );
The cars table now contains the following data:

Selecting from the models view reveals the following data:

3.5.3.2 Updating View Data

You can update data referenced by a view in the same way you update data in a table. The
only exception is that updates to a view are subject to the same restrictions as inserts.
The following statement changes the model of Badcar LX to Leopard ZG.
update models set model=Leopard ZG where model=Badcar LX;
The models view now references the following data:

RIS Overview 3 - 23

3.5.3.3 Deleting View Data

You can delete data from views subject to the same restrictions as inserting and updating.
The following statement deletes a record from the cars table through the models view.
delete from models where number = 10145;

3.6 Privileges
All database privileges are dependent upon the privileges granted to the underlying users. If
the user is not the owner of the database, then the owner of the database has to grant
privileges for the user to create a RIS schema. Privileges you have are the same as the
schema privileges. There are two types of database privileges: database privileges and
relation privileges.

3.6.1 Database Privileges

Database management systems have three database privileges:
1.

The connect privilege lets you access, connect to, or log in to a database and issue
Data Manipulation Language (DML) statements. You must have at least connect
privilege in order to create a schema using a shared dictionary.

2.

The resource privilege lets a user issue Data Definition Language (DDL)
statements. This privilege adds the capability to create, alter, and drop relations. As a
part of creating a schema, RIS needs to create tables; therefore, you must have at least
resource privilege in order to create a schema and a dictionary.

3.

The dba privilege is the highest database privilege. DBA is an acronym for
database administrator. A user with database administrator privileges has access to all
statements and to the entire database. This user usually has the responsibility of
performing administrative duties.
You must set up database privileges in the underlying RDBMS, not through
RIS.

For a complete list of DML and DDL statements, see the sections Data Definition Language
(DDL) Statements and Data Manipulation Language (DML) Statements.

3.6.2 Relation Privileges

Granting access to relations lets schemas access tables and views defined in other schemas.
Each relation privilege grants access to perform a specific type of statement. Likewise,
revoking relation privileges results in the restriction of access to the relation from the
specified schema.
Relation privileges can be granted to, or revoked from, one or more schemas with the grant
or revoke statements and from all schemas by using the public keyword in a grant or
revoke statement. These privileges can be granted in any combination, except for all,

3 - 24

RIS Overview

which must be used alone. Likewise, these privileges can be revoked in any combination
using the revoke statement.
There are five relation privileges:
1.

The delete privilege lets a schema execute the delete statement on the target
relation.

2.

The insert privilege lets a schema execute the insert statement on the target
relation, thus adding rows to the relation.

3.

The select privilege lets a schema execute the select statement on the target
relation.

4.

The update privilege lets a schema execute the update statement on the target
relation, thus modifying existing rows.

5.

The all relation privilege grants or revokes all of the other relation privileges.

3.6.3 Using Privileges

As an example of using relation privileges, consider the development of this simple employee
database.
First, a schema is created which is used by the employee database administrator. The
database administrator has the responsibility of creating, altering, and dropping schemas
and relations with the schema management utility. Creation of databases and users is
vendor-specific and must be done outside of RIS.

create schema p_admin

on database ( oracle, dir c:\orant, dbname ORCL, ostype NT,
osuser Karen.pass)
user p_admin;

This statement creates a schema named p_admin (personnel administrator) on a database

named p_info (personnel information).

3.6.3.1 Creating the Employee Table

This statement creates the employee table.
create table employee_info ( name char(25) not null,
id int not null,
position char(20) not null,
wage real not null,
location char(15),
ext int,
other1 int,
other2 int,
other3 int );

RIS Overview 3 - 25

3.6.3.2 Creating the Maintenance Schema

Next, a schema is created to provide employees in the personnel department access to modify
the data in the database. The users of this schema maintain the data in the database by
inserting, deleting, and updating employee records. Also, the users of this schema do not
need to create or modify any relations as this is done by the administrator.
create schema p_maint user p_maint;
This statement created a schema name p_maint (personnel maintenance) on the same
database as the p_admin. This is because the statement that created the p_admin schema
also set the default schema. Therefore, the on database clause is not needed in this instance.
As created, the p_maint schema can only connect to RIS. It has no privilege to access any
relations. To give this schema access to some relations, the next step would be to grant it
some privileges.
The users of this schema need to insert, delete, update, and, most likely, select records from
the database. Using the following statements:
1.

Set the default schema back to p_admin since the previous statement set the default
schema to p_maint.
default schema p_admin;

2.

Grant the proper privileges to the p_maint schema.

grant select, insert, update, delete on employee_info
to p_maint;

Now p_maint schema can select, insert, update and delete from the table employee_info. In
addition, it can create and manage relations of its own.

3.6.3.3 Creating a Supervisor Schema

If company supervisors or managers need access to some of the data in the employee
database, but they should not be given access to all of it, they could be allowed (and be
limited) to view the data in the name, id, position, wage, location and ext columns.
This can be accomplished by creating a supervisor schema, creating a view in the
administrator schema, and granting access on that view to the supervisor schema. Using
this solution, the supervisor would not have access to the actual table in which the data is
stored, but would have access to the data referenced by the view.

3 - 26

RIS Overview

Also, there could be a need for supervisors to create and maintain some relations. To allow
for this, the user (of supervisor schema) must be given resource access.
1.

Create a view onto the employee_info table.

create view super_view
( name, id, position, wage, location, ext )
as select name, id, position, wage, location, ext
from employee_info;

2.

Create the supervisor schema with resource privilege.

create schema p_super user p_super;

3.

Set the default schema back to p_admin since the previous statement set it to the new
schema.
default schema p_admin;

4.

Grant the supervisor schema access to the view.

grant select on super_view to p_super;

The new view is called super_view and references the name, id, position, wage, location, and
ext columns of the employee_info table.
The new schema is called p_super. This schema can only select from the view super_view,
but can create and maintain relations of its own.

3.6.3.4 Creating an Employee Schema

Suppose there is a need for employees to access a limited amount of data in the employee
database. This can be accomplished by creating a view onto the employee_info table, creating
an employee schema, and granting access on the view to the employee schema.
Using the following statements:
1.

Create a view on the employee database that lets employees see the name, id, location,
and ext columns.
create view employ_view ( name, id, location, ext )
as select name, id, location, ext from employee_info;

2.

Create a schema for employee access.

create schema p_employ user p_employ;

RIS Overview 3 - 27

3.

Set the default schema back to p_admin because the previous statement set it to the
new schema.
default schema p_admin;

4.

Grant access on the employee view to the employee schema.

grant select on employ_view to p_employ;

The new view is named employ_view and references the name, id, location, and ext columns
of the employee_info table.
The new schema is named p_employ and can select from the employ_view view. In addition,
it can create and manage relations of its own.

3.6.4 The Grant Option

When a relation privilege is granted to a schema, it can also be granted the privilege to grant
privileges itself. This is made possible by the grant option and is specified with the with
grant option clause in the grant statement. A schema which has been granted
relational privileges with the grant option not only possesses the privileges, but can grant
them to other schemas as well.
For example: Schema A grants insert, update, and select privileges to Schema B with the
grant option. Schema B can now grant insert, update, or select privileges to other schemas.
Schema B can also grant these privileges with the grant option. However, Schema B cannot
grant delete, or all privileges since it does not possess those privileges.

Privileges granted by a schema that has been granted that privilege (along with the grant
option) can be revoked from a schema by any schema before it in the chain. This creates a
cascading effect of revoking the privilege from all schemas in the chain after the schema
which executed the revoke.
For example, Schema B grants insert, update, and select privileges to Schema C. If Schema
A revokes the update privilege from Schema B, then it is also revoked from Schema C.

3 - 28

RIS Overview

3.7 Transactions
Transactions let you group a set of one or more SQL statements as a single logical unit of
work. The transaction mechanism provided by RIS lets the set of one or more SQL
statements be:
1.

An atomic unit: either all or none of the SQL statements of a transaction affect the
database permanently.

2.

A consistent unit: simultaneous queries and data updates from different transactions do
not interfere with each other.

The transaction-related commands in RIS include commit, rollback, lock tables, and
set transaction.
The commit statement makes all the changes in a transaction permanent in the database
and the rollback statement makes none of its changes present in the database. The lock
tables statement prevents other transactions from reading or overwriting the partial
changes or the temporary results of this transaction. So, the commit statement and the
rollback statement guarantee the atomicity property of a transaction and the lock
tables statement ensures the consistency property.
The set transaction autocommit statement controls transaction autocommit mode. If
the transaction autocommit mode is enabled (by default), a transaction consists of only one
statement and RIS issues a commit statement implicitly after each SQL statement.
Otherwise, a transaction may have more than one SQL statements and a commit statement
or a rollback statement is required to end the transaction.
A transaction in RIS allows access to the tables within only one schema. To enhance the
distributed and parallel processing abilities, RIS lets users work simultaneously on multiple
transactions on different schemas in one program or one interactive session. This ability of
the multiple transactions is specified by the parameter MAX_TRANSACTIONS in the parms
file. The parameter specifies the maximum number of transactions a user can work on
concurrently in one program or one interactive session.
To completely understand transactions and multiple transactions, you must understand that
there are three categories of statements in ANSI SQL:

RIS Overview 3 - 29

1.

Data Definition Language (DDL)statements

2.

Data Manipulation Language (DML) statements

3.

Miscellaneous statements

3.7.1 Data Definition Language (DDL) Statements

Data Definition Language statements can generally be described as statements that
manipulate database object structures and user access (the data dictionary). In relational
databases, the data dictionary catalogs all database object information. For example, tables
that make up the data dictionary contain records of tables and columns that define that
table. Furthermore, the data dictionary contains information pertaining to user access of the
database. When a table is created, the data dictionary contains a record with the table name
and records containing the column names, data types, and whether or not these columns
must or can not contain information.
The most obvious of the DDL statements are the create and drop statements. As
schemas, tables, views, and indexes are created, the information describing them is entered
into the data dictionary. Likewise, this information is deleted from the data dictionary when
they are dropped.
Because DDL statements affect the data dictionary and the actual composition of the
database, they cannot be included in a transaction. Once a DML statement has been issued,
no DDL statements can be issued until a transaction is ended with a commit, rollback, or
set transaction autocommit on statement. However, if no statements are pending in a
transaction, such as immediately after a commit, rollback, or set transaction
autocommit statement, or if the transaction autocommit mode is enabled, DDL statements
can be issued as needed.
This is a complete list of DDL statements:
alter schema
create schema
drop index
drop view

alter table
create table
drop schema
grant

create index
create view
drop table
revoke

3.7.2 Data Manipulation Language (DML) Statements

Data Manipulation Language statements manipulate data in the tables, views, and indexes
defined in schemas. DML statements can be issued in any combination and in any order
within a transaction. DML statements can be made effective with the commit statement or
canceled with the rollback statement.
This is a complete list of DML statements:
delete
union

insert
update

select

3 - 30

RIS Overview

3.7.3 Miscellaneous Statements

The following miscellaneous statements do not fit into the data dictionary or data
manipulation categories:
close schema
declare table
lock tables
set database
undeclare schema
exec <dbtype>

commit
declare view
open schema
set mode
undeclare table
set network

declare schema
default schema
rollback
set transaction autocommit
undeclare view

3.7.4 Enabling and Disabling Transaction Autocommit

The transaction autocommit mode can be enabled or disabled with the set transaction
autocommit statement. If the autocommit mode is on, a transaction consists of only one
SQL statement, and RIS automatically issues a commit statement after every statement.
Likewise, the transaction autocommit mode can be disabled by setting the autocommit mode
to off. When the autocommit mode is off, RIS does not end transactions on behalf of the user.
The user must end the transaction explicitly with a commit or rollback statement.
There are some exceptions to this rule that provide the user with some degree of
safety.
1.

If RIS is terminated with a transaction still in progress, RIS issues a rollback

statement to prevent the possibility of corrupting data.

2.

If an error occurs during the execution of any DML statement, RIS issues a
rollback statement to prevent the corruption of data.

3.7.5 Starting and Ending Transactions

When the transaction autocommit mode is enabled, a transaction consists of only one SQL
statement and, therefore, the transaction starts and ends at the statement.
When the transaction autocommit mode is disabled, a transaction may have more than one
SQL statement and the transaction begins when the first SQL statement is executed after
the set transaction command.
A transaction ends (if the transaction autocommit mode is disabled) when:
1.

A commit or rollback is invoked.

OR

RIS Overview 3 - 31

2.

The transaction autocommit mode is switched to enabled from disabled (the transaction
is committed).
OR

3.

Termination of a user process (the transaction is ended with the rollback statement).

After one transaction ends, the next SQL statement automatically starts the next
transaction.

3.7.6 Committing Transactions

As stated earlier, the commit statement ends a transaction and the effects of all statements
within that transaction are made permanent in the database.
When a commit statement is issued, all cursors are closed and all locked tables
are released. For more information on cursors, see the RIS Programmers
Guide. For more information on table locking, see the section Tables in this
document or the lock tables statement description.
Consider this sample phones table containing the following data:

The following statement enables normal transaction processing by setting the transaction
autocommit mode to off.
set transaction autocommit off;

If the following update statements are issued:

/* the statements in transaction A */
update phones set ext = 201 where name = Jim;
update phones set ext = 315 where name = Jack;

The transaction that issues the updates sees the results immediately. With
most database systems, another transaction (selecting from that relation) does
not see the results until a commit statement is issued by the transaction that
issued the updates. INFORMIX-SE, however, posts all changes to the database
immediately and then reverses those changes if a rollback statement is

3 - 32

RIS Overview

issued. Before the rollback statement is invoked, other transactions can read
the partial results from the update transaction. The solution to prevent from
reading the uncommitted updates is to use the lock tables statement.
The following select statement from another transaction indicates that the updates have
not been performed on the table, if it is invoked before the commit is issued for the first
transaction A.
select * from phones; /* the statement in transaction B */

If a commit statement is issued, however, its update can be read by other transactions. The
following select statement from transaction B is executed after the transaction A is
committed.
select * from phones; /* the statement in transaction B */

3.7.7 Rolling Back Transactions

The rollback statement ends a transaction and discards any statements pending in that
transaction. Therefore, any changes made by the statements in that transaction are
canceled.

RIS Overview 3 - 33

When a rollback statement is issued, all cursors are closed and all locked
tables are released. For more information on cursors, see the RIS
Programmers Guide. For more information on table locking, see the section
Tables in this document or the lock tables statement description.
Consider the phones table again which now appears as follows:

If the transaction autocommit mode is disabled and the following update statements and
select statement are issued (for a transaction), the select statement results from the
phones table appear as follows:
/* the
update
update
select

statements in transaction A */
phones set ext = 407 where name = John;
phones set ext = 683 where name = Jerry;
* from phones;

3 - 34

RIS Overview

If a rollback statement is issued, the transaction is ended and the table once again
appears as follows:

3.7.8 Locking Tables

The lock tables statement locks one or more tables, preventing other users from
changing them while the lock is in effect. It is also used to prevent other users from having
full access to perform their normal operations on any table named in the statement.
Note that, for most of the database servers, RIS implicitly locks all tables for each
transaction. One exception is when the RIS server runs INFORMIX DBMS, in which case
RIS does not prevent other transactions from reading the results from an uncommitted
transaction.
To guarantee the consistency of concurrent executions of several transactions, it is
recommended to use the lock tables statement to explicitly lock all the tables accessed by
each transaction.
The lock tables statement must be the first statement in a transaction. Therefore all
tables to be referenced in a transaction must be included in the lock tables statement. If
a transaction involves more than one schema, each lock statement is needed to get locks for
each schema before other statements are invoked. The lock mechanism supported by RIS is
deadlock-free.
Table locks are automatically removed when a commit or rollback statement is issued.
For more information about the lock statement, see the section lock tables.

Examples
lock tables sch1.tab1, sch1.tab2 in exclusive mode;
lock tables tab1, tab2 in share mode tab3, tab4 in default mode;
lock tables sch1.tab1 in share mode
sch1.tab2 in exclusive mode sch1.tab3 in default mode;

RIS Overview 3 - 35

3.7.9 Using Multiple Transactions

RIS lets users work simultaneously on multiple transactions (one per schema) in one
program or one interactive session. The multiple transactions ability is specified by the
parameter MAX_TRANSACTIONS in the parms file. The parameter specifies the maximum
number of transactions that a user can work on concurrently in one program or one
interactive session. For example, if MAX_TRANSACTIONS is set to 2, then two transactions
can be executed at the same time in one interactive session.

Examples
default schema sch1;
insert into t1 values (1, Jack, 20);
insert into sch2.t1 values (1, Jack, 20);
commit for sch1;
commit for sch2;

In the previous example, the first insert statement belongs to the transaction for the
schema sch1, and the second insert statement belongs to the transaction for the schema
sch2. The first commit statement ends the transaction for schema sch1 and the second ends
the transaction for schema sch2.

3.8 Set Network Verification

In the RIS client-server architecture, the RIS client and RIS server can run on either the
same or separate processors. The RIS client sends requests to the RIS server for each SQL
statement and gets the results from the RIS server.
To more accurately reflect the status of the server, RIS provides the set network
verification statement to let you set up an alarm timestamp mechanism between the RIS
server and the RIS client. Through the mechanism, the RIS server sends a timestamp at the
specified timestamp interval after it begins to execute an SQL statement until the execution
finishes. Before receiving the execution results of the SQL statement, RIS client collects
these timestamps. If the RIS client gets the alarm timestamps from the RIS server properly
before the SQL statement finishes, the RIS server is thought to be still running. Otherwise,
the RIS server is thought to have terminated.
A set network verification statement can specify the alarm timestamp mechanism for
all schemas that are opened after the statement. For example, the following statement sets
up the mechanism to ask all RIS servers started after the statement to send a timestamp at
ten second intervals (note that each opened schema corresponds to a RIS server):
set network verification timestamp interval 10;

3 - 36

RIS Overview

A set network verification statement also can specify the alarm timestamp
mechanism for any opened schema. For example, the following statement sets up the
mechanism to ask the RIS server associated with the schema sch1 to send a timestamp at
ten second intervals:
set network verification timestamp interval 10 for sch1;
For more information, see the section Set Network Verification.

3.9 Indexes
The time required to search a column of a table or view for a matching value can be reduced
by creating an index on that column. An index is a sorted list of the values in that column.
Since the list is sorted, the DBMS can use faster techniques to search for matching values.
The speed gained by indexing a column is greater for larger numbers of values, therefore it is
not advantageous to create an index on a table that contains few values.
One disadvantage of indexes is that they require more disk space to maintain. Also, the time
required to insert a value into an indexed column is greater due to the overhead of
maintaining the index.
Bulk data loading should be done without indexes in existence.

Indexes are created with the create index statement. For example, the following
statement creates an index on the name column of the phones table:
create index name_index on phones (name);
The extern clause can be added to the create index statement to specify an external
name for the index. For example:
create index name_index on phones (name)
extern ind1;
Indexes can be created on several columns. If an index is created on
more than one column, the indexes of the columns are searched from
left to right in the order they are specified in the create
index statement. For example, the following statement creates
an index on the phone number and ext columns of the
addresses table:
create index phone_index on addresses ( phone, ext );
When you search for a phone number and extension, the DBMS attempts to match the phone
number first and, if a match is found, attempts to match the extension number.

RIS Overview 3 - 37

The unique keyword can be used to specify that no duplicate values are allowed in the
column or columns on which the index is created. The DBMS reports an error on an attempt
to create a unique index on a column that contains duplicate data. Likewise, the DBMS
reports an error on an attempt to insert duplicate data into a column for which a unique
index has been created.
The following statement creates a unique index on the name column of the phones table:
create unique index name_index on phones ( name );

3.10 Examples
3.10.1 Using a Secure Schema
As an example of using a secure schema, consider the ORACLE database corp_data that
manages various types of corporate and project data in a company.
Some of the users on this database are king, tom, amy, pat, raj and lee, having different
levels of privileges. A secure schema is created on this database by user king using the
statement:

create secure schema project_data

on database (oracle, dbname corp_data,
dir c:\orant, osuser guest.guestp, ostype nt)
user king.kingp;

King becomes the schema owner (or administrator) of this schema. In addition, king is the
dictionary owner of the RIS dictionary created along with this schema (project_data).
Project_data becomes the default schema with the user king connected to it.
King can now create the following table in this schema :

create table projects (

projname char(20),
manager char(20),
status
int,
comments char(100),
comments2 char(100),
comments3 char(100),
targetdate timestamp,
budget int);

King can let other users connect to his schema. Tom, amy, pat, and raj need to be able to
connect to the schema project_data and also manipulate the table projects. Additionally, pat
and raj need to be able to create their own tables and views.

3 - 38

RIS Overview

The database level privileges for these users to access the table projects are granted in the
underlying ORACLE database.
The schema access is granted by king to the previous users through RIS. Assuming this is
done in a new RIS session, king needs to connect to the secure schema using the following
statements :

declare schema project_data osuser guest.guestp user king.kingp;

default schema project_data;

Tom and amy are granted connect privilege using :

grant connect to tom;

grant connect to AMY;

Since ORACLE is not case sensitive with respect to user names, both of these statements
work. (AMY is entered in upper case letters.)
Pat and raj are granted resource privilege using :

grant resource to pat;

grant resource to raj;

Now, pat can connect to this schema and create his tables and views :

declare schema project_data osuser guest.guestp user pat.patpass;

default schema project_data;
create table myproject (
task char(20),
status int,
start timestamp,
finish timestamp,
cost int);

If pat does not grant DBMS level privileges on this table to other users, for example tom,
tom will not be able to access this table even though he can connect to the schema and see
the table listed in the RIS dictionary.
Tom and amy can connect to the schema in a similar fashion but all they can do is
manipulate the projects table.

RIS Overview 3 - 39

3.10.2 Using a Shared Dictionary

Consider the following example to illustrate the use of a shared dictionary. This example
assumes the users, database, and schema in the previous example.
Lee wants to create a schema to track inventory and facilities but does not want to create
RIS dictionary tables. He wants to use kings dictionary. Lee also wants his schema to be a
standard schema, that is, a single user schema where all the information needed to open the
schema is available in the schema file, thus precluding the need for declaring the schema.
Before lee can create the schema, king needs to grant him schema privilege. To do that, king
connects to his schema first and then issues a grant statement :

declare schema project_data osuser guest.guestp user king.kingp;

default schema project_data;
grant schema to lee;

Now the schema facilities is created for the user lee :

create schema facilities

on database (oracle, dbname corp_data,
dir c: \orant, osuser guest.guestp, ostype nt)
user lee.leepass using king;

The using clause in the previous statement causes the information about this schema to be
stored in the dictionary created along with the schema project_data.
Though the facilities schema and the project_data schema share the dictionary, lee cannot
access the projects schema.
Since the schema facilities is a standard schema, all connections to it are made as user lee.
Access to this schema by other users can be controlled by having a separate schema file or by
passwording the schema.

3.10.3 Using External Objects

External objects are tables, views, or indexes owned by a user other that the current user.
This example shows how to include external objects with the alter schema statement.
The same users, database, and schemas are assumed as in the two previous examples.
Assume there is a view emp_view on the table employee owned by the user payroll. This
table containing information about all the employees and the view shows some of the
columns of this table. At the DBMS level, select privilege is granted to all users of the
database on this view (typically using public as the grantee).

3 - 40

RIS Overview

If all users of the schema project_data should have access to this view, this can be achieved
through the statement:

alter schema project_data include table payroll.emp_view as emp;

Since project_data is a secure schema, it needs to be declared with a valid user identification.
The alter schema statement is a DDL statement requiring resource privilege. Hence the
schema should be declared with king, pat or raj as the user. Note that the user payroll need
not have any access to the schema project_data.

SQL Database Language Reference 4 - 1

SQL Database Language Reference

__________________________________________________________________________________________________________________________________________________

4-2

SQL Database Language Reference

SQL Database Language Reference 4 - 3

4.

__________________________________________________________________________________________________________________________________________________

SQL Database Language Reference

This section provides a list of identifiers and an alphabetical reference to the SQL statements
supported by RIS.
Identifiers can consist of uppercase and lowercase letters, digits, and the underscore
character (_), but must begin with an alphabetic character. The length can range from 1 to
18 characters in ANSII mode, otherwise the length can range from 1 to 31.
Refer to the section Before You Begin for descriptions of syntax notation.

4.1 List of Identifiers

Identifier

Description

<boolean>

Any of the boolean operators.

<char col>

A column whose data type is character.

<column-list>

A comma-separated list of column names.

<column>

The name of a column defined on a table.

<comparison-op>

Any of the comparison operators.

<conditions>

A where clause.

<data type>

Any valid RIS data type.

<db_desc>

A database descriptor (specific per vendor database).

<dbname>

The name of the database.

<dir>

A valid directory.

<expr>

An arithmetic or boolean expression.

<index>

A valid index name.

<m>

An integer value.

4-4

SQL Database Language Reference

<n>

An integer value.

<nested-query>

A valid subset of the select statement.

<node>

A valid nodename or address for TCP/IP.

<num>

An integer value.

<ostype>

Type of operating system.

<osuser>

Operating system username.

<passwd>

A password.

<rel-privileges>

A comma-separated list of relation privileges.

<protocol>

One of the network communication protocols.

<rdbms_name>

A database username.

<relation-list>

A comma-separated list of relation names.

<relation>

A valid relation name. Can be the name of a table or view.

<ris...>

The ris prefix identifies a RIS name in statements where both the
RIS name and the underlying database name (DBMS) occur.

<riscolumn>

An alias for a column name in the underlying database (known only

to RIS).

<risindex>

An alias for an index name in the underlying database (known only to

RIS).

<ristable>

An alias for a table name in the underlying database (known only to

RIS).

<risview>

An alias for a view name in the underlying database (known only to

RIS).

<dbms...>

The dbms prefix identifies a name from the underlying database in

statements where both the RIS name and the underlying database
name (DBMS) occur.

<dbmscolumn>

A column name in the underlying database.

<dbmsindex>

An index name in the underlying database.

<dbmstable>

A table name in the underlying database.

<dbmsview>

A view name in the underlying database.

<schema>

A valid schema name.

SQL Database Language Reference 4 - 5

<schema-list>

A comma-separated list of schemas.

<select-statement>

A valid SQL select statement.

<table>

A valid table name.

<username>

A valid database username.

<value>

A constant value appropriate for one of the supported SQL data

types.

<values-list>

A comma-separated list of values.

<view>

A valid view name.

<wildcard-string>

A string that can contain wildcard characters. Supported wildcard

characters are the underscore character ( _ ) and the percent
character (%). The underscore character matches any single
character while the percent character matches zero or more
occurrences of any characters.

4-6

SQL Database Language Reference

4.2

__________________________________________________________________________________________________________________________________________________

Supported SQL Statements

The following is an alphabetized list of SQL statements supported by RIS. A complete
description of these statements is provided on the following pages. A Quick Reference Card
containing these statements is also provided with this document.
alter schema
alter table
close schema
commit
create index
create schema
create table
create view
declare schema
declare table
declare view
default schema
delete
drop index
drop schema
drop table
drop view
exec
grant
insert
lock tables
open schema
revoke
rollback
select
set database
set mode
set network verification
set transaction
undeclare schema
undeclare table
undeclare view
union
update
where
Nested Query
SQL Functions

SQL Database Language Reference 4 - 7

4.2.1

__________________________________________________________________________________________________________________________________________________

alter schema
The alter schema command modifies a RIS schema definition.
alter schema <schema>[.<passwd>]
{
to secure|
modify schema password <passwd> |
modify [user password <passwd>]
[, osuser <osuser>[.<passwd>]
[, remote ( {<protocol> <node> } [, ...] )] |
modify db2 password from <passwd> to <passwd> [ using mode <mode> ] |
include { table [<dbmsuser>.]<dbmstable> [as <ristable>
[(riscolumn> [,...])]|
view [<dbmsuser>.]<dbmsview> [as <risview>
[(riscolumn> [,...])]|
index [<dbmsuser>.]<dbmsindex> [as <risindex>]} |
exclude { table <ristable>|
view <risview>|
index <risindex>
};

RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.
Notes
_ ____
You must alter a schema if the RIS schema definition becomes inconsistent with the
database. For example, if passwords and network nodes are changed, you can update the
RIS schema definition to reflect these changes. You must issue an alter schema
statement to update the RIS schema definition. Additionally, you can include or exclude RIS
objects from the RIS schema definition (dictionary).
The <schema> identifier is the name of the schema you want to modify.
You can specify only one of the following clauses at a time.
The to secure clause changes a standard schema to a secure schema, thus allowing
multiple users on the same schema.
A secure schema cannot be changed back to a standard schema. Also, the
connection to a secure schema requires that the schema be declared before it is
opened.

4-8

SQL Database Language Reference

The modify user password clause and modify remote clause can be used in a single
modify clause to change the user password and nodename, respectively.
For INFORMIX, SYBASE, and Microsoft SQL Server, the user password must
be changed in the operating system before changing it in RIS. For ORACLE,
the user password must be changed in sqldba before changing it in RIS.
The modify schema password clause changes the password of the schema. You must
specify the current schema password (if any) to modify the schema password unless the
password has been specified in a preceding declare schema statement. The <passwd>
identifier specifies the new schema password.
The modify user password clause changes the password of the user associated with the
schema. The <passwd> identifier specifies the new user password. This modifies the
password only within RIS (this option does not update the password in the vendor DBMS or
the operating system).
The modify osuser clause changes the name and password of the operating system user
associated with the schema. The <osuser> identifier specifies the new operating system
username. The <passwd> identifier specifies the new operating system user password. The
osuser clause lets an operating system user be specified so that the RIS server is not
necessarily started as root.
The modify remote clause changes the node on which the database exists. This is useful
when the hardware address of the machine changes. The <node> identifier can be a
nodename, or an Internet address. Note that modify remote and modify user
password can be done simultaneously. The current value for protocol is: TCP.
The modify db2 password clause performs the same function as the modify user
password clause, except that the user password is also updated on the IBM host system.
This option works only for IBM systems using an external security manager with CICS, such
as RACF, and only for CICS systems supporting the CICS CESN transaction as provided by
IBM. Your IBM security administrator may not allow the use of this function. The CICS
system may require the use of a mode for this function that is different from the one
specified in the create schema command.
The include table/view/index clause includes a table, view, or index from the
underlying vendor DBMS into a RIS schema definition (RIS dictionary). This object is then
known to the schema. If the data type of any column of the table and/or view to be included
is not a RIS supported data type, it is defined as an UNSUPPORTED data type and the
column is not accessible.
The optional <dbmsuser> qualifier lets a table, view, or index owned by a user other than
the schema user be included in the schema.
The as clause permits an alias to be specified. After the as clause is used, RIS knows that
table/view/index by the alias and not by the underlying RDBMS name. Once an alias is
established within RIS, the alias must be used in all subsequent statements. If column
names are given aliases, the number of columns specified in the as clause must match exactly
the number of columns in the original table or view. Note that the column names for the
original table or view are not specified in the include clause.

SQL Database Language Reference 4 - 9

The RIS_VIEW_DEFS column, in the RIS dictionary view RIS_VIEWS, is made null
on a view that already exists in the database when a schema is created. Because the
RIS_VIEW_DEFS column is NULL, you cannot use the risunlod utility to unload
the view definition.
The exclude table/view/index clause excludes a table, view, or index from the RIS
schema definition (RIS dictionary). RIS does not drop and/or delete the object from the
vendor DBMSs dictionary.
The alter schema statement does not cause any changes to occur in the
vendor DBMS. Only the schema definition within the RIS dictionary is
modified.
If there are other parts of the schema definition you need to alter, it is necessary to
drop the schema and re-create it. However, dropping the schema removes any
privileges granted to or by the schema.

For more information about schemas, see the section Schemas.

Examples
_________
alter schema billyjean.passwd modify schema password sesame;
alter schema jackjean modify user password beanstalk, remote (tcp servant);
alter schema jimmydean modify remote (tcp servant), osuser smith.smithpass;
alter schema master modify osuser smith.smithpass;
alter schema db1 modify db2 password from oldpass to newpass
using mode IGRLU62P;
alter schema realt include table tab1 as mytab (mycol1, mycol2);
alter schema realt exclude view view1;
alter schema joe include index i1;
alter schema joe exclude index i2;
See
Also
________
create schema
drop schema

4 - 10

SQL Database Language Reference

4.2.2

__________________________________________________________________________________________________________________________________________________

alter table
The alter table statement adds a column to an existing table in the default schema.
alter table <table> add <riscolumn> <data type> [not null]
[ extern <dbmscolumn> ];
RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.
Notes
_ ____
Currently, the only change you can make to tables is the addition of columns. This is
accomplished with the alter table statement which adds a single column to a table. If
you want to add more than one column, the statement must be issued once for each column.
The alter table statement requires the table name and the name of the column you want
to add. You can use the not null clause to specify that RIS not permit null values in the
column.
The <table> identifier is the name of the target table. The table must exist in the default
schema.
The <riscolumn> identifier is a column name that is unique to the target table.
The <data type> identifier is an SQL data type.
Valid SQL data types and the mapping of SQL data types to vendors data types
are described in the section RIS Data Types.
The not null keywords form an optional phrase specifying whether or not
null values are allowed in the column. You use not null only when the
alter table statement is applied to a table that does not contain any data.

The optional extern keyword and <dbmscolumn> identifier form an optional phrase
specifying a column name for the underlying database different from the RIS column name.
This clause creates an alias (<riscolumn>) for the column name (<dbmscolumn>).

SQL Database Language Reference 4 - 11

When a table is altered, DB2 defines default values for existing data. DB2 has
a default value only when not null is specified.
Examples
_________
alter table table1 add col4 integer not null
extern dbtab1;
Existing views cannot access the new columns even if the view statement used
a wildcard (*) to select all columns.
See
Also
________
create table
drop table

4 - 12

SQL Database Language Reference

4.2.3

__________________________________________________________________________________________________________________________________________________

close schema
The close schema statement deactivates a RIS database server process for a schema.
close schema { <schema> [, ...] | all };
Notes
_ ____
The <schema> identifier is the name of the schema. Do not give the schema password.
The close schema all closes all opened schemas.
An implicit commit is issued if autocommit is off.
If you try to close a schema that is not open, you do not get an error message.
If the default schema is closed, another default schema statement must be
executed before any other SQL statements can be executed.
A schema must be opened before it can be referenced. Schemas can be opened
explicitly with the open schema statement or implicitly by any reference to
the schema.
You do not need any privileges to close a schema.
For more information about schemas, see the section Schemas.
Examples
_________
close schema all;
close schema jim;
close schema jim, joe, fred;
See
Also
________
create schema
default schema
open schema

SQL Database Language Reference 4 - 13

4.2.4

__________________________________________________________________________________________________________________________________________________

commit
The commit statement ends a transaction, or group of SQL statements, making permanent
the effects of all statements in the group.
commit [ work ] [ for <schema> ];
Notes
_ ____
By default, the autocommit mode is on and RIS automatically issues a commit statement
after every SQL statement. Setting the autocommit mode to off enables normal transaction
processing. You can use the set transaction autocommit statement to enable or
disable the autocommit mode. The commit statement is not necessary in autocommit mode
but can still be used.
For more information about transactions and the use of the commit, rollback, and set
transaction autocommit statements, see the rollback and set transaction
autocommit statement descriptions.
The work keyword can be specified to conform to the SQL standard. It is optional and
serves no other function.
The for <schema> clause lets the user specify which transaction to commit (RIS supports
multiple transactions, up to one transaction per schema). The maximum number of multiple
transactions is specified by MAX_TRANSACTIONS in the parms file. If the for <schema>
clause is not specified, the transaction associated to the current default schema is committed
(however, if MAX_TRANSACTIONS is assigned the value 1, the command commits any
transaction, whether or not it is associated with the default schema). If the for <schema>
clause is specified, the transaction associated to the schema name is committed (however,
the schema may not be a default schema).
The vendor DBMSs implement transactions in different ways that determine
when the effects of the statements in a transaction are posted to the physical
database.
When a commit or rollback statement is executed, all cursors are closed and
all locked tables are released.

4 - 14

SQL Database Language Reference

If an error occurs during the execution of a DML statement that updates the database,
a rollback command is executed automatically.
If RIS is terminated within a transaction, a rollback statement is issued
automatically.
Examples
_________
commit;
commit for sch1;
See
Also
________
rollback
set transaction

SQL Database Language Reference 4 - 15

4.2.5

__________________________________________________________________________________________________________________________________________________

create index
The create index statement creates an index on one or more columns in a table in the
default schema.
create [ unique ]index<risindex>
extern <dbmsindex> on <ristable> (<riscolumn> [, ...]);
RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.
Notes
_ ____
The time required to search a column of a table or view for a matching value can be reduced
by creating an index on that column. An index is a sorted list of the values in that column.
Since the list is sorted, the DBMS can use faster techniques to search for matching values.
The speed gained by indexing a column in a table is greater for a large number of rows; there
is no real advantage in creating an index on a table that contains few rows.
A disadvantage of indexing is that indexed tables and views require more disk space to
maintain. Also, the time required to insert a value into an indexed column is greater due to
the overhead of maintaining the index.
Indexes are dropped when the table on which they are created is dropped.
The <index> identifier is the name of the new index. In general, index names must be
unique within a schema.
INFORMIX does not let multiple users in one database have an index of the
same name. Therefore, if more than one schema is defined on one INFORMIX
database, index names must be unique to all of those schemas.
In contrast to INFORMIX, ORACLE let multiple users within the same
ORACLE database have an index of the same name.
The <table> identifier is the table name. The table must exist in the default schema.
The <column> identifier is the name of the column on which to create the index. Creating
an index on more than one column results in an ordering of the row by the columns from left
to right in the column list. An index with multiple columns is called a composite index.

4 - 16

SQL Database Language Reference

The unique keyword indicates whether duplicate values should be allowed for the indexed
column.
The maximum number of columns that can be specified for an index is eight. The total width
(number of bytes) of a composite index must be 120. For information about how to
calculate the number of bytes in an index, see the section RIS Limits.
In the optional extern clause, the <dbmsindex> must be a valid index name for the
underlying database. With this clause, the index name in the underlying database
(dbmsindex) can be given an alias (risindex) that is used by RIS and RIS-based applications.
Indexes add some storage overhead and also degrade insertion and deletion
time.
Bulk data loading should be done before the creation of indexes.
Examples
_________
create unique index t1c1 on table1(column1);
create index t1c1c2 on table1(column1, column2);
create index t1c3 extern t1c3 on table1(column1, column2);
See
Also
________
alter table
create table
drop index
drop table

SQL Database Language Reference 4 - 17

4.2.6

__________________________________________________________________________________________________________________________________________________

create schema
A schema is a named collection of tables, views, indexes, and privileges owned by a user on a
database. Within RIS, the tables, views, indexes, and privileges are contained in, created by,
and owned by the schema.
When the schema is successfully created, the new schema is opened and becomes the default
schema. After the schema has been created, you should use the schema name to refer to the
database/user combination.
If you attempt to create a schema on a database, and a RIS dictionary already
exists for that schema, but there is no entry for the schema in the schema file,
RIS creates an entry in the schema file and does not modify the DBMS.

create [secure] schema [authorization] <schema>[.<passwd>]

[on database (<db_desc>
[, remote (<protocol> <node> [, <protocol> <node> ...])])]
[user <username>[.<passwd>]]
[using <user>]
[server version <maj>[.<feature>]]
[include | exclude]
[force]
The keyword secure denotes a secure schema, that is, a multiuser schema.
The keyword authorization is for compatibility with the ANSI standard, but is not
necessary.
The <schema> identifier is the schema name which can be 18 characters in length (ANSI
mode) or up to 31 characters in length (non-ANSI mode). The ANSI mode can be turned on
or off using set mode statement.
The schema <passwd> can be 31 characters in length. It is independent of ANSI mode.
The syntax of the <db_desc> clause is DBMS dependent. For more information and exact
syntax, see the following sections:
create schema (INFORMIX Database Descriptor)
create schema (ORACLE Database Descriptor)
create schema (DB2 Database Descriptor)
create schema (SYBASE Database Descriptor)
create schema (Microsoft SQL Server Database Descriptor)

4 - 18

SQL Database Language Reference

Notes
_ ____
The schema created has the same authorization as the user. If any particular database user
is not the owner of the database, the owner of the database has to grant privileges to the user
to be able to create a RIS schema
The on database clause specifies the database environment (vendor, location, name, and
other information) on which the schema is created. It is valid to use the on database
clause when creating subsequent schemas on a database. If the on database clause is not
used, then the new schema is created on the same database as the default schema. The
remote clause is part of the on database clause and must be specified if the data server is
on another node or if you need to specify how the database should be accessed remotely (from
another machine). This is necessary to set up the communication information.
Generally, the remote data server and database are on the same node.
However, for INFORMIX, and ORACLE databases accessed by RIS**NET data
servers, the remote clause must specify the location of the RIS**NET data
server rather than the location of the database.

The <protocol> identifier specifies the type of network protocol to use to communicate
with the remote site. The communication protocol currently supported is TCP (TCP/IP). The
valid value is TCP. The <node> identifier can be either a nodename as defined by the
protocol, or an Internet address. Currently three protocols can be listed at one time. The
first protocol that is supported between the client and server nodes found by searching the
list top to bottom is used.
VAX servers allow two protocols: DECNET and DEC TCP/IP. Intergraph
Intel-based systems support only 1 protocol: TCP/IP.
The user clause can be omitted if it has been specified in a previous declare schema
statement. Otherwise, it is mandatory. The <username> identifier must be known to the
vendor DBMS. Database users must be created before RIS schemas can be created. The
length of the <username> and user <password> is dependent on the operating system and
vendor database.
The different vendor DBMSs have different concepts of a user. For example: on INFORMIX,
the <username> in the user clause must be a valid, existing, operating system log-in on the
machine where the database resides. On SYBASE, the database user has to be a SYBASE
system log-in. On Microsoft SQL Server, the database user has to be a Microsoft SQL Server
system log-in. On ORACLE, the <username> does not have to be an operating system log-in
(maxlen for ORACLE is 30). In the user clause, the <username> and <passwd> identifiers
must be valid ORACLE user names and passwords. The <passwd> identifier is required for
ORACLE databases. For DB2, the <username> must be a valid (user authorization) on the
IBM machine. For databases that are case sensitive for usernames, the username has to be
entered in the correct case. When the database is not case sensitive, RIS performs any
necessary case conversion.

SQL Database Language Reference 4 - 19

For INFORMIX, ORACLE, and DB2, RIS internally converts some nonstandard
data types to data types it supports. Any other unsupported data types are
identified as unsupported. As long as RIS describes the columns as
unsupported, the unsupported columns cannot be used in any statement. A
program called risdtype lets you redefine the column to RIS. You are warned
that these changes are not standard and can result in corrupt data.
Unsupported columns cannot be used in any statement. See the RIS Utilities
Guide for 32-Bit Applications for more information.
When a schema is created, information on how to access it is stored in the schema file in the
directory where RIS was loaded on the client machine (usually /usr/ip32/ris for UNIX or
c:\Program Files\Common Files\Intergraph\ris05.nn\ for Windows NT where nn.nn is the
product version number). On all subsequent runs of an application, RIS checks this file to
see where the schema is located. The schema file may exist or be shared on all client nodes
that use RIS. The locate schema command updates the parms file in /usr/ip32/ris (for
UNIX) or c:\Program Files\Common Files\Intergraph\ris05.nn\ (for Windows NT) with the
location of the schema file. These files and directories are the defaults and can be changed.
The locate schema command is not applicable on a VAX server. See the sections
Parameters and Schema Definition File for more information.
The following clauses: user, using, server version, include |
exclude, and force are position sensitive. They must appear in the create
schema statement in the same position as they appear in the documentation.

The using option specifies a vaild DBMS user and enables the sharing of the dictionary
owned by the specified user. The user attempting to share the dictionary must already have
schema privileges granted by the user specified in the using clause.
The server version clause accommodates future features releases after
version 5.0 and can be ignored for 5.0.n releases. (A default value of 0.0 will be
entered in the schema file.)
The server version clause lets you specify the version of RIS for which the schema is
being created. The <maj> identifier must be 5 or higher and the <.feature> identifier
specifies the features release, for example, .1 or .2.

The include | exclude option is used to load or not load the schema with information on
the existing tables/views/indexes of the user. Include is the default.
The force option drops previously created RIS dictionary objects such as RIS tables, views,
indexes, and privileges of the schema before creating the new schema. This option is useful
for corrupt schemas.
Do not edit the schemas file unless absolutely necessary. Doing so could cause RIS to
fail. You may execute the command checksum schema file to correct the damage.
See the RIS Utilities Guide for 32-Bit Applications for more information.
The RIS_VIEW_DEFS column, in the RIS dictionary view RIS_VIEWS, is made null
on a view that already exists in the database when a schema is created. Because the
RIS_VIEW_DEFS column is NULL, you cannot use the risunlod utility to unload
the view definition.

4 - 20

SQL Database Language Reference

To improve overall performance, schema, table, and view definitions stored in

the dictionary are stored in memory. Currently, this in-memory information is
not updated if other RIS users modify the same dictionary through DDL
statements (for example: dropping, creating, or altering schemas, tables, or
views). The in-memory information is not updated with other users changes
until the dictionary is reopened (after exiting or terminating). Although some
schemas, views, or tables may be inaccessible until the information is updated,
there is no data corruption.
For more information about schemas, see the section Schemas. For more information and a
complete list of DDL statements, see the section Transactions.
Examples
_________
For examples of statements creating schemas, see the sections INFORMIX, ORACLE, DB2,
SYBASE, or Microsoft SQL Server.
See
Also
________
create schema (INFORMIX Database Descriptor)
create schema (ORACLE Database Descriptor)
create schema (DB2 Database Descriptor)
create schema (SYBASE Database Descriptor)
create schema (Microsoft SQL Server Database Descriptor)
close schema
default schema
declare schema
drop schema
open schema
set mode

SQL Database Language Reference 4 - 21

4.2.6.1

__________________________________________________________________________________________________________________________________________________

create schema (INFORMIX Database Descriptor)

informix, dbname <dbname>,
ostype <ostype> , dir <dir>
[,option([sqlexec=<sqlexec>]
[,dbtemp=<dbtemp>]
[,tbconfig=<tbconfig>])]

Notes
_ ____
If the RISINFxS data server is on a UNIX node:
For the INFORMIX Standard Engine product, the <dbname> must be a full
pathname. On UNIX systems, the filename portion cannot be longer than ten
characters because INFORMIX adds a DBS suffix to it.
For the INFORMIX OnLine Engine product, the <dbname> needs only to be the
database name.
If the RISINFxS data server is on a Windows NT node:
For the INFORMIX Standard Engine product, the <dbname> must be a full
pathname and must also include the INFORMIX server name with the @ separator:
</c=/dbs/dbname@servername>

For all references to a database use a forward slash with a equal sign. For example:
/c=/dbs/database

For references to a directory use a backward slash and a colon. For example:
c:\dbs\database

For the INFORMIX OnLine Engine product, the <dbname> must include only the
INFORMIX server name with the @ separator:
dbname@servername

The ostype clause specifies the type of operating system the RIS server machine is
running. The <ostype> identifier is the type of operating system. Currently the acceptable
values are UNIX and NT.
The dir clause is mandatory. The dir clause must be used to provide RIS with the
location for the INFORMIX software. The dir clause should contain the value of the
environment variable INFORMIXDIR on the target system.

4 - 22

SQL Database Language Reference

The sqlexec needs to be set if both INFORMIX Standard Engine and INFORMIX-OnLine
Engine products exist on the machine. For the UNIX INFORMIX Database Management
System located in $INFORMIXDIR:
If using INFORMIX OnLine Engine, enter
$INFORMIXDIR/lib/sqlturbo

If using INFORMIX Standard Engine, enter

$INFORMIXDIR/lib/sqlexec

Otherwise, INFORMIX defaults to OnLine.

For the INFORMIX Database Management System located in c:\win32app\informix on
a Windows NT node:
If using INFORMIX OnLine Engine, enter
c:\win32app\informix\bin\sqlturbo.exe

If using INFORMIX Standard Engine, enter

c:\win32app\informix\bin\sqlexec.exe

DBTEMP specifies where INFORMIX creates temporary files. The tbconfig specifies a
configuration file for OnLine only. For example:
On a UNIX node
SQLEXEC=/usr/informix/lib/sqlturbo
DBTEMP=/usr/tmp
TBCONFIG=myconfig

On a Windows NT node
SQLEXEC=C:\win32app\informix\bin\sqlturbo.exe
DBTEMP=C:\TEMP
TBCONFIG=C:\win32app\informix\etc\onconfig

For more information on data types and conversions, see the section Vendor-Specific
Information.
Examples
_________
The following example creates the schema called joe_schema, on the existing INFORMIX
Standard Engine database, on the local machine in /usr2/my_db.dbs. The username joe
specifies an existing operating system log-in and also an INFORMIX username. The
operating system type is UNIX.
create schema joe_schema
on database (informix, dbname my_db, dir /usr3/informix, ostype UNIX)
user joe;

SQL Database Language Reference 4 - 23

The following example creates the schema called joe_schema, on the existing INFORMIX
Standard Engine database, on the local machine in c:\dbs\my_db.dbs, where the
INFORMIX server name is my_server. The username joe specifies an existing operating
system log-in and also an INFORMIX username. The operating system type is NT.
create schema joe_schema
on database (informix, dbname /c=/dbs/my_db@my_server, dir
c:\win32app\informix, ostype NT)
user joe;

The following example creates the schema jim_schema with the password jim_passwd in the
INFORMIX online database on the remote node rnode using the UNIX log-in: jim.pass1 in
the directory /usr2/my_db.dbs. The communication protocol is TCP. Since INFORMIX was
not loaded into /usr/informix on the remote node, the dir keyword is used to specify that it
was loaded into /usr3/informix. The operating system type is unix.
create schema jim_schema.jim_passwd
on database
(informix, dbname my_db,
ostype unix, dir /usr3/informix,
remote (tcp rnode))
user jim.pass1;

In the case where the schema accesses a database through a RIS**NET data
server, the remote clause refers to the location of the data server rather than
the database.
This example adds a schema for the user joan to the database with the name joan_schema.
There is no need to specify the database information. The schema is created on the same
database as the default schema.
create schema joan_schema user joan;

See
Also
________
create schema
close schema
default schema
drop schema
open schema

4 - 24

SQL Database Language Reference

4.2.6.2

__________________________________________________________________________________________________________________________________________________

create schema (ORACLE Database Descriptor)

oracle, dbname <dbname>,
dir <oracle_home>|dbms_net,
[osuser <osuser>[.<passwd>],]
ostype <ostype>
Notes
_ ____
The dbname clause specifies the system identifier of an ORACLE database and should be of
the correct format for ORACLE. If the RISORANS product is being used to access a
database on a remote system using SQL*Net, the dbname clause should be the SQL*Net
identification string (complete string or alias), preceded by @. See the risorans.doc file for
more information.
The dir clause specifies the directory in which ORACLE was loaded on the server node. If
the RISORANS product is being used to access a database on a remote system by the way of
SQL*Net, the dir clause must be dbms_net.
The osuser clause specifies the name and password of the operating system user associated
with the schema. The <osuser> identifier is the name of the operating system user. The
osuser clause lets an operating system user be specified so that the RIS server is not
necessarily started as root. The osuser clause enhances RISs ability to start server
processes as appropriate for the operating system being used. The osuser clause can be
omitted here if it has been specified in a previous declare schema statement.
The <passwd> identifier is the password of the operating system user.
The ostype clause specifies the type of operating system the RIS server machine was
running. The <ostype> identifier is the type of the operating system. Currently the
acceptable values are NT, UNIX, and VMS.
For more information on data types and conversions, see the section Vendor-Specific
Information.
Examples
_________
The following example creates the schema called joe_schema, on the existing ORACLE
database on the local machine. The existing user joe accesses the database through this
schema. The dir clause indicates that ORACLE was loaded into /usr/oracle and dbname
specifies a system ID (SID) of A. The osuser is smith, and the ostype is UNIX.
create schema joe_schema
on database
(oracle, dir /usr/oracle, dbname A, osuser smith, ostype unix)
user joe.passwd;

SQL Database Language Reference 4 - 25

The osuser is smith, and the ostype is NT.

create schema joe_schema
on database
(oracle, dir c:\orant, dbname ORCL, osuser smith.pass, ostype NT)
user joe.passwd;

The following example creates the schema jim_schema with the password jim_passwd on an
ORACLE database on the remote node my_ws with a database log-in of jim.pass1. The
communication protocol is TCP. The dir clause indicates that ORACLE is loaded in
/usr2/oracle and the dbname clause specifies a system ID of 1. The osuser is smith with
password ospass, and the ostype is UNIX.
create schema jim_schema.jim_passwd
on database
(oracle, dir /usr2/oracle, dbname 1, osuser smith.ospass,
ostype UNIX,
remote (tcp my_ws))
user jim.pass1;

The following adds the user joan to the database with the schema joan_schema. There is no
need to specify the database information. The schema is created on the same database as the
default schema.
create schema joan_schema user joan.mypass;

The following examples show possible RISORANS connections:

create schema universal on database
(oracle, dir dbms_net, dbname @t:risnode:tst, osuser smith,
ostype unix) user me.mypass;
create schema via_alias on database
(oracle, dir dbms_net, dbname @paris, osuser smith, ostype unix)
user me.mypass;

Note that the dir clause in both examples is dbms_net which it must be for
all RISORANS connections. Also, The osuser clause must be an osuser for
both client and server systems.
See
Also
________
create schema
close schema
default schema

drop schema
open schema
declare schema

4 - 26

SQL Database Language Reference

4.2.6.3

__________________________________________________________________________________________________________________________________________________

create schema (DB2 Database Descriptor)

db2, dbname <dbname>,
[osuser <user>[.<password>]] ostype {unix|nt},
gateway
([arch=s370,] [os=mvs,] [env=cics,]
{
net_protocol=lu6.2,
host_program=<host_program>,
ris_lu=<ris_lu>,
host_lu=<host_lu>,
mode=<mode>
})
Notes
_ ____
The dbname is the name of the database. It must be from one to eight alphanumeric
characters. It is case sensitive.
The ostype clause specifies the type of operating system the RIS server machine is
running. Currently the supported operating systems are UNIX and Windows NT.
The osuser <user>[<.password>] clause specifies the name and password of the
operating system user associated with the schema. The <user> identifier is the name of the
operating system user. The osuser clause enhances RISs ability to start server processes
as appropriate for the operating system being used. The osuser clause lets an operating
system user be specified so that the RIS server is not necessarily started as root. The
osuser clause can be omitted here if it has been specified in a previous declare schema
statement. The <password> identifier is the password of the operating system user.
The gateway clause lets RIS access DB2 on an IBM mainframe. RIS usually executes
entirely on one machine, or on two machines using a network protocol. With the connection
to DB2, a second network protocol is needed to specify the connection between the data
server and the transaction processor on the IBM system.
The arch is the system architecture that RIS/DBMS runs on. This value is case sensitive
with a valid value of s370 and a default value of s370.
The os is the operating system that RIS and the DBMS use. This value is case sensitive
with the valid value of mvs and the default value of mvs.
The env is the environment that RIS/DBMS uses. This value is case sensitive with the valid
value of CICS (for LU 6.2).

SQL Database Language Reference 4 - 27

The net_protocol is the network protocol that RIS uses to get to the IBM machine that
the DBMS resides on. This value is case sensitive with a valid value of LU6.2 or TCP/IP.
For
LU6.2
__________
The host_program is the name the IBM System Administrator called the RIS
transaction processor when it was installed on the IBM; the CICS transaction name.
This value is case sensitive.
The ris_lu and the host_lu are the names the System Administrator assigned to
the logical units that allow communication to the RIS transaction processor on the
IBM machine. There are two logical units, one on the data server machine, the
ris_lu, and the other on the IBM machine, the host_lu. The lu names are generated
when the LU 6.2 network is configured. These values are case sensitive.

On Windows NT, the ris_lu name can be specified but is not used. The ris_lu
value on Windows NT is determined by the default outgoing LU defined for the user
or system.
On Windows NT, the host_lu must match a LU that has been configured for the
connection to the IBM mainframe.
The mode is the name the System Administrator assigned to the mode that allows
communication to the RIS transaction processor on the IBM machine. On Windows
NT, this name must match the modename specified in the partnering of the RIS and
host LUs. This name also corresponds to the IBM definition of the VTAM mode
entry. The mode assigns attributes to the connection and must be predefined by the
System Administrator. The modename is generated when the LU 6.2 network is
configured. This value is case sensitive.

For more information on data types, see the sections RIS Data Types and Vendor-Specific
Information.
Examples
_________
The following example creates the schema called joe, on an existing database DSNDB04.
The user is executing the statement on a machine that is directly connected to the IBM
network. The values for architecture, os, and environment are default values. Notice that
the values for most of the arguments are in uppercase. The IBM environment does most of
its work in uppercase. Always make sure that you get the case sensitive values from your
System Administrators for each of the arguments.
create schema joe
on database (db2, dbname DSNDB04,
osuser smith, ostype nt,
gateway (net_protocol=lu6.2,
host_program=RISX,
ris_lu=HSV1.L620100,
host_lu=HSV1.A01CICSA,
mode=IGRLU62P) )
user JOE.PASSWD;

4 - 28

SQL Database Language Reference

The following example creates the schema dave on an existing database DSNDB04. The user
is executing the statement on a machine that is not directly connected to the IBM network.
Therefore, we need to specify the remote clause, as well as the gateway clause.
create schema dave
on database (db2, dbname DSNDB04,
remote (tcp ris),
osuser smith.spass, ostype nt,
gateway (arch=s370,
os=mvs,
env=cics,
net_protocol=lu6.2,
host_program=RISX,
ris_lu=HSV1.L620100,
host_lu=HSV1.A01CICSA,
mode=IGRLU62P))
user DAVE.PASSWD;

See Also
________
create schema
close schema
default schema
drop schema
open schema
declare schema

SQL Database Language Reference 4 - 29

4.2.6.4

__________________________________________________________________________________________________________________________________________________

create schema (SYBASE Database Descriptor)

sybase, dbname <dbname>,
[osuser <osuser>[.<passwd>],]
ostype <ostype>,
dir <sybase-interfaces-file-path>
[, option (dsquery=<sybase-server-name>,
filename=<sybase-interfaces-file-name>)]

Notes
_ ____
The dir clause specifies the directory in which the SYBASE interfaces file is located.
The dbname clause specifies the name of a SYBASE database associated with the schema.
The osuser clause specifies the name and password of the operating system user associated
with the schema. The <osuser> identifier is the name of the operating system user. The
<passwd> identifier is the password of the operating system user. The osuser clause lets
an operating system user be specified so that the RIS server is not necessarily started as
root. The osuser clause enhances RISs ability to start server processes as appropriate for
the operating system being used. The osuser clause can be omitted here if it has been
specified in a previous declare schema statement. This is true if the operating system is
NT.
The ostype clause specifies the type of operating system the RIS server machine is
running. The <ostype> identifier is the type of operating system. Currently the acceptable
values are NT and UNIX.
The dsquery specifies the name of the SYBASE server used for the schema. By default, RIS
uses the SYBASE server named as SYBASE.
The filename specifies the name of the SYBASE interfaces file for the schema. By default,
RIS uses the SYBASE interfaces file named interfaces for UNIX and SQL.INI for NT.
In the user clause, the <username> and <passwd> identifiers must be valid SYBASE user
names and passwords. The <passwd> identifier is required for SYBASE databases.
You must be granted create procedure privileges before you can create shared schemas.

4 - 30

SQL Database Language Reference

Examples
_________
The following example creates the schema called joe_schema, on the existing SYBASE
database on the local machine. The existing database user joe with a password of pass1
accesses the database through this schema. The dir clause indicates that the SYBASE
interfaces file is located in /usr/sybase. The dbname is risdb1, the osuser is smith, and
the ostype is UNIX.
create schema joe_schema
on database
(sybase, dir /usr/sybase, dbname risdb1, osuser smith, ostype unix)
user joe.pass1;

The dbname is risdb1, the osuser is smith, and the ostype is NT.
create schema joe_schema
on database
(sybase, dir c:\sql10, dbname risdb1, osuser smith, ostype NT)
user joe.pass1;

The following example creates the schema jim_schema with the password jim_passwd on a
SYBASE database on the remote node my_sun with a database log-in of jim.pass1. The
communication protocol is TCP. The dir clause indicates that the SYBASE interfaces file
named masterfile is located in /usr2/sybase, the dbname clause specifies the name as risdb1
and SYBASE server is named RISSYB. The osuser is smith, and the ostype is UNIX.
create schema jim_schema.jim_passwd
on database
(sybase, dir /usr2/sybase, dbname risdb1, osuser smith,
ostype unix, option (dsquery=RISSYB,filename=masterfile),
remote (tcp my_sun))
user jim.pass1;

See
Also
________
create schema
close schema
default schema
drop schema
open schema
declare schema

SQL Database Language Reference 4 - 31

4.2.6.5

__________________________________________________________________________________________________________________________________________________

create schema (Microsoft SQL Server Database

Descriptor)
mssql, dbname <dbname>,
[osuser <osuser>[.<passwd>],]
ostype <ostype>,
[, option (dsquery=<mssql-server-name>]

Notes
_ ____
The dbname clause specifies the name of a SQL Server database associated with the schema.
The ostype clause specifies the type of operating system the RIS server machine is
running. The <ostype> identifier is the type of operating system. Currently the acceptable
value is NT.
The ostype clause specifies the type of operating system the RIS server machine is
running. The ostype identifier is the type of operating system. Currently, the acceptable
values are NT and UNIX.
The dsquery specifies the name of the SQL Server used for the schema. By default, RIS
uses the SQL Server name as the server/node name.
In the user clause, the <username> and <passwd> identifiers must be valid SQL Server
user names and passwords. The <passwd> identifier is required for SQL Server databases.
Examples
_________
The following example creates the schema called joe_schema, on the existing SQL Server
database on the local machine. The existing database user joe with a password of pass1
accesses the database through this schema. The dbname is risdb1, the osuser is smith,
and the ostype is NT.
create schema joe_schema
on database (mssql, dbname risdb1, ostype nt)
user joe.pass1;

4 - 32

SQL Database Language Reference

The following example creates the schema jim_schema with the password jim_passwd on a
SQL Server database on the remote node my_nt with a database log-in of jim.pass1. The
communication protocol is TCP. The dbname clause specifies the name as risdb1 and
DSQUERY is set to the nodename/SQL Server name of RISMSQ. The osuser is smith, and
the ostype is NT.
create schema jim_schema.jim_passwd
on database
(mssql, dbname risdb1,
ostype nt, option (dsquery=RISMSQ),
remote (tcp my_nt))
user jim.pass1;

See
Also
________
create schema
close schema
default schema
drop schema
open schema
declare schema

SQL Database Language Reference 4 - 33

4.2.7

__________________________________________________________________________________________________________________________________________________

create table
The create table statement creates a table in the default schema.
create table <ristable> ({ <riscolumn> <datatype>[not null] } [, ...]);
[extern <dbmstable> [<dbmscolumn>[,...])]];
RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.
Notes
_ ____
The <ristable> identifier is the table name. The table name must be unique within the
schema in which it is created. The maximum length of the table name is dependent on ANSI
mode. If ANSI mode is on, the maximum length is 18 characters. Otherwise, the
maximum length is 31 characters based on the underlying RDBMS.
The <riscolumn> identifier is a column name. The length of the column is also dependent on
ANSI mode. The number of columns allowed in a table is 100 to be compatible with all
supported databases. This limit is temporarily increased to 254. For more information on
table limits, see the section RIS Limits.
The <data type> identifier is an SQL data type. The valid RIS data types are: character,
integer, smallint, double precision, real, timestamp, decimal, ris_blob, and ris_text. Valid
SQL data types and the mapping of SQL data types to other vendors data types and to C
language data types are listed in the section Data Types.
In the optional extern clause, the <dbmstable> and <dbmscolumn> must be a valid table
name and column names for the underlying database. With this clause, the table name
(dbmstable) and column names (riscolumn) in the underlying database can be given aliases
(ristable and riscolumn) that can be used by RIS and RIS-based applications.
The not null keyword phrase is an optional phrase specifying whether or not null values
are allowed in the column.

Tables are subject to row length and column number restrictions.

Table and column names cannot be the same as RIS or RDBMS reserved words.

4 - 34

SQL Database Language Reference

For more information about tables, see the section Tables.

Examples
_________
create table table1 (col1 integer not null, col2 char(5), col3 real);
extern xtable1 (xcol1, xcol2, xcol3);
create table employee (name char(25), id int, picture ris_blob(50000));
In ANSI mode, names must not exceed 18 characters. Otherwise, depending on
the database, names must not exceed 31 characters. See the section set mode
for more information about ANSI mode.
See
Also
________
alter table
delete
drop table
insert
update
set database
set mode

SQL Database Language Reference 4 - 35

4.2.8

__________________________________________________________________________________________________________________________________________________

create view
The create view statement creates a virtual table consisting of one or more actual tables
or other views. The purpose of a view is to provide another way of viewing data other than
the physical table. Views are useful for logically combining tables to make them appear as
one or to restrict access to columns containing sensitive data.
create view <risview> [ (<column-list>) ]
[extern <dbmsview>[ (<dbmscolumn-list>) ]
as <select-statement>;

RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.
Notes
_ ____
The <risview> identifier is the name of the RIS view to be created. View names must be
unique to a schema. The length of table name is dependent on ANSI mode. If ANSI mode
is on, the length is 18 characters. Otherwise, the length is 31 characters.
The <column-list> identifier is an optional list of virtual column names for the view. The
length of the column is also dependent on ANSI mode. If the <column-list> is given, the
number of columns must match the number of columns returned by the <selectstatement> clause. If the <column-list> identifier is specified, the columns can no longer be
referred to by the original names when selecting from this view. However, this has no effect
on the table.
The <column-list> is required when duplicate column names exist or an expression
exists in the select list.

In the optional extern clause, the <dbmsview> and <dbmscolumn> must be a valid view
name and column names for the underlying database. With this clause, the view names and
column names in the underlying database can be given aliases (synonyms) that are used by
RIS and RIS-based applications.
The <select-statement> clause is any valid RIS select statement and indicates the columns
and data selected for the view. However, the order by clause cannot be used.

4 - 36

SQL Database Language Reference

If a view is composed of more than one table, or if the view definition <select-statement>
phrase contains an expression, the view can only be selected from. If the view is composed of
only one table and does not contain any expressions in the <select-statement> clause, the
view can also be used in the <relation> identifiers of the insert, update, and delete
statements. These operations are not virtual; however, since they affect the data in the table
composing the view. Tables and views used in the view definition must be owned by the
default schema.
Views are subject to the same restrictions as tables.
Drop dependent views that reference a table before you drop the table itself.
Depending upon the underlying DBMS, dependent views might not be deleted,
but remain as invalid views.
Table and column names cannot be the same as RIS or DBMS reserved words.
See the section set database. RIS does not let applications create views on RIS
dictionary objects.
Examples
_________
create view view1
as select * from tab1;
create view view2(var1)
as select col1 from tab1;
create view view3
as select tab1.col1, tab2.col2 from tab1, tab2
where tab1.col1 = tab2.col1;
create view view4(v1,v2,v3)
as select c1,avg(c1),c2 from table tab1;
create view view5(v1,v2,v3)
extern xtvw5(exv1,exv2,exv3)
as select c1,c2,c3 from table tab1;
In ANSI mode, names must not exceed 18 characters. Otherwise, depending on
the database, names must not exceed 31 characters.
See the section set mode for more information about ANSI mode.

See
Also
________
create table
delete
drop table

drop view
insert
select

update
set database
set mode

SQL Database Language Reference 4 - 37

4.2.9

__________________________________________________________________________________________________________________________________________________

declare schema
The declare schema statement lets you specify a schema name and password. Optionally,
you can specify the user and password of the user who owns the schema, and the operating
system user and password in the RIS in-memory data dictionary cache.
This statement must be used to access secure schemas. It can also be used to access
standard schemas.
Potential conflicts with this statement and other SQL statements are discussed in the
following Notes.
declare schema <schema>[.<passwd>]
[user <username>[.<passwd]]
[osuser <osusername>[.<passwd]];
Notes
_ ____
The <schema> identifier is the schema name.
The optional <passwd> identifier is the password for the schema.
The optional user clause specifies a valid RDBMS user and a password (optional) schema.
This user must already be a valid schema user.
The optional osuser clause specifies a valid operating system user and password (optional).
The following explains the possible conflicts between the declare schema statement and
other SQL statements:
1.

The statements which are impacted by the schema name and password in a declare
schema statement include: alter schema, create schema, default schema
and drop schema.
a.

If any of these statements specifies a password with the schema name and the
preceding declare schema statement also specifies a password with the schema
name, then the two passwords must be the same, otherwise an error occurs.

b.

If any of these statements specifies a password with the schema name and the
preceding declare schema does not specify a password with the schema name,
an error occurs.

c.

If any of these statements does not specify a password with the schema name and
the preceding declare schema statement specifies a password with the schema
name, then the schema password in the declare schema statement is used as
the password for the statement.

4 - 38

2.

3.

4.

SQL Database Language Reference

d.

If any of these statements and the preceding declare schema statement do not
specify a schema password, then a NULL password is assumed for the statement.

e.

If no declare schema statement precedes any of these statements, then the

schema password in the statement is assumed to be the password for the schema.

The user password in a declare schema statement impacts the create schema
statement as follows:
a.

If the create schema statement specifies a user clause and the preceding
declare schema statement also specifies a user clause, then the user and
password in both user clauses must be the same.

b.

If the create schema statement specifies a user clause and the preceding
declare schema statement does not specify a user clause, then the user
password in the user clause of the create schema statement is used as the
user password.

c.

If the create schema statement does not specify a user clause and the
preceding declare schema statement specifies a user clause, then the user
password in the declare schema statement is used as the user password for the
schema.

d.

If neither the create schema statement nor the declare schema statement
specify a user clause, an error occurs.

The statements which need to open an existing schema and are impacted by the user
password in the declare schema statement include: alter schema, default
schema, open schema, and drop schema.
a.

If any of these statements accesses a secure schema, then a preceding declare

schema statement must be executed with a valid user clause.

b.

If any of these statements accesses a standard schema and the preceding

declare schema statement specifies a user clause, then both the schema user
and the schema user password must match those in the schema file. Otherwise,
there is an error.

c.

A preceding declare schema statement with a use clause is not mandatory

when any of these statements accesses a standard schema.

The OS user password in a declare schema statement impacts the create schema
statement for SYBASE, Microsoft SQL Server, DB2, or ORACLE as follows:
a.

If the create schema statement specifies an osuser clause and the preceding
declare schema statement also specifies an osuser clause, then the user and
password in both user clauses must be the same. Otherwise, an error occurs.

b.

If the create schema statement specifies an osuser clause and the preceding
declare schema statement does not specify an osuser clause, then the osuser
password in the osuser clause of the create schema statement is used as the
osuser password.

SQL Database Language Reference 4 - 39

5.

c.

If the create schema statement does not specify an osuser clause and the
preceding declare schema statement specifies an osuser clause, then the
osuser password in the declare schema statement is used as the osuser
password in the create schema statement.

d.

If neither the create schema statement nor the declare schema statement
specify an osuser clause, then an error occurs.

The OS user password in a declare schema statement impacts the following

statements for SYBASE, Microsoft SQL Server, DB2, and ORACLE schemas : alter
schema, default schema, open schema, and drop schema.
a.

If any of these statements accesses a secure schema and no other standard

schemas exist on the same database, then a preceding declare schema
statement must be executed with a valid osuer clause. Otherwise, an error occurs.

b.

If any of these statements accesses a standard schema and the preceding

declare schema statement specifies an osuser clause, then the osuser and osuser
password must match the entries in the schema file for the schema specified in the
statement.

c.

A preceding declare schema statement with an osuser clause is not

mandatory when any of these statements accesses a standard schema or a secure
schema which shares the same database with other standard schemas.
This statement must be used carefully. An incorrect schema definition may cause
RIS to behave unpredictably.

Examples
_________
declare schema t1.john;
declare schema sch2.mary
user jones.mary
osuser jones.mary

See
Also
________
create schema
undeclare schema
alter schema
default schema
drop schema

4 - 40

SQL Database Language Reference

4.2.10

__________________________________________________________________________________________________________________________________________________

declare table
The declare table statement lets you define a RIS table in the RIS in-memory data
dictionary cache.
declare table [<schema>.]<table> ({<riscolumn> <data type> [not null]}[,...])
[extern [<dbmsuser>.<dbmstable> [ (dbmscolumn> [,...])]]
[with [partial] verify option];
Notes
_ ____
The <table> identifier is the table name.
The optional <schema> identifier is the schema in which the table exists. The schema
identifier must be specified if the table exists in a schema other than the default schema. No
privileges are required to declare a table that exists in a schema other than the default
schema.
Valid RIS SQL data types, the ones used in create table statements, are listed in the
section RIS Data Types. However, unsupported data types can also be used in declare
table statements. See the section RIS Data Types for more information.
The optional extern clause and <dbmstable> and <dbmscolumn> identifiers specify the
names of the tables and columns in the underlying RDBMS. The <dbmsuser> identifier can
be used to qualify the RDBMS table name with the owner.
The declare table statement lets you define a table in RISs in-memory data dictionary
cache. This eliminates the delay encountered while referencing a table for the first time
(with the no verify option). The verify option validates the table definition specified in the
declare table statement against the definition stored in the RIS dictionary and against
the definition stored in the underlying DBMS dictionary. The keyword partial tells RIS to
validate against the underlying database only. If verify is specified without the partial
keyword, the table definition of the declare table statement is verified against the RISdictionary definition and against the underlying database definition. This is also called the
full verify option. This is similar to the set mode statement and the verify on/off option.
For example, the declare table statement with the verify option is equivalent to the
set verify on statement, and the declare table statement without the verify
option is equivalent to the set verify off statement.
This statement fails if the table definition already exists in memory, or due to a mismatch in
attributes definition.

SQL Database Language Reference 4 - 41

This statement must be used carefully. An incorrect table definition may cause RIS
to behave unpredictably.
Examples
_________
declare table t1 (c1 int, c2 char(12));
declare table sch2.t2 (c1 int, c2 char(12)) with verify option;
declare table t3 (c1 int, c2 unsupported, c3 char(3))
extern dview1 (dvc1, dvc2, dvc3);
See Also
________
create table
create view
declare view
set mode
undeclare table
undeclare view

4 - 42

SQL Database Language Reference

4.2.11

__________________________________________________________________________________________________________________________________________________

declare view
The declare view statement lets you define a view in the RIS in-memory data dictionary
cache.
declare view [<schema>.]<view> ({<riscolumn> <data type> [not null]}[,...])
[extern [<dbmsuser>.]<dbmsview>[(<dbmscolumn>[,...])]]
[with [partial] verify option];
Notes
_ ____
The <view> identifier is the view name.
The optional <schema> identifier is the schema in which the view exists. The schema
identifier must be specified if the view exists in a schema other than the default schema. No
privileges are required to declare a view that exists in a schema other than the default
schema.
The view is declared using the create view statement syntax. The <riscolumn> identifier
represents the virtual column names described in <column-list> of create view syntax.
The optional extern clause and <dbmsview> and <dbmscolumn> identifiers specify the
names of the tables and columns in the underlying RDBMS. The <dbmsuser> identifier can
be used to qualify the RDBMS view name with the owner.
The declare view statement lets you define a view in RISs in-memory data dictionary
cache. This eliminates the delay encountered while referencing a view for the first time (with
the no verify option). The verify option validates the view definition specified in the
declare view statement against the definition stored in the RIS dictionary and against the
definition stored in the underlying DBMS dictionary. The keyword partial tells RIS to
validate against the underlying database only. If verify is specified without the partial
keyword, the view definition of the declare view statement is verified against the RISdictionary definition and against the underlying database definition. This is also called the
full verify option. This is similar to the set mode statement and the verify on/off option.
For example, the declare view statement with the verify option is equivalent to the
set verify on statement, and the declare view statement without the verify option
is equivalent to the set verify off statement.
This statement fails if the view definition already exists in memory, or due to a mismatch in
attributes definition.

SQL Database Language Reference 4 - 43

This statement must be used carefully. An incorrect view definition may cause RIS
to behave unpredictably.
Examples
_________
declare view v1 (c1 int, c2 char(12));
declare view sch2.v2 (c1 int, c2 char(12)) with verify option;
declare table t3 (c1 int, c2 unsupported, c3 char(3))
extern bob.dv1(dvc1, dvc2, dvc3);
See Also
________
create table
create view
declare table
set mode
undeclare table
undeclare view

4 - 44

SQL Database Language Reference

4.2.12

__________________________________________________________________________________________________________________________________________________

default schema
The default schema statement sets the schema (database/user combination) in which
tables and views are created, dropped, and searched for, by default. This statement also
opens the schema.
default schema <schema>[.<passwd>];
Notes
_ ____
The <schema> identifier is the name of the schema.
The <passwd> identifier is the password to the schema specified with the create schema
statement. This is only needed if a password exists for the schema and the password has not
been provided by a preceding declare schema statement.
The default schema statement does not implicitly cause a commit.
The default schema can be changed at any time without affecting transactions
in progress.
For more information about schemas, see the section Schemas.
Examples
_________
default schema jim;
default schema jim.passwd;
See
Also
________
create schema
close schema
drop schema
open schema
declare schema

SQL Database Language Reference 4 - 45

4.2.13

__________________________________________________________________________________________________________________________________________________

delete
The delete statement removes rows of data from a table.
delete from [<schema>.]<relation>[where <conditions>];
Notes
_ ____
The <relation> identifier is the name of a table or view from which to remove rows.
The optional <schema> identifier is the schema in which the relation exists. This identifier
must be specified if the relation exists in a schema other than the default schema. A period
(.) must separate the schema name and the relation name.
The where clause can optionally be used to restrict which rows are to be removed. If the
where clause is not specified, all rows are removed from the table. For a description of the
syntax for the where clause, see the where clause description.
If no rows are deleted, SQLCODE is set to END_OF_DATA.
If an error occurs during a delete or any DML statement, a rollback
statement is automatically issued. For more information about the effects of
errors on transactions, see the section Transactions.
For more information, see the sections on Tables and Views.
Examples
_________
delete from table1;
delete from table1 where column1 = 5;
delete from table1 where column1 between 5 and 7;

4 - 46

SQL Database Language Reference

See
Also
________
alter table
create table
create view
drop table
drop view
insert
update
where

SQL Database Language Reference 4 - 47

4.2.14

__________________________________________________________________________________________________________________________________________________

drop index
The drop index statement removes an index from the default schema. It does not remove
the data associated with the index.
drop index <index>;
Notes
_ ____
The <index> identifier is the name of the index to be dropped.
If the user currently connected to the schema is not the owner of the index, the
underlying DBMS normally causes this statement to fail. This can happen when
using a secure schema or when an external index is included in the schema.
Examples
_________
drop index t1c1;
See
Also
________
create index

4 - 48

SQL Database Language Reference

4.2.15

__________________________________________________________________________________________________________________________________________________

drop schema
The drop schema statement removes a schema from RIS.
drop schema <schema>[.<passwd>][force];
Notes
_ ____
The <schema> identifier is the name of the schema to be removed. When the dictionary
containing the schema is not shared by any other schema, the RIS dictionary tables and
views are dropped along with the schema. If other schemas are present, the RIS dictionary
tables and views remain. Only the information about the schema is deleted. In either case,
all user tables and views still exist.
If the database is not up, RIS only removes the information from the schema
file. An error message is not returned. The RIS dictionary tables still exist.

If the schema is owned by the dictionary owner and all other schemas in the dictionary are
owned by others, then the schema is not dropped because the dictionary itself could not be
dropped later.
The <passwd>, if one exists, must also be keyed in, unless the password has been provided in
a preceding declare schema statement.
The force option causes the schema to be dropped even if other users have it open, or if it
has been corrupted.
When a schema is dropped, other schemas in the schema file may be opened to
remove any references to the schema being dropped.
RIS does not re-generate the ris_view_def string for a RIS-generated view when
the schema has been dropped and then re-created. This affects schemas for the
following databases: INFORMIX, ORACLE, SYBASE, and Microsoft SQL
Server.
For more information about schemas, see the section Schemas.
Examples
_________
drop schema jim;
drop schema joe.passwd;
drop schema jane force;

SQL Database Language Reference 4 - 49

See
Also
________
create schema
default schema
declare schema
grant (to schema)

4 - 50

SQL Database Language Reference

4.2.16

__________________________________________________________________________________________________________________________________________________

drop table
The drop table command removes a table definition from the default schema, deleting all
data in the table and any associated indexes. Once a table has been dropped, it no longer
exists in the database, nor does it exist to RIS.
drop table <table>;
Notes
_ ____
During the lifetime of a database, tables sometimes become useless and should be removed.
Dropping a table removes the table data, the table structure, and any associated indexes.
The <table> identifier is the name of the table to be dropped. The table must exist in the
default schema.
Drop dependent views that reference a table before you drop the table itself.
Depending upon the underlying DBMS, dependent views might not be deleted,
but remain as invalid views.
If the user currently connected to the schema is not the owner of the table, the
underlying DBMS normally causes this statement to fail. This can happen when
using a secure schema or when an external table is included in the schema.
For more information about tables, see the section Tables.
Examples
_________
drop table tab1;

See
Also
________
alter table
create table
create view
drop view

SQL Database Language Reference 4 - 51

4.2.17

__________________________________________________________________________________________________________________________________________________

drop view
The drop view statement removes a view definition from the default schema. It does not
remove any data in the referenced tables.
drop view <view>;
Notes
_ ____
The <view> identifier is the name of the view definition to be removed. The view must exist
in the default schema.
If any existing views reference the view, those views may be deleted or they
may be left around, invalid. This behavior is dependent on the underlying
DBMS. To avoid this, drop dependent views that reference the view before
dropping the view.
If the user currently connected to the schema is not the owner of the view, the
underlying DBMS normally causes this statement to fail. This can happen when
using a secure schema or when an external view is included in the schema.
Examples
_________
drop view view1;
See
Also
________
create table
create view
drop table

4 - 52

SQL Database Language Reference

4.2.18

__________________________________________________________________________________________________________________________________________________

exec
The exec statement executes a vendor database-specific statement on the database
associated with the default schema. This statement is useful for situations where access to
the vendor-specific SQL is required.
exec <database-type> <string>;
Notes
_ ____
The <database-type> identifier is the type of database associated with the default schema.
Either informix, db2, oracle, sybase, or mssql must be specified. The database type
is checked to ensure that it matches the database type of the default schema. If it does not,
RIS reports an error and does not execute the given statement.
The <string> identifier is the vendor SQL statement. RIS does not check for any errors on
this statement. If there is an error in the statement, it is only recognized by the vendor
DBMS. RIS reports any error returned by the vendor DBMS.
This command should be used with extreme caution. Using this statement defeats the
purpose of RIS and renders the application nonportable. Certain statements can also
cause inconsistencies between RIS and the vendor DBMS data definitions. Therefore,
this command should only be used by individuals who understand the potential
problems.
Also, there is no assurance that any of the vendor DBMS SQL statements work
through this interface. No statements that require structured input or output data
area definitions (sqlda) work through this interface.
RIS ensures that the statement is processed within a single transaction. This
means that if you try to create a transaction, and issue several statements, (even
with autocommit off), it creates a separate transaction for each exec <dbms>
statement.
Examples
_________
exec informix create table publisher (pub_name char(40),
pub_address char(30),
city char(25),
country char(20),
post_code char(15));

SQL Database Language Reference 4 - 53

See
Also
________
create schema
drop schema

4 - 54

SQL Database Language Reference

4.2.19

__________________________________________________________________________________________________________________________________________________

grant
The grant statements grant privileges to schemas or users. The syntax is different for each
type of grant statement. The keywords delete, insert, select, update after the
grant statement indicate privileges granted to schemas. Refer to the section grant (to
schema) for the syntax associated with these statements. The keywords schema,
connect, and resource after the grant statement indicate privileges granted to users.
Refer to the section grant (to user) for the syntax associated with these statements.

SQL Database Language Reference 4 - 55

4.2.19.1

__________________________________________________________________________________________________________________________________________________

grant (to schema)

The grant statement grants different levels of access to a relation.
grant <rel-privileges> [(<column-list>)]
on [<schema>.] <relation>
to <schema-list> [ with grant option ];
Notes
_ ____
The <rel-privileges> identifier specifies privileges to be granted on a specified relation. It can
consist of the keyword, all, or one or more of the following access keywords: delete,
insert, select, update, separated by commas.
The access keyword update can have a column list; for example, update (C1,C2,C3). If
a column list is specified, then update is only granted to those specific columns. Otherwise,
update is granted on all columns.
The <relation> identifier is the name of the relation to which the privilege is to be granted.
This can be the name of a table or view.
The optional <schema> identifier is the schema in which the relation exists. This identifier
must be specified if the relation exists in a schema other than the default schema. A period
(.) must separate the schema name and the relation name.
Granting access on a relation through RIS affects only RIS. It does not affect
the vendor database system. That is, the grant statement is not issued to the
vendor database.
By default, all tables and views created through RIS are accessible only by the
creator and any database administrators for that database.
The <schema-list> identifier consists of one or more schema names (separated by commas)
that are granted access; public is used to grant access to all schemas.
The with grant option key phrase lets the schema grant privileges to other schemas.
However, the schema can only grant those privileges which have been granted to it. Any
privileges granted by this schema can also be revoked. If this schema grants privileges, any
privileges revoked by the first schema (the schema that granted the grant option) are
revoked in a cascading effect. For example: schema A grants privileges to schema B. Then
schema B grants privileges to schema C. If any privileges are revoked from schema B by
schema A, those privileges are automatically revoked from schema C.

4 - 56

SQL Database Language Reference

The revoke statement can be used to revoke privileges in a manner similar to

the grant statement.
For more information about privileges, see the section Privileges.
Examples
_________
The following examples show use of the grant statement:

grant all on tab1 to public;

grant select, update on tab2 to joe with grant option;
grant select, insert, update on my_table to schema1, schema2;
grant select on schema3.your_table to schema2;
grant update (C1,C2) on tabl to joe;
grant connect, resource to joe;
grant create table, create view, create stored procedure to joe;

See
Also
________
revoke

SQL Database Language Reference 4 - 57

4.2.19.2

__________________________________________________________________________________________________________________________________________________

grant (to user)

The grant (to user) statement grants schema privileges to valid RDBMS users. The
privileges are granted on the default schema and the dictionary by the schema owner.
grant <rdbmsuser-privilege> to [<rdbmsuser>];

Notes
_ ____
The <rdbmsuser-privilege> identifier specifies privileges to be granted to a database user. It
can consist of one of the following keywords: schema, resource, or connect.
A user with connect privilege can connect to a schema, access and modify data, but not issue
DDL statements.
A user with resource privilege assumes connect privilege and can also issue DDL statements.
Connect and resource are applicable only to a secure schema and can be granted only by the
schema owner.
A user with schema privilege can create another schema using the dictionary of the user that
granted the privilege. (The using keyword in a create schema statement is how the
schema privilege is exercised.) Only the owner of the dictionary, when connected to the
schema, can grant the schema privilege.

Granting the previous privileges to a user through RIS results in RDBMS level
privileges on the RIS dictionary tables and views.
The <rdbmsuser> identifier specifies a valid RDBMS user. Be sure to follow the case rules
for the underlying database when entering the <rdbmsuser>. For example, if your RDBMS is
case sensitive joe does not equal JOE.

The revoke statement can be used to revoke privileges in a manner similar to

the grant statement.
For more information about privileges, see the section Privileges.

4 - 58

SQL Database Language Reference

Examples
_________
grant schema to joan;
grant resource to jim;
grant connect to joe;

See Also
________
revoke

SQL Database Language Reference 4 - 59

4.2.20

__________________________________________________________________________________________________________________________________________________

insert
The insert statement inserts new rows of data into a table or view.
insert into [<schema>.]<relation> [ (<column-list>) ]values (<values-list>);
OR
insert into [<schema>.]<relation> [ (<column-list>) ]<select-statement>;
Notes
_ ____
The insert statement inserts a new row of data into a relation. It cannot be used to
change existing rows. The update statement must be used to change existing data in a
table.
The <relation> identifier is the name of a table or view into which the data is inserted.
Inserting into views is subject to some restrictions. For a complete list of these
restrictions, see the section Views.
The optional <schema> identifier is the schema in which the relation exists. This identifier
must be specified if the relation exists in a schema other than the default schema. A period
(.) must separate the schema name and the relation name.
The <column-list> identifier is an optional list of columns for which data values are specified.
The column list is needed if the number of values does not match the number of columns in
the table or view, or if the ordering of the values does not match the ordering of the columns
(in the create table or create view statement used to create this table or view).
Otherwise, it is optional.
The <values-list> clause can be used to provide a list of values to be inserted into the
relation.
If the <column-list> identifier is specified, one value must be specified for each
column in the list. Any columns not in the list are set to NULL. In that case, if
the column was created with the not null keyword phrase, an error occurs.
If the <column-list> identifier is not specified, one value must be specified for
each column in the table.

4 - 60

SQL Database Language Reference

The <select-statement> identifier can be used to provide a list of values to insert which were
selected from other relations. For the proper syntax for the <select-statement> identifier, see
the select statement description.
Executing the insert statement using the values clause causes one row to be inserted
into the table or view, while using the <select-statement> identifier causes zero or more rows
to be inserted into the table or view.
The <select-statement> cannot contain any references to the table or view being
inserted into.
If no rows are inserted, SQLCODE is set to END_OF_DATA.
If an error occurs during an insert or any Data Manipulation Language
(DML) statement, a rollback statement is automatically issued.
For more information about the effects of errors on transactions, see the section Tables.
Examples
_________
insert into table1 values (1, abcd, 2.0);
insert into table1 (col1, col3) values (1, 2.0);
insert into table1 (col1, col3) select co1, col3 from table2;
See
Also
________
alter table
create view
drop table
drop view
delete
update

SQL Database Language Reference 4 - 61

4.2.21

__________________________________________________________________________________________________________________________________________________

lock tables
The lock tables statement locks one or more tables, preventing other users from
changing them while the lock is in effect. It is also used to prevent other users from having
full access to perform their normal operations on any table named in the statement.
Table locks are automatically removed when a commit or rollback statement is issued.
lock tables [ {[<schema>.]<table>}[,...] in share mode]
[ {[<schema>.]<table>}[,...] in exclusive mode]
[ {[<schema>.]<table>}[,...] in default mode];
Notes
_ ____
The <table> identifiers are the names of the tables to lock.
The optional <schema> identifiers are the schemas in which the tables exist. The schema
identifiers must be specified if the tables exist in a schema other than the default schema. A
period (.) must separate the schema name and the table name.
All tables in the lock tables statement should refer to the same schema.

Two keywords are available with the lock tables command. You can choose either
keyword, depending on how you want to restrict access to the table. These keywords are
share and exclusive.
The share keyword indicates that multiple users may access the locked table for reading
only. No inserts, deletes, or updates may be performed in the table.
The exclusive keyword does not perform in the same manner with all RDBMSs:
For INFORMIX, the exclusive keyword restricts other users from having any access to
the locked table.
For ORACLE, the exclusive keyword prevents other locks from being performed on the
table, but does not restrict users from querying the table.

4 - 62

SQL Database Language Reference

The default mode corresponds to the default locking strategy/mechanism of the underlying
DBMS. At least one locking mode must be specified in the lock tables statement. The
default mode does not lock any tables. The default mode is provided because if any table is
locked, all tables referenced in the transaction must be locked. The lock tables
statement lets different tables be locked using different modes in a single transaction. Use
the default for all tables that do not require a special lock.
At least one locking mode must be specified in the lock tables statement.
The functionality of the lock tables statement is affected by the set
database statement. If Rdb is not enabled, then you do not need to specify all
tables. (Remember this also makes it non-portable.)
The lock tables statement must be the first statement in a transaction.
Therefore all tables to be referenced in a transaction must be included in the lock
tables statement.
Table locks are automatically removed when a commit or rollback statement is
executed (implicitly or explicitly.) Therefore, if autocommit mode is on, the lock
tables statement has no effect because a commit has issued immediately after the
lock tables statement. If an error occurs during a lock tables statement or
any DML statement that updates the database, a rollback statement is
automatically issued.
For more information about tables, transactions, and the commit and rollback
statements, see the sections Transactions.
Examples
_________
lock tables sch1.tab1, sch1.tab2 in exclusive mode;
lock tables tab1, tab2 in share mode tab3, tab4 in default mode;
lock tables sch1.tab1 in share mode
sch1.tab2 in exclusive mode sch1.tab3 in default mode;
See
Also
________
commit
rollback
set database

SQL Database Language Reference 4 - 63

4.2.22

__________________________________________________________________________________________________________________________________________________

open schema
The open schema statement activates and starts a RIS database server for schemas.
Schemas are automatically opened when they are referenced.
open schema <schema>[.<passwd>] [, ...];
Notes
_ ____
The <schema> identifier is the name of the schema. You can also specify the names of one or
more schemas, separated by commas that you want opened.

The <passwd> identifier is the password to the schema specified with the create schema
statement. This is only needed if a password exists for the schema and the password has not
been provided by a preceding declare schema statement.
This statement is useful if the application needs to ensure that there are no additional delays
in time-critical codes.
The default schema statement opens a schema and makes it the default
schema. The create schema statement creates a new schema, opens it, and
makes it the default schema. The open schema statement does not change
the default schema.
RIS limits the total number of database servers to 24 and the number of local
servers to the value of MAX_LOCAL_SERVERS in the c:\Program
Files\Common Files\Intergraph\ris<maj>.<min>\parms file.
However, the number of local schemas which can be open may be less,
depending on the number of semaphores RIS can get from the operating system.
For more information on this and other operating parameters, see the section
Parameters.
If RIS cannot open a server locally, it attempts to open it remotely.

For more information about schemas, see the section Schemas.

4 - 64

SQL Database Language Reference

Examples
_________
open schema jim;
open schema jim, joe, fred;

See
Also
________
close schema
create schema
default schema
drop schema
declare schema

SQL Database Language Reference 4 - 65

4.2.23

__________________________________________________________________________________________________________________________________________________

revoke
The revoke statements revoke privileges from schemas or users. The syntax is different for
each type of revoke statement. The keywords delete, insert, select, update after
the revoke statement indicate privileges revoked from schemas. Refer to the section
revoke (from schema) for the syntax associated with these statements. The keywords
schema, connect, and resource after the revoke statement indicate privileges
revoked from users. Refer to the section revoke (from user) for the syntax associated with
these statements.

4 - 66

SQL Database Language Reference

4.2.23.1

__________________________________________________________________________________________________________________________________________________

revoke (from schema)

The revoke (from schema) statement revokes privileges from one or more schemas.
revoke <rel-privileges> [(<column-list>)]
on [<schema>.]<relation> from <schema-list>;
Notes
_ ____
The <rel-privileges> identifier specifies privileges to be revoked on a specified relation or
relations. It can consist of the keyword, all, or one or more of the following access
keywords: delete, insert, select, update, separated by commas.
The access keyword update can have a column list; for example, update (C1,C2,C3). If
a column list is specified, then update is only revoked from those specific columns.
Otherwise, update is revoked on all columns.
The <relation> identifier is the name of the relation to which the privilege is to be revoked.
This can be the name of a table or view.
The optional <schema> identifier is the schema in which the relation exists. This identifier
must be specified if the relation exists in a schema other than the default schema. A period
(.) must separate the schema name and the relation name.
The <schema-list> identifier consists of one or more comma-separated schema names from
which privileges are revoked. Any privileges granted by this schema are revoked in a
cascading effect.
For more information about privileges, see the section Privileges.
Examples
_________
The following examples revoke the privileges granted in the first set of examples in the
section grant.
revoke all on tab1 from public;
revoke select, update on tab2 from joe;
revoke select, insert, update on my_table from schema1, schema2;
revoke select on schema3.your_table from schema2;
revoke update (C1,C2) on tab1 from joe;

SQL Database Language Reference 4 - 67

See
Also
________
grant (to schema)

4 - 68

SQL Database Language Reference

4.2.23.2

__________________________________________________________________________________________________________________________________________________

revoke (from user)

The revoke (from user) statement revokes schema privileges from valid RDBMS users.
The privileges are revoked on the default schema and dictionary by the schema owner.
revoke <rdbmsuser-privilege> from [<username>];

Notes
_ ____
The <rdbmsuser-privilege> identifier specifies privileges to be revoked from a database user.
It can consist of one of the following keywords: schema, resource, or connect.
A user with connect privilege can connect to a schema, access and modify data, but not issue
DDL statements.
A user with resource privilege assumes connect privilege and can also issue DDL statements.
The connect and resource privileges are only applicable to secure schemas and can only be
issued by the schema owner.
A user with schema privilege can create another schema using the dictionary of the user that
revoked the privilege. (Issuing a create schema statement with the using keyword is
how the schema privilege is exercised.)
The revoke statement can only be issued by the dictionary owner when connected to his
schema.

Revoking privileges from a user through RIS may lead to RDBMS revoke
statements on the RIS dictionary tables and views.
The <username> identifier specifies a valid database user.

The revoke statement can be used to revoke privileges in a manner similar to

the grant (to user) statement.
When resource privilege is revoked from a user, the user still has connect privilege. To
remove a user from the schema, the connect privilege must be revoked.
For more information about privileges, see the section Privileges.

SQL Database Language Reference 4 - 69

Examples
_________
The following examples show use of the revoke statement:

revoke schema from joan;

revoke resource from jim;
revoke connect from joe;

See Also
________
grant

4 - 70

SQL Database Language Reference

4.2.24

__________________________________________________________________________________________________________________________________________________

rollback
The rollback statement cancels the effects of all statements within a transaction.
rollback [ work ] [ for <schema> ];
Notes
_ ____
The rollback statement ends a transaction; canceling the effects of the statements in the
transaction. The rollback statement does not issue any error messages and is only useful
when the transaction autocommit mode is off.
The work keyword can be specified to conform to the SQL standard. It is optional and
serves no other function.
The for <schema> clause lets you specify which transaction to rollback (RIS supports
multiple transactions, up to one transaction per schema). If the for <schema> clause is not
specified, the transaction that is associated to the current default schema is rollbacked. If the
for <schema> clause is specified, the transaction that is associated to the schema name is
rollbacked (however, the schema may not be a default schema).
For more information about transactions and the transaction autocommit mode, see the
section Transactions.
The vendor DBMSs implement transactions in different ways that determine
when the effects of the statements in a transaction are posted to the physical
database.
Whenever a commit or rollback statement is executed, all cursors are closed
and all locked tables are released.
If an error occurs during the execution of a DML statement that updates the database,
a rollback command is executed automatically.
If RIS is terminated within a transaction, a rollback statement is issued
automatically.

SQL Database Language Reference 4 - 71

Examples
_________
rollback;
rollback for sch1;
See
Also
________
commit
set transaction

4 - 72

SQL Database Language Reference

4.2.25

__________________________________________________________________________________________________________________________________________________

select
The select statement retrieves data from a table or view.
select [ all | distinct ] <column-list> from <relation-list>
[ where <conditions> ]
[ group by { <column> } [, ...] ]
[ having <conditions> ]
[ order by { <column> | <num> [{ asc | desc }]} [, ...]];
Notes
_ ____
The <column-list> identifier is an asterisk (*), or a comma-separated list of columns or
expressions. An asterisk (*) specifies that all columns should be retrieved.
The distinct keyword specifies that only unique rows should be retrieved. The all
keyword specifies that all rows matching the selection criteria should be included in the
select and is the default.
If any column in the <column-list> identifier exists in more than one table in the <relationlist> identifier, that column must be identified by prefixing it with the table name and a
period (.). For example: tablename.colname.
The <relation-list> identifier is a comma-separated list of tables or views with optional
correlation names. Correlation names (also known as alias names or table labels) are used to
distinguish between multiple users of a table in one query, particularly when performing a
self join. A correlation name is another name given to a relation and is defined by specifying
the correlation name after the relation name, separated by a space.
If a relation exists in a schema other than the default schema, the schema name must be
specified, followed by a period (.), followed by the relation name.
The optional where clause places restrictions on which data is retrieved. For more
information, see the where clause section.
The group by clause groups the rows by the values in the given columns. Only distinct
values for the columns given are returned. The columns to group by can be specified by
column name (the <column> identifier) or by column position (the <num> identifier) as in the
order by clause. If the group by clause is not specified, each row is considered a group.
The group by limit is the same as the index limit.
The having clause is used to apply conditions to a group. The only valid conditions on a
group are conditions that can be applied to all rows of the group, such as an SQL function.

SQL Database Language Reference 4 - 73

The order by clause, if used, must be the last clause. It causes the resulting rows to be
placed in ascending or descending order (specified with the asc and desc keywords,
respectively) of the values of the given columns. If neither of the asc or desc keywords is
specified, the ordering defaults to ascending order. The columns to order by can be specified
by column name or by column position in the select list. The column name corresponds to the
<column> identifier and the column number corresponds to the <num> identifier. If multiple
columns are specified in the <column-list> identifier of the order by clause, the rows are
first sorted by the first column. If there are any duplicate values in the first column, the
second column is used for ordering.
The order by limit is the same as the index limit.
For more information about selecting from tables and views, see the sections Tables and
Views.
Examples
_________
select * from tab1;
select * from tab1 where col1 = 5;
select * from tab1 where col1 = 5 and col2 = abcd;
select col1, col3 from tab1;
select * from tab1, tab2;
select * from tab1, tab2 where tab1.col1 = tab2.col2;
select tab1.col1, tab2.col2 from tab1, tab2;
select col1, col2 from tab1 order by col1, 2;
select * from tab1 correlation1, tab1 correlation2
where correlation1.col1 = correlation1.col2;
select col1 from tab1 group by col2;
select col1 from tab1 group by col2 having sum(col2) > 5;
The select syntax select * from tab2 where exists (select col1,
col2 from tab3 where ......); is invalid in RIS because several
underlying databases do not support it. Instead, use an * in the second select
statement: select * from tab2 where exists (select * from tab3
where ......);
See
Also
________
where

4 - 74

SQL Database Language Reference

4.2.26

__________________________________________________________________________________________________________________________________________________

set database
The set database statement lets you specify the brands or types of underlying databases
you can use. It also causes the user-supplied names to be verified against the reserved words
of the specified RIS-supported databases.
This statement affects the functionality of the lock tables statement.

set database enable [ all | only <database>[, ...] ];

Notes
_ ____
The <database> identifier specifies the RIS-supported databases. The databases currently
supported are DB2, INFORMIX, ORACLE, SYBASE, and Microsoft SQL Server. Only
schemas which were created on the databases specified in the set database statement can
be accessed. Additionally, RIS verifies user-supplied table names, column names, view
names, and index names against the reserved names of the databases specified in the
statement database list while executing DDL statements such as create schema, create
table, create view, create index, and alter table.
The default is set database enable all. The keywords of all RIS-supported DBMSs are
enforced.
If you use the set database enable only statement, only the specified
databases are usable. This statement makes the application non-portable. If RIS
adds support for additional databases in the future, an application with this
statement cannot use the new databases.
Examples
_________
set database enable all;
set database enable only informix, rdb, sybase;
See Also
________
alter table
create index
create schema
create table
create view

SQL Database Language Reference 4 - 75

4.2.27

__________________________________________________________________________________________________________________________________________________

set mode
The set mode statement lets you toggle the ANSI, verify, and blank strip modes on or off.
set mode [ ansi {on|off} ] [ verify {on|off} ]
[blank strip {on|off} ];
Notes
_ ____
The set mode ANSI on statement restricts user-supplied names for schemas, tables,
columns, views, and indexes to a maximum of 18 characters in length while creating
schemas, tables, views and indexes or altering tables. This statement does effect the existing
schema, table, view, or index names. When ANSI mode is off, the limit is extended to 31
characters.
For more information, see the section Vendor-Specific Information.
Because the underlying DBMSs have their own maximum limits to these usersupplied names, the set mode ANSI off statement should be executed with care.
This statement makes the application non-portable.

The set mode verify on statement validates table and view definitions that are
retrieved from the underlying database against the definitions stored in the RIS dictionary
tables. The set mode verify off statement retrieves the definitions from the
underlying databases only, omitting the validation phase. By omitting the validation phase,
the execution time when referencing a table or view for the first time is reduced.
It is recommended that the set mode verify off statement not be executed by
applications that dynamically create tables and views, because without verification,
the definitions in the RIS dictionary tables and the underlying DBMS dictionary
may become inconsistent.
Because of ambiguity in the mapping of underlying DBMS data types to RIS data
types, columns in tables can have different data types with verify on or off.
Verify off should not be used unless table and view definitions are explicitly
declared with the declare table and declare view statements. For more
information, see the section Vendor-Specific Information.
The set mode blank strip on statement causes RIS to strip the trailing blanks from
character data. The set mode blank strip off statement causes RIS to not strip the
trailing blanks from character data.

4 - 76

SQL Database Language Reference

Examples
_________
set mode ansi on;
set mode ansi off verify off;
set mode blank strip on verify off;
See
Also
________
alter table
create index
create schema
create table
create view
declare table
declare view

SQL Database Language Reference 4 - 77

4.2.28

__________________________________________________________________________________________________________________________________________________

set network verification

The set network verification statement lets you specify the alarm timestamp
parameters and network buffer parameters.
set network verification [timestamp interval <value>,]
[initial timeout <value>,]
[timestamp tolerance <value>,]
[buffer full size <value>,]
[buffer full timeout <value>,]
[response interval <value>] [for <schema>[,...]];
Notes
_ ____
The <value> in the timestamp interval clause specifies the time period of timestamps
that the RIS server sends out to the RIS client. After the RIS server begins to execute a
statement, it sends a timestamp at the specified timestamp interval until the execution of
the statement finishes. Before receiving the execution results of the statement, the RIS
client collects these timestamps and decides the status of the RIS server based on the
number of the collected timestamps and the amount of elapsed time since the statement is
executed. If the multiplication of the number and the period is much less than the elapsed
time, then the RIS client may decide that the server has died. Generally, the smaller the
timestamp interval, the quicker correct response of the RIS client to the status change of the
RIS server. Too small a timestamp interval, however, may increase network traffic, which
may consequently limit the quickness.
If the timestamp interval is set to a value 0, the network verification is
disenabled. That is, all other clauses are meaningless.
The <value> in the initial timeout clause specifies the maximum time period within
which the RIS client must set up timer synchronization with the RIS server. When the RIS
client starts a remote server, it sends a synchronization request to the server and waits for
an acknowledgement from the server. After the server receives the request, it starts its
timer and sends an acknowledgement immediately. If the RIS client gets the
acknowledgement within the time period, it sets the start point of its timer at a medium
moment between the request and the acknowledgement. Otherwise, it decides that the
server is not responding. The synchronized timers in both sides enable the RIS client to
correctly estimate the status of RIS server through counting received timestamps.
The smaller the initial timeout, the smaller the difference between the two timers. An initial
timeout that is too small, however, may increase the chance of unexpected terminating of
RIS.

4 - 78

SQL Database Language Reference

The <value> in the timestamp tolerance clause specifies the maximum tolerable
difference between the number of timestamps the RIS client is expected to receive, and the
number of timestamps the RIS client actually receives. If the difference is larger than the
tolerance, the RIS client reports that the RIS server has died.
Network traffic, heavy site load, and the synchronization error of timers may cause the RIS
client to count less timestamps than expected. A small timestamp tolerance may cause RIS
to terminate unnecessarily.
The <value> in the buffer full size clause specifies the maximum buffer size that the
network software can use. RIS uses this value to determine the maximum number of
timestamps that can be written in the network buffer without the possibility of the network
buffer becoming full.
After the RIS client has read the number of timestamps from the buffer, it takes the effect of
buffer full into account if it received less timestamps than expected, in other words, an
additional delay of timestamps is tolerable due to the buffer full effect.
The <value> in the buffer full timeout clause specifies the longest time period for
which the RIS client can wait to receive the next alarm timestamp from the RIS server after
the RIS client has read more than the buffer full size of timestamps. In other words,
if the RIS client cannot receive a new timestamp within the period, and the received
timestamps is less than expected, the RIS client reports that RIS server has died.
The <value> in the response interval clause specifies the actual time period of
timestamps that the RIS server sends out to the RIS client, while the timestamp interval is
the time period of timestamps in which the RIS client expects the RIS server to have sent
timestamps. If the value is negative, the RIS server dies immediately after a statement is
sent to the server. If the value is much larger than that specified in timestamp interval
clause, RIS waits and then reports that the server has died after a statement is sent.
The response interval clause is specially designed for RIS testing
purposes. The clause is usually used with the timestamp interval clause to
simulate an asynchronization situation in which the RIS server is much slower
than expected, or has died.
The <schema> specifies the schema on which the set command takes effect. The schema
should be defined in the RIS schema file. If the schema has not been opened, the set
command opens the schema. Note that if the for <schema> clause is not specified, the
set command is effective only for the schema that is opened after the set command is
issued.
All five of these parameters are basically independent of each other. However, the different
combinations of these parameters may have different effects on RISs behavior. Consider a
subtle combination such as the following:
If BUFFER_FULL_TIMEOUT > TIMESTAMP_INTERVAL*TIMESTAMP_TOLERANCE
then the buffer full timeout dominates the timestamp tolerance. That is, the RIS
client reports that the server died only after the buffer full timeout has elapsed in
buffer full case.

SQL Database Language Reference 4 - 79

Otherwise, the buffer full timeout does not dominate the timestamp tolerance
when the RIS server has sent all ideal timestamps, on time, at the buffer full moment.
This is because the RIS client is able to wait TIMESTAMP_INTERVAL*TIMESTAMP
_TOLERANCE seconds for the tolerance test.
In the current version, only the RIS ORACLE and the RIS INFORMIX servers
on UNIX workstations and the RIS ORACLE server on Windows NT support
the set network command.
Examples
_________
set network verification timestamp interval 0;
set network verification timestamp interval 20 for inf1, inf2, inf3;
set network verification timestamp interval 12, initial timeout 15,
timestamp tolerance 20, buffer full size 64, buffer full timeout 20;
set network verification response interval 1000, timestamp interval 10 for inf1;
set network verification response interval -30, timestamp interval 10 for inf1;

See
Also
________
create schema
open schema
default schema

4 - 80

SQL Database Language Reference

4.2.29

__________________________________________________________________________________________________________________________________________________

set transaction
The set transaction statement sets the transaction state.
set transaction autocommit { on | off };
Notes
_ ____
The on keyword enables the transaction autocommit mode. When the autocommit mode is
on, RIS automatically issues a commit statement after every SQL statement.
The off keyword enables normal transaction processing.
By default, the transaction autocommit state is set to on.
Autocommit on causes a commit to occur when closing a cursor. Embedded
SQL open and fetch does not cause a commit, only close causes a commit. See
the RIS Programmers Guide.
The following rules provide you with some degree of safety.
1.

If RIS is terminated abnormally, it issues a rollback statement to prevent the

possibility of corrupting data.

2.

If an error occurs during the execution of any DML statement, RIS issues a
rollback statement to prevent the corruption of data.

For more information about transactions, see the section Transactions.

Examples
_________
set transaction autocommit on;
set transaction autocommit off;
See
Also
________
commit
rollback

SQL Database Language Reference 4 - 81

4.2.30

__________________________________________________________________________________________________________________________________________________

undeclare schema
The undeclare schema statement lets you undefine or remove declared schemas from the
RIS in-memory data dictionary cache.
undeclare schema [ALL | <schname1, schname2, ...>]
Notes
_ ____
The ALL identifier removes all schemas from the cache or schema names can be listed
individually.
Examples
_________
undeclare schema all;
undeclare schema john, jones;

See
Also
________
declare schema
create schema
open schema
default schema
drop schema
alter schema

4 - 82

SQL Database Language Reference

4.2.31

__________________________________________________________________________________________________________________________________________________

undeclare table
The undeclare table statement lets you undefine or remove a RIS table from the RIS inmemory data dictionary cache.
undeclare table [<schema>.]<table>;
Notes
_ ____
The <table> identifier is the table name.
The optional <schema> identifier is the schema in which the table exists. The schema
identifier must be specified if the table exists in a schema other than the default schema. No
privileges are required to undeclare a table that exists in a schema other than the default
schema.
The undeclare table statement lets the user remove a table from the RIS in-memory
data dictionary cache. This frees up memory, thus avoiding out of memory problems.
RIS automatically attempts to remove table definitions if the user definable limit
MAX_TABLES_IN_MEM is exceeded. For more information, see the section Parameters.
This statement fails if the table definition is not in memory or is currently being
used by some other statement.

Examples
_________
undeclare table t1;
undeclare table sch2.t2;
See
Also
________
declare table

SQL Database Language Reference 4 - 83

4.2.32

__________________________________________________________________________________________________________________________________________________

undeclare view
The undeclare view statement lets you undefine or remove a RIS view from the RIS inmemory data dictionary cache.
undeclare view [<schema>.]<view>;
Notes
_ ____
The <view> identifier is the view name.
The optional <schema> identifier is the schema in which the view exists. The schema
identifier must be specified if the view exists in a schema other than the default schema. No
privileges are required to undeclare a view that exists in a schema other than the default
schema.
The undeclare view statement lets you remove a view from the RIS in-memory data
dictionary cache. This frees up memory, thus avoiding out of memory problems.
RIS automatically attempts to remove view definitions if the user definable limit
MAX_TABLES_IN_MEM is exceeded. For more information, see the section Parameters.
This statement fails if the view definition is not in memory or is currently being
used by some other statement.

Examples
_________
undeclare view v1;
undeclare view sch2.t2;
See
Also
________
declare table
declare view

4 - 84

SQL Database Language Reference

4.2.33

__________________________________________________________________________________________________________________________________________________

union
The union operator lets you combine two or more select statements into a single query.
<select-statement> union [all] <select-statement>
[union [all] <select-statement] [...];
Notes
_ ____
The union keyword selects all rows from two select queries, removes duplicates, and
returns what is left. All the select statements preceding the union keyword are treated like a
single statement.
The <select-statement> identifier represents a valid SQL statement. The all optional
keyword leaves the duplicates.
The following restrictions apply to queries connected by union operators:
1.

The number of columns in the select-list of each select statement must be the same,
and the corresponding columns in each select-list must have compatible data types.

2.

Corresponding columns need not have the same name.

3.

If you use an order by clause, it must follow the last select-statement. In other
words, it is not valid to use the order by clause in a select statement that precedes a
union operator.

4.

The compatibility of RIS data types is defined as follows:

a.

Each data type is compatible with itself.

b.

All numerical data types are compatible with each other.

For example, a char data type is compatible with itself. An integer data type is
compatible with real, decimal, smallint, and float data types, and itself.
If two data types of corresponding columns are compatible, but not the same, the
data type in the first select statement is used as the data type for the results of
the union select query.

The union operator may not appear within a create view statement, an insertselect statement, a subquery, or a nested query.

SQL Database Language Reference 4 - 85

For more information about selecting from tables and views, see the sections select and
where.
Examples
_________
select * from t1 union select from t1;
select c1, c2 from t1 union all select c21, c22 from t2;
See
Also
________
where
select

4 - 86

SQL Database Language Reference

4.2.34

__________________________________________________________________________________________________________________________________________________

update
The update statement updates or modifies values that already exist in a table. The updates
change data in the table specified in the update statement or the table referenced by the
view specified in the update statement.
update [<schema>.]<relation> set { <column> = <value> } [, ...][ where <conditions> ];
Notes
_ ____
The <relation> is the name of the relation to be updated. This can be the name of a table or
view.
The optional <schema> identifier is the schema in which the relation exists. This identifier
must be specified if the relation exists in a schema other than the default schema. A period
(.) must separate the schema name and the relation name.
The <column> identifier is the column name in that relation to be updated.
The <value> identifier is the value to be assigned to that column.
The where clause can be used to restrict the rows to be updated. If a where clause is not
specified, all rows in the table are updated. For more information, see the where clause
description.
If no rows are updated, SQLCODE is set to END_OF_DATA.
If an error occurs during an update or any DML statement, a rollback
statement is automatically issued.
For more information about the effects of errors on transactions, see the section
Transactions. For more information about tables and views, see the sections Tables and
Views.
Examples
_________
update tab1 set col1=2, col2=defg, col3=3.0;
update tab1 set col1=2, col2=defg, col3=3.0 where col1=1;
update tab1 set col1=2, col2=defg, col3=3.0
where col1=1 and col2=abcd;

SQL Database Language Reference 4 - 87

See
Also
________
alter table
create table
create view
delete
drop table
drop view
insert
where

4 - 88

SQL Database Language Reference

4.2.35

__________________________________________________________________________________________________________________________________________________

where
The where clause restricts the rows of a relation that are selected, updated, or deleted.
where <condition>
Notes
_ ____
The <condition> identifier can consist of one of the following:
<condition> <boolean> <condition>
not <condition>
<expr> <comparison-op> <expr>
<expr> [not] between <expr> and <expr>
<expr> [not] in ( <value-list> )
<column> is [not] null
<char column> [not] like <wildcard-string>
<nested-query>

The <expr> identifier can be a column name, a value, or an arithmetic expression involving
column names and/or values. It can consist of the following:
{ <column> | <value> } [ <arithmetic op> { <column> | <value> } ] [, ...]

The <boolean> identifier can consist of the following:

{ and | or }

The <arithmetic op> identifier can consist of the following:

multiplication (*)
division (/)
addition (+)
subtraction (-)
The arithmetic operators supported are (in order of precedence) multiplication (*), division
(/), addition (+), and subtraction (-). Operators of equal precedence are evaluated from left
to right. The precedence can be changed with parentheses.

SQL Database Language Reference 4 - 89

The <comparison-op> identifier can consist of the following:

equal to (=)
not equal to (!= or <>)
less than (<)
greater than (>)
less than or equal to (<=)
greater than or equal to (>=)
The <comparison-op> identifier specifies a comparison operation to perform on two
expressions. If the result of the comparison operation is a TRUE condition, then the rows in
question are included in the select, update, or delete. Otherwise, they are excluded. The
following comparison operations are supported:
equal to (=) if the left expression equals the right expression, the operation results
in a TRUE condition.
not equal to (<> or !=) if the left expression is not equal to the right expression, the
operation results in a TRUE condition.
less than (<) if the left expression is less than the right expression, the operation
results in a TRUE condition.
less than or equal to (<=) if the left expression is less than or equal to the right
expression, the operation results in a TRUE condition.
greater than (>) if the left expression is greater than the right expression, the
operation results in a TRUE condition.
greater than or equal to (>=) if the left expression is greater than or equal to the
right expression, the operation results in a TRUE condition.
A string can be specified in an expression to be compared to some other value (usually a
column of type char). It must be enclosed in single quotations. Strings are compared
character by character by ASCII value until a mismatch is found. If the strings are identical
except for length, the longer string is considered to be greater than the shorter string.
Use two single quotations to represent a single quotation within a string. Use one double
quotation to represent a double quotation within a string. Each of the following examples
results in the word quoted being printed in between quotations:
1.

This is "quoted" text. - Quoted in double quotations.

2.

This is quoted text. - Quoted in single quotations.

4 - 90

SQL Database Language Reference

The and keyword performs the logical and operation on the results of two conditions and the
or keyword performs the logical or operation on the results of the two conditions. The not
keyword can be used to logically negate a condition. The order of precedence is: not, and,
or.
The between clause checks the left expression against a range of values resulting from the
two right expressions. After all three expressions have been evaluated, the result of the left
expression is tested to determine if it falls between the resulting values of the two right
expressions, inclusively. If so, the condition is TRUE. The not keyword can be used to
logically negate the condition.
The between clause is equivalent to (<expr> >= <first expr> and <expr> <=
<second expr>). The first expression (to the left of the and keyword) must
evaluate to a smaller value than the second expression (to the right of the and
keyword).
The in clause specifies that the set of values in the <value-list> identifier should be checked
for the inclusion of the left expression. The <value-list> identifier is a comma-separated list
of values. If the value resulting from the left expression is in the set of values resulting from
the expressions in the <value-list> identifier, the condition is TRUE. The not keyword can
be used to logically negate the condition.
The is null clause specifies that the column should be tested for a NULL value. If the
value in the column is NULL, the condition is TRUE. The not keyword can be used to
logically negate the condition.
The like clause specifies that the character column be compared to the <wildcard-string>
identifier.
The <wildcard-string> identifier is a string that may contain wildcard characters. The
wildcard characters which are supported are the underscore character ( _ ) and the percent
character (%). The underscore character matches any single character while the percent
character matches zero or more occurrences of any characters. If the value resulting from
the left expression matches the <wildcard-string> identifier, the condition is TRUE. The
not keyword can be used to logically negate the condition.
There is no escape mechanism available to let you literally find the underscore
character (_) or the percent character (%).
See the nested query description for a complete description of the <nested-query> identifier.
Examples
_________
... where column1 < column2 + column3;
... where column1 <> 1 + 2;
... where not column1 = column2;
... where column1 between column2 + 3 and 5;
... where column1 in (1, 2, 3);

SQL Database Language Reference 4 - 91

... where column1 is not null;

... where column1 like _bcdef%;
... where (column1 + 3) * 5 >= column2;
... where (column1 / 2) > column2 and column1 != column3;
See
Also
________
delete
Nested Query
select
update

4 - 92

SQL Database Language Reference

4.3

__________________________________________________________________________________________________________________________________________________

Nested Query
Nested queries let you specify a set of values, to be compared to another value or column in a
where clause, by using a select statement. The values retrieved by the select
statement are compared to the specified value or column. This can be used as the condition
of a where clause.
<expr> <comparison-op> all ( <select-statement> )
<expr> <comparison-op> any ( <select-statement> )
<expr> <comparison-op> some ( <select-statement> )
[not] exists ( <select-statement> )
<expr> [not] in ( <select-statement> )
Notes
_ ____
The <expr> identifier can be a column name, a value, or an arithmetic expression involving
column names and/or values. For more information on arithmetic expressions, see the where
clause description.
The <comparison-op> identifier specifies a comparison operation to perform on two
expressions. If the result of the comparison operation is a TRUE condition, the rows in
question are included in the select, update, or delete statement. Otherwise, they are
excluded. For more information on the comparison operators, see the where clause
description.
The <select-statement> identifier is any valid select statement. For more information, see
the select statement description.
The all clause specifies that the value resulting from the left expression be compared to the
values resulting from the select statement. If the comparison operation results in a TRUE
condition for all values, the nested query is TRUE.
The any clause specifies that the value resulting from the left expression be compared to the
values resulting from the select statement. If the comparison operation results in a TRUE
condition for any of the values, the nested query is TRUE.
The some keyword is a synonym for the any keyword.
The exists clause results in a TRUE condition if one or more values are returned by the
select statement. The not keyword can be used to logically negate the condition.

SQL Database Language Reference 4 - 93

The in clause specifies that the value resulting from the left expression be compared to the
values resulting from the select statement. If the left value is equal to at least one right
value, the where clause is TRUE. The not keyword can be used to logically negate the
condition.
Examples
_________
... where column1 = any (select col1 from tab2);
... where column1 >all (select col1 from tab2);
... where column1 <>some(select col1 from tab2);
... where column1 in (select col1 from tab2);
... where exists (select * from tab2 where ...);
= all is not supported by Microsoft SQL Server.

See Also
________
select
where

4 - 94

SQL Database Language Reference

4.4

__________________________________________________________________________________________________________________________________________________

SQL Functions
The SQL functions provide operations commonly used on sets of data.
count( * )
OR
{ avg | max | min | sum | count } ( distinct <column> )
OR
{ avg | max | min | sum } ( [ all ] <expr> )
OR
user
OR
current_timestamp
Notes
_ ____
The SQL functions, like avg, count, max, min, and sum let you get summary information
about groups of rows in database tables. These functions can be used within the select
statement (with column list) and in the having clause.
The count function returns the total number of rows if the asterisk (*) is specified, or the
number of unique rows if the distinct clause is specified.
The distinct keyword causes any duplicate values to be removed before performing the
function, and can only be used with columns. If the distinct keyword is not used, the
argument to the function can be an expression and the function is applied to all the values.
The all keyword is optional in this case.
The <column> identifier is the name of the column on which the operation would take place.
The <expr> identifier can be a column name, a value, or an arithmetic expression involving
column names and/or values. For more information on the arithmetic operators, see the
where clause description.
The avg function computes the average value of all (or all distinct) values in the column or
expression.

SQL Database Language Reference 4 - 95

The max function returns the maximum value of all (or all distinct) values in the column or
expression.
The min function returns the minimum value of all (or all distinct) values in the column or
expression.
The sum function computes the sum of all (or all distinct) values in the column or expression.
The current_timestamp returns the current timestamp from the database. This is a year,
month, day, hour, minute, second value. If the database resides on a machine in another
time zone, the time is different than local time on the system.
The user returns the name of the default schema.
The current_timestamp (current system date and time) and user (current default
schema name) can appear anywhere a literal is valid.

NULL values have different effects depending on the function. The count(*)
phrase counts all rows, regardless of the presence of NULLs. The count
distinct phrase and the avg, max, min, and sum functions ignore NULL
values, unless there are only NULL values. In this case, the count distinct
phrase returns the number of rows and the avg, max, min, and sum functions
returns NULL.
If no rows are selected, NULL is returned.
In most cases, you may not select both summary information returned by SQL
functions and individual values of columns in one select query. For example,
select name, avg(salary) from tab1;
is invalid. The one exception to this rule is when a group by clause is used on
the columns from which the individual values are selected. For example,
select dept_no, avg(salary) from tab1 group by dept_no;
is valid.
The values returned by functions may differ depending on the underlying
DBMS. For more information refer to the specific DBMS reference manual.
Examples
_________
select count(*) from tab1;
select avg(col1) from tab1;
select avg(distinct col1) from tab1;
select user from tabl;

4 - 96

SQL Database Language Reference

select current_timestamp from tabl;

select * from tabl where col1 < current_timestamp;
select C1 from +1 group by C1 having count (*) >1;
See
Also
________
select
where

Troubleshooting 5 - 1

Troubleshooting

__________________________________________________________________________________________________________________________________________________

5-2

Troubleshooting

Troubleshooting 5 - 3

5.

__________________________________________________________________________________________________________________________________________________

Troubleshooting
This section describes some of the problems, causes, and recoveries for some commonly
encountered RIS error messages.

NETWORK Error: NET_E_CONNECT_ERROR (0x89cd806a)

Unable to connect to server
Problem 1:
Cause 1:

Recovery 1:

The locate client command fails on PC/DOS with: connect

timed out.
Video cards, network cards, sound cards, etc. use memory
that needs to be excluded from the upper memory
management packages. The extended memory manager
entry in the config.sys file is not correctly setup.
Set the x option in the emm386 entry of the config.sys file:
On the TD1 from Intergraph the system functions require:
DEVICE=C:\DOS\EMM386.EXE x=a000-c7ff
x=c800-cbff RAM M9
On the PC433 from Intergraph the system functions require:
DEVICE=C:\DOS\EMM386.EXE x=d800-d9ff RAM
M9
On a NCR 3300 with the IBM Token Ring 16/4 network card
the system functions with:
DEVICE=C:\DOS\EMM386.EXE 2048 x=d800-dbff
On generic PCs you need the x option defined for the RAM
address designated in the network card setup.

Problem 2:
Cause 2:
Recovery 2:

Locate client command fails: error creating tcp socket.

PC/TCP is not installed.
Install PC/TCP version 2.11 or higher.

Problem 3:

Locate client and create schema commands fail: unknown

error.
Cannot telnet to UNIX machine from a TD-1 (running
Windows NT).
The first 2 digits in the TD-1 tcpip address were different
from those of the UNIX server. Also subnet mask was 0.0.0.0
instead of 255.255.255.0.
Locate client command fails on PC/DOS with: connect timed
out.

Cause 3:
Recovery 3:

Problem 4:

5-4

Troubleshooting

Cause 4:
Recovery 4:

The client machine is not set up properly.

Be sure that the client machine has an entry in the
/etc/inetd.conf file for the ristcpsrv. If it is missing then renewprod the RIS products to the client machine.

NETWORK Error: NET_E_READ_BUFFER_TOO_SMALL (0x89cd81d2)

Read buffer too small to receive entire transmission.
Problem:
Cause 1:
Recovery 1:
Cause 2:
Recovery 2:

Cannot create a schema on Sun.

Kernal is not properly configured.
Re-configure the Sun kernel. See the RISsun.doc file in the
riscsu directory.
SunOS Version 4.1.2 is NOT supported by RIS over the
network.
Upgrade to SunOS Version 4.1.3 which is what RIS was built
on and certified with. (Some ris customers have been able to
use this Version (4.1.2) if all the components are on the same
machine.)

NETWORK Error: NET_E_READ_ERROR (0x89cd81da)

Network Read Error.
When this error is an interrupted system call, it appears simultaneously with the error:
RIS_E_SERVER_NETWORK_ERROR (0x8a949f3a).
Problem 1:
Recovery 1:

Cannot communicate with server over the network.

See recovery descriptions for
RIS_E_SERVER_NETWORK_ERROR (0x8a949f3a).

Problem 2:

Cannot connect to existing schema TCP connection has been

broken.
Reloading risoc cleared up this problem.

Recovery 2:
Problem 3:

Recovery 3:

A TD-1 (running Windows NT) could not access an existing

schema on a Clipper machine. This additional error was also
received:
NETWORK ERROR: MESSAGE FILE NOT FOUND FOR
0X89CD81DA
Refer to the error about "internationalization":
RIS_E_SERVER_NETWORK_ERROR (0x8a949f3a)
Unable to communicate with server over network.

RIS Error: RIS_E_BAD_LOGIN (0x)

Invalid username/password combination.
Problem 1:
Cause 1:

Rismgr fails to come up. Show schema file fails in interactive

mode.
A locate client was done on a machine that does not have
risccu loaded on it.

Troubleshooting 5 - 5

Recovery 1:

Edit the schema file to reflect shared memory in client

location.

Problem 2:
Cause 2:

Unable to create a schema.

A schema using the same name with the same os
user/password was previously successful. This information is
stored in the schema file. However, after the successful
creation of the schema, the osuser password was changed so
that the actual osuser/password combination did not match
the schema file.
Edit the schema file and then do a checksum of the file.

Recovery 2:
Problem 3:
Cause 3:

Recovery 3:

Cannot create a schema on an oracle database using the

schema manager.
The schema manager highlighted the database user/passwd
not the os user/passwd field. The customer also used rlogin
to verify that the tcp/ip network connection was working,
which, by way of the .rhosts file bypasses security, and did not
help them identify the problem.
The os user/passwd had changed. This was detected by using
telnet to connect and log in. So, the user only had to change
the os user/passwd field, NOT the database user/passwd
field.

RIS Error: RIS_E_CANT_CREATE_SCHEMA_FILE (0x8a94812a)

Cannot create a schema file.
Problem 1:

Solution 1:

Cannot create a schema and the following errors are also

displayed:
"the system cannot find the file specified"
"file does not exist or is not accessible"
Please check the following:
1. Is RIS_PARAMETERS set? If so, use that value to find
parms file.
2. Check in parms file. Where is client?
3. Schema file location is relative to client, what is protocol for
schema file?
4. If protocol for schema file is other than M, you MUST have
an encrypted password for the schema file user. This should
only be done through ris products locate schema file
statement.

RIS Error: RIS_E_CANT_FREE_DICT (0x8a94817a)

Attempt to free a dictionary statement failed.
Problem:

Cannot access Sybase data.

5-6

Troubleshooting

Cause:

Recovery:

The directory c:\risdata or its equivalant (by way of the

environment variable RISSYBDIR in the config\env0.syb)
file is not writable or present.
Create the directory, or change the permissions on it.

RIS Error: RIS_E_CANT_GET_SCHEMA_FILE (0x8a9481aa)

Cannot make a copy of the schema file.
Problem:
Recovery:

Cannot make a copy of the schema file. Also receiving

net_get_file_error (15).
Check privileges on /usr/tmp or c:\temp for windows NT.

RIS Error: RIS_E_CANT_LOCATE RIS (0x8a9481b2)

Could not determine the location on the RIS schema file machine
Problem:

Cause:
Recovery:

Cannot do a locate schema file from a TD-1 to a server. The

following messages also appeared:
RIS Error: NET_E_GET_FILE_ERROR (0x8cd80b2)
Unable to get a copy of a file
Permissions on the schema file didnt allow user access.
Change permissions on the schema file.

RIS Error: RIS_E_CANT_OPEN_ID_FILE_WRITE (0x8a9481da)

An error occurred while opening the schema id file to write.
Problem:
Cause:
Recovery:

Cannot create a schema on Windows NT

The environment variables temp and tmp are set, BUT,
they do not point to an existing valid directory.
Create the directories that they are pointing to, OR, reset the
environment variables to point to a valid directory.

RIS Error: RIS_E_CANT_OPEN_LANGCONFIG_FILE (0x8a94b2e2)

Unable to open RIS language config file.
Problem:
Cause:
Recovery:

Get error occurred while using interactive RIS on PC/DOS.

Environment variable RISDIR is set to version 4.3.2.x.
Remove RISDIR environment variable. (It was only valid in
version 2.)

RIS Error: RIS_E_CANT_PUT_SCHEMA_FILE (0x8a94820a)

Cannot update the schema file.
Problem 1:
Cause 1:
Recovery 1:

Schema file is not updated when a create schema statement is

issued.
The fmu is failing to replace the schema file.
A change request has been filed to do this a different way.

Problem 2:
Cause 2:
Recovery 2:

Cannot write schema file back to rishome after update.

UNIX permissions on file wont allow write.
Fix permissions.

Troubleshooting 5 - 7

RIS Error: RIS_E_CLIENT_DIED (0x8a9482b2)

The risclient process has died. No RIS statements may be
executed.
Problem:
Cause:

Recovery:

Error occurs when doing anything in RIS interactive (or any

other process that uses RIS).
The RIS client and server are not at the same version level.
Everything has been newproded everything from a local CD.
Somehow the products in the ws_s.prods file showed up as
Version 4.3.1.10 but the actual products that got installed
were 4.3.5.x for the utilities and servers. You can check the
README files in all of the directories to verify the version
number.
The underlying problem was that client and server versions
were incompatable, but this was not obvious from looking at
the versions listed in newprod. This will happen when a RIS
application 4.3.5.x tries to connect to a RIS client 4.3.1.x.
Be sure that the client and server are the same version.

RIS Error: RIS_E_CLIENT_NETWORK_ERROR (0x8a9482c2)

Unable to communicate with client process.
Problem:
Cause:
Recovery:

Cannot default to an existing schema.

Someone has done a locate client command to a machine that
doesnt have a RIS client.
Do a locate client command to a machine that has a client.

RIS Error: RIS_E_CRE_PROC_GET (0x8a94b44a) Error creating stored procedure

RISGETTAB. Refer to:
RIS Error: RIS_E_PROC_GET_MISS (0x8a94b452)
Missing stored procedure gettab.
RIS Error: RIS_E_CRE_PROC_TAB (0x8a94836a)
Error creating stored procedure ristabdel.
Problem 1:
Cause 1:

Recovery 1:

Problem 2:
Cause 2:

The create schema statement fails for Informix 5.0 On-line.

Informix requires products (On-line & ISQL) to be loaded in
ascending order of the version number. For example: ISQL
4.10, then On-line 5.0.
Re-load Informix On-line, then re-start Informix (you do not
need to re-initialize), then re-issue the create schema
statement.
The create schema statement fails for Informix 5.0 Standard
Engine.
Informix requires products (Standard Engine & ISQL) to be
loaded in ascending order of version number. For example:
ISQL 4.10, then Standard Engine 5.0.

5-8

Troubleshooting

Recovery 2:

Re-load Informix standard engine, then re-issue the create

schema statement.

RIS Error: RIS_E_DEFAULT_SCHEMA_DIED (0x8a94842a)

The default schema server died and restarting failed.
Problem:
Cause:

Recovery:

The schema server dies during I/NFM initialization.

I/NFM creates a temporary schema during the initialization
process. Then, this schema is dropped and the real schema is
created. The RIS server(RISOVX) was dying during the
attempt to create the real schema, using Version 04.03.01.08
of RISOV product.
Re-link risovx.exe by running initial.com. Also, change system
logical for pro_dd_ris to:
ASSIGN/SYS/trans=concealed ZFA0:[IGR.RIS.PRO.]
PRO_DD_RIS
After this set default pro_dd_ris:[bin] should work correctly.

RIS Error: RIS_E_INCONSISTENT_ADDRS (0x8a948672)

The network addresses specified identify different nodes.
Problem 1:
Cause 1:
Recovery 1:

Problem 2:
Cause 2:
Recovery 2:

Problem 3:
Cause 3:
Recovery 3:
Problem 4:
Cause 4:

Recovery 4:
Problem 5:
Cause 5:
Recovery 5:

Error occurs while trying to do a default schema

statement.
The RIS server node /etc/hosts file (or tcpware:hosts file on a
VAX) does not contain the servers nodename.
Add the server nodename to the RIS server node /etc/hosts
file (or tcpware:hosts file on a VAX).
Error occurs while trying to do a default schema
statement.
The /usr/lib/nodes/owned/<node-name> file on the UNIX
server node does not exist.
Create /usr/lib/nodes/owned/<node-name> file on the
UNIX server node.
Error occurs while trying to do a default schema
statement.
The /usr/lib/nodes/owned/<node-name> file on the server
node has the privileges set to: "-rw- 1 root"
Change the privileges to : "-rw-rr" (chmod 644).
Error occurs while trying to do a default schema
statement.
More that one address is present for a protocol in a clearing
house file. For example: XNS has two addresses, or TCP has
two addresses.
Reduce the number of addresses.
Error occurs while trying to do a default schema
statement.
Cannot visit, telnet, or sethost to server.
Correctly install or invoke the network software.

Troubleshooting 5 - 9

Problem 6:

Cause 6:
Recovery 6:
Problem 7:
Cause 7:

Revcovery:

Problem 8:
Cause8:
Recovery:

The netaddr command returns one of two different XNS LAN

ID. One of which is the hexadecimal equivalent of the other.
This results in a RIS INCONSISTENT_ADDRESS error.
CISCO routers require a decimal equivalent of the
hexadecimal specified XNS LAN ID in their configuration.
Reconfigure the CISCO routers correctly.
Cannot access existing schema after doing alter schema and
the network addresses of some machines have been altered.
Operator entered 00000000 for the LAN part of the xns
address. This was probably due to executing netaddr when
the router was down and not getting the correct LAN portion
of the xns address.
Ensure that the address, including the LAN portion, is in
total agreement with the server machine (which may require
a re-boot of the server if some network address item was
modified).
Error occurs when using the default schema statement on a
local machine, and the first network protocol is xns or dnp.
The schema file is corrupted. The tcp/ip entry has control
characters instead of a valid tcp/ip address.
Edit the schemas file and remove the data for the tcp/ip entry
to either a valid tcp/ip address, or to a blank entry.
change from:
PROTOCOL=T
NETADDR=?A
to:
PROTOCOL=T
NETADDR=129.135.174.111
or, to:
PROTOCOL=
NETADDR=
Then, issue the checksum schema file statement within a RIS
utility.

RIS Error: RIS_E_INCONSISTENT_DBPARMS (0x8a94b28a)

Specified database parameters are inconsistent with schema file.
Problem:
Recovery:

Cannot create a second schema on the same Oracle or Sybase

database.
Beginning with Version 4 of RIS, the new keyword osuser
must be specified in the create schema statement for Oracle
and Sybase databases. Whenever the second schema is being
created, the osuser and ospassword must be the same as when
the first schema was created. Otherwise, the create schema
statement fails. Confirm the correct osuser value for the first
schema by looking in the schema file and use this login for
creating the 2nd schema.

5 - 10

Troubleshooting

RIS Error: RIS_E_INTERNAL_ERROR (0x8a9486a2)

RIS internal error.
Problem 1:
Cause 1:

Recovery 1:
Recovery 2:

Problem 2:

Cause 2:

Recovery 2:

Cannot do a set default schema.

A system has had its nodename changed and the DNS server
is still referencing the old name. More importantly, the file
/etc/hosts was not readable by everyone. RIS looks at the
DNS server first (if the /etc/resolv.conf file is present), then
the hosts file. RIS was not able to determine the nodename.
Set read permissions for others on the /etc/hosts file and
correct the DNS server hosts database.
If this error occurs in the Windows NT environment the hosts
file would be located in the
c:\winnt\system32\drivers\etc\hosts
directory. The resolv.conf file is not relevant to Windows NT.
This error appears when selecting a data type of long (long,
long varchar, long raw) from an Oracle 7 database when
using a Version 4 application.
The Version 4 RIS application on Windows NT connected to a
Version 5 client on UNIX and Version 5 server on UNIX and
ORACLE 7 on UNIX, cannot handle the error correctly. You
would normally get the error: invalid data type.
There is no workaround for Version 4 applications. You must
get a Version 5 application.

RIS Error: RIS_E_INV_OPEN (0x8a948e1a)

Underlying dbms could not open cursor.
Problem:
Cause:
Recovery:

Cannot default to a Sybase schema.

The transaction log file for the underlying Sybase database is
full.
Dump the transaction log file.

RIS Error: RIS_E_INV_OPEN_DB (0x8a948e22)

Underlying dbms could not open database.
Problem:

Cause:

RDB Error 20480786

<risdb1>
%RDB-E-UNAVAILABLE2, Rdb/VMS is not available on your
system
%LIB-E-ACTIMAGE, error activating image
C130B$ZFA0:[SYS0.SYSCOMMON.][SYSLIB]RDMSHRP.EXE;2
%SYSTEM-F-PROTINSTALL, protected images...
If you are using multiple versions of Rdb, and you want to
access Rdb 4.1, the logical "RDMS$VERSION_VARIANT" is
not defined to be "41". Rdb looks at the logical
"RDMS$VERSION_VARIANT" to determine whether to work
with the 4.1 Version or the 4.0 Version, in a multiple version
environment.

Troubleshooting 5 - 11

Recovery:

Execute the following command on the VAX:

@sys$library:rdbvms_setver.
Enter 4.1 at the prompt: @sys$library:rdbvms_setver
4.1 /system.

RIS Error: RIS_E_INV_SYB_OPTION (0x8a9492f2)

An invalid option has been specified for a Sybase database.
Problem:
Cause:
Recovery:

Cannot create a SYBASE schema using interactive RIS.

Documentation is incorrect for create schema syntax.
Change the ifile keyword to filename in the option clause of
the create schema statement.

RIS Error: RIS_E_INV_TABLE_NAME (0x8a948902)

Invalid table name. Expected an identifier, got "node".
Problem:

Cause:

Recovery:

Cannot create table named "node" (or port). Also received

these error messages:
RIS Error: RIS_E_INV_COLUMN_DEF_LIST (0x8a948902)
Invalid column definition list.
Two new RIS Keywords were added to Version 4.3.1.10; node
and port. They are undocumented. (Corrected in Version 5
documentation.)
Exclude the table from the schema, use a table name other
than a keyword and reinclude the table into the schema.

RIS Error: RIS_E_INV_USER_SPEC (0x8a94942a)

Invalid user specification.
Problem:
Cause:
Recovery:

Cannot create a SYBASE schema using schema manager.

Schema manager has a known bug in Version 04.03.01.10.
1) Use interactive ris to create the schema. Make sure you
use the keyword filename in the option clause and not the
keyword ifile as it is incorrectly documented.
2) Or, load Version 04.03.05.03.

RIS Error: RIS_E_MISSING_DIR_DEF (0x8a949629)

The DBMS directory or home must be specified.
Problem:
Cause:
Recovery:

Rislod fails to load a Sybase schema.

Risunlod failed to generate a valid create schema statement
for a Sybase schema.
A workaround is to create a schema, then use rislod to load an
existing schema.

5 - 12

Troubleshooting

RIS Error: RIS_E_NO_PROTOCOL (0x8a9499ea)

The specified protocol has not been installed or is not functioning.
Problem 1:
Cause 1:

Recovery 1:

Problem 2:
Cause 2:

Recovery 2:

A new machine has trouble defaulting to an existing schema.

XNS is not installed on the machine. 2730s are delivered
without XNS installed. If an existing schema has xns as one
of its protocols, the previous message occurs.
Either change the schema to use TCP or load XNS on the
2730.
Cannot create a schema.
TCP is not installed correctly. This may occur by someone
removing certain information from one of many TCP/IP files,
and can be confirmed by re-booting the machine and finding
that the tcp/ip address is not correctly set. (Before rebooting
you may still be able to access the node by way of ftp and
telnet.)
Run tcpip/tcpconfig/tcpconfig and correctly install the network
address. For Windows NT, use the Network Settings dialog
box in the Control Panel to install TCP/IP.
This is a very difficult problem to diagnose. Everything (networking) appears to
be working correctly. It is only after a reboot that the tcp/ip address comes back
with 000.000.000.000. A good first step when this error occurs is to reboot, then
do a netaddr to see what the tcp/ip address is.

RIS Error: RIS_E_PROC_GET_MISS (0x8a94b452)

Missing stored procedure gettab.
Problem:

Cause:

recovery:

Error occurred using default schema statement with sybase

database and RIS Version 4.3.6.16 after upgrading from
rissybds 4.3.2.6 on smp/sco to rissybds 4.3.6.16 on smp/sco.
This new version now uses stored procedures that were not
used in the previous version. The RIS data server is supposed
to detect that the procedure did not exist and create it when
accessing existing schemas. It appears not to. This problem
does not occur when creating new schemas.
The current workaround is to use the SYBASE interface "isql"
to create the procedure for existing schemas. The create
procedure statement is:
create procedure risgettab @tabname varchar(31)
as select syscolumns.name, syscolumns.usertype,
syscolumns.length,syscolumns.status
from sysobjects, syscolumns
where sysobjects.name = @tabname
and syscolumns.id = sobjects.id
and sysobjects.uid =
(select uid from sysusers where name = user_name())
order by syscolumns.colid
go

Troubleshooting 5 - 13

This can be generated on site by having the customer execute

the file /usr/ip32/ris/rissybds/bin/cre_sch.ksh. This will
generate a file with all the statements needed to create a
schema manually. The customer can then find the string
gettab and use the statement with Sybases isql as the owner
of the schema that needs updating.
RIS Error: RIS_E_SCHEMA_RESTARTED (0x8a949eea)
A schema server died and has been restarted. The query must be
re-executed.
Problem:
Cause:

Recovery:

Cannot unload a schema or select from a schema.

When the ris parameters file has:
SHARED_MEMORY
0x50000 on Clix or SCO
SHARED_MEMORY 0x200000 on Sun or NT
MAX_ROWS
1000
MAX_BUFFER_SIZE 512000
RIS fails to get enough memory and incorrectly calls UMS to
get an error message and fails. When this occurs, the server
does a clean roll-back and the server dies. What has happened
is that the first time RIS tried to select from the table, it got
30KB of memory. Then, when it needed 40KB, (it does not
reuse the memory) RIS tries to get 40KB more contiguous
units of memory. This fails and an incorrect call to UMS
causes RIS to detect an unrecoverable error, RIS rolls back,
and exits.
The current workaround is to set the parameters down in
size.
Recommend defaults:
MAX_ROWS
100
MAX_BUFFER_SIZE 51200
You can also increase the SHARED MEMORY.

RIS Error: RIS_E_SERVER_NETWORK_ERROR (0x8a949f3a)

Unable to communicate with server over network.
Problem 1:
Cause 1:
Recovery 1:

Cannot create schema.

This error can occur when multiple RIS servers on the VAX
are on different disks (devices).
Re-install RIS on single disk.

Problem 2:
Cause 2:
Recovery 2:

Cannot create schema and cannot default schema.

Server product not installed on server node.
Newprod the RIS server to the server node.

Problem 3:
Cause 3:
Recovery 3:

Sudden failure to access server on existing or new schema.

One of the protocols is not working.
Verify the server product is installed. Verify that the net
address (netaddr) is listed correctly. Verify that the
clearinghouse (clh) reflects the proper server address.
XNS

5 - 14

Troubleshooting

test visit to server nodename, log in, test visit back to client,
log in.
Test fmu to server.
Verify XNSINGR is installed.
TCP
Verify TCPIP is installed.
Test ping to server.
Test telnet to server nodename, log in, test telnet back to
client, log in.
Test ftp to server.
Check the /etc/services file to ensure there is a ristcpsrv
entry (#180) and that it is correct. Do this on client and
server. Newprod the RIS product to put the entry in the file.
Check the /etc/inetd.conf file to ensure the ristcpsrv entry
is correct. Do this on the client and the server. Newprod the
RIS product to put the entry in the file.
The inet daemon may not have run, do a TCPIP stop and a
TCPIP start commands.
Problem 4:

Cause 4:
Recovery 4:
Problem 5:
Cause 5:
Recovery 5:

Problem 6:

Cause 6:

Recovery 6:

Cannot create a schema with a new database option. This

error is followed by another error: NET-E-READ_ERROR
(0x89cd81da)
I-LICENSE is not loaded.
Load I_LICENSE.
Cannot create a schema using tcp/ip.
The /etc/inetd.conf file has invalid entries before to the
ristcpsr entry.
Move the ristcpsr entry to the first line, or before the invalid
lines. Or, remove, or correct the invalid entries in the file.
Then reboot the system.
Cannot create a schema using tcp/ip on a VAX. Follows with
another error:
NET-E-READ_ERROR (0x89cd81da)
TCP connection has been broken.
The service entry that RIS added to the Process Softwares
database had no explicit quotas for starting up a detached
process. Since it was using defaults, it was not allocating
enough resources for the RIS data server to start up correctly.
On the VAX, use netcu to modify the ris service to include the
following:
/queue_limit = 100
/sub_process_limit = 0
/buffer_limit = 32768
/enqueue_limit = 100
/file_limit = 10
/page_file = 20000

Troubleshooting 5 - 15

Problem 7:

Cause 7:

Recovery 7:
Problem 8:

Cause 8:
Recovery 8:

A TD1 machine (running Windows NT) could not access an

existing schema on a Clipper machine. These additional
messages appeared:
NETWORK ERROR: MESSAGE FILE NOT FOUND FOR
0X89CD81DA
NETWORK READ ERROR.
The TD1 had used the internationalization value set to a
non-English value (Finnish). This meant that RIS was to pass
this information on to the RIS server on the Clipper machine.
The Clipper machine did not have the finnish language set so
RIS errored out. Then came a more serious problem: the RIS
client was able to pick out a message from the default
message file. Since finnish could not be found, it used the
default of english. But, the ris networking sub system did not
use the default and it tried to find the network error message
file for finnish. When it could not, it returned the previous
error about not finding the message file.
Change the international value to U.S. ENGLISH, as all
parts of RIS and the database must use the same language.
A TD1/NT machine could not access an existing schema on a
Clipper machine. These additional messages appeared:
RIS Error: RIS_E_ENV_FILE_UNDERFLOW (0x8a94b36a)
An environment file has too few entries in it.
Same as the previous problem. Only this time the server was
version 4.3.5.x or later.
Change the international value to U.S. ENGLISH, since all
parts of RIS and the database must use the same language.

RIS Error: RIS_E_UNKNOWN_SCHEMA (0x8a94a142)

No such schema was found in the schema file.
Problem:
Cause:

Recovery:

Any access to a schema fails.

The RISSCH_USR table has an entry in it which matches the
one that RIS is trying to add. There is a unique index on this
entry and this is what is actually causing the problem.
Run risclnsrv to clean up the table.

RIS Utility Error: RISUTL_E_LEFT_DELIMITER_MISSING (0x89ce88e2)

Left Delimiter is Missing.
Problem:
Cause:

Recovery:

rislod fails to load a ris.dmp file.

The user modified the first line in the ris.dmp file, so it would
use a different schema or create a different schema. However,
the sed utility has an undocumented line size of 4,000 bytes,
and sed truncates the line without informing the user. Many
ris.dmp files have rows of data that may exceed 4,000 bytes,
so when the sed script is run, it corrupts the ris.dmp file.
Use the risload feature that allows you to load the schema in
the ris.dmp file into an existing schema. The feature is
available when you get the prompt:
Which schemas should be loaded?
all(a)

5 - 16

Troubleshooting

prompted - optionally transfer into existing schema(p) :[a] >

Choose prompted "p" and you will be able to transfer it into
an existing schema without modifying the ris.dmp file.
RIS Utility Error: RISUTL_E_INVALID_NEW_SCH (0x89ce889a)
Invalid New Renamed Schema.
Problem:
Cause:
Recovery:

Error occurs while running risload on an existing schema.

Schema file location was incorrect so RIS didnt see the
schema.
Locate schema file correctly.

Appendix A: RIS and Vendor DBMS Reserved Words A - 1

Appendix A

__________________________________________________________________________________________________________________________________________________

RIS and Vendor DBMS Reserved Words

A-2

Appendix A: RIS and Vendor DBMS Reserved Words

Appendix A: RIS and Vendor DBMS Reserved Words A - 3

Appendix A

__________________________________________________________________________________________________________________________________________________

RIS and Vendor DBMS Reserved Words

This section presents a complete list of RIS and vendor RDBMS reserved words.

A.1 RIS Reserved Words

The following is a table of all RIS reserved keywords.
add
all
alter
and
ansi
any
arch
as
asc
async
authorization
auto
autocommit
autorename
avg
begin
between
blank
buffer
by
char
character
clear
close
commit
completion
connect
const
continue
count
create
current_timestamp
cursor
database
datetime

db2
dbname
dec
decimal
declare
default
define
delete
desc
describe
descriptor
dir
distinct
dnp
double
drop
else
enable
end
endif
env
error
exclude
exclusive
exec
execute
exists
extern
fetch
float
for
force
found
from
full

gateway
go
goto
grant
group
having
host_lu
host_program
ifdef
ifndef
immediate
in
include
index
indicator
informix
ingres
initial
input
insert
int
integer
interval
into
is
like
lock
long
max
min
mode
modify
net_protocol
network
node

A-4

Appendix A: RIS and Vendor DBMS Reserved Words

not
nt
null
off
on
only
open
option
or
oracle
order
os
os400
ostype
osuser
output
partial
password
port
precision
prepare
primary
privilege
privileges
public
rdb
real
redeclare
register
remote
replace
report

resource
response
revoke
ris_blob
ris_lu
ris_text
rollback
schema
secondary
section
secure
select
server
set
share
short
signed
size
smallint
some
sql
sqlcode
sqlda
sqlds
sqlerror
static
strip
struct
sum
superschema
swap
sybase

table
tables
tcp
test
timeout
timestamp
to
tolerance
transaction
undeclare
undef
union
unix
unique
unsigned
unsupported
update
user
using
values
verify
version
view
virtual
vms
volatile
wait
whenever
where
with
work
xns

Appendix A: RIS and Vendor DBMS Reserved Words A - 5

A.2 DB2 Reserved Words

add
all
alter
and
any
as
audit
between
bufferpool
by
cluster
column
count
current
cursor
database
delete
descriptor
distinct
drop
editproc
erase
execute
exists

fieldproc
for
from
go
goto
grant
group
having
immediate
in
index
insert
into
is
key
like
locksize
not
null
numparts
of
on
or
order

part
plan
priqty
privileges
secqty
select
set
some
stogroup
synonym
table
tablespace
to
union
update
user
using
validproc
values
vcat
view
volumes
where
with

A.3 INFORMIX Reserved Words

The INFORMIX database engine does not enforce reserved words. However,
development tools still have reserved words. Therefore using a reserved word
in a column or table name could make those tables inaccessible through the
utilities.
abort
absolute
accept
access
add
after
all
allowing
alter
and
ansi
any
array
as
asc

ascending
ascii
at
attribute
attributes
audit
auto
autonext
average
avg
background
before
begin
beginning
bell

between
black
blanks
blink
blue
bold
border
bottom
buffered
by
byte
call
case
char
character

A-6

Appendix A: RIS and Vendor DBMS Reserved Words

check
clear
clipped
close
cluster
col
color
colors
column
columns
command
comment
comments
commit
committed
composites
compress
connect
constant
constraint
construct
continue
convert
count
create
current
cursor
cyan
database
date
date_type
datetime
day
dba
debug
dec
dec_t
decimal
decimal_type
declare
default
defaults
defer
define
delete
delimiter
delimiters
desc
descending
describe
descriptor

dim
dirty
display
displayonly
distinct
do
dominant
double
down
downshift
drop
dtime
dtime_t
editadd
editupdate
else
end
endif
ending
error
escape
every
exclusive
exec
execute
exists
exit
exitnow
exits
explain
extend
extent
extern
external
false
fetch
field
file
finish
first
fixchar
float
flush
for
foreach
form
format
formonly
found
fraction
free

from
function
globals
go
goto
grant
green
group
having
header
headings
help
hold
hour
identified
if
ifdef
ifndef
immediate
in
include
index
indicator
infield
info
initialize
input
insert
instructions
int
integer
interrupt
intersect
interval
into
intrvl_t
inverse
invisible
is
isam
isolation
join
joining
key
lable
last
left
len
length
let
like

Appendix A: RIS and Vendor DBMS Reserved Words A - 7

line
lineno
lines
load
loc_t
locator
lock
log
long
long_float
long_integer
lookup
loop
magenta
main
margin
master
matches
max
mdy
memory
menu
message
min
minus
minute
mod
mode
modify
module
money
month
name
natural
need
new
next
nextfield
no
nocr
noentry
normal
not
notfound
noupdate
now
null
numeric
of
off
on

open
option
options
or
order
otherwise
out
outer
output
package
page
pageno
param
pause
percent
perform
picture
pipe
positive
precision
prepare
previous
print
printer
prior
privilege
privileges
program
prompt
public
put
query
queryclear
quit
raise
range
read
readonly
real
record
recover
red
register
relative
remove
rename
repair
repeatable
report
required
resource

return
returning
reverse
revoke
right
rollback
rollforward
row
rowid
rows
run
savepoint
screen
scroll
second
section
select
serial
serial_type
set
share
shift
short
short_float
short_integer
sitename
size
skip
sleep
smallfloat
smallint
some
space
spaces
sql
sqlca
sqlchar_type
sqlda
sqldecimal_type
sqlerr
sqlerror
sqlfloat_type
sqlint_type
sqlmoney_type
sqlsmfloat_type
sqlsmint_type
sqlwarning
stability
start
startlog
static

A-8

Appendix A: RIS and Vendor DBMS Reserved Words

statistics
status
stdv
step
stop
string
struct
subtract
subtype
sum
synonym
systables
table
temp
text
then
through
thru
time
tiny_integer
to
today
top

total
trailer
trailing
true
type
typedef
undef
underline
union
unique
units
unload
unlock
up
update
upshift
user
using
validate
values
varchar
variable

vc_t
verify
view
wait
waiting
warning
weekday
when
whenever
where
while
white
window
with
without
wordwrap
work
wrap
year
yellow
yes
zerofill

Appendix A: RIS and Vendor DBMS Reserved Words A - 9

A.4 ORACLE Reserved Words

access
add
admin
after
all
allocate
alter
analyze
and
any
archive
archivelog
as
asc
audit
authorization
avg
backup
become
before
begin
between
body
by
cache
cancel
cascade
change
char
character
check
checkpoint
close
cluster
cobol
column
comment
commit
compile
compress
connect
constraint
constraints
contents
continue
controlfile
count
crash
create

current
cursor
cycle
database
datafile
date
dba
dec
decimal
declare
default
delete
desc
disable
dismount
distinct
double
drop
dump
each
else
enable
end
escape
events
except
exceptions
exclusive
exec
execute
exists
explain
extent
externally
fetch
file
float
flush
for
force
foreign
fortran
found
freelist
freelists
from
function
go
goto

grant
graphic
group
groups
having
identified
if
immediate
in
including
increment
index
indicator
initial
initrans
insert
instance
int
integer
intersect
into
is
key
language
layer
level
like
link
lists
lock
logfile
long
manage
manual
max
maxdatafiles
maxextents
maxinstances
maxlogfiles
maxloghistory
maxlogmembers
maxtrans
maxvalue
min
minextents
minus
minvalue
mode
modify

A - 10

Appendix A: RIS and Vendor DBMS Reserved Words

module
mount
new
next
noarchivelog
noaudit
nocache
nocompress
nocycle
nomaxvalue
nominvalue
none
noorder
noresetlogs
normal
nosort
not
nowait
null
number
numeric
of
off
offline
old
on
online
only
open
optimal
option
or
order
own
package
parallel
pascal
pctfree
pctincrease
pctused
pl1
pli
plan
precision
primary
prior
private

privileges
procedure
profile
public
raw
read
real
recover
references
referencing
release
rename
resetlogs
resource
restricted
reuse
revoke
role
roles
rollback
row
rowid
rowlabel
rownum
rows
savepoint
schema
scn
section
segment
select
sequence
session
set
share
shared
size
smallint
snapshot
some
sort
specified
sql
sqlcode
sqlerror
start

statement
statement_id
statistics
stop
storage
successful
sum
switch
synonym
sysdate
system
table
tables
tablespace
temporary
then
thread
time
to
tracing
transaction
trigger
triggers
truncate
uid
under
unlimited
union
unique
until
update
use
user
using
validate
values
varchar
varchar2
vargraphic
view
when
whenever
where
with
work
write

Appendix A: RIS and Vendor DBMS Reserved Words A - 11

A.5 SYBASE Reserved Words

$channel
$curfield
$curform
$curgroup
$curpick
$date
$index
$status
abort
add
all
alter
and
any
append
apt
as
asc
at
avg
backtab
begin
between
binary
bit
break
browse
bulk
by
call
callextern
callform
callreport
cancelform
case
channel
char
charindex
checkpoint
closesql
clustered
commit
compute
confirm
connect
continue
controlrow
convert
count

create
curindex
cursqlindex
database
datalength
datename
datepart
datetime
dbcc
declare
default
define
delete
desc
disconnect
disk
distinct
drop
dummy
dump
else
end
enter
entry
errlvl
errorexit
except
exec
execute
exists
exit
exitform
exp
false
fetchsql
field
fillfactor
float
for
foreach
form
from
goto
grant
group
having
hidden
holdlock
if

image
in
index
insert
int
interruptsql
intersect
into
is
kill
like
lineno
list
load
log
lower
max
mchoice
menu
menubar
min
mirrorexit
money
nextquery
nomsg
nonclustered
not
null
off
offset
on
once
opensql
or
order
over
parentname
perform
perm
permanent
plan
positionform
post
prepare
print
printform
proc
procedure
processexit

A - 12

Appendix A: RIS and Vendor DBMS Reserved Words

public
raiserror
rchoice
readtext
reconfigure
reset
return
revoke
rollback
rowcount
rule
save
schoice
scroll
select
set
setuser
shared
shutdown
smallint
sqlbegin
sqlend

sqlexpr
sqlrow
statistics
submit
substring
sum
switch
switchend
syb_terminate
system
tab
table
tape
temp
temporary
text
textport
textsize
tinyint
to
trace
tran

transaction
transfer
trigger
trim
true
truncate
tsequal
union
unique
update
upper
use
useform
values
variable
view
waitfor
where
while
with
writetext

A.6 Microsoft SQL Reserved Words

add
all
alter
and
any
arith_overflow
as
asc
at
authorization
avg
backtab
backtab
begin
between
break
browse
bulk
by
cascade
char_convert
check
checkpoint
close

clustered
commit
compute
confirm
constraint
continue
controlrow
convert
count
create
current
cursor
data_pgs
database
dbcc
deallocate
declare
default
delete
desc
disk
distinct
double
drop

dummy
dump
else
end
endtran
errlvl
errorexit
escape
except
exec
execute
exists
exit
fetch
fillfactor
for
foreign
from
goto
grant
group
having
holdlock
identity

Appendix A: RIS and Vendor DBMS Reserved Words A - 13

identity_insert
if
in
index
insert
intersect
into
is
isolation
key
kill
level
like
lineno
load
max
min
mirror
mirrorexit
national
noholdlock
nonclustered
not
null
numeric_transaction
of
off
offsets
on
only
open
option
or
order

over
perm
permanent
plan
precision
prepare
primary
print
privileges
proc
procedure
processexit
public
raiserror
read
readtext
reconfigure
references
replace
reserved_pgs
return
revoke
role
rollback
rowcnt
rowcount
rows
rule
save
schema
select
set
setuser

shared
shutdown
some
statistics
stripe
sum
syb_identity
syb_restree
table
temp
temporary
textsize
to
tran
transaction
trigger
truncate
tsequal
union
unique
update
user
user_option
using
values
varying
view
waitfor
where
while
with
work
writetext

A - 14

Appendix A: RIS and Vendor DBMS Reserved Words

Appendix B: RIS Data Types B - 1

Appendix B

__________________________________________________________________________________________________________________________________________________

RIS Data Types

B-2

Appendix B: RIS Data Types

Appendix B: RIS Data Types B - 3

Appendix B

__________________________________________________________________________________________________________________________________________________

RIS Data Types

This appendix presents the SQL data types supported by RIS, the corresponding SQL code,
and a description of each.
SQL string

SQL code

Description

char[acter](n)

CHARACTER

Stores a maximum of 240 characters. The

characters that can be stored are determined
by the underlying database.

int[eger]

INTEGER

Stores an integer in the range -2,147,483,648

to 2,147,483,647.

smallint

SMALLINT

Stores an integer value in the range -32,768 to

32,767.

double [precision]

DOUBLE

Stores a real number (one that may contain a

fractional unit) in double precision floating
point format.

real

REAL

Stores a real number (one that may contain a

fractional unit) in single precision floating
point format.

decimal[(p[, s])]

DECIMAL

Stores a fixed point decimal number with

optional precision and scale. Maximum
precision is 15. The scale must be less than
the precision. The default precision is 8 and
the default scale is 0.

timestamp

TIMESTAMP

Stores a timestamp consisting of year, month,

day, hour, minute, second. A timestamp
literal must be specified with the syntax:
timestamp yyyy-mm-dd:hh:mm:ss or
current_timestamp.

ris_blob(n)

RIS_BLOB

Stores up to 2 gigabytes of binary data. The

size in bytes can be specified in parentheses
after the keyword. The default is vendor
specific. The ris_blob data is not interpreted.
Only ORACLE and INFORMIX OnLine
support RIS_BLOB.

B-4

Appendix B: RIS Data Types

ris_text(n)

RIS_TEXT

Stores up to 2 gigabytes of variable length

character data. The size in bytes can be
specified in parentheses after the keyword.
The default is vendor specific. The ris_text
data is interpreted by RIS when moving
between different systems. Only ORACLE
and INFORMIX OnLine support RIS_BLOB.

The SQL string is used within SQL statements where a data type is required (for example:
in the create table statement).
The following examples illustrate the use of the SQL code form of the timestamp.
select * from table1 where
timecolumn > timestamp 1994-04-01:00:00:00;
update table1 set (time.column)=current_timestamp;

The SQL code is used in the sqltype field in the dynamic sqlvar structure.

RIS null-terminates strings of character data only if there is sufficient space in

the character data buffer.

Appendix C: RIS Dictionary Views C - 1

Appendix C

__________________________________________________________________________________________________________________________________________________

RIS Dictionary Views

C-2

Appendix C: RIS Dictionary Views

Appendix C: RIS Dictionary Views C - 3

Appendix C

__________________________________________________________________________________________________________________________________________________

RIS Dictionary Views

This section documents the Version 5 RIS dictionary views. For compatibility
with applications based on RIS Version 4, the Version 5 RIS dictionary also
contains Version 4 views. However, these views are not available from a
Version 5 application or in a schema that uses Version 5 capabilities (secure
schema, shared dictionary). An upgrade utility is provided to upgrade a Version
4 dictionary to Version 5. Refer to the section RIS V5 Schema and Dictionary
Converter.
RIS provides a set of tables and views that catalog all information about objects in the
schema. These tables and views are collectively referred to as the RIS data dictionary and
can be used in the same manner as the data dictionary or system catalog of the underlying
database system.
This section describes the dictionary views created and maintained by RIS.
Case Rule 1
___________
One of the column headings describing the tables and views is Case. The valid entries for
this column are UPPER, lower, as DBMS, N/A, as input, either, and Rule 1. Rule 1 is the
following:
If the underlying DBMS is case sensitive, the column is in the case that the string was given
to RIS (either by the application or the DBMS). If the database is not case sensitive, then
the column is maintained in the case used by the DBMS. For example, the DB2 username is
stored in UPPER case. For Informix, the username provided by the application (in the SQL
statement) is stored as is.
Do not change the values in the RIS dictionary tables. This can cause internal RIS
errors and unpredictable or inconsistent results.
The views described in this section are based on internal RIS dictionary tables which
are not intended for application access and hence are not documented.

C-4

Appendix C: RIS Dictionary Views

C.1

__________________________________________________________________________________________________________________________________________________

RIS-Supported Dictionary Views

Supported dictionary tables and views are provided for general use. Items in this class all
have names of the form RIS*. The tables and views are listed in alphabetical order.

C.1.1

RIS5COLUMN_PRIVS

This view lists all privileges granted on the columns in the tables and views of a schema.

Column

Type

Description

Case

schema_name
table_name
upper_table_name
column_name
upper_column_name
grantor
grantee
ris_privileges
ris_object

char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(7)
char(1)

not null
not null
not null
not null
not null
not null
not null
not null
not null

lower
lower
UPPER
lower
UPPER
lower
lower (or PUBLIC)
either
UPPER

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

table_name

This is the name of the table for which privileges exist.

upper_table_name

This is the name of the table for which privileges exist.

column_name

This is the name of the column for which privileges exist.

upper_column_name

This is the name of the column for which privileges exist.

grantor

This is the name of the schema that granted the privileges.

grantee

This is the name of the schema to which the privileges have

been granted, or PUBLIC.

Appendix C: RIS Dictionary Views C - 5

ris_privileges

A 7-character string indicating privileges. Each character

position indicates a specific privilege or lack thereof.
position 1:
position 2:
position 3:
position 4:
position 5:
position 6:
position 7:

select privilege s, S, or insert privilege i, I, or delete privilege d, D, or update privilege u, U, or reserved

reserved
reserved

A lowercase character indicates the schema has the

privilege. An uppercase character indicates the schema has
the privilege and can grant it to others. A dash (-) indicates
that the schema does not have the privilege.
ris_object

C.1.2

Y for a RIS dictionary object, or N for a user/application

object. To see only the application objects, use the condition,
ris_object=N

RIS5COLUMNS

This view contains all information known about the columns in the tables and views of a
schema. It does not include information about any RIS dictionary table or view.
The columns of tables and views maintained by RIS have two names: the internal or RIS
name and the external or DBMS name. Columns can be renamed using the extern clause in
the create table/view statement and the as clause in the include table/view statement. In
the view below, column_name refers to the RIS (internal) name and ext_column_name refers
to the DBMS (external) name.

Column

Type

Description

Case

schema_name
table_name
upper_table_name
column_name
ext_column_name
upper_column_name
position
ris_type
ris_type_string
dbms_type_string
char_max_length
prec
scale
nullable
ris_object

char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
integer
integer
char(11)
char(31)
integer
integer
integer
char(3)
char(1)

not null
not null
not null
not null
not null
not null
not null
not null
not null
not null

lower
lower
UPPER
lower
As DBMS
UPPER
N/A
N/A
lower
lower
N/A
N/A
N/A
lower
UPPER

not null
not null

C-6

Appendix C: RIS Dictionary Views

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

table_name

The name of the table/view.

upper_table_name

The name of the table/view.

column_name

The name of the column.

ext_column_name

The name of the column in the underlying DBMS.

upper_column_name

The name of the column.

position

The position of the column in the table (1,2,3,...). This is the

order in which the columns appear in a select * from <table>.

ris_type

The columns RIS data type represented as an integer.

Data type CHARACTER is represented by 1
Data type DECIMAL is represented by 3
Data type INTEGER is represented by 4
Data type SMALLINT is represented by 5
Data type REAL is represented by 7
Data type DOUBLE is represented by 8
Data type TIMESTAMP is represented by 9
Data type UNSUPPORTED is represented by 14
Data type RIS_BLOB is represented by 15
Data type RIS_TEXT is represented by 16

ris_type_string

The columns RIS data type represented as a character

string.
Data type CHARACTER is represented by char
Data type DECIMAL is represented by decimal
Data type INTEGER is represented by integer
Data type SMALLINT is represented by smallint
Data type REAL is represented by real
Data type DOUBLE is represented by double
Data type TIMESTAMP is represented by timestamp
Data type UNSUPPORTED is represented by unsupported
Data type RIS_BLOB is represented by ris_blob
Data type RIS_TEXT is represented by ris_text

dbms_type_string

The columns underlying RDBMS data type as interpreted

by RIS. This indicates how RIS views the column, and is
database dependent.

Appendix C: RIS Dictionary Views C - 7

char_max_length

For columns of type CHARACTER, this is the maximum

length. (For a char(14) column, char_max_length is 14.)
For columns of all other types, this is NULL.

prec

For columns of type DECIMAL, this is the precision. (For a

decimal(x,y) column, prec is x.) For columns of all other
types, this is NULL.

scale

For columns of type DECIMAL, this is the scale. (For a

decimal(x,y) column, scale is y.) For columns of all other
types, this is NULL.

nullable

This is YES if the column can be null, or NO if nulls are not

permitted.

ris_object

Y for a RIS dictionary object, or N for a user/application

object. To see only the application objects, use the condition,
ris_object=N

C.1.3

RIS5DBMS_COLUMNS

This view lists the owner of the database and the columns of all the tables and views in the
database including the RIS tables and views. In some cases, this list may include only those
tables and views accessible to the current log-in/user of the database.
Some databases do not let privileges be granted on views defined on system
catalogs (this is such a view). As a result, this view may be accessible only to
the dictionary owner.
This view is not recommended for use by the applications. This is provided for use by
the Schema Manager only. If used at all, the query should have some restrictive
condition. A select * statement from this view can lead to a significant
performance degradation. For example, the Schema Manager queries this view for a
specific table/owner combination.

Column

Type

Description

Case

table_name
dbms_owner
column_name
position

char(31)
char(31)
char(31)
integer

not null
not null
not null
not null

As DBMS
As DBMS
As DBMS
N/A

The Type may vary depending on the database.

C-8

Appendix C: RIS Dictionary Views

table_name

This is the name of the table/view. It comes directly from

the underlying database system.

dbms_owner

The owner of the table/view in the underlying database.

column_name

This is the name of the column.

position

The position of the column in the table (1,2,3,...). This is the

order in which the columns appear in a select * from table.

C.1.4

RIS5DBMS_INDEXES

This view lists the owner of the database and all the indexes in the underlying database,
except the RIS dictionary indexes. In some cases, this list may include only those indexes
accessible to the current log-in/user of the database.
Some databases do not let privileges be granted on views defined on system
catalogs (this is such a view). As a result, this view may be accessible only to
the dictionary owner.
This view is not recommended for use by the applications. This is provided for use by
the Schema Manager only. If used at all, the query should have some restrictive
condition. A select * statement from this view can lead to a significant
performance degradation.

Column

Type

Description

Case

table_name
dbms_owner
index_name

char(31)
char(31)
char(31)

not null
not null
not null

As DBMS
As DBMS
As DBMS

The Type may vary depending on the database.

table_name

This is the name of the table. This comes directly from the
underlying database system. It may be in uppercase or
lowercase, depending on how the underlying RDBMS stores
the information.

dbms_owner

Owner of the index in the underlying database.

index_name

This is the name of the index.

Appendix C: RIS Dictionary Views C - 9

C.1.5

RIS5DBMS_TABLES

This view lists the user that owns the database and all the table names in the underlying
database, except the RIS dictionary tables.
Some databases do not let privileges be granted on views defined on system
catalogs (this is such a view). As a result, this view may be accessible only to
the dictionary owner.
This view is not recommended for use by the applications. This is provided for use by
the Schema Manager only. If used at all, the query should have some restrictive
condition. A select * statement from this view can lead to a significant
performance degradation.

Column

Type

Description

Case

table_name
dbms_owner

char(31)
char(31)

not null
not null

As DBMS
As DBMS

The Type may vary depending on the database.

table_name

This is the name of the table. This comes directly from the
underlying database system. It may be in uppercase or
lowercase, depending on how the underlying RDBMS stores
the information.

dbms_owner

Owner of the table in the underlying database.

C.1.6

RIS5DBMS_USERS

This view lists all the users in the underlying database. In some databases, such as Sybase,
the user XYZ who logs in to the database system can have an alias ABC on a database. This
users objects are referred to as ABC.t1 and not XYZ.t1. However, if XYZ is the owner of the
database, all the objects are referred to as dbo.t1, dbo.t2, etc.
Some databases do not let privileges be granted on views defined on system
catalogs (this is such a view). As a result, this view may be accessible only to
the dictionary owner.
This view is not recommended for use by the applications. This is provided for use by
the Schema Manager only.

C - 10

Appendix C: RIS Dictionary Views

Column

Type

Description

Case

user_name
dbms_owner

char(31)
char(31)

not null
not null

As DBMS
As DBMS

The Type may vary depending on the database.

user_name

This is the name of a database user. It comes directly from

the underlying database system. This is the name by which
a user connects to the system

dbms_owner

This is also the name of a database user. This comes from

the underlying database system. This is the name that
would be used as a table/view/index owner.

C.1.7

RIS5DBMS_VIEWS

This view lists the owner of the underlying database and all the view names in the
underlying database, except the RIS dictionary views. In some cases, this list may include
only those views accessible to the current log-in/user of the database.
Some databases do not let privileges be granted on views defined on system
catalogs (this is such a view). As a result, this view may be accessible only to
the dictionary owner.
This view is not recommended for use by the applications. This is provided for use by
the Schema Manager only. If used at all, the query should have some restrictive
condition. A select * statement from this view can lead to a significant
performance degradation.

Column

Type

Description

Case

view_name
dbms_owner

char(31)
char(31)

not null
not null

As DBMS
As DBMS

view_name

This is the name of the view. This comes directly from the
underlying database system. It may be in uppercase or
lowercase, depending on how the underlying RDBMS stores
the information.

dbms_owner

Owner of the view in the underlying database.

Appendix C: RIS Dictionary Views C - 11

C.1.8

RIS5DBS

This view is a relational representation of the database information in the schema file. The
data in this table is transient and is not available for access through database-specific
utilities.
The data required for a database definition varies widely from one database system to
another. In order to make the information available, this table includes several generic
columns where the meaning differs depending on the database type for the record.

Column

Type

Description

Case

database_id
database_type
database_name
protocol_1
net_address_1
protocol_2
net_address_2
protocol_3
net_address_3
protocol_4
net_address_4
long_parameter_1
long_parameter_2
long_parameter_3
short_parameter_1
short_parameter_2
short_parameter_3
short_parameter_4
short_parameter_5
short_parameter_6
short_parameter_7
short_parameter_8
srvid

smallint
char(1)
char(240)
char(1)
char(28)
char(1)
char(28)
char(1)
char(28)
char(1)
char(28)
char(240)
char(240)
char(240)
char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
integer

not null
not null
not null

N/A
UPPER
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
lower
N/A

not null

database_id

This is the database identification number (arbitrary).

database_type

This is the database type:

For DB2 the value is D
For ORACLE the value is O
For INFORMIX the value is X
For SYBASE the value is Y
For MSSQL the value is M

C - 12

Appendix C: RIS Dictionary Views

database_name

This is RDBMS-specific information used to identify a

particular database:
For DB2 this is the database name
For ORACLE this is the system identifier (SID) or SQL*Net
alias/identification string
For INFORMIX this is the database name
For INFORMIX-Net/Star this is the identification string

protocol_1

This is a communication protocol the RIS client can use to

communicate with the RIS data server. The possible values
are:
For TCP/IP the value is T
(NULL)

net_address_1

This is the network address of the platform on which the

RIS data server resides. Its format is appropriate for the
network protocol in protocol_1.

protocol_2

Same as protocol_1 for an alternate protocol.

net_address_2

Same as net_address_1 for an alternate protocol.

protocol_3

Same as protocol_1 for an alternate protocol.

net_address_3

Same as net_address_1 for an alternate protocol.

protocol_4

Same as protocol_1 for an alternate protocol.

net_address_4

Same as net_address_1 for an alternate protocol.

long_parameter_1

This usually holds the directory value used in schema

creation, and generally indicates the location of the database
system.
For INFORMIX the value is INFORMIXDIR
For ORACLE the value is ORACLE_HOME
For DB2 the value is not used
For SYBASE the value is not used
For MSSQL the value is not used

long_parameter_2

This is completely database specific.

For INFORMIX the value is SQLEXEC
For ORACLE the value is not used
For SYBASE the value is not used
For MSSQL the value is not used
For DB2 the value is not used

Appendix C: RIS Dictionary Views C - 13

long_parameter_3

This is completely database specific.

For INFORMIX the value is DBTEMP
For ORACLE the value is not used
For SYBASE the value is not used
For MSSQL the value is not used
For DB2 the value is not used

short_parameter_1

This is completely database specific.

For INFORMIX the value is TBCONFIG
For ORACLE the value is the database system identifier
(ORACLE_SID)
For DB2 the value is the architecture name
For SYBASE the value is not used
For MSSQL the value is not used

short_parameter_2

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For DB2 the value is the operating system name
For SYBASE the value is not used
For MSSQL the value is not used

short_parameter_3

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For SYBASE the value is not used
For MSSQL the value is not used
For DB2 the value is the environment name

short_parameter_4

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For DB2 the value is the Intergraph/IBM network protocol
For SYBASE the value is not used
For MSSQL the value is not used

short_parameter_5

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For DB2 the value is the host program name
For SYBASE the value is not used
For MSSQL the value is not used

C - 14

Appendix C: RIS Dictionary Views

short_parameter_6

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For DB2 the value is the RIS LU
For SYBASE the value is not used
For MSSQL the value is not used

short_parameter_7

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For DB2 the value is the host LU
For SYBASE the value is not used
For MSSQL the value is not used

short_parameter_8

This is completely database specific.

For INFORMIX the value is not used
For ORACLE the value is not used
For DB2 the value is the mode
For SYBASE the value is not used
For MSSQL the value is not used

srvid

C.1.9

The process-id of the RIS data server being used.

RIS5INDEX_COLUMNS

This view lists columns that are indexed, along with the name of the index and the table on
which it exists. It excludes columns of tables and views of the RIS dictionary.

Column

Type

Description

Case

schema_name
index_name
upper_index_name
table_name
upper_table_name
column_name
upper_column_name
position

char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
integer

not null
not null
not null
not null
not null
not null
not null
not null

lower
lower
UPPER
lower
UPPER
lower
UPPER
N/A

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

Appendix C: RIS Dictionary Views C - 15

index_name

This is the name of the index.

upper_index_name

This is the name of the index.

table_name

This is the name of the table.

upper_table_name

This is the name of the table.

column_name

This is the name of the column in the index.

upper_column_name

This is the name of the column in the index.

position

The position of the column in the table (1,2,3,...). This is the

order in which the columns appear in a select * from table.

C.1.10 RIS5INDEXES
This view lists all indexes known to RIS, excluding those on RIS dictionary tables and views.
The indexes maintained by RIS have two names: the internal or RIS name and the external
or DBMS name. In the following view, index_name refers to the RIS (internal) name and
ext_index_name refers to the DBMS (external) name.
Most RDBMS vendors let two indexes with the same name owned by different users. The
dbms_owner is the owner of the index in the underlying database. While the index_name is
unique within the schema, the combination of dbms_owner and ext_index_name is unique
within the database.

Column

Type

Description

Case

schema_name
index_name
dbms_owner
ext_index_name
upper_index_name
table_name
upper_table_name
index_type

char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(31)
char(1)

not null
not null
not null
not null
not null
not null
not null
not null

lower
lower
As DBMS
As DBMS
UPPER
lower
UPPER
UPPER

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

index_name

This is the name of the index.

dbms_owner

Owner of the index in the underlying database system.

C - 16

Appendix C: RIS Dictionary Views

ext_index_name

This is the name of the index in the underlying database

system.

upper_index_name

This is the name of the index.

table_name

This is the name of the table.

upper_table_name

This is the name of the table.

index_type

U for unique or D for duplicate.

C.1.11 RIS5SCHEMAS
This view is a relational representation of the schema information in the schema file. The
data in this table is transient and is not available through database-specific utilities.

Column

Type

Description

Case

schema_name
schema_owner
database_id
schema_type
dictionary_owner
srvid

char(31)
char(31)
smallint
smallint
char(31)
integer

not null
not null
not null
not null
not null
not null

lower
As input
N/A
N/A
As input
N/A

schema_name

This is the schema name.

schema_owner

This is the schema owner/administrator. (The databasespecific log-in that owns the schema.) For standard
schemas, this is the log-in that will be used for connecting to
the database.

database_id

This is the database identification number (arbitrary).

schema_type

0 for standard schema, or 1 for secure schema.

dictionary_owner

The dictionary owner is the owner of the RIS tables and

views that maintain information about the schema. When
the dictionary is not shared, the schema owner and the
dictionary owner are usually the same person. This value
comes directly from the underlying database.

srvid

The process-id of the RIS data server being used.

Appendix C: RIS Dictionary Views C - 17

C.1.12 RIS5SCHPRIV
This view lists all the users who have the privilege to create a schema using the dictionary in
which the schema (that is being queried) resides. The user_privilege is D for the dictionary
administrator and S for others.

Column

Type

Description

Case

user_name
user_privilege

char(31)
char(1)

not null
not null

Rule 1
UPPER

user_name

This is the name of a RIS user. This comes directly from the
underlying database system. It may be in uppercase or
lowercase, depending on how the underlying RDBMS stores
the information.

user_privilege

This is the user privilege. The valid values are:

D - Dictionary administration privilege
S - Schema administration privilege

C.1.13 RIS5TABLE_PRIVS
This view lists all privileges granted on tables and views in the schema. It does not include
column privileges.

Column

Type

Description

Case

schema_name
table_name
upper_table_name
grantor
grantee
ris_privileges
ris_object

char(31)
char(31)
char(31)
char(31)
char(31)
char(7)
char(1)

not null
not null
not null
not null
not null
not null
not null

lower
lower
UPPER
lower
lower (or PUBLIC)
either
UPPER

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

table_name

This is the name of the table.

C - 18

Appendix C: RIS Dictionary Views

upper_table_name

This is the name of the table.

grantor

This is the schema that granted the privileges.

grantee

This is the name of the schema to which the privileges were

granted, or PUBLIC.

ris_privileges

A 7-character string indicating privileges. Each character

position indicates a specific privilege or lack thereof.
position 1:
position 2:
position 3:
position 4:
position 5:
position 6:
position 7:

select privilege s, S, or insert privilege i, I, or delete privilege d, D, or update privilege u, U, or reserved

reserved
reserved

A lowercase character indicates the schema has the

privilege. An uppercase character indicates the schema has
the privilege and can grant it to others. A dash (-) indicates
that the schema doses not have the privilege.
ris_object

Y for a RIS dictionary object, or N for a user/application

object. To see only the application objects, use the condition,
ris_object=N

C.1.14 RIS5TABLES
This view lists all tables and views included in the schema. (The base tables of the RIS
dictionary are not included in this list.)
The tables/views maintained by RIS have two names: the internal or RIS name and the
external or DBMS name. In the following view, table_name refers to the RIS (internal) name
and ext_table_name refers to the DBMS (external) name.
Most RDBMS vendors let two tables/views with the same name owned by different users.
The dbms_owner is the owner of the table/view in the underlying database. While the table
name is unique within the schema, the combination of dbms_owner and ext_table_name is
unique within the database.
A view is also a table in the context of RIS5TABLES, RIS5COLUMNS,
RIS5TABLE_PRIVS, and RIS5COLUMN_PRIVS.

Appendix C: RIS Dictionary Views C - 19

Column

Type

Description

Case

schema_name
table_name
dbms_owner
ext_table_name
upper_table_name
table_type
date_entered
date_modified
ris_object

char(31)
char(31)
char(31)
char(31)
char(31)
char(1)
timestamp
timestamp
char(1)

not null
not null
not null
not null
not null
not null
not null
not null
not null

lower
lower
As DBMS
As DBMS
UPPER
UPPER
N/A
N/A
UPPER

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

table_name

This is the name of the table.

dbms_owner

Owner of the table/view in the underlying DBMS.

ext_table_name

This is the table name as in the underlying DBMS.

upper_table_name

This is the name of the table.

table_type

T if it is a table, and V if it is a view.

date_entered

The date when the table was first created or included in the
schema.

date_modified

The date when the table definition was last modified with
the alter table add <col> statement.

ris_object

Y for a RIS dictionary object, or N for a user/application

object. To see only the application objects, use the condition,
ris_object=N

C.1.15 RIS5USERS
(This view returns nothing for a standard schema.) This view lists all the RIS users in a
secure (multiuser) schema.

Column

Type

Description

Case

schema_name
user_name
user_privilege

char(31)
char(31)
char(1)

not null
not null
not null

lower
Rule 1
UPPER

C - 20

Appendix C: RIS Dictionary Views

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

user_name

This is the name of a RIS user. This comes directly from the
underlying database system. It may be in uppercase or
lowercase, depending on how the underlying RDBMS stores
the information.

user_privilege

This is the user privilege. The valid values are:

D - Dictionary administration privilege
S - Schema administration privilege
R - Resource privilege
C - Connect privilege

C.1.16 RIS5VIEWS
This view lists all information known about views owned by the schema (excluding the RIS
dictionary views). The "create view" strings can be quite long, so there is usually multiple
records for each view. Each record has just one piece of the string.
The dbms_owner and the ext_view_name have the same meaning as RIS5TABLES. Since a
view is also a table, this information is also in RIS5TABLES. They are shown in this view
for convenience.

Column

Type

Description

Case

schema_name
view_name
dbms_owner
ext_view_name
upper_view_name
ris_view_def
dbms_view_def
sequence_id

char(31)
char(31)
char(31)
char(31)
char(31)
char(64)
char(64)
integer

not null
not null
not null
not null
not null

lower
lower
As DBMS
As DBMS
UPPER
lower
lower
N/A

not null

schema_name

Schema_name is always set to the schema that is queried.

It is set to the schema that qualifies the view name or the
default schema, if there is no qualifier.

view_name

This is the name of the view.

dbms_owner

Owner of the view in the underlying DBMS.

Appendix C: RIS Dictionary Views C - 21

ext_view_name

This is the view name in the underlying DBMS.

upper_view_name

This is the name of the view.

ris_view_def

One piece of the original RIS create view string.

dbms_view_def

One piece of the create view as stored by the underlying

RDBMS.

sequence_id

A number that indicates the order of the string pieces

(0,1,2,...). Each view restarts the sequence.

C - 22

Appendix C: RIS Dictionary Views

C.2

__________________________________________________________________________________________________________________________________________________

RIS V5 Schema and Dictionary Converter

This utility converts Version 4.n schemas and dictionary tables to version 5.X. Database
information remains the same.
This utility runs on UNIX and NT operating systems. It is a command line interface with no
GUI.
Several changes were made to the Version 5 schema file and Version 5 data dictionary. To
receive full Version 5 functionality, it is necessary to convert Version 4.n schemas and
dictionary tables to Version 5.0. This utility provides a simpler upgrade than using standard
RIS facilities. In the absence of this utility, the customer would have to perform the
following steps:
Before the upgrade, perform risunload of the schemas.
Upgrade the RIS software.
Edit the schema file to add the required new information.
Perform risload of each of the schemas.
Instead key in:
risupgrd

Command line options are:

-g
-s <schemalist>

Logging information (debug mode). The log file is risapp.out

in the C:\TMP directory.
List of schemas that need to be upgraded. Enclose the list
in double quotation marks and separate schema names with
blanks ("sch1 sch2"). If there is a password on a schema,
append a period (.) and the password to the schema name
(sch1.sch1pass). A single schema name requires no
quotation marks. If the schema list is not given, the utility
prompts for each schema from the schema file before the
schema is upgraded. If the schema listed in the schema list
is not in the schema file, the utility displays a message
about this fact and continues with the next schema.

In the absence of any of the previous options, the utility uses the current schema file and
upgrades all the schemas. If a specific schema can not be converted, the utility writes this
schema to the V4 format schema file (the copy), displays a message about the action taken
and continues with the next schema.

Appendix C: RIS Dictionary Views C - 23

Schema information in the schema files has the following new entries:
SERVER_VERSION
SECURE
DICTOWNER
For example, for a schema named sch1, schema entries in a Version 4 schema are:
SCHNAME=sch1
USER=rc01
USRPASS=
BEGIN_GRANTEES
END_GRANTEES
DBID=13
The corresponding Version 5 schema entries are:

SCHNAME=sch1
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=rc01
SCHOWNER=rc01
SCHOWNPASS=
BEGIN_GRANTEES
END_GRANTEES
DBID=13
When a schema file is specified, the utility copies and renames the V4 schema file so that the
Version 4 client can continue to use the file. After the utility is run, the original schema file
and the Version 5 schema file contain the same entries except that the Version 5 schema file
contains 3 new items per schema.
Environments using both Version 4 and Version 5 clients have to take care to specify
the correct schema file name with the locate schema file command. Version 4 clients
cannot use Version 5 schema files and Version 5 clients cannot use Version 4 schema
files.
The upgrade utility does not provide a way to convert Version 4.n schemas to
SECURE schemas. This can be done with an alter schema statement.
Examples
_________
This example turns debug mode on and uses the current schema file.
risupgrd -g

This example turns debug mode on and lists two schemas.

risupgrd -g -s "sch1 sch2"

C - 24

Appendix C: RIS Dictionary Views

This example turns debug mode on and lists two schemas and their passwords.
risupgrd -g -s "sch1.sch1pass sch2.sch2pass"

This example lists a single schema. The double quotations are unnecessary.
risupgrd -s sch1

This example uses the current schema file.

risupgrd

Appendix D: Vendor-Specific Information D - 1

Appendix D

__________________________________________________________________________________________________________________________________________________

Vendor-Specific Information

D-2

Appendix D: Vendor-Specific Information

Appendix D: Vendor-Specific Information D - 3

Appendix D

__________________________________________________________________________________________________________________________________________________

Vendor-Specific Information
This section contains information on vendor-specific data types.

D.1 General Notes on Data Types

Database systems exceed the scope of ANSI SQL data types. Thus, cases occur where the
mapping between a database-specific data type and a standard data type is not accurate.
Several database-specific data types appear as unsupported in RIS. This indicates that RIS
cannot interpret the column as one of the standard data types in a reliable manner, and that
using such a column requires extreme caution.
The current implementation of RIS allows for limited use of unsupported data types. One
mechanism, useful for experimentation but very risky in a production environment, is to
explicitly declare the table or view while preventing RIS from checking for data types. This
can be done by using the set mode verify off statement in conjunction with declare
table or declare view statements. It is imperative that the MAX_TABLES_IN_MEM
value and the SHARED_MEMORY value of the RIS parameters file be high enough for RIS
to cache all table definitions. If the values are not high enough, a declared table definition
may be pushed out of the cache, causing RIS to go to its data dictionary for the table
definition. This can result in a table definition changing in the middle of a session.
An alternative is to use the risdatatypes program to define the unsupported types. This
modifies the RIS data dictionary and causes RIS to treat the unsupported type in a specific
manner.
Data types appear as unsupported because they cannot be reliably supported. Using
them is risky, and is not guaranteed to work. Modifications of data types in the RIS
data dictionary, or the use of declare table statement with some underlying data
types, can cause internal RIS errors.

D-4

Appendix D: Vendor-Specific Information

D.1.1 Data type Mappings

These conventions are used in the following mapping tables:
Convention

Meaning

Unambiguous mapping.

Unambiguous mapping, although there are other possible

mappings.

best guess (default) in an ambiguous mapping.

For more information, see the following sections:

INFORMIX
ORACLE
DB2
SYBASE
MSSQL

Appendix D: Vendor-Specific Information D - 5

D.2

__________________________________________________________________________________________________________________________________________________

DB2

D.2.1 RIS-To-DB2 Mapping

RIS

DB2

CHARACTER(x)
DECIMAL(p,s)
DOUBLE
INTEGER
REAL
SMALLINT
TIMESTAMP
RIS_BLOB
RIS_TEXT

varchar(x)
decimal(p,s)
float
integer
real
smallint
timestamp
unsupported
unsupported

D-6

Appendix D: Vendor-Specific Information

D.2.2 DB2-To-RIS Mapping

DB2

RIS

RISCOLUMNS.dbms_type_string

char(x),x<=240
char(x),241<=x
date
decimal(p,s)
float
float(x),x<=21
float(x),22<=x
graphic
integer
long varchar
long vargraphic
real
smallint
time
timestamp
varchar(x), x<=240
varchar(x), 241<=x
vargraphic

CHARACTER(x)
UNSUPPORTED
UNSUPPORTED
DECIMAL(p,s)
DOUBLE
REAL
DOUBLE
UNSUPPORTED
INTEGER
UNSUPPORTED
UNSUPPORTED
REAL
SMALLINT
UNSUPPORTED
TIMESTAMP
CHARACTER(x)
UNSUPPORTED
UNSUPPORTED

char
char
date
decimal
float
float
float
graphic
integer
longvarchar
longgraphic
float
smallint
time
timestamp
varchar
varchar
graphic

In DB2 you cannot compare a decimal column with a parameterized value that
is larger than the maximum column value.

Appendix D: Vendor-Specific Information D - 7

D.3

__________________________________________________________________________________________________________________________________________________

INFORMIX

D.3.1 Schemas and Unique Identifiers

Identifiers, such as index names, are unique to an INFORMIX database, not to an
INFORMIX user. Unlike tables and view names, when two or more schemas are defined on
one INFORMIX database, all index names must be unique to the entire database, not just to
the schema. RIS requires INFORMIX Versions 4, 5, and 7 databases to be created in ANSI
mode only.

D.3.2 Transactions
INFORMIX immediately posts the effects of statements issued within a transaction as
opposed to waiting for a commit. If a rollback is issued, INFORMIX restores the data to
its state at the beginning of the transaction.
For example, if schemaA inserts a record in schemaA.table1 within a transaction but does
not commit the transaction, schemaB can see the new record if it selects it from
schemaA.table1.
The concept of a transaction suggests that statements do not take effect until a commit
statement is issued, therefore, it is necessary to consider the INFORMIX implementation.

D.3.3 Moving Databases

Moving INFORMIX databases (either to a different directory or a different machine) is not
recommended. This is because the INFORMIX standard engine stores directory and
filenames internally that become invalid if the database is moved. The database files are
also owned by a specific user and group, which may not exist if the database is moved to
another machine.
It is better to unload the database into ASCII format and then reload the data into a
database in the new location.

D-8

Appendix D: Vendor-Specific Information

D.3.4 RIS-To-INFORMIX Mapping

RIS

INFORMIX

CHARACTER(x)
DECIMAL(p,s)
DOUBLE
INTEGER
REAL
SMALLINT
TIMESTAMP
RIS_BLOB

char(x)
decimal(p,s)
float
integer
real
smallint
datetime year to second
byte (supported only in INFORMIXOnLine)
text (supported only in INFORMIXOnLine)

RIS_TEXT

D.3.5 INFORMIX-To-RIS Mapping

INFORMIX

RIS

RISCOLUMNS.dbms_type_string

byte 1byte-2Gbchar(x), x <= 240

char(x), 241 <= x
date
datetime x to y (all others)
datetime year to second
decimal(p), 1 <= p <= 7
decimal(p), 8 <= p
decimal(p, s), 1 <= p <= 15
decimal(p, s), p >= 16
float
integer
interval x to y
real
serial
smallint
text
varchar(x), x <= 240
varchar(x), 241 <= x

RIS_BLOB
CHARACTER(x)
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
TIMESTAMP
REAL
DOUBLE
DOUBLE
UNSUPPORTED
DOUBLE
INTEGER
UNSUPPORTED
REAL
UNSUPPORTED
SMALLINT
RIS_TEXT
CHARACTER(x)
UNSUPPORTED

byte
char
char
date
datetime
datetime
decimal
decimal
decimal
decimal
float
integer
interval
smallfloat
serial
smallint
text
varchar
varchar

Appendix D: Vendor-Specific Information D - 9

D.4

__________________________________________________________________________________________________________________________________________________

ORACLE
Oracle maps all numeric data types to one internal type. If a double type field is created
through RIS, the schema is dropped, then re-created, and the field is no longer defined as a
float.

D.4.1 RIS-To-ORACLE Mapping

RIS

ORACLE

CHARACTER(x)
DECIMAL(p,s)
DOUBLE
INTEGER
REAL
SMALLINT
TIMESTAMP
RIS_BLOB
RIS_TEXT

char(x)
number(p,s)
number
number(10,0)
float(21)
number(5,0)
date
long raw (1byte-2Gb)
long (1byte-2Gb)

D.4.2 ORACLE-To-RIS Mapping

ORACLE

RIS

RISCOLUMNS.dbms_type_string

varchar(x)
varchar(2)
char(x), x <= 240
char(x), 241 <=x
date
long (1byte-2Gb)
long raw(1byte-2Gb)
number(p,s)
raw(x)
rowid

CHARACTER(x)
CHARACTER(x)
CHARACTER(x)
UNSUPPORTED
TIMESTAMP
RIS_BLOB
RIS_TEXT
see full details that follow
UNSUPPORTED
UNSUPPORTED

char
char
char
char
date
long
long raw
number
raw
rowid

D - 10

Appendix D: Vendor-Specific Information

RIS Supported Data Types for number(p,s)

number(p,s)
case (p=0)

* DOUBLE

case (p != 0)

p is never negative

subcase (s<=0)
1
6
11
16

<=
<=
<=
<=

p <= 5
p <= 10
p <= 15
p

?
?
?
*

SMALLINT
INTEGER
DOUBLE
DOUBLE

subcase (s>0)
subsubcase (s>p) note that the value is floating point
1 <= p <= 7
8 <= p

* REAL
* DOUBLE

subsubcase (s<=p)
p <= 15
p > 15

- DECIMAL(p,s)
- DOUBLE

Syntactic variations:
long varchar
decimal(p)
number(p)
number(*,s)
decimal(p,s)
number
varchar

===
===
===
===
===
===

long
number(p)
number(p,0)
decimal(*,s) === number(38,s)
number(p,s)
real, float, float(*), float(b), double precision,
number(*)
=== char

Appendix D: Vendor-Specific Information D - 11

D.5

__________________________________________________________________________________________________________________________________________________

SYBASE
SYBASE does not support the operator =all.

D.5.1 RIS-To-SYBASE Mapping

RIS

SYBASE

CHARACTER(x)
DECIMAL(p,s)
DOUBLE
INTEGER
REAL
SMALLINT
TIMESTAMP
RIS_BLOB
RIS_TEXT

char(x)
decimal
float
integer
real
smallint
datetime
unsupported
unsupported

D - 12

Appendix D: Vendor-Specific Information

D.5.2 SYBASE-To-RIS Mapping

SYBASE

RIS

RISCOLUMNS.dbms_type_string

binary(n)
bit
char(x),x<=240
char(x),241<=x
datetime
float
image
int
money
real
smalldatetime
smallint
smallmoney
text
timestamp
tinyint
varbinary(n)
varchar(x), x<=240
varchar(x), 241<=x

UNSUPPORTED
UNSUPPORTED
CHARACTER(x)
UNSUPPORTED
TIMESTAMP
DOUBLE
UNSUPPORTED
INTEGER
UNSUPPORTED
REAL
UNSUPPORTED
SMALLINT
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
CHARACTER(x)
UNSUPPORTED

binary
bit
char
char
timestamp
float
image
integer
money
real
smalldatetime
smallint
smallmoney
text
timestamp
tinyint
varbinary
varchar
varchar

Appendix D: Vendor-Specific Information D - 13

D.6

__________________________________________________________________________________________________________________________________________________

MSSQL
MSSQL refers to Microsoft SQL Server.

MSSQL does not support the operator =all.

D.6.1 RIS-To-MSSQL Mapping

RIS

MSSQL

CHARACTER(x)
DECIMAL(p,s)
DOUBLE
INTEGER
REAL
SMALLINT
TIMESTAMP
RIS_BLOB
RIS_TEXT

varchar(x)
float
float
integer
real
smallint
datetime
unsupported
unsupported

D - 14

Appendix D: Vendor-Specific Information

D.6.2 MSSQL-To-RIS Mapping

MSSQL

RIS

RISCOLUMNS.dbms_type_string

binary(n)
bit
char(x),x<=240
char(x),241<=x
datetime
float
image
int
money
real
smalldatetime
smallint
smallmoney
text
timestamp
tinyint
varbinary(n)
varchar(x), x<=240
varchar(x), 241<=x

UNSUPPORTED
UNSUPPORTED
CHARACTER(x)
UNSUPPORTED
TIMESTAMP
DOUBLE
UNSUPPORTED
INTEGER
UNSUPPORTED
REAL
UNSUPPORTED
SMALLINT
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
UNSUPPORTED
CHARACTER(x)
UNSUPPORTED

binary
bit
char
char
timestamp
float
image
integer
money
real
smalldatetime
smallint
smallmoney
text
timestamp
tinyint
varbinary
varchar
varchar

Appendix E: RIS Limits E - 1

Appendix E

__________________________________________________________________________________________________________________________________________________

RIS Limits

E-2

Appendix E: RIS Limits

Appendix E: RIS Limits E - 3

Appendix E

__________________________________________________________________________________________________________________________________________________

RIS Limits
RIS enforces several limits that help ensure that applications written using RIS work with
any of the supported database management systems. Some of these limits have been
temporarily increased to values greater than shown in the following list. The expanded limits
are documented at the end of this section.
RIS Version 5.3.1 and later support 16-bit or multi-byte languages. (Most 16bit languages are Asian.) In the RIS documentation, the maximum size allowed
for table names, view names, index names, schema names, column widths, and
character data is specified as x bytes, where x is an integer. For those using
multibyte languages, the maximum number of characters should be interpreted
as the maximum size in bytes. Therefore, the normal maximum of 18
characters translates into 9 16-bit characters.
These RIS limits are:
1.

The number of characters in a column cannot exceed 240.

2.

The precision of a decimal column cannot exceed 15 digits.

3.

The number of columns in a table or view cannot exceed 100.

4.

The length of a row in a table or view cannot exceed 2000 when computed using the
sum of the following items:
Twice the number of columns in the table or view
The sum of the lengths of all character fields in a row
The sum of the precisions of all numeric fields in a row where the precisions are:
INTEGER
SMALLINT
REAL
DOUBLE
DECIMAL
TIMESTAMP

10
5
7
15
user specified <= 15
24

Consider the following table definition:

create table t1(c1 int, c2 char(5), c3 decimal(12,2));
Total length is 2 * 3 + 5 + 10 + 12 = 33

E-4

Appendix E: RIS Limits

5.

The number of columns specified in a create index statement cannot exceed 6.

6.

The total length of all the columns involved in an index cannot exceed 120.

7.

The number of columns specified in a group by clause cannot exceed 6.

8.

The total length of all the columns involved in a group by clause cannot exceed 120.

9.

The number of columns specified in an order by clause cannot exceed 6.

10.

The total length of all the columns involved in an order by clause cannot exceed 120.

11.

The maximum length for schema, table, view, index, and column names is 18
characters in ANSI mode. If not in ANSI mode, the length cannot exceed 31, though
some RDBMSs do not support names of this size.

12.

The size of passwords cannot exceed 31.

13.

The file path size cannot exceed 240.

14.

The size for macro names cannot exceed 80.

15.

The nodename size allowed cannot exceed 28.

16.

The host program size for a DB2 schema cannot exceed 4.

17.

The lu name size for a DB2.

18.

The mode name size for a DB2.

19.

The group size for a DB2 schema cannot exceed 8.

20.

The limits for an ORACLE double data type are 1.0e+130 to 1.0e-130 and -1.0e+130 to
-1.0e-130. ORACLE returns values of 0 or MAX_DOUBLE when out of range.

21.

The default decimal precision is 8.

22.

The default decimal scale is 0.

23.

The limits for a RIS integer are -2147483647 to 2147483647.

24.

The number of prepared statements cannot exceed 40.

25.

The size of a RIS error message cannot exceed 160.

26.

The size of a RIS error name cannot exceed 40.

27.

The size of the database parameters string in the schema file cannot exceed 512.

28.

The number of schemas that can be defined for a database cannot exceed 300.

Appendix E: RIS Limits E - 5

29.

The size of a RIS statement cannot exceed 32765.

30.

The number of network protocols that can be specified for a schema cannot exceed 4.

31.

The number of concurrent transactions cannot exceed 1.

32.

The number of table definitions RIS can store in memory cannot exceed 100.

33.

The size of a RIS reserved word cannot exceed 18.

34.

The hashed string size for an external name is 4 characters.

35.

The maximum number of attempts for resolving external name collisions is 5.

Some of the previous limits have been temporarily increased to let applications specify
which types of databases they need to support. You should stay within the preceding
limits to ensure compatibility with all database types.

The increased RIS limits that you can currently use are:
1.

The number of columns in a table or view cannot exceed 254.

2.

The length of a row in a table or view cannot exceed 8192. (For SYBASE and Microsoft
SQL Server the maximum row length is 1962 bytes.)

3.

The number of columns specified in a create index statement cannot exceed 8.

4.

The number of columns specified in a group by clause cannot exceed 10.

5.

The total length of all the columns involved in a group by clause cannot exceed 2008.

6.

The number of columns specified in an order by clause cannot exceed 10.

7.

The total length of all the columns involved in an order by clause cannot exceed
2008.

E-6

Appendix E: RIS Limits

Appendix F: Parameters File F - 1

Appendix F

__________________________________________________________________________________________________________________________________________________

Parameters File

F-2

Appendix F: Parameters File

Appendix F: Parameters File F - 3

Appendix F

__________________________________________________________________________________________________________________________________________________

Parameters File
The parameters, or parms, file contains operational parameters, the location of the client,
and the location of the schema definition file for access to all schemas from the RIS client.
The parms file is generated the first time RIS is invoked. The parms file defines a default
schema definition file specification, referencing the file schemas in the directory where RIS
was installed. You can change the default setting by using the locate schema file
command in the interactive utility or RIS Schema Manager to put the appropriate entry in
the parms file or the function RISlocate_schema_file can be used in an embedded program.
The file RISnn.nn\parms on the client machine must contain the location of the schema
definition file. The parms file describes the network address and filename of the schema
definition file. (nn.nn refers to the RIS version number.)
If a network address is not provided, the schema definition file is created or used on the local
machine.
If the filename is not a full pathname, RIS looks for the file in the directory where RIS was
installed on the machine. This is seen by issuing the command:
start regedt32

then traversing the HKEY_LOCAL_MACHINE tree within the HKEY_LOCAL_MACHINE

window using the following steps:
1.

Select Software key

2.

Select Intergraph key

3.

Select RIS key

4.

Select nn.nn key (nn.nn = the RIS version number.)

The PathName value is c:\Program Files\Common Files\Intergraph\RIS05.nn by default.

F-4

Appendix F: Parameters File

Before using RIS, you may need to change some of the RIS operating parameters. These
parameters are located in the file parms in the directory in which RIS was installed. If the
environment variable RIS_PARAMETERS is defined, RIS looks for the file it indicates. This
file is read by RIS whenever an application issues its first SQL statement.
The parms file is in ASCII format, so you can use any text editor (such as vi or EDIT) to
modify it. You specify a parameter value by the parameter name followed by a value. All
parameter names must begin in the first column. Also, you can include comments by placing
the pound character (#) in column one of a comment line. The following is a list of supported
parameters:
1.

SHARED_MEMORY

2.

MAX_LOCAL_SERVERS

3.

MAX_ROWS

4.

MAX_BUFFER_SIZE

Appendix F: Parameters File F - 5

5.

MAX_STATIC_STMTS

6.

MAX_USER_STMTS

7.

MAX_SECONDARY_SCHEMAS

8.

MAX_TRANSACTIONS

9.

MAX_TABLES_IN_MEM

10.

Network Verification Parameters

11.

Schema Definition File Location

12.

LOCK_FILE_RETRY

13.

Client Process Location

Some of the parameters are new and some of the old parameters have changed.
Old parameter files are automatically updated to the new format. Any values
that are changed are preserved. Also, if a parms file does not exist, RIS
generates one with all the parameters set to the default values.

F.1 SHARED_MEMORY
SHARED_MEMORY is the size of the shared memory segment allocated by RIS. Using a
large shared memory region does not alter RIS memory usage and does not affect system
performance. SHARED_MEMORY is simply the maximum amount of shared memory that
RIS can use. The size of the shared memory does affect swap space requirements. If your
system is running out of swap space on a regular basis, you may want to reduce the size of
this parameter.
The SHARED_MEMORY maximum value is subject to system limitations.
SHARED_MEMORY must be a hex number.
SHARED_MEMORY minimum:
SHARED_MEMORY maximum:
SHARED_MEMORY default:

0x50000
0x400000
0x200000

F-6

Appendix F: Parameters File

F.2 MAX_LOCAL_SERVERS
MAX_LOCAL_SERVERS is the maximum number of local servers each RIS client
(application) can start. A local server is started for each schema opened on a local database.
MAX_LOCAL_SERVERS affects the number of UNIX semaphores RIS uses because RIS
allocates MAX_LOCAL_SERVERS semaphores for each RIS client process (application).
Note the MAX_LOCAL_SERVERS maximum value is subject to system limitations on
number semaphores per ID and per system.
MAX_LOCAL_SERVERS minimum:
MAX_LOCAL_SERVERS maximum:
MAX_LOCAL_SERVERS default:

0
24
8

F.3 MAX_ROWS
MAX_ROWS is the maximum number of rows of data RIS fetchs into the communication
buffer with local and remote servers when a fetch request is made. Larger values are more
efficient when many rows are returned by a query and fetched by the user. Smaller values
are more efficient when many rows are returned by a query but the user may not actually
use all those rows. Note that the actual maximum value possible for MAX_ROWS is most
likely much less than the theoretical max value given in the following table. This is due to
the amount of shared memory available to RIS, the number of contiguous bytes of memory
that RIS can allocate, and the total communication buffer size being representable by an
unsigned long integer.
MAX_ROWS minimum:
MAX_ROWS maximum:
MAX_ROWS default:

1
8388606
100

F.4 MAX_BUFFER_SIZE
MAX_BUFFER_SIZE is the maximum size of buffer that RIS uses to hold results from a
fetch request. If MAX_ROWS rows of data does not fit in a buffer of MAX_BUFFER_SIZE
then only the number of complete rows that fit in the buffer are fetched. The buffer is made
large enough to hold 1 row of data, even if this results in a buffer of size greater than
MAX_BUFFER_SIZE.
MAX_BUFFER_SIZE minimum:
MAX_BUFFER_SIZE maximum:
MAX_BUFFER_SIZE minimum
default:

66552
67108848
66552

Appendix F: Parameters File F - 7

F.5 MAX_STATIC_STMTS
MAX_STATIC_STMTS is the maximum number of static statements that RIS attempts to
keep prepared. This only applies to static data manipulation statements except for select.
By keeping these statements prepared, RIS improves the performance of static statements
that are executed multiple times. When the MAX_STATIC_STMTS limit or the total
statement limit is reached, RIS clears the least recently used static statement. If
MAX_STATIC_STMTS is set to 0, then each static statement is cleared immediately after it
is executed.
MAX_STATIC_STMTS minimum:
MAX_STATIC_STMTS maximum:
MAX_STATIC_STMTS default:

0
512
10

F.6 MAX_USER_STMTS
MAX_USER_STMTS is the maximum number of statements that RIS will attempt to keep
prepared.
MAX_USER_STMTS minimum:
MAX_USER_STMTS maximum:
MAX_USER_STMTS default:

1
512
40

F.7 MAX_SECONDARY_SCHEMAS
MAX_SECONDARY_SCHEMAS is the maximum number of secondary schemas that RIS
allows per super schema.
MAX_SECONDARY_SCHEMAS
minimum:
MAX_SECONDARY_SCHEMAS
maximum:
MAX_SECONDARY_SCHEMAS
default:

0
9
0

F.8 MAX_TRANSACTIONS
MAX_TRANSACTIONS is the maximum number of transactions that RIS runs at a time.
MAX_TRANSACTIONS minimum:
MAX_TRANSACTIONS maximum:
MAX_TRANSACTIONS default:

1
40
1

F-8

Appendix F: Parameters File

F.9 MAX_TABLES_IN_MEM
MAX_TABLES_IN_MEM is the maximum number of tables that RIS stores in memory.
Through this limiting factor, memory usage is optimized. Once the MAX_TABLES_IN_MEM
limit is reached, RIS clears the least recently used table. A high limiting value results in
larger memory usage if the number of tables referenced during a session is high. If the value
is set low, less memory is used, but the overhead of purging is increased.
MAX_TABLES_IN_MEM minimum:
MAX_TABLES_IN_MEM maximum:
MAX_TABLES_IN_MEM default:

1
1024
50

F.10 Network Verification Parameters

The network verification parameters concern only those RIS users who also use
Intergraphs Dispatch Management product.
The TIMESTAMP_INTERVAL minimum and the TIMESTAMP_INTERVAL
default must remain set to 0.

Network verification parameters include a set of alarm timestamp parameters and network
buffer parameters. They are:
1.

TIMESTAMP_INTERVAL
TIMESTAMP_INTERVAL is the time period of timestamps that RIS server sends out
presumptively to RIS client. These timestamps help RIS client to determine the status
of RIS server which is executing an opcode from RIS client. Generally, the smaller the
timestamp interval is, the quicker RIS client is to correctly response the status change
of RIS server. A too small timestamp interval, however, may increase network traffic,
which may limit the quickness consequently.

TIMESTAMP_INTERVAL minimum:
TIMESTAMP_INTERVAL maximum:
TIMESTAMP_INTERVAL default:
2.

0
100000
0

INITIAL_TIMEOUT
INITIAL_TIMEOUT is the longest time period for which RIS client can wait to get an
acknowledgement from RIS server for an opcode execution request. The round
transmission of send-ack helps RIS client to synchronize its time counter with RIS
servers. Two synchronized time counters in both sides enable RIS client to correctly
estimate the status of RIS server through counting received timestamps. The smaller
the initial timeout, the closer the two time counters. A too small initial timeout,
however, may increase the chance of unexpected terminating of RIS.

Appendix F: Parameters File F - 9

INITIAL_TIMEOUT minimum:
INITIAL_TIMEOUT maximum:
INITIAL_TIMEOUT default:
3.

0
100000
12

TIMESTAMP_TOLERANCE
TIMESTAMP_TOLERANCE is the maximum number of timestamps by which RIS
client is allowed to be behind to count received timestamps. Network traffic, heavy site
load and difference of time counters prevent RIS client from counting exact number of
timestamps that is supposed to be sent by RIS server. A small timestamp tolerance may
incur RIS to terminate itself unnecessarily.
TIMESTAMP_TOLERANCE minimum:
TIMESTAMP_TOLERANCE maximum:
TIMESTAMP_TOLERANCE default:

4.

0
1000
5

BUFFER_FULL_SIZE
BUFFER_FULL_SIZE is used to specify the maximum size of buffer that the network
software can use. RIS will use this value to determine the maximum number of
timestamps that can be written in the network buffer without the possibility of the
network buffer becoming full.
BUFFER_FULL_SIZE minimum:
BUFFER_FULL_SIZE maximum:
BUFFER_FULL_SIZE default:

5.

8
8000
64

BUFFER_FULL_TIMEOUT
BUFFER_FULL_TIMEOUT is the longest time period for which RIS client can wait to
receive next alarm timestamp from RIS server after RIS client has read more than
BUFFER_FULL_SIZE of timestamp data.
BUFFER_FULL_TIMEOUT minimum:
BUFFER_FULL_TIMEOUT maximum:
BUFFER_FULL_TIMEOUT default:

0
100000
12

All above five parameters are basically independent of each other. However, the different
combination of these parameters may have different effects on RIS. Consider a subtle
combination as following.
If BUFFER_FULL_TIMEOUT > TIMESTAMP_INTERVAL*TIMESTAMP_TOLERANCE,
then the buffer full timeout dominates the timestamp tolerance. That is, RIS client reports
server died only after the buffer full timeout has elapsed in buffer full case. Otherwise, the
buffer full timeout dominates the timestamp tolerance when RIS server has sent all ideal
timestamps on time at buffer full moment. This is because RIS client is able to wait
TIMESTAMP_INTERVAL*TIMESTAMP _TOLERANCE seconds for tolerance test.

F - 10

Appendix F: Parameters File

F.11 Schema Definition File Location

The schema definition file contains all of the information about the schemas and databases
that can be used. The schema definition file can be located on any node. The schema file
location parameters specify the location of the schema file to the RIS client. You can set the
parameters to describe the schema definition file with the locate schema file command
in the RIS Interactive utility or the Schema Manager utility.
There are five parts of the schema definition file location parameter:
1.

SCHEMA_FILE_PROTOCOL
xns:
tcp/ip:
decnet:
memory(local):

X
T
D
M

All of the protocols, except memory, require that you specify an address, username, and
password. A password is needed only if the username has a password. The format of
the address varies according to the protocol used.
2.

SCHEMA_FILE_ADDRESS
xns:
tcp/ip:
decnet:
memory(local):

3.

name or XXXXXXXX.XX-XX-XX-XX-XX-XX
name or XXX.XXX.XXX.XXX
name or XX.XXXX
n/a

SCHEMA_FILE_USERNAME
example:

bob

The username specified must be a valid user on the node specified in the address and
have read access to the schema file.
4.

SCHEMA_FILE_PASSWORD
example:

XP,Zh+&;PVQiU)w)mE6x

If a password is required for the user, an encrypted representation of the password

must be specified. This can be copied from another parameter or schema file, or
generated by using the RIS utilities.
5.

SCHEMA_FILE_NAME
UNIX example:
Windows NT example:

/usr/bob/risschema
c:\users\bob\risschema

Appendix F: Parameters File F - 11

SCHEMA_FILE_PROTOCOL default:
SCHEMA_FILE_ADDRESS default:
SCHEMA_FILE_USERNAME default:
SCHEMA_FILE_PASSWORD default:
SCHEMA_FILE_NAME default:

schemas

Regardless of the protocol used, you must specify a name for the schema definition file.
The schema definition file must be located in a directory to which the user can read and
write. If the memory protocol is specified, the directory must be readable and writable
by the user running RIS. If the filename is not prepended with a path, then it is
assumed to be in the directory where RIS is installed. Write access is required only
when the user that is using RIS tries to create, alter, or drop a schema.

F.12 LOCK_FILE_RETRY
LOCK_FILE_RETRY is the number of times RIS attempts to remove the schema lock file,
risschema.LCK. After RIS attempts to remove the schema lock file the specified number of
times, it takes one of two actions, depending if LOCK_FILE_RETRY is positive or negative.
If LOCK_FILE_RETRY is positive, RIS assumes a process has terminated without replacing
the lock file and continue processing. If LOCK_FILE_RETRY is negative, RIS stops
processing and returns an error.
The schema lock file stops multiple processes from writing to the schema file at the same
time. When a process attempts to write to the schema file, it removes the schema lock file,
indicating to other processes the schema file is locked. Once done writing to the schema file,
it replaces the lock file, indicating other processes can now write to the schema file.
LOCK_FILE_RETRY default:

25

F.13 Client Process Location

These are the default values for the CLIENT parameters:
CLIENT_PROTOCOL default:
CLIENT_ADDRESS default:
CLIENT_USERNAME default:
CLIENT_PASSWORD default:
CLIENT_VERSION default:

0.0

The CLIENT_VERSION parameter is set to 0.0 by default, meaning that the application will
connect to a compatible client. This parameter is set to m.n where m is the major version
and n is the minor version of the client product that will used when multiple versiona of the
client are available at the client location.

F - 12

Appendix F: Parameters File

Appendix G: Schema Definition File G - 1

Appendix G

__________________________________________________________________________________________________________________________________________________

Schema Definition File

G-2

Appendix G: Schema Definition File

Appendix G: Schema Definition File G - 3

Appendix G

__________________________________________________________________________________________________________________________________________________

Schema Definition File

The RIS schema definition file (schemas) maintains all schema definitions known to RIS.
You may store it in a central location on the network so it can be used by all RIS client
programs to ensure that all RIS clients use the same set of schema definitions. The client
learns the location of the schemas file through an entry in the parms file.
Although you can use multiple schema definition files, it is best to use only one.
Using multiple schema definition files may result in inconsistencies. However,
each site must define rules for administrating the RIS schemas.

Access to the schema definition file is controlled by the presence of another file, the schema
lock file. The name of the schema lock file is the same as the schema definition file with the
addition of the .LCK extension. The schema definition file is accessible only if the schema
lock file exists. If the schema lock file does not exist, then the schema definition file is in use.
If the schema definition file is in use, the action RIS takes is specified by the
LOCK_FILE_RETRY parameter in the RIS parms file. Sometimes, when RIS is abnormally
terminated, the schema lock file is not replaced. In these cases, the schema lock file must be
replaced manually.
The schema definition file consists of database and schema entries that are associated by a
DBID (database ID) key value. There can be multiple schema entries for each database
entry. A blank line separates entries. The following is a description of the fields in the
schema definition file:

G-4

Appendix G: Schema Definition File

Field

Description

DBID

The database ID; a unique key to identify the database.

DTYPE

The database type; X for INFORMIX, O for ORACLE, D

for DB2, Y for SYBASE, and M for Microsoft SQL Server
(MSSQL)

DBNAME

The database name as in the create schema

statement. It must be a name or pathname as required
by the DBMS.

OSPASS

The password for the operating system user. This field is

blank if all the schemas on this database are secure
schemas.

OSTYPE

The type of operating system running on the current

machine. Currently supported values are U for UNIX, V
for VMS, and N for Windows NT.

OSUSER

The operating system username.

PROTOCOL

The communication protocol to be used to communicate

with the database. Value is T for TCP/IP.

NETADDR

The network address (must be an address, not a name).

SCHNAME

The name of the schema.

SERVER_VERSION

The version of the RIS server that is started by the RIS

client. The format of this field is of the form m.n where
m is the major version number and n is the minor version
number. The default setting is 0.0. This means that the
RIS client starts a compatible version of the RIS server.

SECURE

1 for a secure schema, 0 for a standard schema.

DICTOWNER

The user who owns the dictionary.

SCHOWNER

The owner of the schema.

SCHOWNPASS

The database user password (encrypted) of the schema

owner. This field is blank if the schema is a secure
schema, or the database user has no password.

BEGIN_GRANTEES
and END_GRANTEES

A list of schema names that have been granted access to

the schema.

DIR

The location of the RDBMS system.

Appendix G: Schema Definition File G - 5

The following fields are specific to INFORMIX databases:

SQLEXEC

Specifies whether INFORMIX Standard Engine or

INFORMIX Online should be used.

DBTEMP

Specifies where INFORMIX creates temporary files.

TBCONFIG

Specifies a configuration file for INFORMIX On-Line

only.

The following fields are specific to DB2 databases:

ARCH

The system architecture on which the RIS/DBMS runs.

This value is case sensitive. The valid value is s370 and
the default value is s370.

OS

The operating system that the RIS/DBMS uses. This

value is case sensitive. The valid value is mvs and the
default value is mvs.

ENV

The environment that the RIS/DBMS uses. This value is

case sensitive. The valid value is CICS and the default
value is cics.

NET_PROTOCOL

The network protocol that RIS uses to get to the IBM

machine where the DBMS resides. This value is case
sensitive. The valid value is LU6.2.

HOST_PROGRAM

The name the IBM System Administrator called the RIS

server when it was installed on the IBM, the CICS
transaction name.

RIS_LU or HOST_LU

The name of the CLIPPER System Administrator

assigned to the logical unit that allows communication to
the RIS program on the IBM machine. There are two
logical units, one on the CLIPPER, the other on the IBM.
The LU names are generated when RIS is installed. This
value is case sensitive.

MODE

The name the CLIPPER System Administrator assigned

to the mode that allows communication to the RIS
program on the IBM machine.

GROUP

Currently unused.

G-6

Appendix G: Schema Definition File

The following fields are specific to SYBASE databases:

DSQUERY

Specifies the name of the SYBASE server used for the

schema.

FILENAME

Specifies the name of the SYBASE interfaces file for the

schema. By default, RIS uses the SYBASE interfaces file
named interfaces for UNIX and SQL.INI for NT.

The following fields are specific to Microsoft SQL Server databases:

DSQUERY

Specifies the name of the Microsoft SQL Server used for

the schema.

FILENAME

This field is not currently used.

The following fields are for RIS internal use:

CHECKSUM

A checksum of the schema file, used to determine if the

schema file has been modified. The value can be
recalculated by issuing the checksum schema file
command in the interactive utility, by calling the
function RISrestore_schema_file_checksum in an
embedded program, or by selecting the appropriate
button in the Schema Manager.

TIMESTAMP

A field used to determine the last time the schema file

was modified.

The schema file must be readable by all users permitted to access the schemas.
A schema file must be readable and writable by all users authorized to create,
alter, or drop schemas. Users permitted to create, alter, and drop schemas
must be able to create and delete files in the directory where the schema file is
located.
The following is a sample schema definition file. This includes sections for the INFORMIX,
ORACLE, SYBASE, Microsoft SQL Server, and DB2 databases.
Comments are not allowed in schema files. The comments to the right of the following
code sections below were added to this document to clarify which sections were
associated with which databases.
CHECKSUM:240378796
TIMESTAMP:733791488
DBID=1
***(INFORMIX Standard Engine on UNIX)***
DTYPE=X
DBNAME=/usr/dbs/risdb1
OSTYPE=U
PROTOCOL=T
NETADDR=129.135.178.124
PROTOCOL=X
NETADDR=000134bb.aa-00-04-00-ac-78
PROTOCOL=D

Appendix G: Schema Definition File G - 7

NETADDR=33.121
PROTOCOL=
NETADDR=
DIR=/usr/informix
SQLEXEC=/usr/informix/lib/sqlexec
DBTEMP=
TBCONFIG=
DBID=2
***(INFORMIX OnLine Engine on UNIX)***
DTYPE=X
DBNAME=risdb1@serv2
OSTYPE=U
PROTOCOL=T
NETADDR=129.135.172.189
PROTOCOL=X
NETADDR=000134bb.08-00-36-35-c3-01
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
DIR=/usr/informix
SQLEXEC=/usr/informix/lib/sqlturbo
DBTEMP=/usr/tmp
TBCONFIG=/usr/informix/etc/tbconfig
DBID=3
***(INFORMIX Standard Engine on NT)***
DTYPE=X
DBNAME=/c=/dbs/risdb1@serv1
OSTYPE=N
PROTOCOL=T
NETADDR=129.135.178.124
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
PROTOCOL=
DIR=c:\win32app\informix
SQLEXEC=c:\win32app\informix\bin\sqlexec.exe
DBTEMP=
TBCONFIG=
DBID=4
***(INFORMIX OnLine Engine on NT)***
DTYPE=X
DBNAME=risdb1@serv1
OSTYPE=N
PROTOCOL=T
NETADDR=129.135.178.124
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
DIR=c:\win32app\informix
SQLEXEC=c:\win32app\informix\bin\sqlturbo.exe
DBTEMP=
TBCONFIG=c:\win32app\informix\etc\config
DBID=5
***(ORACLE)***
DTYPE=O
DBNAME=A
OSTYPE=U

G-8

Appendix G: Schema Definition File

PROTOCOL=T
NETADDR=0001352b.aa-00-04-00-a6-78
PROTOCOL=XX
NETADDR=129.135.127.174
PROTOCOL=D
NETADDR=39.19
PROTOCOL=
NETADDR=
OSUSER=ken
OSPASS=anything
DIR=/usr/oracle
DBID=6
DTYPE=O
DBNAME=A
OSTYPE=N
PROTOCOL=T
NETADDR=129.135.127.174
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
OSUSER=mary
OSPASS=anything
DIR=c:\orant
DBID=7
DTYPE=Y
DBNAME=risdb6
OSTYPE=U
PROTOCOL=T
NETADDR=129.135.169.47
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
OSUSER=washington
OSPASS=anything
DIR=/usr2/sybase
DSQUERY=RISAT0
FILENAME=
DBID=8
DTYPE=Y
DBNAME=risdb7
OSTYPE=N
PROTOCOL=T
NETADDR=129.135.169.47
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
OSUSER=jones
OSPASS=anything
DIR=c:\sql10
DSQUERY=RISAT0

***(ORACLE on NT)***

***(SYBASE)***

***(SYBASE on NT)***

Appendix G: Schema Definition File G - 9

FILENAME=
DBID=9
***(Microsoft SQL Server on NT)***
DTYPE=M
DBNAME=risdb8
OSTYPE=N
PROTOCOL=T
NETADDR=129.135.169.45
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
OSUSER=jones
OSPASS=anything
DIR=
DSQUERY=RISMSQ
IFILE=
DBID=10
***(DB2 Using LU6.2)***
DTYPE=D
DBNAME=risdb10
OSTYPE=U
PROTOCOL=X
NETADDR=0001388e.aa-00-04-00-20-2a
PROTOCOL=T
NETADDR=129.135.170.23
PROTOCOL=
NETADDR=
PROTOCOL=
NETADDR=
OSUSER=rc01
OSPASS=anything
ARCH=s370
OS=mvs
NET_PROTOCOL=lu6.2
ENV=cics
HOST_PROGRAM=RISX
RIS_LU=HSV1.L62S700
HOST_LU=HSV1.A01CICSA
MODE=IGRLU62P
GROUP=
NODE=
PORT=0
SCHNAME=sch1
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=informix
SCHOWNER=informix
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=1
SCHNAME=sch2
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=informix
SCHOWNER=informix
SCHOWNPASS=anything

G - 10

Appendix G: Schema Definition File

BEGIN_GRANTEES
END_GRANTEES
DBID=2
SCHNAME=sch3
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=informix
SCHOWNER=informix
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=3
SCHNAME=sch4
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=informix
SCHOWNER=informix
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=4
SCHNAME=oracle_clip
SERVER_VERSION=0.0
SECURE=1
DICTOWNER=jane
SCHOWNER=jack
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=5
SCHNAME=oracle_nt
SERVER_VERSION=0.0
SECURE=1
DICTOWNER=jane
SCHOWNER=bob
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=6
SCHNAME=sybase_sun
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=jil
SCHOWNER=gary
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=7
SCHNAME=sybase_nt
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=jill
SCHOWNER=sue
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES

Appendix G: Schema Definition File G - 11

DBID=8
SCHNAME=mssql_nt
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=jill
SCHOWNER=sue
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=9
SCHNAME=db2_ibm_tcp
SERVER_VERSION=0.0
SECURE=1
DICTOWNER=RC00
SCHOWNER=RC00
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=10
SCHNAME=db2_ibm_lu62
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=rc01
SCHOWNER=RC01
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=11
-

There is a list of protocols in the database entry which allows for additional
protocols. Currently, only the first protocol in the list is used.
All these entries are created by the create schema statement. If the file is corrupted or
removed, the entries can be re-created by issuing the create schema statement again.

G - 12

Appendix G: Schema Definition File

Appendix H: Language Configuration File H - 1

Appendix H

__________________________________________________________________________________________________________________________________________________

Language Configuration File

H-2

Appendix H: Language Configuration File

Appendix H: Language Configuration File H - 3

Appendix H

__________________________________________________________________________________________________________________________________________________

Language Configuration File

Before using RIS, you can change the language used by RIS. The RIS_get_language_name
function call in a RIS application sets the language to the specified value. The language map
information is located in the RIS language configuration file langs in the config directory of
the riscli product directory:
c:\Program Files\Common Files\Intergraph\ris05.nn\riscli\config\langs

You can also add new languages currently not supported by RIS as long as they are
supported by the operating system and database.
Defining RIS Language Settings for NT:
1.

From the Control Panel, double-click the International icon.

2.

Scroll through the list of languages available under the Language drop-down list.

3.

Select the language desired.

4.

Click OK. The system prompts you for the source of the operating system language
files.

5.

Reboot the system when the process is complete.

The following is the langs file currently supported by RIS. The format of this file is specified
by six (6) fields per line separated by a pipe (|) delimiter. Each line represents one language
mapping between RIS and the underlying operating system. The format is:
ris_lang_id|ris_lang_name|ris_lang_dir|os_lang_id|code_page|os_lang_name
ris_lang_id

Unique RIS language identifier. For every new

language added, this identifier is incremented.

ris_lang_name

Unique RIS language name to used by RIS

applications during RISinitialize().

ris_lang_dir

Directory name under the riscli/config directory. This

directory holds all RIS-specific language files
generated by Intergraphs UMS (User Message
System).

os_lang_id

Language identifier used by the underlying operating

system for the language you want RIS to use.

code_page

Language ANSI code page for the given os_lang_id.

H-4

Appendix H: Language Configuration File

os_lang_name

Language name used by the underlying operating

system for the language you want RIS to use.

Below is a sample language configuration file. Only languages with the same code page can
interoperate. If the two languages do not have the same code page then RIS gives an error of
RIS_E_INCOMPATIBLE_LANGS.
Sample langs file:
0 |english
|english
|0x0409|1252|U.S. English
1 |korean
|korean
|0x0412|946|korean
2 |chinese
|chinese
|0x0404|950|Traditional Chinese
3 |japanese
|japanese
|0x0411|932|Japanese
4 |german
|german
|0x0407|1252|German
5 |french
|french
|0x040C|1252|French
6 |spanish
|spanish
|0x0C0A|1252|Modern Spanish
7 |italian
|italian
|0x0410|1252|Italian
8 |arabic
|arabic
|0x0401|1256|Arabic
9 |bulgarian
|bulgaria
|0x0402|1251|Bulgarian
10|catalan
|catalan
|0x0403|1252|catalan
11|traditional chinese |chinese.smp |0x0804|936|Simplified Chinese
12|czech
|czech
|0x0405|1250|Czech
13|danish
|danish
|0x0406|1252|Danish
14|swiss german
|german.sws |0x0807|1252|Swiss German
15|uk english
|english.uk |0x0809|1252|U.K. English
16|australian english |english.aus |0x0C09|1252|Australian English
17|canadian english
|english.can |0x1009|1252|Canadian English
18|mexican spanish
|spanish.mex |0x080A|1252|Mexican Spanish
19|finnish
|finnish
|0x040B|1252|Finnish
20|belgian french
|french.blg |0x080C|1252|Belgian French
21|canadian french
|french.can |0x0C0C|1252|Canadian French
22|swiss french
|french.sws |0x100C|1252|Swiss French
23|hebrew
|hebrew
|0x040D|1255|Hebrew
24|hungarian
|hungarian
|0x040E|1250|Hungarian
25|icelandic
|icelandic
|0x040F|1252|Icelandic
26|swiss italian
|italian.sws |0x0810|1252|Swiss Italian
27|dutch
|dutch
|0x0413|1252|Dutch
28|belgian dutch
|dutch.blg
|0x0813|1252|Belgian Dutch
29|norwegian bokmal
|norwegia.bkm|0x0414|1252|Norwegian-Bokmal
30|norwegian nynorsk
|norwegia.nyn|0x0814|1252|Norwegian-Nynorsk
31|polish
|polish
|0x0415|1250|polish
32|brazilian portuguese|portugue.brz|0x0416|1252|Brazilian Portuguese
33|portuguese
|portugue
|0x0816|1252|Portuguese
34|rhaeto romanic
|rhaeto.rom |0x0417|0|Rhaeto-Romanic
35|romanian
|romanian
|0x0418|1250|Romanian
36|russian
|russian
|0x0419|1251|Russian
37|croata serbian
|croata
|0x041A|1250|Croato-Serbian
38|serbo croatian
|serbo
|0x081A|1250|Serbo-Croatian
39|slovak
|slovak
|0x041B|1250|Slovak
40|albanian
|albanian
|0x041C|1250|Albanian
41|swedish
|swedish
|0x041D|1252|Swedish
42|thai
|thai
|0x041E|874|Thai
43|turkish
|turkish
|0x041F|1254|Turkish
44|urdu
|urdu
|0x0420|0|Urdu
45|bahasa
|bahasa
|0x0421|1252|Bahasa

Appendix I: Changes to This Version of RIS I - 1

Appendix I

__________________________________________________________________________________________________________________________________________________

Changes to This Version of RIS

I-2

Appendix I: Changes to This Version of RIS

Appendix I: Changes to This Version of RIS I - 3

Appendix I

__________________________________________________________________________________________________________________________________________________

Changes to This Version of RIS

This section describes changes between RIS Version 4 and RIS Version 5.

I.1 RDBMS Versions

For the most current information concerning RDBMS version compatibility for
supported RIS platforms, see the Architecture and Configuration Overview
section in the installation guide for your platform.

I.2 UNION and UNION ALL Supported

RIS Version 5 supports UNION and UNION ALL operators with the select statement.
For example:
select * from t1 union select * from t2;
select c1, c2 from t1 union all select c21, c22 from t2;
UNION and UNION ALL are not supported in subqueries. See the RIS SQL Users Guide
for more information.

I.3 Objects of Different Owners Within a Schema

In RIS Version 4 a schema created by an RDBMS user contained only objects (tables, views,
and indexes) owned by that user. In RIS Version 5 a schema can contain objects owned by
multiple users. For example, schema S1, created by RDBMS user U1, can contain objects
owned by RDBMS users U2 and U3, as well as those owned by U1. This capability:
Is a fundamental redefinition of a schema to be simply a named collection of objects in a
database.
Lets data owned by privileged accounts be included without views or security violations.
Allows sharing of common objects among schemas. For example, table T1, created by
user U1, can be shared by schemas S1, S2, and S3, where S1 was created by user U1,
S2 by user U2, and S3 by user U3.
Lets applications easily create logical groupings of tables.

I-4

Appendix I: Changes to This Version of RIS

Considerations when using this capability:

Since objects owned by different users can be included in the schema, the owner
information is maintained in the RIS dictionary. The dbms_owner value applies to a
table, view, or an index, and can be in upper or lowercase.
This capability cannot be accessed through RIS Version 4.
The access restrictions of the underlying RDBMS are encountered when using this
capability.
Most databases let two different users create tables/views/indexes with the same name.
However the names of tables/views/indexes within a schema are unique, regardless of
the dbms_owner. If both T1 owned by U1, and T1 owned by U2 need to be included in a
schema, one of the tables has to be aliased. See the section Object Aliases for more
information.

I.4 Object Aliases

With RIS Version 5, any column or table name can be given an alias. For example, table
abc_123 with columns abc1, abc2, and abc3, can be included and referred to as EMPLOYEES
with columns FIRST_NAME, GENDER, and DATE_OF_BIRTH, respectively. This
capability:
Lets identically-named tables owned by different RDBMS users exist in a single
schema. For example, suppose three different users create three different tables with
the same name:
RDBMS: PROJ1.NAMES, PROJ2.NAMES, PROJ3.NAMES
These tables must be aliased so that they have distinct names.
SCHEMA1: NAMES1, NAMES2, NAMES3
Names in RIS can be longer than the underlying database supports. See the RIS SQL
Users Guide for more information.
Object names and keyword conflicts can be worked around. For example, if a column
name is a RIS keyword, such as t1(informix, oracle, db2), it can be included as t1(col1,
col2, col3).
Considerations when using this capability:
An exclude/include sequence loses all aliases.
This capability cannot be accessed through RIS Version 4.
Within RIS only the RIS names (aliases) are valid. The external/DBMS name is not
valid.

Appendix I: Changes to This Version of RIS I - 5

I.5 Multi-User/Secure Schemas

In RIS Version 5 two types of schemas are supported: the standard schema and the secure
schema. The standard schema is a single-user schema and the information necessary for
connecting to this schema is stored in the schema file (this is no different from a RIS Version
4 schema). The secure schema has no username/password combination stored for it. The
RIS Version 4 (single user) schema is still supported and still the default. This multiuser/secure schema capability:
Allows no connection until a user provides a username/password combination.
Lets you use the same schema, but provide different RDBMS log-ins.
Considerations when using this capability:
No password is stored in any form by RIS.
Individuals appear distinct to the RDBMS and are subject to RDBMS security tracking.
The declare schema statement lets you specify a schema name and password, and
optionally, the user and password of the user who owns the schema, and the operating
system user and password in the RIS in-memory data dictionary cache.
This statement must be used to access secure schemas. It can also be used to access
standard schemas. See the RIS SQL Users Guide for more information. This capability
can be used by any site. It is most useful to those interested in high levels of security
(usually DB2, ORACLE, and so on).
The schema administrator (user who creates the schema) controls authority to connect
to a schema and to create tables on a schema, using:
GRANT CONNECT TO <rdbms_user>;
REVOKE CONNECT FROM <rdbms_user>;
GRANT RESOURCE TO <rdbms_user>;
REVOKE RESOURCE FROM <rdbms_user>;
A username/password combination should be provided before a schema is open.
There is case-sensitivity of the RDBMS username (except in cases where some
databases accept names in a particular case; then RIS does a conversion).
This capability cannot be accessed through RIS Version 4.

I-6

Appendix I: Changes to This Version of RIS

I.6 Shared Dictionaries

In RIS Version 5 when a schema s1 is created and creates the dictionary as in RIS Version 4,
schemas s2, s3, s4, and so on can be created using the dictionary created by schema s1. This
capability:
Allows multiple schemas in databases that cannot have tables of the same name (nonANSI INFORMIX).
Requires minimal dictionary creation when there are many schemas.
Allows limited dictionary creation, administration, and ownership outside of RIS for
DB2, SYBASE, and Microsoft SQL Server.
Considerations when using this capability:
The system administrator must grant and revoke an RDBMS user the authority to
create a schema on a dictionary, using:
GRANT SCHEMA TO <rdbms_user>;
REVOKE SCHEMA FROM <rdbms_user>;
Creators of dictionaries cannot drop all their schemas while there are other schemas in
the dictionary.
An application based on RIS Version 4 must create a dictionary in order to use it.
Additional schemas can then be added to the dictionary and used by applications based
on RIS Version 5. Schemas s2, s3, and so on, cannot be accessed from RIS Version 4.

I.7 Dictionary Objects

Dictionary objects in RIS Version 5 are all renamed (ris5*). This capability:
Removes the distinction between ris* and ris_*.
Makes RIS dictionary objects now appear in the dictionary views.
Considerations when using this capability:
Additional columns are needed to distinguish among schemas in shared dictionaries, to
distinguish between user objects and dictionary objects, and for internal/external object
names.
Names may need to be changed in queries.
New columns should be considered in queries.

Appendix I: Changes to This Version of RIS I - 7

I.8 Dictionary Views

In RIS Version 4 the internal RIS dictionary tables were documented with the note that they
are not intended for application use, and information about them was maintained in the
dictionary. In RIS Version 5, the internal tables are not documented and information about
them is not available in the dictionary. Only dictionary views can be accessed from an
application.
In RIS Version 4 the dictionary views showed information about only the user (or
application) objects and the base tables contained both application objects and RIS dictionary
objects. In RIS Version 5, since the base tables are not accessible from the applications, the
views show both user objects and RIS objects.
Considerations:
If only user objects need to be selected, the condition ris_object=N should be used in the
where clause.
This rule applies to the views ris5columns, ris5column_privs, ris5tables, and
ris5table_privs.
In RIS Version 4 the views risdbms_tables, risdbms_views, and risdbms_indexes, listed
the objects, views, and indexes, respectively, that were in the database, but not
included in the schema. Due to the RIS Version 5 capabilities allowing objects of
different users within a schema and shared dictionaries, the exact equivalent of the RIS
Version 4 views cannot be provided. In Version 5, the ris5dbms_tables view lists all the
tables in the database, along with the user that owns the database. The ris5dbms_views
view lists all the views in the database, along with the user that owns the database.
The ris5dbms_indexes view lists all the indexes in the database, along with the user
that owns the database. In some cases, these lists may include only those
tables/views/indexes accessible to the current log-in/user of the database.
These views are not recommended for use by applications. If used, the
query should have some restrictive condition (specifically, WHERE).
Using select * from these views can lead to significant performance
degradation. Since this view is defined to show everything, it should be
used with caution. In some cases these views are accessible only for the
dictionary creator since some databases do not allow granting system
privileges on catalogs (where these views are defined).

I-8

Appendix I: Changes to This Version of RIS

I.9 RIS_BLOB/RIS_TEXT
RIS Version 5 allows long binary or long text data that lets you:
Use it for document or picture storage by INFORMIX OnLine and ORACLE. RIS has no
RIS_BLOB/RIS_TEXT support for INFORMIX Standard Engine, SYBASE, Microsoft
SQL Server, or DB2.
Insert, update, or retrieve large data.
Access character strings with a length greater than 249 characters for other RDBMSs
not supporting RIS_BLOB.
Considerations when using this capability:
To use RIS_BLOB/RIS_TEXT data, the client and data server versions must be at least
05.01.01.xx.
This feature is available only through the programming interface; no interactive access
is available.
The application should track the data length.
The RIS_BLOB data type is for binary data; for example, GIF files, executables, and so
forth. RIS makes no attempt to convert or interpret the data.
The RIS_TEXT data type is for text data; for example, ASCII files. RIS does convert
the text data between different hardware platforms as it would for char data.
The text data can be inserted into a RIS_BLOB column, but no blob data should be
inserted into a RIS_TEXT column.
To create a table with a column of RIS_BLOB/RIS_TEXT data type
create table emp (name char(25), id int, picture ris_blob (50000))

The default size of the RIS_BLOB/RIS_TEXT column is 0. The maximum length of the
data is dependent on the database. If the maximum data size is set to 0, data can be
retrieved from the database to a memory array and not a file.
The file_used field is required for inserting and retrieving. RIS uses the filename or the
memory array as the targeted user variable.
The text data and character data are converted for different hardware platforms.
The maximum size limit cannot be zero when retrieving data from the database. The
maximum size limit is zero when retrieving data from memory.
RIS_BLOB/RIS_TEXT columns cannot be used in the SQL WHERE clause or GROUP
BY statements, and cannot be indexed.

Appendix I: Changes to This Version of RIS I - 9

The number of RIS_BLOB/RIS_TEXT columns allowed in one table is subject to the

restrictions of the underlying RDBMS. INFORMIX allows multiple
RIS_BLOB/RIS_TEXT columns while ORACLE allows one RIS_BLOB/RIS_TEXT
column per table.
The size of RIS_BLOB/RIS_TEXT is subject to the restrictions and limitations of the
underlying RDBMS.
Tables with RIS_BLOB/RIS_TEXT are created through RIS and data is inserted
through RIS.
Currently, RIS uses the first 8 bytes (ORACLE only) of the RIS_BLOB/RIS_TEXT column in
databases to store the length of the data. Existing tables with data, when included in a RIS
schema, will result in incomplete data when retrieved from the database. To manipulate
RIS_BLOB/RIS_TEXT data, any tables with RIS_BLOB/RIS_TEXT fields need to be created
through RIS and the data inserted only through RIS.
When the maximum size limit for a RIS_BLOB/RIS_TEXT column is zero, data cannot be
retrieved from the database to a file. This situation does not apply when the data is retrieved
into a memory array.
If a positive, non-zero value is used, RIS will use this value as the maximum size limit for the
RIS_BLOB/RIS_TEXT object. If the value is zero, or no value is specified (using default of
zero), then RIS does not impose a limit and the maximum size supported by the underlying
RDBMS can be used.
The limit size can be set to zero in the following situations:
An existing table which has RIS_BLOB/RIS_TEXT columns is included in a RIS
schema
A table is excluded from the RIS schema and later included back into the schema
A table is created through RIS without specifying a RIS_BLOB/RIS_TEXT column size.
To check the value of the maximum size limit:
select char_max_length from ris5columns
where table_name = table and column_name = column;

I - 10

Appendix I: Changes to This Version of RIS

To reset the maximum size limit use risdtype:

c:\risdtype
Enter schema (<CR> to exit) :sch1
Enter a table or view name (or ? for a list of names):
>blob_table
Pos
Column Name
type type-string len
prec
scale null
1
c1
15
ris_blob
10000 null
null
Yes
Do you wish to modify this column? <y(es), n(o), d(one with table)>>y
0 Unsupported
1 Character
2 RIS_BLOB
3 RIS_TEXT
Choose a datatype from those listed (enter the number) >>2
Current maximum ris_blob length is:0
Current maximum ris_blob length is:10000
Current status for nullable is YES, nulls are allowed
Are null values allowed? <y(es), n(o)> >>y
Column definitions modified for object sch1.blob_table:
Pos
Column Name
type type-string len
prec
scale
1
c1
15
ris_blob
10000 null
null

null
Yes

Is this correct? <y(es), n(o), q(uit> >>y

In the above example, RC01 is the dictionary owner as shown in the schema file, blob_table
is the name of the table with a blob column, set to values other than 10000.
RIS limits the data size inserted into a RIS_BLOB/RIS_TEXT column if a size is specified
when the table is created.
For example:
create table blob1 (c1 ris_blob(100000))

would impose a limit of 100,000 bytes. If the table is created without specifying a size, then
the underlying RDBMSs maximum limit for RIS_BLOB/RIS_TEXT data will be used.
For example:
create table blob2 (c2 ris_blob)

Appendix I: Changes to This Version of RIS I - 11

I.10 Interoperability
RIS Version 5 lets multiple versions of RIS products be available on most systems. The
following figure details interoperability of RIS Version 4 and RIS Version 5.

This capability:
Lets you continue to use RIS Version 4 applications with minimal impact. Version 4
applications should continue to run.
Considerations when using this capability:
RIS Client and Data Servers should be upgraded to RIS Version 5.
Multiple versions are available remotely through TCP only.
The ORACLE 7 Data Server requires the RIS Version 5 Client.
The Sybase SQL Data Server requires the Version 5.02 Client.
Only RIS Version 5 applications can query RIS Version 5 dictionary objects. Only RIS
Version 4 applications can query RIS Version 4 dictionary objects.
The RIS utilities are also applications and the previous restrictions apply.
The risdtype utility of RIS Version 4 cannot be used with the RIS Client Version 5 or
the RIS Data Server Version 5.
Files generated by the RIS Version 4 risrecrd utility cannot be processed by the RIS
Version 5 risplbck utility. If an application is built with RIS Version 4, the resulting
record file can be processed only by the RIS Version 4 risplbck utility.

I - 12

Appendix I: Changes to This Version of RIS

I.11 Upgrade Utility

A utility to convert a schema (dictionary and schema file) from RIS Version 4 to RIS Version
5 is delivered with the RIS Client.
While RIS Version 4 is not available for Solaris, the upgrade utility can be used
to upgrade a Version 4 schema file on another platform (for example, CLIX).

Considerations when using this utility:

This conversion should be applied to every existing schema when RIS Version 5 Data
Servers are installed.
The RIS Version 4 Data Servers should be removed.
The conversion of the dictionary is irreversible and is done in-place.
The schema file conversion is non-destructive. The Version 5 schema file is generated
from the Version 4 schema file. This feature lets you mix Version 4 and Version 5
clients to access a Version 5 data server. The schema file that matches the client
version should be used.

I.12 Utilities
The RIS Version 4 ad hoc utility ris has been renamed risbatch. There is now an ad hoc
query utility with a graphic user interface (GUI), called risgui.
Considerations when using the Version 5 loader/unloader:
The loader/unloader provides no BLOB support.
The unloader unloads (or saves) RIS names (aliases) only, not the underlying object
names.
The unloader unloads (or saves) schema ownership only, not underlying RDBMS
ownership.

I.13 Parameters
The parameter file generated by a Version 5 application or utility is compatible with Version
4 applications. In Version 4, if a parameter file existed, all parameters were expected to be
set. Unlike Version 4, Version 5 is more tolerant with respect to parameter files: any number
of parameters can be left unspecified and RIS uses the default values.
A new parameter, CLIENT_VERSION, has been added with the default value set to 0.0,
meaning that the application connects to a compatible client. When future versions of RIS
become available, Version 5 and higher applications will be able to use this parameter to
specify the client version.

Appendix I: Changes to This Version of RIS I - 13

Using this parameter causes Version 4 applications to fail; hence, for now, leave it
commented out. When the CLIENT_VERSION parameter is set, Version 4
applications can no longer use that parameter file.

I.14 Internationalization
RIS for 32-bit applications (Version 5.3.1 and later) support 16-bit or multi-byte languages.
Most 16-bit languages are Asian. In the RIS documentation, the maximum size allowed for
table names, view names, index names, schema names, column widths, and character data is
specified as x characters, where x is an integer. For those using multi-byte languages, the
maximum number of characters should be interpreted as the maximum size in bytes.
RISMGR and RISGUI implement multi-byte character support.
RIS limitations and guidelines:
RIS schema and user names can be internationalized, but not passwords.
Only alpha-numeric characters can be internationalized.
Setup is not fully internationalized.
RIS does not localize dialogs, gadgets and error messages.
RIS is internationalized on NT only. The RIS application, RIS Client, and RIS Data
Server must be on NT to take advantage of the RIS internationalization.
The period (.) used between username and passwords must be 8-bit English.
All punctuation, keywords, column datatype definitions, timestamp data, statements
must be 8-bit English.
Schemas, tables, views, columns, index names can be 8-bit or 16-bit characters.
RIS data dictionary tables and views are created using 8-bit English characters.
The following components of a create schema statement are 8-bit and 16-bit characters:
create schema
schema name
schema pass
db type
dbname
db dir
osuser
ospass
ostype
db user
remote clause

8-bit English
8-bit and 16-bit English
8-bit English
8-bit English
8-bit and 16-bit English
8-bit and 16-bit English
16-bit English
8-bit English
8-bit English
8-bit and 16-bit English
8-bit English

I - 14

Appendix I: Changes to This Version of RIS

Character columns are analyzed to make sure that they are wide enough to hold the data.
For example, a 10 character name in a 16-bit language requires a char(20) column.
The maximum number of 8-bit characters in a column is 240. The maximum number of 16bit characters in a column is 120.

Glossary GL - 1

Glossary

__________________________________________________________________________________________________________________________________________________

GL - 2

Glossary

Glossary GL - 3

Glossary

__________________________________________________________________________________________________________________________________________________

absolute pathname

Sequence of directories, beginning with the root directory (/)

that locates a file. See also pathname and relative pathname.

accept

Receive input, such as characters, integers, or data buttons.

Also, confirming an element selection.

access

Perform actions necessary to use software.

activate

Change the state of an object or entity so that it accepts

and/or displays data.

ad hoc query

Query formulated at runtime by input from a user or by the

program itself.

address

Label, name, or number that identifies an exact storage

location in memory.

address expression

Expression which evaluates to the address of a data item.

alias

Line added to start-up file that lets you start the software
without having to key in the full pathname each time you
want to use the software.

ANSI

Acronym for American National Standards Institute, a

private organization that develops, maintains, and publishes
industry standards in the United States.

application

System of programs and/or utilities designed to accomplish

specific tasks as requested by the user.

arithmetic expression

Algebraic formula consisting of arithmetic operators, constant

values, variables, and algebraic grouping symbols.

array

Data structure used to organize data into contiguous lists.

ASCII

American Standard Code for Information Interchange

character set.

attribute

Characteristic of an element. See parameter.

attribute, database

Characteristic. Also known as a field or column.

bar menu

Strip at the top of the screen that contains icons for selecting
commands.

GL - 4

Glossary

bit

Binary digit represented by a 1 or 0. Smallest unit of storage

in a digital computer.

block

Unit of storage which usually equals the amount of data that

can be read from or written to the storage device. For
example, most disk drives read or write a minimum of 512
bytes. Therefore, the block size of most disk drives is 512
bytes.

buffer

Data area.

byte

Group of bits forming a unit of storage in a digital computer.

A byte usually consists of 8 bits but may contain more or
fewer depending on the model of computer. Bytes may also
contain error recognition information.

General-purpose, structured programming language

developed at Bell Labs in the early 1970s.

cache

To store frequently used information in a device that is faster

than the device it is usually stored in to improve performance.
For example, frequently used information that is usually
stored on a hard disk drive can be cached in memory which is
considerably faster.

catalog

Table of files, arranged systematically, containing required

and user-defined file attributes.

char

Data type which stores one character.

character

Alphabetic letter, digit, punctuation, or symbol.

class

Consists of the definition of the data structure for an object

(called an instance of the class), a set of messages which may
be sent to instances of the class, and a set of methods which
are invoked on those objects by the delivery of a message.

clearinghouse

Network wide, distributed database used, mainly, to bind

nodenames to network addresses.

client

Portion of a client/server based application that requests

services.

CLIX

Version of the UNIX operating system ported to run on

Intergraph systems.

code page

Set of characters that a numeric value is associated with and

also referred to as a character set or charset.

collapse

Changing a form or window from the normal display to a

small icon representing the collapsed form or window.

Glossary GL - 5

column

Vertical arrangement of figures or words.

command

Software that interacts with the user, obtaining user input

and then acting in a specified way based on that input. Each
icon on the menu accesses a command, although there may
also be additional commands accessed only by key-in.

command line

Alphanumeric key-ins used to invoke an executable directly

from the operating system environment.

communication
protocol

Rules or standards defining communication and data transfer

between two or more computer devices.

compile

Translate a program written in some programming language

into machine language or assembly language.

compress

Process that eliminates gaps, empty fields, redundancies, or

unnecessary data in a file so that the size of the file is
reduced.

configuration file

A system defined and user configurable file containing

settings that control environment variables.

constant

Value that remains unchanged during a programs execution.

cursor

Pointer that the user moves on the screen to indicate an item

or area.

cursor statement

Embedded SQL statement requiring a cursor data area; that

is, a select statement.

Data Definition
Language

(DDL) Subset of the ANSI SQL Standard statements which

defines the schemas and relations of a database.

data dictionary

Either a filed object space that contains information about the

classes that make up an application or a set of ASCII files
created by a utility called a data dictionary processor (ddp).

data dictionary,
database

Set of data that describes the format in which an application

stores its data. In RIS, the data dictionary stores information
about the databases, schemas, users, tables, and views.

Data Manipulation
Language

(DML) Subset of the ANSI SQL Standard statements which

manipulate the data contained in a table.

data point

Point entered with the mouse or with a precision key-in,

which specifies a position in a drawing file.

data structure

Structure whose components are data objects. Data

structures are used to group logically related data.

GL - 6

Glossary

data type

Classification of a data item as an integer, letter, or real

number.

database

Collection of comprehensive informational files having

predetermined structure and organization that can then be
communicated, interpreted, or processed by a specific
program.

database
administrator

User on a database or a schema defined on that user which

has complete access to all data defined on a database.

database privilege

Privilege granted to a schema regarding its access to a

database.

DB2

Relational database management system.

DBA

Acronym for Database Administrator or DB Access.

DDL

Acronym of Data Definition Language.

debug

Locate and correct errors in the syntax or logic of program

source code.

declaration

Programming statement that provides information about a

variable, function, or data type but does not perform any
operation.

default

Predetermined value of a parameter or option that is

automatically supplied by the system or program whenever a
value is not specified by the user.

default schema

Schema in which statements are issued unless another

schema is specified (a RIS concept).

delete

To remove, destroy, eliminate, or erase.

delimiter

Separating mark or space; a character or sequence of

contiguous characters that mark the end of a string of
characters.

detach

To dismiss, separate, disengage, withdraw, or discontinue an

association.

development platform

Base or foundation of software on which application programs

can be built.

device

Nonaddressable component of a network, that is, a component

onto which a user cannot log, for example, tape drive, disk
drive, and floppy disk.

Glossary GL - 7

directory system

Directory structure that contains the information for a design

file.

disk

Round flat plate coated with a magnetic substance on which

data is stored.

DML

Acronym of Data Manipulation Language.

double

Data type which stores a range of floating point numbers.

The storage requirement and range of values are dependent
on the computer and compiler.

double precision

Data type which stores a range of floating point numbers.

The storage requirement and range of values are dependent
on the computer and compiler.

drop

To discontinue current status or association; to return to a

previous or more primitive status or association; to descend
levels.

dynamic SQL
statement

Embedded SQL statement that is not known until the

program is executed.

EMACS

ASCII text editor.

Embedded SQL
Interface

Set of embedded SQL statements that interface applications

with an RDBMS.

Embedded SQL
Statement

SQL statement that can be embedded (or placed) in host

programming language source code.

enter

To enter data from a mouse or from a keyboard.

entity

Graphic or descriptive component in a graphics file. Can also

mean a database table.

environment variable

Variable defined on or across invocations of a command shell.

Processes are given access to the information in these
variables by the operating system.

error handler

Subroutine or group of statements that are executed when an

error occurs, and are designed to react to the error.

error message

Description of an error found in a program.

Ethernet

Popular implementation of a local area network.

exception

Condition caused by an attempt to perform an erroneous

operation.

GL - 8

Glossary

exception handler

Subroutine or group of statements that are executed when an

exception occurs, and are designed to react to the exception.
Also known as an error handler.

executable

Program that has been written in or translated into, a

machine language that is ready for execution by the
computer.

exit

To terminate a job or process.

field

Any of the data grouped together in a record (also known as

an attribute or column). Also, a gadget allowing text entry on
a form.

file

Collection of logical records stored as a unit.

filename

User-defined name given to an interactively created file. The

name should be relevant to the contents of the file.

float

Data type which stores a range of floating point numbers.

The storage requirement and range of values are dependent
on the computer and compiler.

floating point
notation

Notation describing a real number value. It consists of a

fractional value multiplied by an exponent.

floating point number

Real number value in floating point notation.

font

Complete set and style of the characters and symbols of a

typeface used for displaying text.

full pathname

Name of the entire path or directory hierarchy to a file,

including the filename. See also relative pathname.

function

Small segment of code written to complete a portion of a

larger task.

grant option

Relation privilege which gives a schema the ability to grant

relation privileges to other schemas.

graphic

Any symbol or method of visual communication that is not

text.

Help

See on-line Help.

Help window

Form in which the Help topics are displayed by the Help

process.

home directory

Directory recognized by the operating system as root of a

users own directory system. In UNIX, the environment
variable HOME is set to this directory.

Glossary GL - 9

host variable

Variable defined in host language source code and used in an

embedded SQL statement.

icon

Symbol that graphically identifies a command, application, or

document.

ID

Name comprised of numbers or characters given for

identification purposes to a record. A record number.

identify

To locate an element on the screen by tapping the mouse on it

or by keying in the name from the keyboard.

index

Storage mechanism used to provide faster access to the rows

in a table.

indicator variable

Variable defined in host language source code and used in an

embedded SQL statement to indicate the usage of a NULL
value.

INFORMIX

Relational database management system.

initialize

To set storage location, counter, variable, internal structures,

or the like to a beginning value.

int

Data type which stores a range of integer values.

integer

Value in the set of all positive and negative whole numbers

and zero. Also, a data type which stores a range of integer
values. Storage requirement and range of values are
dependent on the computer and compiler. Of or relating to
the process of entering data and receiving a response from the
computer.

interactive

Of or relating to the process of entering data and receiving a

response from the computer.

interface

Shared boundary through which the user and software

communicate.

I/ORL

Intergraph On-line Reference Library. Provides easy access

to Intergraph documentation on compact disk.

item

Unit of storage within a larger unit, such as a file in a catalog.

joining

Process of relating the data in two or more tables, possibly

restricted by some condition.

keyword

Word defined to have special meaning in a programming,

command, or query language.

GL - 10

Glossary

kill

To terminate a job or process without saving any changes or

entered data.

LAN

Acronym for Local Area Network.

library

Collection of subroutines.

link

Combine one or more program segments, subroutines, or

library routine into a single executable program.

local area network

Computer networking scheme in which nodes which are

geographically local are connected to a network through
multiplexers, and networks of geographically remote nodes
are connected through routers.

log in

Enter the necessary information, such as a username and/or

password, to begin a session on a terminal.

log-in

Username/password combination used to gain access to a

computer.

macro, RIS

Mechanism which allows strings to be assigned symbolic

names and to be replaced by their full values at a later time.

map

Outline of correspondence between the members of one set of

data and the members of another set of data.

memory

Device that can store data.

menu

Means for storing and selecting commands: icon-based,

function key, or paper.

mode

Particular functioning arrangement or condition. Also, the

behavior of a gadget.

model

Graphic representation or schema.

mouse

Hand-controlled input and command selection device. There

are several models; most common are the 2-button mouse, the
3-button mouse, and the 12-button mouse.

network

Interconnection of host computers and workstations that

enables them to share data and control. The term network
can mean the devices that connect the system, or it can mean
the connected system.

node

Any non-addressable component of a network, that is, any

component of the network onto which a user can locally or
remotely log.

Glossary GL - 11

nodename

Symbolic name given to each device on an ethernet network

which can be translated into a network address.

non-cursor statement

Embedded SQL statement that does not require a cursor data

area; that is, all statements other that the select statement.

NULL

Indicates no value.

on-line Help

Set of on-line, context sensitive files, that provide information

to the user about the capabilities of an application.

operating system

System programs that control the overall operation of a

computer system.

operator

Symbol that indicates that an arithmetic, logical, or relational

operation is to be performed.

ORACLE

Relational database management system.

parameter

Property that associates a variable name with a value.

parameter, RIS

Mechanism for representing an unknown value in a

subroutine call or a host variable in an embedded SQL
statement.

password

Word that is entered during log in that prevents unauthorized

people from using the file, software, or computer.

path

Sequence of directories leading to a file or a sequence of

menus leading to a command.

pathname

Sequence of directories leading to a file. See absolute

pathname and relative pathname.

portable

Designating a program that is easily executed (or can be

easily modified to execute) on multiple computers or software
systems.

preprocessor

Program that performs some type of calculation or

manipulations on the data in a file, usually in preparation for
another process.

privilege

Described by the ANSI SQL Standard. A privilege is a right

to access. For example: a relation privilege is a right to
access a relation (table or view) within a database.

process

Entity comprised of a program or series of programs.

prompt

Text displayed by a command that tells you the inputs

expected by that command.

GL - 12

Glossary

query

A search in a database.

quit

Terminate a job or process without saving any changes or

data entered. Also, to dismiss a form without processing any
changes.

RDBMS

Acronym for Relational Database Management System, the

software that lets you organize, store, and manipulate data in
a database.

real

Data type which stores a range of floating point numbers.

The storage requirement and range of values are dependent
on the computer and compiler.

record

Grouping of logically related data which may be manipulated

as a single entity. One or more records make up a file or a
table. Also known as a row or tuple.

relation

Table or view.

relation privilege

Privilege granted to a schema regarding its access to relations

in other schemas.

relational database

Organizes data in two-dimensional tables in order to define

relationships.

relational database
management system

Database management system that adheres to concepts

defined by the relational database model.

Relational Interface
System

Intergraph software system that provides a generic interface

for applications to access many popular relational database
management systems.

relative pathname

Sequence of directories leading from the current directory to a

particular file. See also pathname and absolute pathname.

report

Standard and user-definable table format for information

queried from the database.

requester

See client.

RIS

Acronym for Relational Interface System, the software that

allows communication to different relational database
management systems.

routine

Set of functions constructed to process specific information.

row

Grouping of logically related data which may be manipulated

as a single entity. One or more rows make up a file or table.
Also known as a record or tuple.

Glossary GL - 13

run

To execute a program or process.

runtime

Time at or during which a program or process is executed.

scalar data type

Simple data type. For example, integer, character, real.

scale

To enlarge or reduce the size of a defined element, modifying

only the dimensions, not the ratio among the pieces.

schema

Concept described by the ANSI SQL Standard as a collection

of tables and views. Within RIS, this collection corresponds to
the collection of tables and views owned by a user within a
database.

scripts

C-like statements that let you further customize reports.

scroll

To move vertically or horizontally through displayed text,

symbols, or windows.

select

To activate a command. This can be done by the user or

software.

semaphore

Flag that prevents two or more UNIX processes from

accessing the same resource at the same time.

server

Computer connected to a network, which provides services to

one or more devices on that network. A server can also refer
to a process which provides services to one or more client
(requester) processes locally or remotely.

set

Grouping of items that can be manipulated as a single item.

Shamrock

Intergraph graphical user-interface toolkit for Windows NT.

shared library

Library from which several programs can call routines. The

code for the called routines is not copied into the executable
program at the time the program is linked. Instead, it is read
in (on demand) at runtime. This results in smaller executable
programs.

shared memory

(shmem) UNIX shared memory; that is, memory whose

protection and access is global to more than one process.

shell

Body of commands providing interface to low level software.

For example, a UNIX shell provides an interface between
users and the UNIX kernel.

short

Data type which stores a range of integer values. Storage

requirement and range of values are dependent on the
computer and compiler.

GL - 14

Glossary

signal

Mechanism provided by the UNIX operating system for

interprocess communication.

signal handler

Function designed to respond to a signal.

smallint

Data type which stores a range of integer values. Storage

requirement and range of values are dependent on the
computer and compiler.

SQL

Acronym for Structured Query Language.

SQL terminator

Semicolon (;). It is used to terminate an Embedded SQL

statement.

sqlda structure

ANSI Standard SQL structure used to represent information

about the sqlvar structures in an Embedded SQL statement.

sqlvar structure

ANSI Standard SQL structure used to represent information

about a parameter (variable) in an Embedded SQL statement.

statement

Word or group of words that has a specific meaning in a

programming language.

states

Steps that an item goes through from creation to completion.

static SQL statement

Embedded SQL statement that is known when the program is

created and is compiled into that program.

stop

Terminate a job or process.

string

Sequence of characters.

Structured Query
Language

Structured language designed for accessing relational

database management systems.

syntax

Rules governing the structure and use of statements in a

language.

system

Collection of information and processes designed to interact to

complete a task.

table

Collection of data for quick reference, stored in sequential

locations in memory or printed as an array of rows and
columns of data items of the same type.

table, database

Collection of data rows (also known as tuples or records) and

columns (also known as attributes or fields). A unit of storage
described by the ANSI SQL Standard.

tap

To quickly press and immediately release a button.

Glossary GL - 15

text editor

Utility that lets you create an ASCII file.

toggle

To switch; to change between two alternatives. Also, a state

gadget that can be used to change between two alternatives.

transaction

Concept described by the ANSI SQL Standard. A transaction

is a group of SQL Statements that affect the database
simultaneously or can be canceled simultaneously.

tuple

Record or a row.

type

Type of data that a programming variable may contain.

UNIX

General purpose timesharing system developed at Bell

Laboratories in the late 60s and early 70s.

user

Person who uses a computer.

user interface

End users means of communicating with the software,

including any of the means of entering values, selecting
commands, or locating elements. The menus and prompts are
examples of user interfaces.

value

Numeric or character data.

variable

Quantity that may assume any one of a set of values.

VAX/VMS

Computer/operating system combination. The VAX is a

family of processors manufactured and sold by Digital
Equipment Corporation. VMS is an operating system for the
VAX family.

version

The number associated with the specific release of a product.

vi

ASCII text editor available on many systems.

view

Concept described by the ANSI SQL Standard, used to

combine tables or restrict access to columns in a table. A view
looks and acts like a table, but does not actually store data.

virtual declaration

Mechanism in RIS which allows complex data types and

address expressions to be used in Embedded SQL statements.

virtual table

Synonym for view.

wildcard

Symbol representing any string of characters.

window

Independent rectangular area which displays applications or

documents and that can be moved, resized, reshaped,
minimized, or maximized.

GL - 16

Glossary

workstation

Terminal that contains an internal CPU and can operate in a

standalone mode or as part of a network.

XNS

Communication protocol used on the Ethernet network.

Index IN - 1

Index

__________________________________________________________________________________________________________________________________________________

IN - 2

Index

Index IN - 3

Index

__________________________________________________________________________________________________________________________________________________

A
access
grant 4-54 4-55, 4-57
revoke 4-65, 4-68
revoking 4-66
accessing
dictionary views I-7
add
columns 3-14, 4-10
alias 4-8
as clause 4-8
column 3-13
aliases
exclude/include sequences I-4
object I-4
within RIS I-4
all
privileges 3-23, 4-55, 4-66
alter
statement
schema 4-7
table 3-14, 4-10
table 3-14
alter schema 4-7
alter table 4-10
ANSI SQL
Standard 2-4, 3-3
application support 2-4
as clause 4-8
autocommit mode 4-70
B
binary data I-8
blob 3-11 3-12
BLOBS
programming interface I-8
BUFFER_FULL_SIZE F-9
BUFFER_FULL_TIMEOUT F-9
C
cancel
statement 4-70
transactions 3-29, 3-32, 4-70

character data type 3-11

choose 1-4
close
statement
schema 4-12
close schema 4-12
columns 3-11
adding 3-14, 4-10
aliases 3-13
data types 3-11
defining 4-33
definition 3-10
deleting indexes 4-47
dropping indexes 4-47
indexing 4-15
NULL values 3-13
select 3-15
selecting 3-15 3-16, 4-72
update 3-18
virtual naming of 3-20
commit 4-13
autocommit mode 4-13
for schema clause 4-13
multiple transactions 4-13
statement 3-29, 3-31, 4-13
transactions 3-29, 3-31, 4-13
work keyword 4-13
concepts 3-3
conditions 3-16, 4-88
configuration file
language H-3
connect
privileges 3-23
connecting to tables
granting and revoking authority I-5
create
database 3-9, 4-17
DB2 4-26
INFORMIX 4-21
Microsoft SQL server 4-31
ORACLE 4-24
SQL server 4-31
SYBASE 4-29
indexes 4-15

IN - 4

Index

create (continued)
schema 3-7, 3-9, 3-23 3-26, 4-17
DB2 4-26
INFORMIX 4-21
Microsoft SQL Server 4-31
ORACLE 4-24
SQL Server 4-31
SYBASE 4-29
schemas 3-9 3-10
statement
index 3-36, 4-15
schema 3-9, 3-24 3-26, 4-17, 4-21,
4-24, 4-26, 4-29, 4-31
table 3-11 3-12, 3-21, 3-24, 4-33
view 3-20 3-21, 3-26, 4-35
table 3-12 3-13, 3-24, 4-33
users 3-9, 4-17
view 3-20 3-21, 3-26, 4-35
views 3-20
create index 4-15
create schema
(DB2 Database Descriptor) 4-26
(Microsoft SQL Server Database
Descriptor) 4-31
(ORACLE Database Descriptor) 4-24
(SYBASE Database Descriptor) 4-29
create table 4-33
create view 4-35
creating
tables, granting and revoking authority
I-5
creating dictionaries I-6
cursors 3-31
D
data
including owned by privileged accounts
I-3
inserting large I-8
long binary I-8
long text I-8
retrieving large I-8
updating large I-8
Data Definition Language (DDL) statements
3-28
data dictionary C-3, 3-29
data types C-11
database type C-11
protocols C-12
RIS5COLUMN_PRIVS view C-4
RIS5COLUMNS view C-4

data dictionary (continued)

RIS5DBMS_COLUMNS view C-7
RIS5DBMS_INDEXES view C-8
RIS5DBMS_TABLES view C-9
RIS5DBMS_USERS view C-9
RIS5DBMS_VIEWS view C-10
RIS5INDEX_COLUMNS view C-14
RIS5INDEXES view C-15
RIS5SCHEMAS view C-16
RIS5SCHPRIV view C-17
RIS5TABLE_PRIVS view C-17
RIS5TABLES table C-18
RIS5TABLES view C-18
RIS5USERS view C-19
RIS5VIEWS view C-20
Data Manipulation Language (DML)
statements 3-28
data type
RIS_BLOB I-8
RIS_TEXT I-8
data types B-3, 3-11
ANSI SQL 3-12
blob(n) 3-12
char B-3
character B-3, 3-11
DB2
char D-5
decimal D-5
double D-5
float D-5
integer D-5
real D-5
smallint D-5
timestamp D-5
varchar D-5
decimal B-3, 3-12
double B-3, 3-11
float B-3, 3-11
general information D-3
INFORMIX
char D-8
datetime D-8
decimal D-8
double D-8
float D-8
integer D-8
real D-8
ris_blob D-8
ris_text D-8
smallint D-8
timestamp D-8

Index IN - 5

data types (continued)

INFORMIX (continued)
varchar D-8
int B-3
integer B-3, 3-11
mapping
DB2 to RIS D-5
INFORMIX to RIS D-7
MSSQL to RIS D-13
ORACLE to RIS D-9
RIS to DB2 D-5
RIS to INFORMIX D-7
RIS to MSSQL D-13
RIS to ORACLE D-9
RIS to SYBASE D-11
SYBASE to RIS D-11
MSSQL
decimal D-14
double D-14
float D-14
integer D-14
money D-14
real D-14
smallint D-14
text D-14
timestamp D-14
ORACLE
char D-9
decimal D-9
double D-9
integer D-9
long D-9
real D-9
ris_blob D-9
ris_text D-9
smallint D-9
timestamp D-9
real B-3
ris_blob(n) 3-12
ris_text 3-12
smallint B-3, 3-11
SYBASE
decimal D-12
double D-12
float D-12
integer D-12
money D-12
real D-12
smallint D-12
text D-12
timestamp D-12

data types (continued)

text 3-12
timestamp B-3, 3-12 3-13
database 3-3, 3-7 3-8
administrator 3-9, 3-23 3-26
bulk loading 3-36
columns 3-36
create
DB2 4-26
INFORMIX 4-21
creating 3-9, 4-17
DB2 4-52
DDL statements 3-23
definition 3-3
deleting 4-48
descriptor
DB2 4-26
INFORMIX 4-21
Microsoft SQL Server 4-31
ORACLE 4-24
SQL Server 4-31
SYBASE 4-29
DML statements 3-23
dropping 4-48
indexing 3-36
INFORMIX 4-52
INGRES 4-52
management systems
definition 3-3
Microsoft SQL Server 4-52
ORACLE 4-52
OS400 4-52
privileges 3-23
Rdb 4-52
servers
limits 4-63
SYBASE 4-52
tables 3-36 3-37
users 3-3
vendor
executing SQL 4-52
databases
multiple schemas in I-6
DB2 D-5
users 4-19
dba
privileges 3-23
DBMS
create schema 4-17
exclude table/view/index clause 4-9
include index clause 4-8

IN - 6

Index

DBMS (continued)
include table clause 4-8
include view clause 4-8
users 4-19
dbms_owner I-4
DDL statements 3-23, 3-28 3-29
alter schema 3-29
alter table 3-29
create index 3-29
create schema 3-29
create table 3-29
create view 3-29
drop index 3-29
drop schema 3-29
drop table 3-29
drop view 3-29
grant 3-29
revoke 3-29
decimal data type 3-12
declare schema 3-8, 4-37
declare schema statement I-5
declare table 4-40
declare view 4-42
no verify 4-42
verify 4-42
default
schema 3-8 3-10, 3-25
set 4-44
statement
schema 3-8 3-9, 3-25, 4-44
default schema 4-44
defining columns 4-33
definition of schema in RIS 5 I-3
delete 4-45
data from views 3-21, 3-23
databases 4-48
DML statement 4-45
indexes 4-47
privileges 3-24, 4-55, 4-66
relation identifier 4-45
rollback 4-45
rows 3-19
schemas 4-48
statement 3-10, 3-19, 3-21, 3-23, 3-30
table 3-14
table data 3-19
tables 4-50
users 4-48
views 4-51
where clause 4-45

dictionary 3-39
adding schemas to I-6
creating I-6
creation I-6
objects I-6
shared I-6
shared dictionary 3-39
views
accessing from application I-7
information in I-7
Dictionary Converter C-22
DML statements 3-23, 3-28 3-29, 4-14
delete 3-29
insert 3-29
select 3-29
union 3-29
update 3-29
document conventions 1-4
double data type 3-11
drop
databases 4-48
indexes 4-47
schemas 4-48
statement 3-10
index 4-47
schema 4-48
table 3-14, 4-50
view 3-20, 4-51
table 3-14
tables 4-50
indexes 4-50
views 4-50
tables referenced by views 3-14
view 3-20
views 4-51
drop index 4-47
drop view 4-51
dropping schemas I-6
dropschema 4-48
E
environment variable
INFORMIXDIR 4-21
RIS_PARAMETERS F-4
environment variables F-4
examples 3-37
exclude table/view/index clause 4-9
exclude/include sequences I-4
exec 4-52
executing
vendor SQL 4-52

Index IN - 7

extern clause 3-13

external objects 3-39
using 3-39
F
Features of RIS 2-3
fields
definition 3-10
float data type 3-11
functions
sql 4-94
G
grant 4-54
option 3-27
privileges 3-23, 4-54 4-55, 4-57
with grant option 4-55
statement 3-23, 3-25 3-27
public keyword 3-23
GRANT CONNECT TO I-5
GRANT RESOURCE TO I-5
GRANT SCHEMA TO I-6
grant (to schema) 4-55
grant (to user) 4-57
group by clause 3-21
H
Hardware and Software Platforms 2-5
having clause 3-21
Help
using on-line 1-6
I
IBM
CICS 4-8
modify password 4-8
identifiers 4-3
identify 1-4
include index clause 4-8
include sequences I-4
include table clause 4-8
include view clause 4-8
including data owned by privileged accounts
I-3
indexes 3-36
columns 4-15
composite 4-15
creating 3-36, 4-15
deleting 4-47
dropping 4-15, 4-47
INFORMIX 4-15

indexes (continued)
limits 4-16
unique 3-36, 4-16
with same name I-4
INFORMIX D-7
create schema 3-9
data types 4-21
transactions 3-31
users 3-4, 4-19
INFORMIXDIR 4-21
INGRES
users 4-19
INITIAL_TIMEOUT F-8
insert 4-59
data into views 3-21
into views 3-21
multiple values 3-18
privileges 3-24, 4-55, 4-66
rows 3-17 3-18, 4-59
statement 3-10, 3-17, 3-21, 3-30
column list 3-17
values list 3-17
table data 3-17, 4-59
values clause 4-60
view data 4-59
inserting large data I-8
integer data type 3-11
Introduction to RIS 2-3
J
join
table 3-16
tables 3-15 3-16, 4-72
views 4-72
K
key in 1-4
L
language
descriptions 4-6
language configuration file H-3
limits
character columns E-3
column names E-4
database servers 4-63
DB2 specific E-4
decimal columns E-3
file path size E-4
local servers 4-63
macro names E-4

IN - 8

Index

limits (continued)
node name E-4
number of columns E-3
password size E-4
RIS E-3
row length E-3
list
data types B-3
local servers
limits 4-63
lock
statement
tables 4-61
tables 4-61
lock tables 3-31, 4-61
INFORMIX 3-34
LOCK_FILE_RETRY F-11
long binary data I-8
long text data I-8
M
MAX_BUFFER_SIZE F-6
MAX_LOCAL_SERVERS F-6
MAX_LOCAL_SERVERS variable 4-63
MAX_ROWS F-6
MAX_SECONDARY_SCHEMAS F-7
MAX_STATIC_STMTS F-7
MAX_TABLES_IN_MEM F-8
MAX_TRANSACTIONS F-7
MAX_USER_STMTS F-7
Microsoft SQL Server D-13
users 4-19
miscellaneous statements 3-28
modes
disabling 4-75
enabling 4-75
setting ANSI 4-75
setting verify 4-75
modify
db2 password clause 4-8
node 4-7
osuser 4-8
remote 4-8
schema password 4-7
user password 4-7
modify remote clause 4-8
mouse 1-4
MSSQL D-13
multiple transactions
MAX_TRANSACTIONS variable 4-13

N
name
schemas 3-7
names, aliases I-4
nested query 3-18, 3-21, 4-92
network
set verification 4-77
NETWORK Error
NET_E_CONNECT_ERROR 5-3
NET_E_READ_BUFFER_TOO_SMALL
5-4
NET_E_READ_ERROR 5-4
Network Protocols
TCP/IP 2-4
Network Support 2-4
network verification parameters F-8
node
clearinghouse 4-8
Ethernet address 4-8
modify 4-7
modify remote 4-8
protocols 4-8
nodes
schema
remote clause 4-18
not null clause 3-13, 3-21
NULL clause 3-13
O
objects
aliases I-4
dictionary I-6
of different owners within a schema I-3
ownership I-3
sharing among schemas I-3
on-line Help 1-6
open
schema 3-8, 4-63
statement
schema 4-63
open schema 3-8, 4-63
operating system
osuser 4-8
operators
UNION and UNION ALL I-3
ORACLE D-9
create schema 3-9
data types 4-24
sqldba 4-8
SQL*Net
and schemas 4-24

Index IN - 9

ORACLE (continued)
users 3-4, 4-19
order by clause 3-21
osuser
modify 4-8
ownership of objects I-3
P
parameters
client process location F-4
file F-3
LOCK_FILE_RETRY F-4
MAX_BUFFER_SIZE F-4
MAX_LOCAL_SERVERS F-4
MAX_ROWS F-4
MAX_SECONDARY_SCHEMASy F-4
MAX_STATIC_STMTS F-4
MAX_TABLES_IN_MEM F-4
MAX_TRANSACTIONS F-4
MAX_USER_STMTS F-4
network verification parameters F-4
schema definition file location F-4
SHARED_MEMORY F-4
parameters file F-3
parms file F-3 F-4
parts of the Help window 1-6
password
IBM 4-8
INFORMIX 4-8
INGRES 4-8
Microsoft SQL Server 4-8
modify 4-7
modify db2 4-8
ORACLE 4-8
Rdb 4-8
SYBASE 4-8
passwords
RIS I-5
stored for schema I-5
Performance 2-4
privileged accounts
including data owned by I-3
privileges 3-5, 3-8, 3-23
all 3-23 3-24, 4-55
column list 4-55, 4-66
connect 3-23, 4-54, 4-57, 4-65, 4-68
database 3-23
dba 3-9, 3-23
delete 4-55
deleting 3-24
grant 3-23, 3-26 3-27, 4-54 4-55, 4-57

privileges (continued)
grant to public 3-23
grant (to schema) 4-55
grant (to user) 4-57
insert 3-24, 4-55
relation 3-23
relation identifier 4-55
resource 3-23, 3-25, 4-54, 4-57, 4-65,
4-68
revoke 4-65, 4-68
revoke (from user) 4-68
revoking 3-23, 3-27, 4-66
revoking from public 3-23
sample usage 3-24
schema 4-54, 4-57, 4-65, 4-68
schemas 3-23
select 3-24, 4-55
update 3-24, 4-55
with grant option 3-27, 4-55
protocols
and schemas 4-18
dnp 4-8, 4-18
tcp 4-8, 4-18
xns 4-8, 4-18
public schema 3-23
Q
queries
changing object names I-6
nested 3-18, 3-21, 4-92
R
Rdb
users 4-19
RDBMS
logins I-5
schemas 3-5
security tracking I-5
table 3-10
users 3-4
versions, compatible with RIS 5 I-3
records
definition 3-10
references 1-3
relation 3-11
and schemas 3-8
definition 3-10
in other schemas 3-8
privileges 3-23, 4-55, 4-66
relational database management systems
definition 3-3

IN - 10

Index

remove
view 3-20
reserved words A-3
DB2 A-5
INFORMIX A-5
Microsoft SQL A-12
MSSQL A-12
ORACLE A-9
SYBASE A-11
reset 1-4
resource
privileges 3-23, 3-25
retrieving
large data I-8
revoke 4-65
privileges 4-65, 4-68
statement 3-23, 3-27
public keyword 3-23
REVOKE CONNECT FROM I-5
revoke (from schema 4-66
revoke (from schema)
privileges 4-66
statement 4-66
revoke (from user) 4-68
REVOKE RESOURCE FROM I-5
REVOKE SCHEMA FROM I-6
RIS
ANSI SQL Standard support 2-4, 3-3
AS/400 support 2-5
client 3-35
concepts 3-3
data dictionary 4-40, 4-42
DB2 support 2-4 2-5
environment variables F-4
features 2-3
INFORMIX support 2-4 2-5
INGRES support 2-4 2-5
Intergraph platform support 2-5
introduction 2-3
Microsoft SQL Server support 2-4 2-5
need for 2-3
network verification 3-35
networking 2-4, 3-9
object ownership I-3
operating parameters F-4
ORACLE support 2-4 2-5
OS400 support 2-4 2-5
password storage I-5
PC DOS support 2-4
PC support 2-5
PC Windows support 2-4

RIS (continued)
performance 2-4
platforms supported 2-5
Rdb support 2-4 2-5
server 3-35
SQL Server support 2-5
SUN support 2-5
SYBASE support 2-4
users 3-3
VAX support 2-5
versions
interoperability I-11
RIS and DBMS Reserved Words A-3
RIS dictionary 3-4, 4-8
RIS Error
RIS_E_BAD_LOGIN (0x) 5-4
RIS_E_CANT_CREATE_SCHEMA_FILE
(0x8a94812a) 5-5
RIS_E_CANT_FREE_DICT 5-5
RIS_E_CANT_GET_SCHEMA_FILE 5-6
RIS_E_CANT_LOCATE RIS 5-6
RIS_E_CANT_OPEN_ID_FILE_WRITE
5-6
RIS_E_CANT_OPEN_LANGCONFIG_FILE
5-6
RIS_E_CANT_PUT_SCHEMA_FILE 5-6
RIS_E_CLIENT_DIED 5-6
RIS_E_CLIENT_NETWORK_ERROR
5-7
RIS_E_CRE_PROC_GET 5-7
RIS_E_CRE_PROC_TAB 5-7
RIS_E_DEFAULT_SCHEMA_DIED 5-7
RIS_E_INCONSISTENT_ADDRS 5-8
RIS_E_INCONSISTENT_DBPARMS
5-9
RIS_E_INTERNAL_ERROR 5-9
RIS_E_INV_OPEN 5-10
RIS_E_INV_OPEN_DB 5-10
RIS_E_INV_SYB_OPTION 5-10
RIS_E_INV_TABLE_NAME 5-11
RIS_E_INV_USER_SPEC 5-11
RIS_E_MISSING_DIR_DEF 5-11
RIS_E_NO_PROTOCOL 5-11
RIS_E_PROC_GET_MISS 5-12
RIS_E_SCHEMA_RESTARTED 5-12
RIS_E_SERVER_NETWORK_ERROR
5-13
RIS_E_UNKNOWN_SCHEMA 5-15
RIS Limits E-3
RIS Overview 3-3

Index IN - 11

RIS Reserved Words A-3

RIS Utility Error
RISUTL_E_INVALID_NEW_SCH 5-16
RISUTL_E_LEFT_DELIMITER_MISSING
(0x89ce88e2) 5-15
RIS V5 Schema and Dictionary Converter
C-22
risalpha utility I-12
RIS_BLOB I-8
risdbms_indexes I-7
risdbms_tables I-7
risdbms_views I-7
risgui utility I-12
RIS**NET Products 2-6
ris_object I-7
RIS_PARAMETERS F-4
RIS-supported dictionary views C-4
RIS_TEXT I-8
rollback 4-70
statement 3-29, 3-32
transactions 3-29, 4-70
rows 3-11
definition 3-10
deleting 3-19
insert 3-17 3-18
inserting 4-59
inserting multiple values 3-18
restricting
deletion 4-88
selection 4-88
update 4-88
select 3-15 3-16
selecting 4-72
union 4-84
update 3-18
updating 4-86
S
schema 3-3, 3-7 3-8
administrator
granting and revoking authority I-5
alter 4-7
ANSI SQL 3-5
closing 4-12
commit 4-12
create 3-7, 3-9 3-10, 3-24 3-26
DB2 4-26
force option 4-19
INFORMIX 4-21
Microsoft SQL Server 4-31
SQL Server 4-31

schema (continued)
create (continued)
SYBASE 4-29
creating 3-9, 3-23, 4-17
ORACLE 4-24
DB2
arch clause 4-26
env clause 4-26
gateway clause 4-26
host program clause 4-27
lu clause 4-27
mode clause 4-27
net_protocol clause 4-27
os clause 4-26
ostype clause 4-26
osuser clause 4-26
declare 3-8, 4-37
default 3-8 3-9, 3-11, 3-25, 4-10, 4-17
definition 3-5
deleting 4-48
dropping 4-48
INFORMIX
online engine 4-21
sqlexec 4-21
standard engine 4-21
Microsoft SQL Server
dsquery 4-31
ostype clause 4-31
osuser clause 4-31
multiple 3-9, 4-63
naming 3-7
on database clause 4-18
opening 3-8, 4-63
ORACLE
ostype clause 4-24
osuser clause 4-24
SQL*Net 4-24
privileges 4-57, 4-68
Rdb 4-18
referencing 3-10
relations 3-8
remote clause 4-18
restrictions 3-7
schema file 4-19
secure 3-6
set default 3-9
setting defaults 4-44
SQL Server
ostype clause 4-31
osuser clause 4-31
SYBASE

IN - 12

Index

schema (continued)
SYBASE (continued)
dsquery 4-29
filename 4-29
ostype clause 4-29
osuser clause 4-29
undeclare 4-81
with grant option 3-27
Schema
Standard 3-5
schema definition file G-3
BEGIN_GRANTEES and
END_GRANTEES G-4
DBID G-3
DBNAME G-3
DICTOWNER G-4
DIR G-4
DTYPE G-3
NETADDR G-4
OSPASS G-3
OSTYPE G-3
OSUSER G-3
PROTOCOL G-3
SCHEMA_FILE_ADDRESS F-10
SCHEMA_FILE_NAME F-10
SCHEMA_FILE_PASSWORD F-10
SCHEMA_FILE_PROTOCOL F-10
SCHEMA_FILE_USERNAME F-10
SCHNAME G-4
SCHOWNER G-4
SCHOWNPASS G-4
SECURE G-4
SERVER_VERSION G-4
schema definition file location F-10
Schema Management Utility 4-18
SCHEMA_FILE_ADDRESS F-10
SCHEMA_FILE_NAME F-10
SCHEMA_FILE_PASSWORD F-10
SCHEMA_FILE_PROTOCOL F-10
SCHEMA_FILE_USERNAME F-10
schemas
adding to dictionary I-6
definition file G-3
definition in RIS 5 I-3
dictionary creation I-6
dropping I-6
granting and revoking authority I-5
multiple in databases I-6
multi-user I-5
objects of different owners within I-3
passwords stored for I-5

schemas (continued)
secure I-5, 4-37
sharing objects among I-3
usernames stored for I-5
secure schema 3-6, 3-37
using 3-37
secure schemas I-5, 4-37
security I-5
tracking, RDBMS I-5
violations, including data without I-3
select 1-4, 4-72
columns 3-15 3-16, 4-72
conditions 3-16, 4-88
privileges 3-24, 4-55, 4-66
rows 3-15 3-16, 4-72
statement 3-10, 3-15 3-16, 3-32
conditions 3-16
group by clause 3-21
having clause 3-21
nested query 3-21
order by clause 3-21
using in create view statement 3-20
using in insert statement 3-18
table 3-15 3-16
table data 4-72
tables 4-72
view data 4-72
views 4-72
select statement I-3
sequences, exclude/include I-4
set
ANSI 4-75
autocommit 4-80
database 4-74
database statement 4-74
default schema 3-8 3-10, 3-25, 4-44
mode
ANSI statement 4-75
verify statement 4-75
network verification 4-77
transaction
autocommit statement 3-29, 3-31,
4-80
verify 4-75
set database 4-74
set mode 4-75
Set Network Verification 3-35
set network verification> 4-77
set transaction 4-80
shared component 2-5

Index IN - 13

shared dictionaries I-6

shared dictionary 3-39
using 3-39
SHARED_MEMORY F-5
smallint data type 3-11
software changes I-3
SQL
statement processing 3-35
SQL commands 4-3, 4-51, 4-63
alter schema 4-7
alter table 3-14, 4-10
close schema 4-12
commit 3-29, 3-31, 4-13
create index 4-15
create schema 3-9, 3-24 3-26, 4-17,
4-21, 4-24, 4-26, 4-29, 4-31
create table 3-11 3-12, 3-21, 3-24, 4-33
create view 3-20 3-21, 3-26, 4-35
declare schema 4-37
declare table 4-40
declare view 4-42
default schema 3-9, 3-25, 4-44
delete 3-10, 3-19, 3-21, 3-23, 3-30, 4-45
drop 3-10
drop index 4-47
drop schema 3-9, 4-48
drop table 3-14, 4-50
drop view 3-20
grant 3-8, 3-23, 3-25 3-27, 4-54 4-55,
4-57
insert 3-10, 3-17, 3-21, 3-30, 4-59
lock tables 4-61
reserved words A-3
revoke 3-23, 3-27, 4-65, 4-68
revoke (from schema) 4-66
rollback 3-29, 3-32, 4-13, 4-70
select 3-10, 3-15 3-16, 3-18, 3-20, 3-32,
4-72
set database 4-74
set mode ANSI 4-75
set mode verify 4-75
set network verification 4-77
set transaction 3-28
set transaction autocommit 3-29, 3-31,
4-80
undeclare schema 4-81
undeclare table 4-82
undeclare view 4-83
union 4-84
update 3-10, 3-18, 3-21 3-22,
3-30 3-31, 3-33, 4-86

SQL commands (continued)

where clause 3-15
SQL Database Language Reference 4-3
SQL Functions 4-94
SQL Server D-13
SQL statements 4-3
create view 3-21
DDL 3-28 3-29
DML 3-28 3-29
DML statement 4-14
grant 3-27
identifiers 4-3
miscellaneous 3-28
reserved words A-3
vendor specific 4-52
Standard Schema 3-5
statement
declare schema I-5
select I-3
statements
commit 4-13
declare schema 4-37
declare table 4-40
declare view 4-42
delete 4-45
rollback 4-70
setting ANSI mode 4-75
setting autocommit 4-80
setting database 4-74
setting verify mode 4-75
undeclare schema 4-81
undeclare table 4-82
undeclare view 4-83
with grant option 4-55
SYBASE D-11
users 4-19
T
table 3-5, 3-10
aliases 3-13
alter 3-14, 4-10
ANSI SQL 3-10
columns
not null clause 4-33
create 3-12, 3-24, 4-33
creating 3-11, 3-13
data types 3-11
declare 4-40
definition 3-10
delete 3-14
delete rows 3-19

IN - 14

Index

table (continued)
deleting 4-50
drop 3-14
dropping 4-50
in other schemas 3-8
insert rows 3-17
inserting data 4-59
inserting rows 4-59
inserting values 3-18
join 3-15 3-16
joining 4-72
locking 4-61
naming 4-34
RIS 3-10
select 3-15 3-16
selecting 4-72
SQL commands 3-11
SQL data types 4-33
undeclare 4-82
union 4-84
updating rows 3-18, 4-86
table data
inserting 3-17
tables
creating logical groupings I-3
with same name I-4
with same name in one schema I-4
text 3-12
text data I-8
timestamp 3-12
alarm 3-35
TIMESTAMP_INTERVAL F-8
TIMESTAMP_TOLERANCE F-9
Transactions 3-28
atomic 3-28
autocommit mode 4-70
cancel 3-29, 3-32
commands
commit 3-28
lock tables 3-28
rollback 3-28
set transaction 3-28
commit 3-29, 3-31, 4-13
consistent 3-28
disabling 3-30, 4-80
enabling 3-30 3-31, 4-80
MAX_TRANSACTIONS variable 3-35
multiple 3-35
rollback 3-32, 4-70
setting autocommit 4-80

tuples
definition 3-10
U
undeclare
table 4-82
view 4-83
undeclare schema 4-81
undeclare table 4-82
undeclare view 4-83
UNION I-3
union 4-84
rows 4-84
table data 4-84
tables 4-84
view data 4-84
views 4-84
UNION ALL I-3
update 4-86
columns 3-18
data in views 3-21 3-22
privileges 3-24, 4-55, 4-66
rows 3-18, 4-86
statement 3-10, 3-18, 3-21 3-22,
3-30 3-31, 3-33
table data 3-18, 4-86
tables 4-86
views 4-86
updating large data I-8
usernames, stored for schema I-5
users 3-3 3-4, 3-7 3-8
create 3-9
creating 3-9, 4-17
database
DB2 4-19
INFORMIX 4-19
INGRES 4-19
Microsoft SQL Server 4-19
ORACLE 4-19
OS4 4-19
Rdb 4-19
SYBASE 4-19
deleting 4-48
dropping 4-48
operating system 3-3 3-4
RIS 3-3
using on-line Help 1-6
utilities
risalpha I-12
risgui I-12
Schema Management 4-18

Index IN - 15

V
values, dbms_owner I-4
variables
MAX_LOCAL_SERVERS 4-63
vendor databases
executing SQL 4-52
Vendor-Specific Information D-3
view 3-5, 3-19
column list option 4-35
column names 3-20
create 3-20 3-21, 3-26, 4-35
creating 3-20
declare 4-42
deleting 4-51
deleting data 3-21
deleting data from 3-23
dictionary C-3
drop 3-20
drop table referenced by 3-14
dropping 4-51
group by clause 3-21
having clause 3-21
in other schemas 3-8
insert 3-21
insert data 3-21
inserting data 4-59
inserting rows 4-59
nested query 3-21
not null clause 3-21
order by clause 3-21
remove 3-20
restricting access with 4-35
select statement clause 4-35
selecting 4-72
undeclare 4-83
union 4-84
update data 3-22
updating data 3-21
updating rows 4-86
using to combine tables 3-19
using to restrict access 3-19
viewing on-line Help 1-6
views
including data without I-3
with same name I-4
virtual tables 3-19
W
WHERE clause I-7
ris_object condition I-7

where clause 3-15, 3-18 3-19, 4-88

delete 4-45
wildcards
in select statements 3-15 3-16

IN - 16

Index