The SOLID Server 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.
This appendix presents a simplified description of the SQL statements including some examples. The same information is included in the SOLID Server Programmer's Guide and Reference.
The description syntax uses these conversions:
- SQL keywords appear in all UPPERCASE letters
- syntax elements are specified in lowercase
- syntax elements specified in lowercase italics are explained in the end of this appendix
- the notation ... indicates that elements can be repeated
- vertical bars | indicates a choice between two or more alternative syntax elements
- square brackets [ ] indicate an optional syntax element
- braces { } indicate a choice among required syntax elements
ADMIN COMMAND
ADMIN COMMAND 'command-name'
command-name ::= EXIT | HELP | SHUTDOWN | OPEN |
CLOSE | THROWOUT | USERLIST | MAKECP | BACKUP |
BACKUPLIST | STATUS | REPORT | MESSAGES |
MONITOR | VERSION | ERRORCODE | HOTSTANDBY
This SQL extension executes administrator commands. Syntax for the extension is
ADMIN COMMAND 'command-name'
where command-name is a SOLID Remote Control (Teletype) command string. The result set contains two columns: RC INTEGER and TEXT VARCHAR(254). Integer column RC is a command return code (0 if success), varchar column TEXT is the command reply. The TEXT field contains same lines that a displayed on SOLID Remote Control (Teletype) screen, one line per one result row.
ADMIN COMMAND 'USERLIST';
ALTER TABLE
ALTER TABLE base-table-name
{ADD [COLUMN] column-identifier data-type |
DROP [COLUMN] column-identifier |
RENAME [COLUMN]
column-identifier column-identifier |
MODIFY [COLUMN]
column-identifier data-type} |
MODIFY SCHEMA schema-name |
SET {OPTIMISTIC | PESSIMISTIC}
The structure of a table may be modified through the ALTER TABLE statement. Within the context of this statement, columns may be added, modified, or removed.
The owner of a table can be changed using the
ALTER TABLE base-table-name MODIFY SCHEMA schema-name statement. This statement gives all rights to the new owner of the table including creator rights. The old owners access rights to the table, excluding the creator rights, are preserved.
Individual tables can be set to optimistic or pessimistic with the command
ALTER TABLE base-table-name SET {OPTIMISTIC | PESSIMISTIC}. By default, all tables are optimistic. A database-wide default can be set in the General section of the configuration file with the parameter Pessimistic = yes.
If transaction early validate is used, update and delete operations use locks for the early validation. Read operations do not lock, but update and delete operations lock the updated or deleted row.
ALTER TABLE TEST ADD X INTEGER; ALTER TABLE TEST RENAME COLUMN X Y; ALTER TABLE TEST MODIFY COLUMN X SMALLINT; ALTER TABLE TEST DROP COLUMN X;
ALTER USER
ALTER USER user-name IDENTIFIED BY password
The password of a user may be modified through the ALTER USER statement.
ALTER USER MANAGER IDENTIFIED BY O2CPTG;
CALL
CALL procedure-name [parameter ...]
Stored procedures are called with statement CALL.
CALL proctest;
COMMIT
COMMIT WORK
The changes made in the database are made permanent by COMMIT statement. It terminates the transaction.
COMMIT WORK;
CREATE EVENT
CREATE EVENT event-name
[(parameter-definition
[, parameter-definition ...])]
Event alerts are used to signal an event in the database. Events are simple objects with a name. The use of event alerts removes resource consuming database polling from applications.
An event object is created with the SQL statement
CREATE EVENT event-name [parameter-list]
The name can be any user-specified alphanumeric string. The parameter list specifies parameter names and parameter types. The parameter types are normal SQL types.
Events are dropped with the SQL statement
DROP EVENT event-name
Events are triggered and received inside stored procedures. Special stored procedure statements are used to trigger and receive events.
The event is triggered with the stored procedure statement
POST EVENT event-name [parameters]
Event parameters must be local variables or parameters in the stored procedure where the event is triggered. All clients that are waiting for the posted event will receive the event.
To make a procedure wait for an event to happen, the WAIT EVENT construct is used in a stored procedure:
wait-event-statement ::=
WAIT EVENT
[event-specification ...]
END WAIT
event-specification ::=
WHEN event-name (parameters) BEGIN
statements
END EVENT
Example of a procedure that waits for an event:
create procedure "event-wait(i1 integer)
returns (result varchar)
begin
declare i integer;
declare c char(4);
i := 0;
wait event
when test1 begin
result := 'event1';
return;
end event
when test2(i) begin
end event
when test3(i, c) begin
end event
end wait
if i <> 0 then
result := 'if';
post event test1;
else
result := 'else';
post event test2(i);
post event test3(i, c);
end if
end";
The creator of an event or the database administrator can grant and revoke access rights. Access rights can be granted to users and roles. The select access right gives waiting access to an event. The insert access right gives triggering access to an event.
CREATE EVENT ALERT1(I INTEGER, C CHAR(4));
CREATE INDEX
CREATE [UNIQUE] INDEX index-name
ON base-table-name
(column-identifier [ASC | DESC]
[, column-identifier [ASC | DESC]] ...)
Creates an index for a table based on the given columns. Keyword UNIQUE specifies that columns being indexed must contain unique values. Keywords ASC and DESC specify whether the given columns should be indexed in ascending or descending order. If not specified ascending order is used.
CREATE UNIQUE INDEX UX_TEST ON TEST (I); CREATE INDEX X_TEST ON TEST (I, J);
CREATE PROCEDURE
CREATE PROCEDURE procedure-name
[(parameter-definition
[, parameter-definition ...])]
[RETURNS (parameter-definition
[, parameter-definition ...])]
BEGIN procedure-body END; parameter-definition ::= parameter-name data-type procedure-body ::= [declare-statement; ...]
procedure-statement; [procedure-statement; ...] declare-statement ::= DECLARE variable-name
data-type procedure-statement ::= prepare-statement |
exec-statement | fetch-statement |
control-statement | post-statement |
wait-event-statement prepare-statement ::= EXEC SQL PREPARE
cursor-name sql-statement execute-statement ::=
EXEC SQL EXECUTE
cursor-name
[USING (variable [, variable ...])]
[INTO (variable [, variable ...])] |
EXEC SQL {COMMIT | ROLLBACK} WORK |
EXEC SQL SET TRANSACTION {READ ONLY | READ WRITE} |
EXEC SQL WHENEVER SQLERROR [ROLLBACK [WORK],] ABORT |
EXEC SEQUENCE sequence-name.CURRENT INTO variable |
EXEC SEQUENCE sequence-name.NEXT INTO variable |
EXEC SEQUENCE sequence-name SET VALUE USING variable fetch-statement ::= EXEC SQL FETCH cursor-name post-statement ::= POST EVENT event-name [parameters] wait-event-statement ::=
WAIT EVENT
[event-specification ...]
END WAIT event-specification ::=
WHEN event-name (parameters) BEGIN
statements
END EVENT control-statement ::=
SET variable-name = value |
variable-name := value |
WHILE expression
LOOP procedure-statement... END LOOP |
LEAVE |
IF expression THEN procedure-statement ...
[ ELSEIF procedure-statement ... THEN] ...
ELSE procedure-statement ... END IF |
RETURN | RETURN SQLERROR OF cursor-name | RETURN ROW
Stored procedures are simple programs, or procedures, that are executed in the server. The user can create a procedure that contains several SQL statements or a whole transaction and execute it with a single call statement. Usage of stored procedures reduces network traffic and allows more strict control to access rights and database operations.
Procedures are created with the statement
CREATE PROCEDURE name body
and dropped with the statement
DROP PROCEDURE name
Procedures are called with the statement
CALL name [parameter ...]
Procedures can take several input parameters and return a single row or several rows as a result. The result is built from specified output parameters. Procedures are thus used in ODBC in the same way as the SQL SELECT statement.
Procedures are owned by the creator of the procedure. Specified access rights can be granted to other users. When the procedure is run, it has the creator's access rights to database objects.
The stored procedure syntax is a proprietary syntax modeled from SQL3 specifications and dynamic SQL. Procedures contain control statements and SQL statements.
The following control statements are available in the procedures:
All SQL DML and DDL statements can be used in procedures. Thus the procedure can, e.g., create tables or commit a transaction. Each SQL statement in the procedure is atomic.
Preparing SQL Statements
The SQL statements are first prepared with the statement
EXEC SQL PREPARE cursor sql-statement
The cursor specification is a cursor name that must be given. It can be any unique cursor name inside the transaction. Note that if the procedure is not a complete transaction, other open cursors outside the procedure may have conflicting cursor names.
Executing Prepared SQL Statements
The SQL statement is executed with the statement
EXEC SQL EXECUTE cursor [opt-using ] [opt-into ]
The optional opt-using specification has the syntax
USING (variable-list)
where variable-list contains a list of procedure variables or parameters separated by a comma. These variables are input parameters for the SQL statement. The SQL input parameters are marked with the standard question mark syntax in the prepare statement. If the SQL statement has no input parameters, the USING specification is ignored.
The optional opt-into specification has the syntax
INTO (variable-list)
where variable-list contains the variables that the column values of the SQL SELECT statement are stored into. The INTO specification is effective only for SQL SELECT statements.
Fetching Results
Rows are fetched with the statement
EXEC SQL FETCH cursor
If the fetch completed successfully, the column values are stored into the variables defined in the opt-into specification.
Checking for Errors
The result of each EXEC SQL statement executed inside a procedure body is stored into the variable SQLSUCCESS. This variable is automatically generated for every procedure. If the previous SQL statement was successful, a value one is stored into SQLSUCCESS. After a failed SQL statement, a value zero is stored into SQLSUCCESS.
EXEC SQL WHENEVER SQLERROR [ROLLBACK [WORK],] ABORT
is used to decrease the need for IF NOT SQLSUCCESS THEN tests after every executed SQL statement in a procedure. When this statement is included in a stored procedure all return values of executed statements are checked for errors. If statement execution returns an error, the procedure is automatically aborted. Optionally the transaction can be rolled back.
This statement can be used with SOLID Server Version 2.2 or later.
Using Transactions
EXEC SQL {COMMIT | ROLLBACK} WORK
is used to terminate transactions.
EXEC SQL SET TRANSACTION {READ ONLY | READ WRITE}
is used to control the type of transactions.
Using Sequencer Objects and Event Alerts
Refer to the usage of the CREATE SEQUENCE and CREATE EVENT statements.
create procedure "test2(tableid integer)
returns (cnt integer)
begin
exec sql prepare c1 select count(*) from
sys_tables where id > ?;
exec sql execute c1 using (tableid) into
(cnt);
exec sql fetch c1;
end";
-- This procedure can only be used with SOLID Server -- version 2.2 or later. create procedure "return_tables
returns (name varchar)
begin
exec sql whenever sqlerror rollback, abort;
exec sql prepare c1 select table_name
from sys_tables;
exec sql execute c1 into (name);
while sqlsuccess loop
exec sql fetch c1;
return row;
end loop;
end";
CREATE ROLE
CREATE ROLE role-name
Creates a new user role.
CREATE ROLE GUEST_USERS;
CREATE SEQUENCE
CREATE [DENSE] SEQUENCE sequence-name
Sequencer objects are objects that are used to get sequence numbers.
Using a dense sequence guarantees that there are no holes in the sequence numbers. The sequence number allocation is bound to the current transaction. If the transaction rolls back, also the sequence number allocations are rolled back. The drawback of dense sequences is that the sequence is locked out from other transactions until the current transaction ends.
Using a sparse sequence guarantees uniqueness of the returned values, but they are not bound to the current transaction. If a transaction allocates a sparse sequence number and later rolls back, the sequence number is simply lost.
The advantage of using a sequencer object instead of a separate table is that the sequencer object is specifically fine-tuned for fast execution and requires less overhead than normal update statements.
Sequences are accessed from stored procedures. The current sequence value can be retrieved using the following stored procedure statement:
EXEC SEQUENCE sequence-name.CURRENT INTO variable
The new sequence value can be retrieved using the following stored procedure statement:
EXEC SEQUENCE sequence-name.NEXT INTO variable
Sequence values can be set with the following stored procedure statement:
EXEC SEQUENCE sequence-name SET VALUE USING variable
Select access rights are required to retrieve the current sequence value. Update access rights are required to allocate new sequence values. These access rights are granted and revoked in the same way as table access rights.
CREATE DENSE SEQUENCE SEQ1;
CREATE TABLE
CREATE TABLE base-table-name
(column-element [, column-element] ...) base-table-name ::= base-table-identifier |
schema-name.base-table-identifier column-element ::= column-definition |
table-constraint-definition column-definition ::= column-identifier
data-type
[column-constraint-definition
[column-constraint-definition] ...] column-constraint-definition ::=
NOT NULL | NOT NULL UNIQUE |
NOT NULL PRIMARY KEY | CHECK (check-condition) table-constraint-definition ::=
UNIQUE (column-identifier
[, column-identifier] ...) |
PRIMARY KEY (column-identifier
[, column-identifier] ...) |
CHECK (check-condition) |
FOREIGN KEY (column-identifier
[, column-identifier] ...)
REFERENCES table-name
(column-identifier [, column-identifier] ...)
Tables are created through the CREATE TABLE statement. The CREATE TABLE statement requires a list of the columns created, the data types, and, if applicable, sizes of values within each column, in addition to other related alternatives (such as whether or not null values are permitted).
CREATE TABLE DEPT (DEPTNO INTEGER NOT NULL, DNAME VARCHAR, PRIMARY KEY(DEPTNO)); CREATE TABLE DEPT2 (DEPTNO INTEGER NOT NULL PRIMARY KEY, DNAME VARCHAR); CREATE TABLE DEPT3 (DEPTNO INTEGER NOT NULL UNIQUE, DNAME VARCHAR); CREATE TABLE DEPT4 (DEPTNO INTEGER NOT NULL, DNAME VARCHAR, UNIQUE(DEPTNO)); CREATE TABLE EMP (DEPTNO INTEGER, ENAME VARCHAR, FOREIGN KEY (DEPTNO) REFERENCES DEPT (DEPTNO)); CREATE TABLE EMP2 (DEPTNO INTEGER, ENAME VARCHAR, CHECK (ENAME IS NOT NULL), FOREIGN KEY (DEPTNO) REFERENCES DEPT (DEPTNO));
CREATE USER
CREATE USER user-name IDENTIFIED BY password
Creates a new user with a given password.
CREATE USER HOBBES IDENTIFIED BY CALVIN;
CREATE VIEW
CREATE VIEW viewed-table-name
[(column-identifier
[, column-identifier]... )]
AS query-specification
A view can be viewed as a virtual table; that is, a table that does not physically exist, but rather is formed by a query specification against one or more tables.
CREATE VIEW TEST_VIEW
(VIEW_I, VIEW_C, VIEW_ID)
AS SELECT I, C, ID FROM TEST;
DELETE
DELETE FROM table-name
[WHERE search-condition]
Depending on your search condition the specified row(s) will be deleted from a given table.
DELETE FROM TEST WHERE ID = 5; DELETE FROM TEST;
DELETE (positioned)
DELETE FROM table-name WHERE CURRENT OF cursor-name
The positioned DELETE statement deletes the current row of the cursor.
DELETE FROM TEST WHERE CURRENT OF MY_CURSOR;
DROP EVENT
DROP EVENT event-name
The DROP EVENT statement removes the specified event from the database.
DROP EVENT EVENT-TEST;
DROP INDEX
DROP INDEX index-name
The DROP INDEX statement removes the specified index from the database.
DROP INDEX UX_TEST;
DROP PROCEDURE
DROP PROCEDURE procedure-name
The DROP PROCEDURE statement removes the specified procedure from the database.
DROP PROCEDURE PROCTEST;
DROP ROLE
DROP ROLE role-name
The DROP ROLE statement removes the specified role from the database.
DROP ROLE GUEST_USERS;
DROP SEQUENCE
DROP SEQUENCE sequence-name
The DROP SEQUENCE statement removes the specified sequence from the database.
DROP SEQUENCE SEQ1;
DROP TABLE
DROP TABLE base-table-name
The DROP TABLE statement removes the specified table from the database.
DROP TABLE TEST;
DROP USER
DROP USER user-name
The DROP USER statement removes the specified user from the database.
DROP USER HOBBES;
DROP VIEW
DROP VIEW viewed-table-name
The DROP VIEW statement removes the specified view from the database.
DROP VIEW TEST_VIEW;
EXPLAIN PLAN FOR
EXPLAIN PLAN FOR sql-statement
The EXPLAIN PLAN FOR statement shows the selected search plan for the specified SQL statement.
EXPLAIN PLAN FOR select * from tables;
GRANT
GRANT {ALL | grant-privilege
[, grant-privilege]...}
ON table-name
TO {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... } [WITH GRANT OPTION] GRANT role-name TO user-name grant-privilege ::= DELETE | INSERT | SELECT |
UPDATE [( column-identifier
[, column-identifier]... )] |
REFERENCES [( column-identifier
[, column-identifier]... )] GRANT EXECUTE ON procedure-name
TO {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... } GRANT {SELECT | INSERT} ON event-name
TO {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... } GRANT {SELECT | UPDATE} ON sequence-name
TO {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... }
The GRANT statement is
- 1. used to grant privileges to the specified user or role.
- 2. used to grant privileges to the specified user by giving
the user the privileges of the specified role.
If you do use the optional WITH GRANT OPTION, you give permission for the user(s) to whom you are granting the privilege to pass it on to other users.
GRANT GUEST_USERS TO CALVIN; GRANT INSERT, DELETE ON TEST TO GUEST_USERS;
INSERT
INSERT INTO table-name [(column-identifier
[, column-identifier]...)]
VALUES (insert-value[, insert-value]... )
There are several variations of the INSERT statement. In the simplest instance, a value is provided for each column of the new row in the order specified at the time the table was defined (or altered). In the preferable form of the INSERT statement the columns are specified as part of the statement and they neednt to be in any specific order as long as the orders of the column and value lists match with one another.
INSERT INTO TEST (C, ID) VALUES (0.22, 5); INSERT INTO TEST VALUES (0.35, 9);
INSERT (Using Query)
INSERT INTO table-name [( column-identifier
[, column-identifier]... )]
query-specification
The query specification creates a virtual table. Using the INSERT statement the rows of created virtual table are inserted into the specified table (the degree and data types of the virtual table and inserted columns must match).
INSERT INTO TEST (C, ID) SELECT A, B FROM INPUT_TO_TEST;
REVOKE (Role from User)
REVOKE {role-name [, role-name]... }
FROM {PUBLIC | user-name [, user-name]... }
The REVOKE statement is used to take a role away from users.
REVOKE GUEST_USERS FROM HOBBES;
REVOKE (Privilege from Role or User)
REVOKE
{revoke-privilege [, revoke-privilege]... }
ON table-name
FROM {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... } revoke-privilege ::= DELETE | INSERT |
SELECT | UPDATE | REFERENCES REVOKE EXECUTE ON procedure-name
FROM {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... } REVOKE {SELECT | INSERT} ON event-name FROM
{PUBLIC | user-name [, user-name]... |
role-name [, role-name]... } REVOKE {SELECT | INSERT} ON sequence-name
FROM {PUBLIC | user-name [, user-name]... |
role-name [, role-name]... }
The REVOKE statement is used to take privileges away from users and roles.
REVOKE INSERT ON TEST FROM GUEST_USERS;
ROLLBACK
ROLLBACK WORK
The changes made in the database are discarded by ROLLBACK statement. It terminates the transaction.
ROLLBACK WORK;
SELECT
SELECT [ALL | DISTINCT] select-list
FROM table-reference-list
[WHERE search-condition]
[GROUP BY column-name [, column-name]... ]
[HAVING search-condition]
[[UNION | INTERSECT | EXCEPT] [ALL]
select-statement]...
[ORDER BY {unsigned integer | column-name}
[ASC|DESC]]
The SELECT statement is used to retrieve information.
SELECT ID FROM TEST; SELECT DISTINCT ID, C FROM TEST WHERE ID = 5; SELECT DISTINCT ID FROM TEST ORDER BY ID ASC; SELECT NAME, ADDRESS FROM CUSTOMERS UNION SELECT NAME, DEP FROM PERSONNEL;
SET
SET SQL INFO {ON | OFF} [FILE {file-name |
"file-name" | 'file-name'}]
[LEVEL info-level] SET SQL SORTARRAYSIZE {array-size | DEFAULT} SET SQL JOINPATHSPAN {path-span | DEFAULT} SET SQL CONVERTORSTOUNIONS
{YES [COUNT value] | NO | DEFAULT} SET LOCK TIMEOUT timeout-in-seconds SET STATEMENT MAXTIME minutes SET TRANSACTION READ ONLY SET TRANSACTION READ WRITE SET TRANSACTION CHECK WRITESET SET TRANSACTION CHECK READSET SET TRANSACTION ISOLATION LEVEL READ COMMITTED SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
All the settings a re per user settings unlike the settings in the solid.ini file.
In SQL INFO the default file is a global soltrace.out shared by all users. If the file name is given, all future INFO ON settings will use that file unless a new file is set. It is recommended that the file name is given in single quotes, because otherwise the file name is converted to uppercase. The info output is appended to the file and the file is never truncated, so after the info file is not needed anymore, the user must manually delete the file. If the file open fails, the info output is silently discarded.
The default SQL INFO LEVEL is 4. A good way to generate useful info output is to set info on with a new file name and then execute the SQL statement using EXPLAIN PLAN FOR syntax. This method gives all necessary estimator information but does not generate output from the fetches which may generate a huge output file.
The sort array is used for in memory sorts in the SQL interpreter. The minimum value for SORTARRAYSIZE is 100. If a smaller value is given, minimum value 100 will be used. If large sorts are needed, it is recommended that the external sorter facility is used (in Sorter section in solid.ini) instead on using very large SORTARRAYSIZE.
The COUNT parameter in SQL CONVERTORSTOUNIONS tells how many ors are converted to unions. The default is 10 which should be enough in most cases.
SET STATEMENT MAXTIME sets connection specific maximum execution time in minutes. Setting is effective until a new maximum time if set. Zero time means no maximum time, which is also the default.
The SET TRANSACTION settings are borrowed from ANSI SQL. It sets the transaction isolation level.
SET SQL INFO ON FILE 'sqlinfo.txt' LEVEL 5
SET SCHEMA
SET SCHEMA {USER | 'user-name'}
From version 2.2 SOLID Server supports SQL89 style schemas for database entity name qualifying. All created database entities belong to a schema, and different schemas may contain entities with same name.
The default schema can be changed with the SET SCHEMA statement. Schema can be change to the current user name by using the SET SCHEMA USER statement. Alternatively schema can be set to user-name which must be a valid user name in the database.
The algorithm to resolve entity names [schema-name.]table-identifier is the following:
1. If schema-name is given then table-identifier is searched only from that schema.
2. If schema-name is not given, then
a. First table-identifier is searched from default schema. Default schema is initially the same as user name, but can be changed with SET SCHEMA statement
b. Then table-identifier is searched from all schemas in the database. If more than one entity with same table-identifier and type (table, procedure, ...) is found, a new error code 13110 (Ambiguous entity name table-identifier ) is returned.
The SET SCHEMA statement effects only to default entity name resolution and it does not change any access rights to database entities. It sets the default schema name for unqualified names in statements that are prepared in the current session by an execute immediate statement or a prepare statement.
SET SCHEMA 'CUSTOMERS'
UPDATE (Positioned)
UPDATE table-name
SET [table-name.]column-identifier = {expression |
NULL}
[, [table-name.]column-identifier = {expression |
NULL}]...
WHERE CURRENT OF cursor-name
The positioned UPDATE statement updates the current row of the cursor. The name of the cursor is defined using ODBC API function named SQLSetCursorName.
UPDATE TEST SET C = 0.33
WHERE CURRENT OF MYCURSOR
UPDATE (Searched)
UPDATE table-name
SET [table-name.]column-identifier = {expression |
NULL}
[, [table-name.]column-identifier = {expression |
NULL}]...
[WHERE search-condition]
The UPDATE statement is used to modify the values of one or more columns in one or more rows, according the search conditions.
UPDATE TEST SET C = 0.44 WHERE ID = 5
Table-reference
Query-specification
Search-condition
Check-condition
Expression
Data-type
Date and Time Literals
Date/time literal
date-literal
´YYYY-MM-DD´
time-literal
´HH:MM:SS´
timestamp-literal
´YYYY-MM-DD HH:MM:SS´
Pseudo Columns
The following pseudo columns may also be used in the select-list of a SELECT statement:
NOTE! Since ROWID and ROWVER refer to a single row, they may only be used with queries that return rows from a single table.
Copyright © 1992-1997 Solid Information Technology Ltd All rights reserved.