Previous Page TOC Index Next Page

ADMINISTRATION WITH SQL STATEMENTS


This chapter tells you how to manage users, tables, and indexes using SQL statements. You can use SOLID SQL Editor and many ODBC compliant tools for executing these SQL statements.

To automate these tasks, you may want to save the SQL statements to a file. You can use these files for rerunning your SQL statements later or as a document of your users, tables, and indexes.

The SQL syntax is based on the ANSI X3.135-1989 level 2 standard including important ANSI X3.135-1992 (SQL2) extensions. User and role management services missing from previous standards are based on the ANSI SQL3 draft. For a more formal definition of the syntax, refer to Appendix D SOLID Server SQL Syntax of this document. For the full description of the SOLID SQL API, refer to the SOLID SQL API Help file. The same information is included in SOLID Server Programmer's Guide and SOLID Server Programmer's Reference.

Managing User Privileges and Roles

You can use SOLID SQL Editor and many ODBC compliant SQL tools to modify user privileges. Users and roles are created and deleted using SQL statements or commands. A file consisting of several SQL statements is called a SQL script.

In the SOLID directory, you will find an SQL script called users.sql, which gives an example of creating users and roles. You can open, view and run it using SOLID SQL Editor. To create your own users and roles, you can make your own script describing your user environment.


NOTE. All SQL statements must be terminated with a semicolon (;).


User Privileges

When using SOLID Server in a multi-user environment, you may want to apply user privileges to hide certain tables from some users. For example, you may not want an employee to see the table in which employee salaries are listed, or you may not want other users to mess with your test tables.

SOLID Server allows you to apply five different kinds of user privileges. A user may be able to view, delete, insert, update or reference information in a table or view. Any combination of these privileges may also be applied. A user who has none of these privileges to a table is not able to use the table at all.

User Roles

Privileges can also be granted to an entity called a role. A role is a group of privileges that can be granted to users as one unit. SOLID Server allows you to create roles and assign users to certain roles.


NOTE. Same string can not be used both as a user name and a role name.


The following user and role names are reserved:

Reserved name

Description

PUBLIC

You can use this role to grant privileges to all users. When user privileges to a certain table are granted to the role PUBLIC, all current and future users have the specified user privileges to this table. This role is granted automatically to all users.

SYS_ADMIN_ROLE

This is the default role for the database administrator. This role has administration privileges to all tables, indexes and users. This is also the role of the creator of the database.

_SYSTEM

This is the schema name of all system tables and views.

SYS_CONSOLE_ROLE

This role has right to use SOLID Remote Control, but does not have other administration privileges.

Examples of SQL Statements

Below are some examples of SQL commands for administering users, roles and user privileges.

Creating Users

CREATE USER <username> IDENTIFIED BY <password>;

Only an administrator has the privilege to execute this statement. The following example creates a new user named CALVIN with the password HOBBES.

CREATE USER CALVIN IDENTIFIED BY HOBBES;

Deleting Users

DROP USER <username>;

Only an administrator has the privilege to execute this statement. The following example deletes the user named CALVIN.

DROP USER CALVIN;

Changing a Password

ALTER USER <username> IDENTIFIED BY <new password>;

The user <username> and the administrator have the privilege to execute this command. The following example changes CALVIN's password to GUBBES.

ALTER USER CALVIN IDENTIFIED BY GUBBES;

Creating Roles

CREATE ROLE <rolename>;

The following example creates a new user role named GUEST_USERS.

CREATE ROLE GUEST_USERS;

Deleting Roles

DROP ROLE <role_name>;

The following example deletes the user role named GUEST_USERS.

DROP ROLE GUEST_USERS;

Granting Privileges to a User or a Role

GRANT <user_privilege> ON <table_name> TO <username or role_name>;

The possible user privileges on tables are SELECT, INSERT, DELETE, UPDATE, REFERENCES and ALL. ALL will give a user or a role all five privileges mentioned above. EXECUTE privilege will give a user a right to execute a stored procedure. A new user has not any privileges.

The following example grants INSERT and DELETE privileges on a table named TEST_TABLE to the GUEST_USERS role.

GRANT INSERT, DELETE ON TEST_TABLE TO GUEST_USERS;

The following example grants EXECUTE privilege on a stored procedure named SP_TEST to user CALVIN.

GRANT EXECUTE ON SP_TEST TO CALVIN;

Granting Privileges to a User by Giving the User a Role

GRANT <role_name> TO <username>;

The following example gives the user CALVIN the privileges that are defined for the GUEST_USERS role.

GRANT GUEST_USERS TO CALVIN;

Revoking Privileges from a User or a Role

REVOKE <user_privilege> ON <table_name> FROM <username or role_name>;

The following example revokes the INSERT privilege on the table named TEST_TABLE from the GUEST_USERS role.

REVOKE INSERT ON TEST_TABLE FROM GUEST_USERS;

Revoking Privileges by Revoking the Role of a User

REVOKE <role_name> FROM <username>;

The following example revokes the privileges that are defined for the GUEST_USERS role from CALVIN.

REVOKE GUEST_USERS FROM CALVIN;

Granting Administrator Privileges to a User

GRANT SYS_ADMIN_ROLE TO <username>;

The following example grants administrator privileges to CALVIN, who now has all privileges to all tables.

GRANT SYS_ADMIN_ROLE TO CALVIN;

Managing Tables

SOLID Server has a dynamic data dictionary that allows you to create, delete and alter tables on-line. SOLID Server tables are managed using SQL commands.

In the SOLID directory, you can find an SQL script named sample.sql, which gives an example of managing tables. You can view and run the script using SOLID SQL Editor.

Below are some examples of SQL statements for managing tables. For a formal definition of the SOL syntax of SOLID Server, refer to Appendix D SOLID Server SQL Syntax of this document.


TIP. If you want to see the names of all tables in your database, issue the SQL statement SELECT * FROM TABLES or use predefined command TABLES from SOLID SQL Editor. The table names can be found in the column TABLE_NAME.


Examples of SQL Statements

Below are some examples of SQL commands for administering tables.

Creating Tables

CREATE TABLE <table_name> (<column> <column type> 

[,<column> <column type>]...);

All users have privileges to create tables.

The following example creates a new table named TEST with the column I of the column type INTEGER and the column TEXT of the column type VARCHAR.

CREATE TABLE TEST (I INTEGER, TEXT VARCHAR);

Removing Tables

DROP TABLE <table_name>;

Only the creator of the particular table or users having SYS_ADMIN_ROLE have privileges to remove tables.

The following example removes the table named TEST.

DROP TABLE TEST;

Adding Columns to a Table

ALTER TABLE <table_name> ADD COLUMN <column_name> 

<column type>;

Only the creator of the particular table or users having SYS_ADMIN_ROLE have privileges to add or delete columns in a table.

The following example adds the column C of the column type CHAR(1) to the table TEST.

ALTER TABLE TEST ADD COLUMN C CHAR(1);

Deleting Columns from a Table

ALTER TABLE <table_name> DROP COLUMN 

<column_name>;

The following example statement deletes the column C from the table TEST.

ALTER TABLE TEST DROP COLUMN C;


Commit button

SOLID SQL Editor:

Commit button

NOTE. If the autocommit mode is set OFF, you need to commit your work before you can modify the table you altered. To commit your work after altering a table, use the SQL statement COMMIT WORK;, or press the Commit button in SOLID SQL Editor. If the autocommit mode is set ON - this is the default in SOLID SQL Editor - the transactions are committed automatically.


Managing Indexes

Indexes are used to speed up access to tables. The database engine uses indexes to access the rows in a table directly. Without indexes, the engine would have to search the whole contents of a table to find the desired row. There are two kinds of indexes: non-unique indexes and unique indexes. A unique index is an index where all key values are unique. You can create as many indexes as you like to a single table. However, adding indexes slows down updates on that table.

SOLID Server allows you to create and delete indexes using the following SQL statements. For a formal definition of the syntax of these statements, refer to Appendix D SOLID Server SQL Syntax of this document.

Examples of SQL Statements

Below are some examples of SQL commands for administering indexes.

Creating an Index to a Table

CREATE INDEX <index_name> ON <table_name> 

(<column_name> [ASC | DESC]); Only the creator of the particular table or users having SYS_ADMIN_ROLE have privileges to create or delete indexes.

The following example creates an index named X_TEST on the table TEST to the column I.

CREATE INDEX X_TEST ON TEST (I);

Creating a Unique Index to a Table

CREATE UNIQUE INDEX <index_name> ON <table_name> 

(<column_name>);

The following example creates a unique index named UX_TEST on the table TEST to the column I.

CREATE UNIQUE INDEX UX_TEST ON TEST (I);

Deleting an Index

DROP INDEX <index_name>;

The following example deletes the index named X_TEST.

DROP INDEX X_TEST;


Undisplayed Graphic

SOLID SQL Editor:
Commit button

NOTE. If the autocommit mode is set OFF, you need to commit your work before you can modify the table on which you altered the indexes. To commit your work after modifying indexes, use the SQL statement COMMIT WORK;, or press the Commit button in SOLID SQL Editor. If the autocommit mode is set ON - this is the default in SOLID SQL Editor - the transactions are committed automatically.


Primary Keys

A primary key is a column or combination of columns that uniquely identify each record in a table. Primary keys like indexes speed up access to tables. The difference between primary keys and indexes in SOLID Server is that the primary key cluster data in the database according to the key values.

This behavior differs from the default clustering in SOLID Server, where the data is clustered according to the insertion time only.

Foreign Keys

A foreign key is a column or group of columns within a table that refers to, or relates to, some other table through its values. The foreign key must always include enough columns in its definition to uniquely identify a row in the referenced table. The main reason for defining foreign keys is to ensure that rows in one table always have corresponding rows in another table; that is, to ensure that referential integrity of data is maintained.

Previous Page TOC Index Next Page

Copyright © 1992-1997 Solid Information Technology Ltd All rights reserved.