Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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.
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
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
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
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
Preface PDS
This document provides command reference information and procedural instructions for the
Relational Interface System (RIS) task.
Preface PDS
vi
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.
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%).
Introduction to RIS
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).
Introduction to RIS
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.
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).
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.
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.
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.
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
RIS Overview
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:
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:
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
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.
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
RIS Overview
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.
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
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:
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.
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
RIS Overview
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;
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
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;
21
RIS Overview
This statement creates a table named cars with the following rows and columns:
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 );
22
RIS Overview
Selecting from the models view reveals 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 );
23
RIS Overview
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
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).
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.
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;
Now p_maint schema can select, insert, update and delete from the table employee_info. In
addition, it can create and manage relations of its own.
3. Set the default schema back to p_admin since the previous statement set it to the new
schema.
default schema p_admin;
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
RIS Overview
3. Set the default schema back to p_admin because the previous statement set it to the new
schema.
default schema p_admin;
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.
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
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
RIS Overview
29
RIS Overview
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
RIS Overview
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.
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;
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
RIS Overview
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
If a rollback statement is issued, the transaction is ended and the table once again appears as
follows:
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;
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
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
35
RIS Overview
create index statement. For example, the following statement creates an index on the phone
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;
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
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.
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.
37
RIS Overview
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
SECTION 3
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
39
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
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.
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)
43
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
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.
45
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.
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
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
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)
49
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
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 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)
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
51
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.
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
53
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
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]];
55
56
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];
57
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
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>];
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)
59
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>;
See Also
create index (on page 46)
60
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.
61
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
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)
63
See Also
revoke (on page 69)
64
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.
65
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
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
67
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
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.
See Also
grant (to schema) (on page 64)
69
See Also
grant (on page 63)
70
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 }]} [, ...]];
71
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
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).
73
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)
74
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.
75
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
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)
77
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>;
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>;
78
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)
79
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
where
The where clause restricts the rows of a relation that are selected, updated, or deleted.
where <condition>
81
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
where
where
where
where
where
where
where
where
where
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.
83
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
...);
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.
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
85
See Also
select (on page 71)
where (on page 80)
86
SECTION 4
Troubleshooting
This section describes some of the problems, causes, and recoveries for some commonly
encountered RIS error messages.
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.)
88
Troubleshooting
89
Troubleshooting
90
Troubleshooting
91
Troubleshooting
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.
93
Troubleshooting
94
Troubleshooting
95
Troubleshooting
96
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.
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
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.
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.
100
APPENDIX A
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
101
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
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
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
103
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
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
105
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
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
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
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
107
union
unique
update
user
user_option
using
values
varying
view
waitfor
where
while
with
work
writetext
108
APPENDIX B
SQL string
SQL code
Description
char[acter](n)
CHARACTER
int[eger]
INTEGER
smallint
SMALLINT
double [precision]
DOUBLE
real
REAL
decimal[(p[, s])]
DECIMAL
timestamp
TIMESTAMP
-orcurrent_timestamp.
ris_blob(n)
RIS_BLOB
109
SQL string
SQL code
Description
ris_text(n)
RIS_TEXT
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
APPENDIX C
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.
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
111
112
grantor
char(31)
not null
lower
grantee
char(31)
not null
ris_privileges
char(7)
not null
either
ris_object
char(7)
not null
UPPER
schema_name
table_name
upper_table_name
column_name
upper_column_name
grantor
grantee
ris_privileges
ris_object
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
table_name
113
114
upper_table_name
column_name
ext_column_name
upper_column_name
position
ris_type
ris_type_string
dbms_type_string
char_max_length
prec
nullable
ris_object
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
column_name
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.
115
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
index_name
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
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
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.
117
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
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
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
database_type
not null
N/A
protocol_1
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
net_address_2
protocol_3
net_address_3
protocol_4
net_address_4
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
119
short_parameter_1
short_parameter_2
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
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
upper_index_name
table_name
upper_table_name
column_name
upper_column_name
position
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
index_name
dbms_owner
121
upper_index_name
table_name
upper_table_name
index_type
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
schema_owner
database_id
schema_type
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
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
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
table_name
upper_table_name
grantor
123
This is the name of the schema to which the privileges were granted, or
PUBLIC.
ris_privileges
ris_object
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
timestamp
not null
N/A
ris_object
char(1)
not null
UPPER
schema_name
table_name
dbms_owner
ext_table_name
upper_table_name
table_type
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
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
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
125
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
view_name
dbms_owner
ext_view_name
upper_view_name
ris_view_def
dbms_view_def
sequence_id
A number that indicates the order of the string pieces (0,1,2,...). Each
view restarts the sequence.
not null
N/A
APPENDIX D
Vendor-Specific Information
This section contains information on vendor-specific data types.
Convention
Meaning
Unambiguous mapping.
See Also
ORACLE (on page 128)
MSSQL (on page 129)
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
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
CHARACTER(x)
char
UNSUPPORTED
char
date
TIMESTAMP
date
long (1byte-2Gb)
RIS_BLOB
long
long raw(1byte-2Gb)
RIS_TEXT
long raw
number(p,s)
number
raw(x)
UNSUPPORTED
raw
rowid
UNSUPPORTED
rowid
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)
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
varchar
=== char
129
Vendor-Specific Information
MSSQL
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
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
131
Vendor-Specific Information
132
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
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.
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
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
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
Parameters File
10.
11.
12.
13.
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
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
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
139
Parameters File
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
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.
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
Parameters File
143
Parameters File
144
APPENDIX G
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
DTYPE
DBNAME
OSPASS
The password for the operating system user. This field is blank if
all the schemas on this database are secure schemas.
OSTYPE
145
PROTOCOL
NETADDR
SCHNAME
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
DICTOWNER
SCHOWNER
SCHOWNPASS
BEGIN_GRANTEES
and
END_GRANTEES
DIR
Specifies the name of the Microsoft SQL Server used for the schema.
FILENAME
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
147
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
APPENDIX H
Unique RIS language identifier. For every new language added, this
identifier is incremented.
ris_lang_name
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
code_page
os_lang_name
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
149
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
|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
151
152
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
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