Sei sulla pagina 1di 163

Relational Interface System (RIS)

SQL User's Guide

Version 6

November 2009

DNA111660

Copyright
Copyright 1989-2009 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 law, trade secret law, and
international treaty, and may not be provided or otherwise made available without proper authorization from Intergraph Corporation.

U.S. Government Restricted Rights Legend


Use, duplication, or disclosure by the government is subject to restrictions as set forth below. For civilian agencies: This was developed at
private expense and is "restricted computer software" submitted with restricted rights in accordance with subparagraphs (a) through (d) of the
Commercial Computer Software - Restricted Rights clause at 52.227-19 of the Federal Acquisition Regulations ("FAR") and its successors,
and is unpublished and all rights are reserved under the copyright laws of the United States. For units of the Department of Defense ("DoD"):
This is "commercial computer software" as defined at DFARS 252.227-7014 and the rights of the Government are as specified at DFARS
227.7202-3.
Unpublished - rights reserved under the copyright laws of the United States.
Intergraph Corporation
P.O. Box 240000
Huntsville, AL 35813
Street address: 170 Graphics Drive, Madison, AL 35758

Terms of Use
Use of this software product is subject to the End User License Agreement and Limited Product Warranty ("EULA") delivered with this
software product unless the licensee has a valid signed license for this software product with Intergraph Corporation. If the licensee has a valid
signed license for this software product with Intergraph Corporation, the valid signed license shall take precedence and govern the use of this
software product. Subject to the terms contained within the applicable license agreement, Intergraph Corporation gives licensee permission to
print a reasonable number of copies of the documentation as defined in the applicable license agreement and delivered with the software
product for licensee's internal, non-commercial use. The documentation may not be printed for resale or redistribution.

Warranties and Liabilities


All warranties given by Intergraph Corporation about equipment or software are set forth in the EULA provided with the software or
applicable license for the software product signed by Intergraph Corporation, and nothing stated in, or implied by, this document or its
contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes the information in this
publication is accurate as of its publication date.
The information and the software discussed in this document are subject to change without notice and are subject to applicable technical
product descriptions. Intergraph Corporation is not responsible 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. THE USER OF THE SOFTWARE IS EXPECTED TO MAKE THE FINAL EVALUATION AS TO THE
USEFULNESS OF THE SOFTWARE IN HIS OWN ENVIRONMENT.
Intergraph is not responsible for the accuracy of delivered data including, but not limited to, catalog, reference and symbol data. Users should
verify for themselves that the data is accurate and suitable for their project work.

Trademarks
Intergraph, the Intergraph logo, PDS, SmartPlant, FrameWorks, I-Convert, I-Export, I-Sketch, SmartMarine, IntelliShip, INtools, ISOGEN,
MARIAN, SmartSketch, SPOOLGEN, SupportManager, and SupportModeler are trademarks or registered trademarks of Intergraph
Corporation or its subsidiaries in the United States and other countries. Microsoft and Windows are registered trademarks of Microsoft
Corporation. Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its affiliates. MicroStation is
a registered trademark of Bentley Systems Inc, all rights reserved. Other brands and product names are trademarks of their respective owners.

Contents
Preface PDS ................................................................................................................................................. v
Introduction to RIS .................................................................................................................................... 1
Features of RIS....................................................................................................................................... 1
Application Support ............................................................................................................................... 2
Network Support .................................................................................................................................... 2
Performance ........................................................................................................................................... 2
Hardware and Software Platforms ......................................................................................................... 3
RIS Installation for Windows................................................................................................................. 3
RIS Overview .............................................................................................................................................. 5
Databases ............................................................................................................................................... 5
Database Users ................................................................................................................................ 6
RIS Dictionary ....................................................................................................................................... 6
Schemas ................................................................................................................................................. 7
Standard Schema ............................................................................................................................. 7
Secure Schema ................................................................................................................................. 8
Schema Names ................................................................................................................................ 9
Default Schema.............................................................................................................................. 10
Declare Schema ............................................................................................................................. 10
Relating Databases, Users, and Schemas ...................................................................................... 11
Tables ................................................................................................................................................... 12
Creating Tables .............................................................................................................................. 13
Altering Tables .............................................................................................................................. 15
Dropping Tables ............................................................................................................................ 16
Selecting Tables ............................................................................................................................. 16
Joining Tables ................................................................................................................................ 17
Inserting Rows ............................................................................................................................... 18
Updating Rows .............................................................................................................................. 19
Deleting Rows ............................................................................................................................... 20
Views ................................................................................................................................................... 20
Creating Views .............................................................................................................................. 21
Dropping Views ............................................................................................................................. 21
Manipulating View Data ............................................................................................................... 22
Privileges ....................................................................................................................................... 24
SQL Database Language Reference........................................................................................................ 39
List of Identifiers .................................................................................................................................. 39
Supported SQL Statements .................................................................................................................. 40
alter schema ................................................................................................................................... 41
alter table ....................................................................................................................................... 44
close schema .................................................................................................................................. 45

Relational Interface System (RIS) SQL User's Guide

Contents
commit ........................................................................................................................................... 45
create index .................................................................................................................................... 46
create schema ................................................................................................................................. 47
create table ..................................................................................................................................... 52
create view ..................................................................................................................................... 53
declare schema ............................................................................................................................... 55
declare table ................................................................................................................................... 57
declare view ................................................................................................................................... 58
default schema ............................................................................................................................... 59
delete.............................................................................................................................................. 60
drop index ...................................................................................................................................... 60
drop schema ................................................................................................................................... 61
drop table ....................................................................................................................................... 61
drop view ....................................................................................................................................... 62
exec ................................................................................................................................................ 63
grant ............................................................................................................................................... 63
insert .............................................................................................................................................. 65
lock tables ...................................................................................................................................... 67
open schema .................................................................................................................................. 68
revoke ............................................................................................................................................ 69
rollback .......................................................................................................................................... 71
select .............................................................................................................................................. 71
set database .................................................................................................................................... 73
set mode ......................................................................................................................................... 73
set network verification ................................................................................................................. 74
set transaction ................................................................................................................................ 77
undeclare schema ........................................................................................................................... 77
undeclare table ............................................................................................................................... 78
undeclare view ............................................................................................................................... 78
union .............................................................................................................................................. 79
update ............................................................................................................................................ 80
where ............................................................................................................................................. 81
Nested Query........................................................................................................................................ 83
SQL Functions ..................................................................................................................................... 84
Troubleshooting ........................................................................................................................................ 87
NETWORK Error: NET_E_CONNECT_ERROR (0x89cd806a) ....................................................... 87
NETWORK Error: NET_E_READ_BUFFER_TOO_SMALL (0x89cd81d2) ................................... 88
NETWORK Error: NET_E_READ_ERROR (0x89cd81da) ............................................................... 88
RIS Error: RIS_E_BAD_LOGIN (0x) ................................................................................................. 89
RIS Error: RIS_E_CANT_CREATE_SCHEMA_FILE (0x8a94812a) ............................................... 89
RIS Error: RIS_E_CANT_FREE_DICT (0x8a94817a) ...................................................................... 90
RIS Error: RIS_E_CANT_GET_SCHEMA_FILE (0x8a9481aa) ....................................................... 90
RIS Error: RIS_E_CANT_LOCATE RIS (0x8a9481b2) .................................................................... 90
RIS Error: RIS_E_CANT_OPEN_ID_FILE_WRITE (0x8a9481da) .................................................. 90
RIS Error: RIS_E_CANT_OPEN_LANGCONFIG_FILE (0x8a94b2e2)........................................... 91
RIS Error: RIS_E_CANT_PUT_SCHEMA_FILE (0x8a94820a) ....................................................... 91
RIS Error: RIS_E_CLIENT_DIED (0x8a9482b2) .............................................................................. 91
ii

Relational Interface System (RIS) SQL User's Guide

Contents
RIS Error: RIS_E_CLIENT_NETWORK_ERROR (0x8a9482c2) ..................................................... 92
RIS Error: RIS_E_DEFAULT_SCHEMA_DIED (0x8a94842a) ........................................................ 92
RIS Error: RIS_E_INCONSISTENT_ADDRS (0x8a948672) ............................................................ 92
RIS Error: RIS_E_INCONSISTENT_DBPARMS (0x8a94b28a)....................................................... 94
RIS Error: RIS_E_INTERNAL_ERROR (0x8a9486a2) ..................................................................... 94
RIS Error: RIS_E_INV_OPEN (0x8a948e1a) ..................................................................................... 95
RIS Error: RIS_E_INV_OPEN_DB (0x8a948e22) ............................................................................. 95
RIS Error: RIS_E_INV_SYB_OPTION (0x8a9492f2) ....................................................................... 95
RIS Error: RIS_E_INV_TABLE_NAME (0x8a948902) .................................................................... 96
RIS Error: RIS_E_INV_USER_SPEC (0x8a94942a) ......................................................................... 96
RIS Error: RIS_E_MISSING_DIR_DEF (0x8a949629) ..................................................................... 96
RIS Error: RIS_E_NO_PROTOCOL (0x8a9499ea)............................................................................ 96
RIS Error: RIS_E_SCHEMA_RESTARTED (0x8a949eea) ............................................................... 97
RIS Error: RIS_E_SERVER_NETWORK_ERROR (0x8a949f3a) .................................................... 97
RIS Error: RIS_E_UNKNOWN_SCHEMA (0x8a94a142)................................................................. 99
RIS Utility Error: RISUTL_E_LEFT_DELIMITER_MISSING (0x89ce88e2) .................................. 99
RIS Utility Error: RISUTL_E_INVALID_NEW_SCH (0x89ce889a) .............................................. 100
RIS and Vendor DBMS Reserved Words............................................................................................. 101
RIS Reserved Words .......................................................................................................................... 101
Oracle Reserved Words...................................................................................................................... 103
Microsoft SQL Reserved Words ........................................................................................................ 106
RIS Data Types ....................................................................................................................................... 109
RIS Dictionary Views ............................................................................................................................. 111
RIS-Supported Dictionary Views....................................................................................................... 111
RIS5COLUMN_PRIVS .............................................................................................................. 111
RIS5COLUMNS ......................................................................................................................... 113
RIS5DBMS_COLUMNS ............................................................................................................ 115
RIS5DBMS_INDEXES............................................................................................................... 116
RIS5DBMS_TABLES................................................................................................................. 116
RIS5DBMS_USERS ................................................................................................................... 117
RIS5DBMS_VIEWS ................................................................................................................... 117
RIS5DBS ..................................................................................................................................... 118
RIS5INDEX_COLUMNS ........................................................................................................... 120
RIS5INDEXES ............................................................................................................................ 121
RIS5SCHEMAS .......................................................................................................................... 122
RIS5SCHPRIV ............................................................................................................................ 123
RIS5TABLE_PRIVS ................................................................................................................... 123
RIS5TABLES .............................................................................................................................. 124
RIS5USERS ................................................................................................................................ 125
RIS5VIEWS ................................................................................................................................ 126
Vendor-Specific Information ................................................................................................................. 127
General Notes on Data Types ............................................................................................................ 127
Data type Mappings ..................................................................................................................... 127

Relational Interface System (RIS) SQL User's Guide

iii

Contents
Oracle ................................................................................................................................................. 128
RIS-To-ORACLE Mapping ........................................................................................................ 128
ORACLE-To-RIS Mapping ........................................................................................................ 128
MSSQL .............................................................................................................................................. 130
RIS-To-MSSQL Mapping ........................................................................................................... 130
MSSQL-To-RIS Mapping ........................................................................................................... 130
RIS Limits ............................................................................................................................................... 133
Parameters File ....................................................................................................................................... 135
SHARED_MEMORY ........................................................................................................................ 137
MAX_LOCAL_SERVERS................................................................................................................ 137
MAX_ROWS ..................................................................................................................................... 138
MAX_BUFFER_SIZE ....................................................................................................................... 138
MAX_STATIC_STMTS.................................................................................................................... 138
MAX_USER_STMTS ....................................................................................................................... 139
MAX_SECONDARY_SCHEMAS ................................................................................................... 139
MAX_TRANSACTIONS .................................................................................................................. 139
MAX_TABLES_IN_MEM................................................................................................................ 139
Network Verification Parameters ....................................................................................................... 140
Schema Definition File Location ....................................................................................................... 141
LOCK_FILE_RETRY ....................................................................................................................... 142
Client Process Location...................................................................................................................... 143
Schema Definition File ........................................................................................................................... 145
Language Configuration File ................................................................................................................. 149
Index ........................................................................................................................................................ 153

iv

Relational Interface System (RIS) SQL User's Guide

Preface PDS
This document provides command reference information and procedural instructions for the
Relational Interface System (RIS) task.

List of PDS Documentation

DPDS3-PB-200003 - DesignReview Integrator (PD_Review) Reference Guide


DPDS3-PB-200004 - Drawing Manager (PD_Draw) User's Guide
DPDS3-PB-200005 - EE Raceway Modeling Reference Guide
DPDS3-PB-200006 - Interference Checker/Manager (PD_Clash) User's Guide
DPDS3-PB-200010 - PDS 3D Theory User's Guide
DPDS3-PB-200013 - PDS EDEN Interface Reference Guide Volume I : Piping
DPDS3-PB-200015 - PDS Equipment Modeling (PD_EQP) User's Guide
DPDS3-PB-200017 - PDS ISOGEN Reference Guide, Vol. 1
DPDS3-PB-200022 - PDS Piping Component Data Reference Guide
DPDS3-PB-200023 - PDS Project Setup Technical Reference
DPDS3-PB-200025 - PDS Stress Analysis Interface (PD_Stress) User's Guide
DPDS3-PB-200026 - Pipe Supports Modeler Reference Guide
DPDS3-PB-200028 - Piping Design Graphics (PD_Design) Reference Guide
DPDS3-PB-200030 - Project Administrator (PD_Project) Reference Guide
DPDS3-PB-200033 - Project Engineer HVAC (PE-HVAC) Reference Guide
DPDS3-PB-200034 - Reference Data Manager (PD_Data) Reference Guide
DPDS3-PB-200035 - Report Manager (PD_Report) User's Guide
DPDS3-PB-200041 - PDS EDEN Interface Reference Guide Volume 2 : Equipment
DPDS3-PB-200042 - PDS EDEN Interface Reference Guide Volume 3 : Pipe Supports
DPDS3-PE-200016 - PDS Express Project Creation Quick Start Guide
DPDS3-PE-200052 - PDS Ortho Draw User's Guide
DPDS3-PE-200029 - Piping Model Builder (PD_Model) Reference Guide
DPDS3-PE-200031 - Project Engineer HVAC Getting Started Guide
DPDS3-PE-200032 - Project Engineer HVAC Overview
DPDS3-PE-200045 - PDS Label Library Merger Utility
DPDS3-PE-200047 - PDS Reference Data Auditing Tool
DPDS3-PE-200048 - Pipe Supports Explorer Utility
DPDS3-PE-200050 - Batch Services Quick Start Guide
DPDS3-PE-200051 - Batch Services User's Guide

Relational Interface System (RIS) SQL User's Guide

Preface PDS

vi

Relational Interface System (RIS) SQL User's Guide

SECTION 1

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 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
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.

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.
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.

Relational Interface System (RIS) SQL User's Guide

Introduction to RIS

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.

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.

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%).

Relational Interface System (RIS) SQL User's Guide

Introduction to RIS

Hardware and Software Platforms


RIS currently supports ORACLE and Microsoft SQL Server.
RIS is fully supported on 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 more information.
Programs linked with RIS can run on PCs running Windows and remotely accessed 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.

RIS Installation for Windows


RIS installation on Windows 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\risNN.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:\win32app\ingr directory.
The products and their associated DBMSs are:

32-Bit RIS Product

DBMS

RISORADS, RISORANS

ORACLE

RISMSFDS
Microsoft SQL
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).

Relational Interface System (RIS) SQL User's Guide

Introduction to RIS

Relational Interface System (RIS) SQL User's Guide

SECTION 2

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

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.

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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.
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.

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).

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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.

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.

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.

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 created within, or by, RIS.
However, the RDBMS is aware of the tables and views that constitute the RIS dictionary.

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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.

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.

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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.

Schema Names

Schema names must be 1-18 characters in length in ANSI mode, (up to 31 characters inother
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:
_schema1 - Incorrect because a schema name cannot begin with the underscore ( _ ) character.
1_schema - Incorrect because a schema name cannot begin with a digit.
schema-1 - Incorrect because the dash ( - ) character is not allowed in a schema name. Only
alphabetic characters, digits, and the underscore ( _ ) character are allowed.

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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.

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.

10

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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.
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.
For Example:

Relational Interface System (RIS) SQL User's Guide

11

RIS Overview
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.

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.

12

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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.

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

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.

Relational Interface System (RIS) SQL User's Guide

13

RIS Overview

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.
RIS recognizes the following ANSI SQL data types:
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.
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.

14

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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 );

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.
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.

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.

Relational Interface System (RIS) SQL User's Guide

15

RIS Overview
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.

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.

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;

16

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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:

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.
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:

Relational Interface System (RIS) SQL User's Guide

17

RIS Overview
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 ...

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

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:

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) ;

18

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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;

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;

Relational Interface System (RIS) SQL User's Guide

19

RIS Overview
The addresses table now contains the following rows and columns:

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:

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.

20

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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:

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;

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;

Relational Interface System (RIS) SQL User's Guide

21

RIS Overview

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.

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.

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:

22

Relational Interface System (RIS) SQL User's Guide

RIS Overview
Selecting from the models view reveals the following data:

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:

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:

Relational Interface System (RIS) SQL User's Guide

23

RIS Overview

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;

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.

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.

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, 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.

24

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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.

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).

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 );

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.

Relational Interface System (RIS) SQL User's Guide

25

RIS Overview
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.

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.
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.

26

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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;

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.

The Grant Operation


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

Relational Interface System (RIS) SQL User's Guide

27

RIS Overview
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.

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:
1. Data Definition Language (DDL) statements
2. Data Manipulation Language (DML) statements
3. Miscellaneous statements
28

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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
alter table
create index
create schema
create table
create view
drop index
drop schema
drop table
drop view
grant
revoke

Relational Interface System (RIS) SQL User's Guide

29

RIS Overview

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
insert
select
union
update

Miscellaneous Statements
The following miscellaneous statements do not fit into the data dictionary or data manipulation
categories:
close schema
commit
declare schema
declare table
declare view
default schema
lock tables
open schema
rollback
set database
set mode
set transaction autocommit
undeclare schema
undeclare table
undeclare view
exec <dbtype>
set network

30

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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.

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 QL
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
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.

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 (on page 12) in this document or the lock
tables statement description.

Relational Interface System (RIS) SQL User's Guide

31

RIS Overview
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 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 */

32

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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.
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 (on page 12) 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

state ments in transaction A */


phones set ext = 407 where name = John;
phones set ext = 683 where name = Jerry;
* from phones;

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

Relational Interface System (RIS) SQL User's Guide

33

RIS Overview

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.
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;

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.

34

Relational Interface System (RIS) SQL User's Guide

RIS Overview

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;

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;

See Also
set network verification (on page 74)

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

Relational Interface System (RIS) SQL User's Guide

35

RIS Overview
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.
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 );

Examples
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.
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 :

36

Relational Interface System (RIS) SQL User's Guide

RIS Overview
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.

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 king's 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.

Relational Interface System (RIS) SQL User's Guide

37

RIS Overview

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).
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.

38

Relational Interface System (RIS) SQL User's Guide

SECTION 3

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.

List of Identifiers
<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>VA 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.
<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

Relational Interface System (RIS) SQL User's Guide

39

SQL Database Language Reference


<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.
<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.

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
40

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


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

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 16-bit languages are
Asian.) In the RIS documentation, the maximum size allowed for table names, view names,
Relational Interface System (RIS) SQL User's Guide

41

SQL Database Language Reference


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.

42

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.
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 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.
Modify remote and modify user password can be done simultaneously. The
current value for protocol is: TCP.
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.

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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.
The column names for the original table or view are not specified in the include
clause.
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 DBMS's 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.
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
Schemas (on page 7)
create schema (on page 47)
drop schema (on page 61)

Relational Interface System (RIS) SQL User's Guide

43

SQL Database Language Reference

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.

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 (on page 13).
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>).
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
Data Types (on page 13)
create table (on page 52)
drop table (on page 61)

44

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

close schema
The close schema statement deactivates a RIS database server process for a schema.
close schema { <schema> [, ...] | all };

The <schema> identifier is the name of the schema. Do not give the schema a password.
The close schema all closes all open 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 open 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.
Examples
close schema all; close schema jim; close schema jim, joe, fred;

See Also
Schemas (on page 7)
create schema (on page 47)
default schema (on page 59)
open schema (on page 68)

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> ];

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 it can still be used.
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.

Relational Interface System (RIS) SQL User's Guide

45

SQL Database Language Reference

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.
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 (on page 70)
set transaction (on page 76)

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.

46

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.
ORACLE lets 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.

Relational Interface System (RIS) SQL User's Guide

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 (on page 43)
create table (on page 52)
drop index (on page 60)
drop table (on page 61)

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:
Relational Interface System (RIS) SQL User's Guide

47

SQL Database Language Reference


create schema (ORACLE Database Descriptor) (on page 50)
create schema (Microsoft SQL Server Database Descriptor) (on page 51)

48

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
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.
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 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 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.
For ORACLE, 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 c:\Program Files\Common
Files\Intergraph\risNN.nn\ for Windows where NN.nn is the product version number). On
Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


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 c:\Program Files\Common
Files\Intergraph\risNN.nn\ (for Windows) with the location of the schema file. These files
and directories are the defaults and can be changed.
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.
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.
Examples
For examples of statements creating schemas, see the sections create schema (ORACLE
Database Descriptor) (on page 50) or create schema (Microsoft SQL Server Database
Descriptor) (on page 51).

See Also
create schema (ORACLE Database Descriptor) (on page 50)
create schema (Microsoft SQL Server Database Descriptor) (on page 51)
default schema (on page 59)
declare schema (on page 55)
drop schema (on page 61)

Relational Interface System (RIS) SQL User's Guide

49

SQL Database Language Reference


open schema (on page 68)
set mode (on page 73)
Parameters File (on page 135)
Schema Definition File (on page 145)
Transactions (on page 28)

create schema (ORACLE Database Descriptor)


oracle, dbname <dbname>,
dir <oracle_home>|dbms_net,
[osuser <osuser>[.<passwd>],]
ostype <ostype>

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 RIS's 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 and VMS.
For more information on data types and conversions, see the section Vendor-Specific
Information (on page 127).
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 c:\orant and dbname
specifies a system ID (SID) of ORCL. 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;

50

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 NT.
Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


create schema jim_schema.jim_passwd
on database (oracle, dir /usr2/oracle, dbname 1, osuser
smith.ospass, ostype NT, 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;

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 (on page 47)
drop schema (on page 61)
close schema (on page 44)
open schema (on page 68)
declare schema (on page 55)
default schema (on page 59)

create schema (Microsoft SQL Server Database Descriptor)


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

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

Relational Interface System (RIS) SQL User's Guide

51

SQL Database Language Reference


on database (mssql, dbname risdb1, ostype nt)
user joe.pass1;

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 (on page 47)
drop schema (on page 61)
close schema (on page 44)
open schema (on page 68)
declare schema (on page 55)
default schema (on page 59)

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.

52

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.

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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.
For more information about tables, see the section Tables (on page 12).
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 (on page 73) for more
information about ANSI mode.

See Also
alter table (on page 43)
delete (on page 60)
drop table (on page 61)
insert (on page 65)
update (on page 80)
set database (on page 73)
set mode (on page 73)

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 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 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.

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

Relational Interface System (RIS) SQL User's Guide

53

SQL Database Language Reference


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.
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 (on page 73) for more information about ANSI mode.

See Also
create table (on page 52)
delete (on page 60)
drop table (on page 61)
drop view (on page 62)
insert (on page 65)
set database (on page 73)
select (on page 71)
set mode (on page 73)
54

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


update (on page 80)

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]];

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.
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.
2. 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.

Relational Interface System (RIS) SQL User's Guide

55

SQL Database Language Reference


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.
3. 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.
4. The OS user password in a declare schema statement impacts the create schema
statement for Microsoft SQL Server 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.
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.
5. The OS user password in a declare schema statement impacts the following statements for
Microsoft SQL Server 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.

56

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


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 (on page 47)
undeclare schema (on page 77)
default schema (on page 59)
drop schema (on page 61)

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];

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 (on page 109) 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 RIS's 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.

Relational Interface System (RIS) SQL User's Guide

57

SQL Database Language Reference

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.
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 (on page 52)
create view (on page 53)
declare view (on page 58)
set mode (on page 73)
undeclare table (on page 78)
undeclare view (on page 78)

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];

58

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 RIS's 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 RIS-

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


dictionary 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.
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 (on page 52)
create view (on page 53)
declare view (on page 58)
set mode (on page 73)
undeclare table (on page 78)
undeclare view (on page 78)

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>];

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 (on page 7).
Examples
default schema jim; default schema jim.passwd;

See Also
create schema (on page 47)
close schema (on page 44)
drop schema (on page 61)
undeclare schema (on page 77)
open schema (on page 68)
declare schema (on page 55)

Relational Interface System (RIS) SQL User's Guide

59

SQL Database Language Reference

delete
The delete statement removes rows of data from a table.
delete from [<schema>.]<relation>[where <conditions>];

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 (on page 28).
For more information, see the sections on Tables (on page 12) and Views (on page 20).
Examples
delete from table1; delete from table1 where column1 = 5; delete
from table1 where column1 between 5 and 7;

See Also
alter table (on page 43)
create table (on page 52)
create view (on page 53)
drop table (on page 61)
drop view (on page 62)
insert (on page 65)
update (on page 80)
where (on page 80)

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>;

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 (on page 46)
60

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

drop schema
The drop schema statement removes a schema from RIS.
drop schema <schema>[.<passwd>][force];

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: ORACLE and Microsoft SQL Server.
For more information about schemas, see the section Schemas (on page 7).
Examples
drop schema jim; drop schema joe.passwd; drop schema jane force;

See Also
create schema (on page 47)
default schema (on page 59)
declare schema (on page 55)
grant (to schema) (on page 64)

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>;

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.

Relational Interface System (RIS) SQL User's Guide

61

SQL Database Language Reference

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 (on page 12).
Examples
drop table tab1;

See Also
alter table (on page 43)
create table (on page 52)
create view (on page 53)
drop view (on page 62)

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>;

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 (on page 52)
create view (on page 53)
drop table (on page 61)

62

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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 vendorspecific SQL is required.
exec <database-type> <string>;

The <database-type> identifier is the type of database associated with the default schema.
Either oracle 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));

See Also
create schema (on page 47)
drop schema (on page 61)

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) (on page
64) 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.

See Also
grant (to schema) (on page 64)
grant (to user) (on page 65)

Relational Interface System (RIS) SQL User's Guide

63

SQL Database Language Reference

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 ];

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.
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 (on page 69)

64

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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>];

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 (on page 24).
Examples
grant schema to joan; grant resource to jim; grant connect to joe;

See Also
revoke (on page 69)

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>;

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.

Relational Interface System (RIS) SQL User's Guide

65

SQL Database Language Reference

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.
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 (on
page 12).
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 (on page 43)
create view (on page 53)
drop table (on page 61)
drop view (on page 62)
delete (on page 60)
update (on page 80)

66

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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];

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 ORACLE, the exclusive keyword prevents other locks from being performed on the
table, but does not restrict users from querying the table.
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 (on page 28).
Examples

Relational Interface System (RIS) SQL User's Guide

67

SQL Database Language Reference


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 (on page 45)
rollback (on page 70)
set database (on page 73)

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>] [, ...];

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 File (on page 135).
If RIS cannot open a server locally, it attempts to open it remotely.
For more information about schemas, see the section Schemas. (see "Schemas" on page 7)
Examples
open schema jim;
open schema jim, joe, fred;

See Also
close schema (on page 44)
create schema (on page 47)
default schema (on page 59)
drop schema (on page 61)
declare schema (on page 55)

68

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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, and update after
the revoke statement indicate privileges revoked from schemas.
Refer to the section revoke (from schema) (on page 69) 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) (on page 69) for
the syntax associated with these statements.

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>;

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 (on page 24).
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;

See Also
grant (to schema) (on page 64)

Relational Interface System (RIS) SQL User's Guide

69

SQL Database Language Reference

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>];
1. 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.
2. A user with connect privilege can connect to a schema, access and modify data, but not issue
DDL statements.
3. A user with resource privilege assumes connect privilege and can also issue DDL
statements.
4. The connect and resource privileges are only applicable to secure schemas and can only be
issued by the schema owner.
5. 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.)
6. The revoke (from user) statement can only be issued by the dictionary owner when
connected to his schema.
7. Revoking privileges from a user through RIS may lead to RDBMS revoke statements on the
RIS dictionary tables and views.
8. The <username> identifier specifies a valid database user.
9. The revoke statement can be used to revoke privileges in a manner similar to the grant (to
user) statement.
10. 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.
11. For more information about privileges, see the section Privileges (on page 24).
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 (on page 63)

70

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

rollback
The rollback statement cancels the effects of all statements within a transaction.
rollback [ work ][ for <schema> ];

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 (on page 28).
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.
Examples
rollback; rollback for sch1;

See Also
commit (on page 45)
set transaction (on page 76)

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 }]} [, ...]];

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.

Relational Interface System (RIS) SQL User's Guide

71

SQL Database Language Reference

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.
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 (on
page 12) and Views (on page 20).
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 ......);

72

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

See Also
where (on page 80)

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>[, ...] ];

The <database> identifier specifies the RIS-supported databases. The databases currently
supported are ORACLE 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 (on page 43)
create index (on page 46)
create schema (on page 47)
create table (on page 52)
create view (on page 53)

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} ];

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 (on page 127).

Relational Interface System (RIS) SQL User's Guide

73

SQL Database Language Reference

Because the underlying DBMSs have their own maximum limits to these user-supplied
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 (on page 127).
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.
Examples
set mode ansi on;
set mode ansi off verify off;
set mode blank strip on verify off;

See Also
alter table (on page 43)
create index (on page 46)
create schema (on page 47)
create table (on page 52)
create view (on page 53)
declare table (on page 57)
declare view (on page 58)

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>,]

74

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


[response interval <value>] [for <schema>[,...]];

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.
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.

Relational Interface System (RIS) SQL User's Guide

75

SQL Database Language Reference

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 the behavior of RIS.
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.
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, the RIS ORACLE server on Windows supports 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 (on page 47)
open schema (on page 68)
default schema (on page 59)

76

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

set transaction
The set transaction statement sets the transaction state.
set transaction autocommit { on | off };

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
Programmer's Guide.
The following rules provide you with some degree of safety.
If RIS is terminated abnormally, it issues a rollback statement to prevent the
possibility of corrupting data.
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 (on page 28).
Examples
set transaction autocommit on;
set transaction autocommit off;

See Also
commit (on page 45)
rollback (on page 70)

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, ...>]

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 (on page 55)
create schema (on page 47)
open schema (on page 68)
default schema (on page 59)

Relational Interface System (RIS) SQL User's Guide

77

SQL Database Language Reference


drop schema (on page 61)

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>;

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 Parameters File (on
page 135).
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 (on page 57)

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>;

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;

78

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


undeclare view sch2.t2;

See Also
declare table (on page 57)
declare view (on page 58)

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] [...];

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.
For more information about selecting from tables and views, see the sections select (on page
71) and where (on page 80).
Examples
select * from t1 union select from t1; select c1, c2 from t1 union
all select c21, c22 from t2;

See Also
select (on page 71)
where (on page 80)

Relational Interface System (RIS) SQL User's Guide

79

SQL Database Language Reference

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>
];

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';

See Also
alter table (on page 43)
create table (on page 52)
create view (on page 53)
delete (on page 60)
drop table (on page 61)
drop view (on page 62)
insert (on page 65)

80

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

where
The where clause restricts the rows of a relation that are selected, updated, or deleted.
where <condition>

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.
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.

Relational Interface System (RIS) SQL User's Guide

81

SQL Database Language Reference

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:
'This is "quoted" text.' -Quoted in double quotations.
'This is ''quoted'' text.' -Quoted in single quotations.
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 commaseparated 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

82

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference


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
where
where
where
where
where
where
where
where

column1 < column2 + column3;


column1 <>1+2;
not column1 = column2;
column1 between column2 + 3 and 5;
column1 in (1, 2, 3);
column1 is not null;
column1 like '_bcdef%';
(column1 + 3)*5>= column2;
(column1 / 2) > column2 and column1 != column3;

See Also
delete (on page 60)
Nested Query (on page 83)
select (on page 71)
update (on page 80)

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> )

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 (on page 80) clause
description.

Relational Interface System (RIS) SQL User's Guide

83

SQL Database Language Reference

The <select-statement> identifier is any valid select statement. For more information, see
the select (on page 71) 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.
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
... where
... where
... where
... where
...);

column1 = any (select col1 from tab2);


column1 >all (select col1 from tab2);
column1 <>some(select col1 from tab2);
column1 in (select col1 from tab2);
exists (select * from tab2 where

= all is not supported by Microsoft SQL Server.

See Also
select (on page 71)
where (on page 80)

SQL Functions
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

84

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.

Relational Interface System (RIS) SQL User's Guide

SQL Database Language Reference

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.
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, the following is
invalid:
select name, avg(salary) from tab1;

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, the following is valid:
select dept_no, avg(salary) from tab1 group by dept_no;

The values returned by functions may differ depending on the underlying DBMS. For
more information refer to the specific DBMS reference manual.
Examples
select
select
select
select

count(*) from tab1;


avg(col1) from tab1;
avg(distinct col1) from tab1;
user from tabl;

Relational Interface System (RIS) SQL User's Guide

85

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 (on page 71)
where (on page 80)

86

Relational Interface System (RIS) SQL User's Guide

SECTION 4

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 - The locate client command fails on PC/DOS with: connect timed out.
Cause 1 - 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.
Recovery 1 - 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 an 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 - Locate client command fails: error creating tcp socket.
Cause 2 - PC/TCP is not installed.
Recovery 2 - Install PC/TCP version 2.11 or higher.
Problem 3 - Locate client command fails on PC/DOS with: connect timed out.
Cause 3 - The client machine is not set up properly.
Recovery 3 - 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.

Relational Interface System (RIS) SQL User's Guide

87

Troubleshooting

NETWORK Error:
NET_E_READ_BUFFER_TOO_SMALL (0x89cd81d2)
Read buffer too small to receive entire transmission.
Problem:Cannot create a schema on Sun.
Cause 1 - Kernal is not properly configured.
Recovery 1 - Reconfigure the Sun kernel. See the RISsun.doc file in the riscsu directory.
Cause 2 - SunOS Version 4.1.2 is NOT supported by RIS over the network.
Recovery 2 - 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 - Cannot communicate with server over the network.
Recovery 1 - See recovery descriptions for RIS_E_SERVER_NETWORK_ERROR
(0x8a949f3a).
Problem 2 - Cannot connect to existing schema TCP connection has been broken.
Recovery 2 - Reloading risoc cleared up this problem.
Problem 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
Recovery 3 - Refer to the error about "internationalization":
RIS_E_SERVER_NETWORK_ERROR (0x8a949f3a) Unable to communicate with server over
network.

88

Relational Interface System (RIS) SQL User's Guide

Troubleshooting

RIS Error: RIS_E_BAD_LOGIN (0x)


Invalid username/password combination.
Problem 1 - Rismgr fails to come up. Show schema file fails in interactive mode.
Cause 1 - A locate client was done on a machine that does not have risccu loaded on it.
Recovery 1 - Edit the schema file to reflect shared memory in client location.
Problem 2 - Unable to create a schema.
Cause 2 - 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.
Recovery 2 - Edit the schema file and then do a checksum of the file.
Problem 3 - Cannot create a schema on an oracle database using the schema manager.
Cause 3 - 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.
Recovery 3 - 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 - 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"
Recovery - 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.

Relational Interface System (RIS) SQL User's Guide

89

Troubleshooting

RIS Error: RIS_E_CANT_FREE_DICT (0x8a94817a)


Attempt to free a dictionary statement failed.
Problem - Cannot access Sybase data.
Cause - 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.
Recovery - 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 - Cannot make a copy of the schema file. Also receiving net_get_file_error (15).
Recovery - 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 - 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.
Cause - Permissions on the schema file didnt allow user access.
Recovery - 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 - Cannot create a schema on Windows NT.
Cause - The environment variables temp and tmp are set, BUT, they do not point to an
existing valid directory.
Recovery - Create the directories that they are pointing to, OR, reset the environment variables
to point to a valid directory.

90

Relational Interface System (RIS) SQL User's Guide

Troubleshooting

RIS Error: RIS_E_CANT_OPEN_LANGCONFIG_FILE


(0x8a94b2e2)
Unable to open RIS language config file.
Problem - Get error occurred while using interactive RIS on PC/DOS.
Cause - Environment variable RISDIR is set to version 4.3.2.x.
Recovery - 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 - Schema file is not updated when a create schema statement is issued.
Cause - The fmu is failing to replace the schema file.
Recovery - A change request has been filed to do this a different way.

RIS Error: RIS_E_CLIENT_DIED (0x8a9482b2)


The risclient process has died. No RIS statements may be executed.
Problem - Error occurs when doing anything in RIS interactive (or any other process that uses
RIS).
Cause - 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.
Recovery - Be sure that the client and server are the same version.

Relational Interface System (RIS) SQL User's Guide

91

Troubleshooting

RIS Error: RIS_E_CLIENT_NETWORK_ERROR


(0x8a9482c2)
Unable to communicate with client process.
Problem - Cannot default to an existing schema.
Cause - Someone has done a locate client command to a machine that doesnt have a RIS client.
Recovery - Do a locate client command to a machine that has a client.

RIS Error: RIS_E_DEFAULT_SCHEMA_DIED


(0x8a94842a)
The default schema server died and restarting failed.
Problem - The schema server dies during I/NFM initialization.
Cause - 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.
Recovery - Follow these steps and set default pro_dd_ris:[bin] should work
correctly.
1. Re-link risovx.exe by running initial.com.
2. Change system logical for pro_dd_ris to: ASSIGN/SYS/trans=concealed
ZFA0:[IGR.RIS.PRO.] PRO_DD_RIS.

RIS Error: RIS_E_INCONSISTENT_ADDRS


(0x8a948672)
The network addresses specified identify different nodes.
Problem 1 - Error occurs while trying to do a default schema statement.
Cause 1 - The RIS server node /etc/hosts file (or tcpware:hosts file on a VAX) does not contain
the servers nodename.
Recovery 1 - Add the server nodename to the RIS server node /etc/hosts file (or tcpware:hosts
file on a VAX).
Problem 2 - Error occurs while trying to do a default schema statement.
Cause 2 - The /usr/lib/nodes/owned/<node-name> file on the UNIX server node does not exist.
Recovery 2 - Create /usr/lib/nodes/owned/<node-name> file on the UNIX server node.
Problem 3 - Error occurs while trying to do a default schema statement.
Cause 3 - The /usr/lib/nodes/owned/<node-name> file on the server node has the privileges set
to: "-rw- 1 root"
Recovery 3 - Change the privileges to : "-rw-rr" (chmod 644).
Problem 4 - Error occurs while trying to do a default schema statement.
92

Relational Interface System (RIS) SQL User's Guide

Troubleshooting
Cause 4 - 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.
Recovery 4 - Reduce the number of addresses.
Problem 5 - Error occurs while trying to do a default schema statement.
Cause 5 - Cannot visit, telnet, or sethost to server.
Recovery 5 - Correctly install or invoke the network software.
Problem 6 - 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.
Cause 6 - CISCO routers require a decimal equivalent of the hexadecimal specified XNS LAN
ID in their configuration.
Recovery 6 - Reconfigure the CISCO routers correctly.
Problem 7 - Cannot access existing schema after doing alter schema and the network addresses
of some machines have been altered.
Cause 7 - 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.
Recovery 7 - 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).
Problem 8 - Error occurs when using the default schema statement on a local machine, and the
first network protocol is xns or dnp.
Cause 8 - The schema file is corrupted. The tcp/ip entry has control characters instead of a valid
tcp/ip address.
Recovery 8 - 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.

Relational Interface System (RIS) SQL User's Guide

93

Troubleshooting

RIS Error: RIS_E_INCONSISTENT_DBPARMS


(0x8a94b28a)
Specified database parameters are inconsistent with schema file.
Problem - Cannot create a second schema on the same Oracle or Sybase database.
Recovery - 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.

RIS Error: RIS_E_INTERNAL_ERROR (0x8a9486a2)


RIS internal error.
Problem 1 - Cannot do a set default schema.
Cause 1 - 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.
Recovery 1a - Set read permissions for others on the /etc/hosts file and correct the DNS server
hosts database.
Recovery 1b - 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.
Problem 2 - 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.
Cause 2 - 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.
Recovery 2 - There is no workaround for Version 4 applications. You must get a Version 5
application.

94

Relational Interface System (RIS) SQL User's Guide

Troubleshooting

RIS Error: RIS_E_INV_OPEN (0x8a948e1a)


Underlying dbms could not open cursor.
Problem - Cannot default to a Sybase schema.
Cause - The transaction log file for the underlying Sybase database is full.
Recovery - Dump the transaction log file.

RIS Error: RIS_E_INV_OPEN_DB (0x8a948e22)


Underlying dbms could not open database.
Problem - 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...
Cause - 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.
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 - Cannot create a SYBASE schema using interactive RIS.
Cause - Documentation is incorrect for create schema syntax.
Recovery - Change the ifile keyword to filename in the option clause of the create schema
statement.

Relational Interface System (RIS) SQL User's Guide

95

Troubleshooting

RIS Error: RIS_E_INV_TABLE_NAME (0x8a948902)


Invalid table name. Expected an identifier, got "node."
Problem - 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.
Cause - Two new RIS Keywords were added to Version 4.3.1.10; node and port. They are
undocumented. (Corrected in Version 5 documentation.)
Recovery - 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 - Cannot create a SYBASE schema using schema manager.
Cause - Schema manager has a known bug in Version 04.03.01.10.
Recovery - 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_MISSING_DIR_DEF (0x8a949629)


The DBMS directory or home must be specified.
Problem - Rislod fails to load a Sybase schema.
Cause - Risunlod failed to generate a valid create schema statement for a Sybase schema.
Recovery - A workaround is to create a schema, then use rislod to load an existing schema.

RIS Error: RIS_E_NO_PROTOCOL (0x8a9499ea)


The specified protocol has not been installed or is not functioning.
Problem 1 - A new machine has trouble defaulting to an existing schema.
Cause 1 - 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.
Recovery 1 - Either change the schema to use TCP or load XNS on the 2730.
Problem 2 - Cannot create a schema.
Cause 2 - 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.)
Recovery 2 - 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.

96

Relational Interface System (RIS) SQL User's Guide

Troubleshooting
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_SCHEMA_RESTARTED


(0x8a949eea)
A schema server died and has been restarted. The query must be re-executed.
Problem - Cannot unload a schema or select from a schema.
Cause - When the ris parameters file has the following:
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.
Recovery - 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 - Cannot create schema.
Cause 1 - This error can occur when multiple RIS servers on the VAX are on different disks
(devices).
Recovery 1 - Re-install RIS on single disk.
Problem 2 - Cannot create schema and cannot default schema.
Cause 2 - Server product not installed on server node.
Recovery 2 - Newprod the RIS server to the server node.
Problem 3 - Sudden failure to access server on existing or new schema.
Cause 3 - One of the protocols is not working.
Recovery 3 - Verify the server product is installed. Verify that the net

Relational Interface System (RIS) SQL User's Guide

97

Troubleshooting
address (netaddr) is listed correctly. Verify that the clearinghouse (clh) reflects the proper server
address.
XNS
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 ristcpsr 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 - Cannot create a schema with a new database option. This error is followed by
another error: NET-E-READ_ERROR (0x89cd81da)
Cause 4 - I-LICENSE is not loaded.
Recovery 4 - Load I_LICENSE.
Problem 5 - Cannot create a schema using tcp/ip.
Cause 5 - The /etc/inetd.conf file has invalid entries before to the ristcpsr entry.
Recovery 5 - 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.
Problem 6 - Cannot create a schema using tcp/ip on a VAX. Follows with another error:
NET-E-READ_ERROR (0x89cd81da)
TCP connection has been broken.
Cause 6 - 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.
Recovery 6 - 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

Problem 7 - 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

98

Relational Interface System (RIS) SQL User's Guide

Troubleshooting
NETWORK READ ERROR.
Cause 7 - 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.
Recovery 7 - Change the international value to U.S. ENGLISH, as all parts of RIS and the
database must use the same language.
Problem 8 - 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.
Cause 8 - Same as the previous problem. Only this time the server was version 4.3.5.x or later.
Recovery 8 - 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 - Any access to a schema fails.
Cause - 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.
Recovery - Run risclnsrv to clean up the table.

RIS Utility Error:


RISUTL_E_LEFT_DELIMITER_MISSING (0x89ce88e2)
Left Delimiter is Missing.
Problem - rislod fails to load a ris.dmp file.
Cause - 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.
Recovery - 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)

Relational Interface System (RIS) SQL User's Guide

99

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 - Error occurs while running risload on an existing schema.
Cause - Schema file location was incorrect so RIS didnt see the schema.
Recovery - Locate schema file correctly.

100

Relational Interface System (RIS) SQL User's Guide

APPENDIX A

RIS and Vendor DBMS Reserved Words


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

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

Relational Interface System (RIS) SQL User's Guide

101

RIS and Vendor DBMS Reserved Words

102

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

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
Relational Interface System (RIS) SQL User's Guide

RIS and Vendor DBMS Reserved Words


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

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

Relational Interface System (RIS) SQL User's Guide

103

RIS and Vendor DBMS Reserved Words

104

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

module

mount

new

next

noarchivelog

noaudit

nocache

nocompress

nocycle

nomaxvalue

nominvalue

none
Relational Interface System (RIS) SQL User's Guide

RIS and Vendor DBMS Reserved Words


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

Relational Interface System (RIS) SQL User's Guide

105

RIS and Vendor DBMS Reserved Words


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

Microsoft SQL Reserved Words

106

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
Relational Interface System (RIS) SQL User's Guide

RIS and Vendor DBMS Reserved Words


exec

execute

exists

exit

fetch

fillfactor

for

foreign

from

goto

grant

group

having

holdlock

identity

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

Relational Interface System (RIS) SQL User's Guide

107

RIS and Vendor DBMS Reserved Words


tsequal

union

unique

update

user

user_option

using

values

varying

view

waitfor

where

while

with

work

writetext

108

Relational Interface System (RIS) SQL User's Guide

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 yyyymm-dd:hh:mm:ss

-orcurrent_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.

Relational Interface System (RIS) SQL User's Guide

109

RIS Data Types

SQL string

SQL code

Description

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-0401: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.

110

Relational Interface System (RIS) SQL User's Guide

APPENDIX C

RIS Dictionary Views


This section documents the RIS dictionary views.
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.

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.

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

char(31)

not null

lower

table_name

char(31)

not null

lower

upper_table_name

char(31)

not null

UPPER

column_name

char(31)

not null

lower

upper_column_name

char(31)

not null

UPPER

Relational Interface System (RIS) SQL User's Guide

111

RIS Dictionary Views

112

grantor

char(31)

not null

lower

grantee

char(31)

not null

lower (or PUBLIC)

ris_privileges

char(7)

not null

either

ris_object

char(7)

not null

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 table for which privileges exist.

upper_column_name

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

grantor

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

grantee

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


been granted, or PUBLIC.

ris_privileges

A 7-character string indicating privileges. Each character


position indicates a specific privilege or lack thereof.
position 1: select privilege s, S, or position 2: insert privilege i, I, or position 3: delete privilege d, D, or position 4: update privilege u, U, or position 5: reserved
position 6: reserved
position 7: 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

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

Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views

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 RI (internal) name and ext_column_name refers to the DBMS
(external) name.

Column

Type

Description

Case

schema_name

char(31)

not null

lower

table_name

char(31)

not null

lower

upper_table_name

char(31)

not null

UPPER

column_name

char(31)

not null

lower

ext_column_name

char(31)

not null

As DBMS

upper_column_name

char(31)

not null

UPPER

position

integer

not null

N/A

ris_type

integer

not nul

N/A

ris_type_string

char(11)

not null

lower

dbms_type_string

char(31)

not null

lower

char_max_length

integer

N/A

prec

integer

N/A

scale

integer

N/A

nullable

char(3)

not null

lower

ris_object

char(1)

not null

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

The name of the table/view.

Relational Interface System (RIS) SQL User's Guide

113

RIS Dictionary Views

114

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.

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.

Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views


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

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 tothe 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

char(31)

not null

As DBMS

dbms_owner

char(31)

not null

As DBMS

column_name

char(31)

not null

As DBMS

position
integer
not null
The Type may vary depending on the database.

N/A

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.

Relational Interface System (RIS) SQL User's Guide

115

RIS Dictionary Views

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

char(31)

not null

As DBMS

dbms_owner

char(31)

not null

As DBMS

index_name
char(31)
not null
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

The owner of the index in the underlying database.

index_name

This is the name of the index.

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

char(31)

not null

As DBMS

dbms_owner
char(31)
not null
As DBMS
The Type may vary depending on the database.
table_name

116

This is the name of the table. This comes directly from the underlying

Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views


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.

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.

Column

Type

Description

Case

table_name

char(31)

not null

As DBMS

dbms_owner
char(31)
not null
As DBMS
The Type may vary depending on the database.
table_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.

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.

Relational Interface System (RIS) SQL User's Guide

117

RIS Dictionary Views

Column

Type

Description

Case

view_name

char(31)

not null

As DBMS

dbms_owner
char(31)
not null
As DBMS
The Type may vary depending on the database.
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.

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.

118

Column

Type

Description

Case

database_id

smallint

not null

N/A

database_type

char(1)

not null

UPPER

database_name

char(240)

not null

lower

protocol_1

char(1)

lower

net_address_1

char(28)

lower

protocol_2

char(1)

lower

net_address_2

char(28)

lower

protocol_3

char(1)

lower

net_address_3

char(28)

lower

protocol_4

char(1)

lower

net_address_4

char(28)

lower

long_parameter_1

char(240)

lower

long_parameter_2

char(240)

lower

long_parameter_3

char(240)

lower

short_parameter_1

char(31)

lower

short_parameter_2

char(31)

lower

short_parameter_3

char(31)

lower

Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views


short_parameter_4

char(31)

lower

short_parameter_5

char(31)

lower

short_parameter_6

char(31)

lower

short_parameter_7

char(31)

lower

short_parameter_8

char(31)

lower

srvid

integer

database_id

This is the database identification number (arbitrary).

database_type

This is the database type:

not null

N/A

For ORACLE the value is O


For MSSQL the value is M
database_name

This is RDBMS-specific information used to identify a particular


database:
For ORACLE this is the system identifier (SID) or SQL*Net
alias/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 ORACLE the value is ORACLE_HOME
For MSSQL the value is not used

long_parameter_2

This is completely database specific.


For ORACLE the value is not used
For MSSQL the value is not used

Relational Interface System (RIS) SQL User's Guide

119

RIS Dictionary Views


long_parameter_3

This is completely database specific.


For ORACLE the value is not used
For MSSQL the value is not used

short_parameter_1

This is completely database specific.


For ORACLE the value is the database system identifier
(ORACLE_SID)
For MSSQL the value is not used

short_parameter_2

This is completely database specific


For ORACLE the value is not used
For MSSQL the value is not used

short_parameter_3

Same as short_parameter_2

short_parameter_4

Same as short_parameter_2

short_parameter_5

Same as short_parameter_2

short_parameter_6

Same as short_parameter_2

short_parameter_7

Same as short_parameter_2

short_parameter_8

Same as short_parameter_2

srvid

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.

120

Column

Type

Description

Case

schema_name

char(31)

not null

lower

index_name

char(31)

not null

lower

upper_index_name

char(31)

not null

UPPER

table_name

char(31)

not null

lower

upper_table_name

char(31)

not null

UPPER

column_name

char(31)

not null

lower

upper_column_name

char(31)

not null

UPPER

position

integer

not null

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,
Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views


if there is no qualifier.
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.

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

char(31)

not null

lower

index_name

char(31)

not null

lower

dbms_owner

char(31)

not null

As DBMS

ext_index_name

char(31)

not null

As DBMS

upper_index_name

char(31)

not null

UPPER

table_name

char(31)

not null

lower

upper_table_name

char(31)

not null

UPPER

index_type

char(1)

not null

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.

Relational Interface System (RIS) SQL User's Guide

121

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.

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.

122

Column

Type

Description

Case

schema_name

char(31)

not null

lower

schema_owner

char(31)

not null

As input

database_id

smallint

not null

N/A

schema_type

smallint

not null

N/A

dictionary_owner

char(31)

not null

As input

srvid

integer

not null

N/A

schema_name

This is the schema name.

schema_owner

This is the schema owner/administrator. (The database-specific 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.

Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views

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

char(31)

not null

Rule 1

user_privilege

char(1)

not null

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

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

char(31)

not null

lower

table_name

char(31)

not null

lower

upper_table_name

char(31)

not null

UPPER

grantor

char(31)

not null

lower

grantee

char(31)

not null

lower (or
PUBLIC)

ris_privileges

char(7)

not null

either

ris_object

char(1)

not null

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.

upper_table_name

This is the name of the table.

grantor

This is the schema that granted the privileges.

Relational Interface System (RIS) SQL User's Guide

123

RIS Dictionary Views


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: select privilege s, S, or position 2: insert privilege i, I, or position 3: delete privilege d, D, or position 4: update privilege u, U, or position 5: reserved
position 6: reserved
position 7: 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

for a RIS dictionary object, or N for a user/application object. To see


only the application objects, use the condition, ris_object=N

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.

124

Column

Type

Description

Case

schema_name

char(31)

not null

lower

table_name

char(31)

not null

lower

dbms_owner

char(31)

not null

As DBMS

ext_table_name

char(31)

not null

As DBMS

upper_table_name

char(31)

not null

UPPER

table_type

char(1)

not null

UPPER

date_entered

timestamp

not null

N/A

Relational Interface System (RIS) SQL User's Guide

RIS Dictionary Views


date_modified

timestamp

not null

N/A

ris_object

char(1)

not null

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

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

char(31)

not null

lower

user_name

char(31)

not null

Rule 1

user_privilege

char(1)

not null

UPPE
R

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

Relational Interface System (RIS) SQL User's Guide

125

RIS Dictionary Views


R -Resource privilege
C -Connect privilege

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.

126

Column

Type

Description

Case

schema_name

char(31)

not null

lower

view_name

char(31)

not null

lower

dbms_owner

char(31)

not null

As DBMS

ext_view_name

char(31)

not null

As DBMS

upper_view_name

char(31)

not null

UPPER

ris_view_def

char(64)

lower

dbms_view_def

char(64)

lower

sequence_id

integer

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.

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.

not null

N/A

Relational Interface System (RIS) SQL User's Guide

APPENDIX D

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

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.

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.

See Also
ORACLE (on page 128)
MSSQL (on page 129)

Relational Interface System (RIS) SQL User's Guide

127

Vendor-Specific Information

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 recreated, and the field is no longer defined as a float.

RIS-To-ORACLE Mapping
RIS

ORACLE

CHARACTER(x)

char(x)

DECIMAL(p,s)

number(p,s)

DOUBLE

number

INTEGER

number(38,0)

REAL

float(21)

SMALLINT

number(38,0)

TIMESTAMP

date

RIS_BLOB

long raw (1byte-2Gb)

RIS_TEXT

long (1byte-2Gb)

ORACLE-To-RIS Mapping
ORACLE

RIS

RISCOLUMNS.dbms_type_st
ring

varchar(x)

CHARACTER(x)

char

varchar(2)

CHARACTER(x)

char

char(x), x <= 240

CHARACTER(x)

char

char(x), 241 <=x

UNSUPPORTED

char

date

TIMESTAMP

date

long (1byte-2Gb)

RIS_BLOB

long

long raw(1byte-2Gb)

RIS_TEXT

long raw

number(p,s)

see full details that follow

number

raw(x)

UNSUPPORTED

raw

rowid

UNSUPPORTED

rowid

RIS Supported Data Types for number(p,s)


number(p,s)

128

* DOUBLE
Relational Interface System (RIS) SQL User's Guide

Vendor-Specific Information
case (p=0)
case (p != 0)

p is never negative

subcase (s<=0)
1 <= p <= 38

? SMALLINT

6 <= p <= 38

? INTEGER

11 <= p <= 15

? DOUBLE

16 <= p

* DOUBLE

subcase (s>0)
subsubcase (s>p)

the value is floating


point

1 <= p <= 7

* REAL

8 <= p

* DOUBLE

subsubcase (s<=p)
p <= 15

-DECIMAL(p,s)

p > 15

-DOUBLE

Syntactic variations
long varchar

=== long

decimal(p)

=== number(p)

number(p)

=== number(p,0)

number(*,s)

=== decimal(*,s)
=== number(38,s)

decimal(p,s)

=== number(p,s)

number

=== real, float, float(*), float(b), double precision, number(*)

varchar

=== char

Relational Interface System (RIS) SQL User's Guide

129

Vendor-Specific Information

MSSQL

MSSQL refers to Microsoft SQL Server.


MSSQL does not support the operator =all.

RIS-To-MSSQL Mapping
RIS

MSSQL

CHARACTER(x)

varchar(x)

DECIMAL(p,s)

float

DOUBLE

float

INTEGER

integer

REAL

real

SMALLINT

smallint

TIMESTAMP

datetime

RIS_BLOB

unsupported

RIS_TEXT

unsupported

MSSQL-To-RIS Mapping
MSSQL

RIS

RISCOLUMNS.dbms_type_string

binary(n)

UNSUPPORTED

binary

bit

UNSUPPORTED

bit

char(x),x<=240

CHARACTER(x)

char

char(x),241<=x

UNSUPPORTED

char

datetime

TIMESTAMP

timestamp

float

DOUBLE

float

image

UNSUPPORTED

image

int

INTEGER

integer

money

UNSUPPORTED

money

real

REAL

real

smalldatetime

UNSUPPORTED

smalldatetime

smallint

SMALLINT

smallint

130

Relational Interface System (RIS) SQL User's Guide

Vendor-Specific Information
smallmoney

UNSUPPORTED

smallmoney

text

UNSUPPORTED

text

timestamp

UNSUPPORTED

timestamp

tinyint

UNSUPPORTED

tinyint

varbinary(n)

UNSUPPORTED

varbinary

varchar(x), x<=240

CHARACTER(x)

varchar

varchar(x), 241<=x

UNSUPPORTED

varchar

Relational Interface System (RIS) SQL User's Guide

131

Vendor-Specific Information

132

Relational Interface System (RIS) SQL User's Guide

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 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
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

10

SMALLINT

REAL

DOUBLE

15

DECIMAL TIMESTAMP

user specified <= 15 24

Consider the following table definition:


create table t1(c1 int, c2 char(5), c3 decimal(12,2));

5.
6.
7.
8.
9.
10.

Total length is 2 * 3 + 5 + 10 + 12 = 33
The number of columns specified in a create index statement cannot exceed 6.
The total length of all the columns involved in an index cannot exceed 120.
The number of columns specified in a group by clause cannot exceed 6.
The total length of all the columns involved in a group by clause cannot exceed 120.
The number of columns specified in an order by clause cannot exceed 6.
The total length of all the columns involved in an order by clause cannot exceed 120.

Relational Interface System (RIS) SQL User's Guide

133

RIS Limits
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 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.
17. The default decimal precision is 8.
18. The default decimal scale is 0.
19. The limits for a RIS integer are -2147483647 to 2147483647.
20. The number of prepared statements cannot exceed 40.
21. The size of a RIS error message cannot exceed 160.
22. The size of a RIS error name cannot exceed 40.
23. The size of the database parameters string in the schema file cannot exceed 512.
24. The number of schemas that can be defined for a database cannot exceed 300.
25. The size of a RIS statement cannot exceed 32765.
26. The number of network protocols that can be specified for a schema cannot exceed 4.
27. The number of concurrent transactions cannot exceed 1.
28. The number of table definitions RIS can store in memory cannot exceed 100.
29. The size of a RIS reserved word cannot exceed 18.
30. The hashed string size for an external name is 4 characters.
31. The maximum number of attempts for resolving external name collisions is 5.
32.
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 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.

134

Relational Interface System (RIS) SQL User's Guide

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.)

Relational Interface System (RIS) SQL User's Guide

135

Parameters File
The PathName value is c:\Program Files\Common Files\Intergraph\RIS05.nn by default.

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
5. MAX_STATIC_STMTS
6. MAX_USER_STMTS
7. MAX_SECONDARY_SCHEMAS
8. MAX_TRANSACTIONS
9. MAX_TABLES_IN_MEM

136

Relational Interface System (RIS) SQL User's Guide

Parameters File
10.
11.
12.
13.

Network Verification Parameters


Schema Definition File Location
LOCK_FILE_RETRY
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.

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: 0x50000
SHARED_MEMORY maximum: 0x400000
SHARED_MEMORY default: 0x200000

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: 0
MAX_LOCAL_SERVERS maximum: 24
MAX_LOCAL_SERVERS default: 8

Relational Interface System (RIS) SQL User's Guide

137

Parameters File

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: 1
MAX_ROWS maximum: 8388606
MAX_ROWS default: 100

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: 66552
MAX_BUFFER_SIZE maximum: 67108848
MAX_BUFFER_SIZE minimum default: 66552

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: 0
MAX_STATIC_STMTS maximum: 512
MAX_STATIC_STMTS default: 10

138

Relational Interface System (RIS) SQL User's Guide

Parameters File

MAX_USER_STMTS
MAX_USER_STMTS is the maximum number of statements that RIS will attempt to keep
prepared.
MAX_USER_STMTS minimum: 1
MAX_USER_STMTS maximum: 512
MAX_USER_STMTS default: 40

MAX_SECONDARY_SCHEMAS
MAX_SECONDARY_SCHEMAS is the maximum number of secondary schemas that RIS
allows per super schema.
MAX_SECONDARY_SCHEMAS minimum: 0
MAX_SECONDARY_SCHEMAS maximum: 9
MAX_SECONDARY_SCHEMAS default: 0

MAX_TRANSACTIONS
MAX_TRANSACTIONS is the maximum number of transactions that RIS runs at a time.
MAX_TRANSACTIONS minimum: 1
MAX_TRANSACTIONS maximum: 40
MAX_TRANSACTIONS default: 1

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: 1
MAX_TABLES_IN_MEM maximum: 1024
MAX_TABLES_IN_MEM default: 50

Relational Interface System (RIS) SQL User's Guide

139

Parameters File

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: 0
TIMESTAMP_INTERVAL maximum: 100000
TIMESTAMP_INTERVAL default: 0
2. 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.
INITIAL_TIMEOUT minimum: 0
INITIAL_TIMEOUT maximum: 100000
INITIAL_TIMEOUT default: 12
3. 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: 0
TIMESTAMP_TOLERANCE maximum: 1000
TIMESTAMP_TOLERANCE default: 5
4. 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

140

Relational Interface System (RIS) SQL User's Guide

Parameters File
that can be written in the network buffer without the possibility of the network buffer
becoming full.
BUFFER_FULL_SIZE minimum: 8
BUFFER_FULL_SIZE maximum: 8000
BUFFER_FULL_SIZE default: 64
5. 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: 0
BUFFER_FULL_TIMEOUT maximum: 100000
BUFFER_FULL_TIMEOUT default: 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.

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: X
tcp/ip: T
decnet: D
memory(local): 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: name or XXXXXXXX.XX-XX-XX-XX-XX-XX
tcp/ip: name or XXX.XXX.XXX.XXX
decnet: name or XX.XXXX
memory(local): n/a
Relational Interface System (RIS) SQL User's Guide

141

Parameters File
3. 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: /usr/bob/risschema
Windows NT example: c:\users\bob\risschema
SCHEMA_FILE_PROTOCOL default: M
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.

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

142

Relational Interface System (RIS) SQL User's Guide

Parameters File

Client Process Location


These are the default values for the CLIENT parameters:
CLIENT_PROTOCOL default: M
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.

Relational Interface System (RIS) SQL User's Guide

143

Parameters File

144

Relational Interface System (RIS) SQL User's Guide

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:

Field

Description

DBID

The database ID; a unique key to identify the database.

DTYPE

The database type; O for ORACLE 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 value is N for Windows.

Relational Interface System (RIS) SQL User's Guide

145

Schema Definition File


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.

Fields 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.

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 ORACLE and
Microsoft SQL Server.

146

Relational Interface System (RIS) SQL User's Guide

Schema Definition File


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=5 ***(ORACLE)***
DTYPE=O
DBNAME=A
OSTYPE=U
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 ***(ORACLE on NT)***
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=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=

Relational Interface System (RIS) SQL User's Guide

147

Schema Definition File


DSQUERY=RISMSQ
IFILE=
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=mssql_nt
SERVER_VERSION=0.0
SECURE=0
DICTOWNER=jill
SCHOWNER=sue
SCHOWNPASS=anything
BEGIN_GRANTEES
END_GRANTEES
DBID=9
-

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.

148

Relational Interface System (RIS) SQL User's Guide

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\risNN.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.

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.
0 |english

|english

|0x0409|1252|U.S. English

1 |korean

|korean

|0x0412|946|korean

Relational Interface System (RIS) SQL User's Guide

149

Language Configuration File

150

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
Relational Interface System (RIS) SQL User's Guide

Language Configuration File


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

Relational Interface System (RIS) SQL User's Guide

151

Language Configuration File

152

Relational Interface System (RIS) SQL User's Guide

Index
A
alter schema 41
alter table 44
Altering Tables 15
Application Support 2

C
Client Process Location 143
close schema 45
commit 45
Committing Transactions 31
create index 46
create schema 47
create schema (Microsoft SQL Server
Database Descriptor) 51
create schema (ORACLE Database
Descriptor) 50
create table 52
create view 53
Creating a Supervisor Schema 26
Creating an Employee Schema 27
Creating Tables 13
Creating the Employee Table 25
Creating the Maintenance Schema 25
Creating Views 21

D
Data Definition Language (DDL) Statements
29
Data Manipulation Language (DML)
Statements 30
Data type Mappings 127
Data Types 14
Database Privileges 24
Database Users 6
Databases 5
declare schema 55
Declare Schema 10
declare table 57
declare view 58
default schema 59
Default Schema 10
delete 60
Relational Interface System (RIS) SQL User's Guide

Deleting Rows 20
Deleting View Data 24
drop index 60
drop schema 61
drop table 61
drop view 62
Dropping Tables 16
Dropping Views 21

E
Enabling and Disabling Transaction
Autocommit 31
Examples 36
exec 63
extern Clause 15

F
Features of RIS 1

G
General Notes on Data Types 127
grant 63
grant (to schema) 64
grant (to user) 65

H
Hardware and Software Platforms 3

I
Indexes 35
insert 65
Inserting a Single Row 18
Inserting Rows 18
Inserting Rows Using a Select Statement 19
Inserting View Data 22
Introduction to RIS 1

J
Joining Tables 17

L
Language Configuration File 149

153

Index
List of Identifiers 39
lock tables 67
LOCK_FILE_RETRY 142
Locking Tables 34

M
Manipulating View Data 22
MAX_BUFFER_SIZE 138
MAX_LOCAL_SERVERS 137
MAX_ROWS 138
MAX_SECONDARY_SCHEMAS 139
MAX_STATIC_STMTS 138
MAX_TABLES_IN_MEM 139
MAX_TRANSACTIONS 139
MAX_USER_STMTS 139
Microsoft SQL Reserved Words 106
Miscellaneous Statements 30
MSSQL 130
MSSQL-To-RIS Mapping 130

N
Nested Query 83
NETWORK Error
NET_E_CONNECT_ERROR
(0x89cd806a) 87
NET_E_READ_BUFFER_TOO_SMALL
(0x89cd81d2) 88
NET_E_READ_ERROR (0x89cd81da)
88
Network Support 2
Network Verification 35
Network Verification Parameters 140
not null Clause 15

O
open schema 68
Oracle 128
Oracle Reserved Words 103
ORACLE-To-RIS Mapping 128

P
Parameters File 135
Performance 2
Preface PDS v
Privileges 24

154

Relating Databases, Users, and Schemas 11


Relation Privileges 24
revoke 69
revoke (from schema) 69
revoke (from user) 70
RIS and Vendor DBMS Reserved Words
101
RIS Data Types 109
RIS Dictionary 6
RIS Dictionary Views 111
RIS Error
RIS_E_BAD_LOGIN (0x) 89
RIS_E_CANT_CREATE_SCHEMA_FIL
E (0x8a94812a) 89
RIS_E_CANT_FREE_DICT
(0x8a94817a) 90
RIS_E_CANT_GET_SCHEMA_FILE
(0x8a9481aa) 90
RIS_E_CANT_LOCATE RIS
(0x8a9481b2) 90
RIS_E_CANT_OPEN_ID_FILE_WRITE
(0x8a9481da) 90
RIS_E_CANT_OPEN_LANGCONFIG_F
ILE (0x8a94b2e2) 91
RIS_E_CANT_PUT_SCHEMA_FILE
(0x8a94820a) 91
RIS_E_CLIENT_DIED (0x8a9482b2)
91
RIS_E_CLIENT_NETWORK_ERROR
(0x8a9482c2) 92
RIS_E_DEFAULT_SCHEMA_DIED
(0x8a94842a) 92
RIS_E_INCONSISTENT_ADDRS
(0x8a948672) 92
RIS_E_INCONSISTENT_DBPARMS
(0x8a94b28a) 94
RIS_E_INTERNAL_ERROR
(0x8a9486a2) 94
RIS_E_INV_OPEN (0x8a948e1a) 95
RIS_E_INV_OPEN_DB (0x8a948e22)
95
RIS_E_INV_SYB_OPTION (0x8a9492f2)
95
RIS_E_INV_TABLE_NAME
(0x8a948902) 96
RIS_E_INV_USER_SPEC (0x8a94942a)
96

Relational Interface System (RIS) SQL User's Guide

Index
RIS_E_MISSING_DIR_DEF
(0x8a949629) 96
RIS_E_NO_PROTOCOL (0x8a9499ea)
96
RIS_E_SCHEMA_RESTARTED
(0x8a949eea) 97
RIS_E_SERVER_NETWORK_ERROR
(0x8a949f3a) 97
RIS_E_UNKNOWN_SCHEMA
(0x8a94a142) 99
RIS Installation for Windows 3
RIS Limits 133
RIS Overview 5
RIS Reserved Words 101
RIS Utility Error
RISUTL_E_INVALID_NEW_SCH
(0x89ce889a) 100
RISUTL_E_LEFT_DELIMITER_MISSIN
G (0x89ce88e2) 99
RIS5COLUMN_PRIVS 111
RIS5COLUMNS 113
RIS5DBMS_COLUMNS 115
RIS5DBMS_INDEXES 116
RIS5DBMS_TABLES 116
RIS5DBMS_USERS 117
RIS5DBMS_VIEWS 117
RIS5DBS 118
RIS5INDEX_COLUMNS 120
RIS5INDEXES 121
RIS5SCHEMAS 122
RIS5SCHPRIV 123
RIS5TABLE_PRIVS 123
RIS5TABLES 124
RIS5USERS 125
RIS5VIEWS 126
RIS-Supported Dictionary Views 111
RIS-To-MSSQL Mapping 130
RIS-To-ORACLE Mapping 128
rollback 71
Rolling Back Transactions 33

Selecting Tables 16
set database 73
set mode 73
set network verification 74
set transaction 77
SHARED_MEMORY 137
SQL Database Language Reference 39
SQL Functions 84
Standard Schema 7
Starting and Ending Transactions 31
Supported SQL Statements 40

T
Tables 12
The Grant Operation 27
Transactions 28
Troubleshooting 87

U
undeclare schema 77
undeclare table 78
undeclare view 78
union 79
update 80
Updating Rows 19
Updating View Data 23
Using a Secure Schema 36
Using a Shared Dictionary 37
Using External Objects 38
Using Multiple Transactions 34
Using Privileges 25

V
Vendor-Specific Information 127
Views 20

W
where 81

S
Schema Definition File 145
Schema Definition File Location 141
Schema Names 9
Schemas 7
Secure Schema 8
select 71
Relational Interface System (RIS) SQL User's Guide

155

Potrebbero piacerti anche