READ statement [Interactive SQL]

READ [ ENCODING encoding ] filename [ parameter ] ...

encoding : identifier | string

ENCODING The ENCODING clause allows you to specify the encoding that is used to read the file. The READ statement does not process escape characters when it reads a file. It assumes that the entire file is in the specified encoding.
When running Interactive SQL, the encoding that is used to read the data is determined in the following order:
1. The encoding specified by the ENCODING clause (if this clause is specified).
2. The encoding specified by the byte order mark (BOM) in the file (if a BOM is specified).
3. The encoding specified with the default_isql_encoding option (if this option is set).
4. The default encoding for the platform you are running on. On English Windows computers, the default encoding is 1252.

The READ statement reads a sequence of Interactive SQL statements from the named file. This file can contain any valid Interactive SQL statements, including other READ statements. READ statements can be nested to any depth.

If filename has no file extension, Interactive SQL searches for the same file name with the extension .sql.

If filename does not contain an absolute path, Interactive SQL searches for the file. The location of filename is determined based on the location of the READ statement, as follows:

If the READ statement is executed directly in Interactive SQL, Interactive SQL first attempts to resolve the path to filename relative to the directory in which Interactive SQL is running. If unsuccessful, Interactive SQL looks for filename in the directories specified in the environment variable SQLPATH, and then the directories specified in the environment variable PATH.
If the READ statements reside in an external file (for example, a .sql file), Interactive SQL first attempts to resolve the path to filename relative to the location of the external file. If unsuccessful, Interactive SQL looks for filename in a path relative to the directory in which Interactive SQL is running. If still unsuccessful, Interactive SQL looks in the directories specified in the environment variable SQLPATH, and then the directories specified in the environment variable PATH.

Parameters can be listed after the name of the SQL script file. These parameters correspond to the parameters named in the PARAMETERS statement at the beginning of the statement file.

Parameter names must be enclosed in square brackets. Interactive SQL substitutes the corresponding parameter wherever the source file contains { parameter-name } , where parameter-name is the name of the appropriate parameter.

The parameters passed to a script file can be identifiers, numbers, quoted identifiers, or strings. When quotes are used around a parameter, the quotes are put into the text during the substitution. Parameters that are not identifiers, numbers, or strings (contain spaces or tabs) must be enclosed in square brackets ([ ]). This allows for arbitrary textual substitution in the script file.

If not enough parameters are passed to the script file, Interactive SQL prompts for values for the missing parameters.

When executing a reload.sql file with Interactive SQL, you must specify the encryption key as a parameter. If you do not provide the key in the READ statement, Interactive SQL prompts for the key.

None.

SQL/2008 Vendor extension.

This example reads from a fictitious files status.rpt and birthday.sql:

READ status.rpt '160';
READ birthday.sql [>= '1988-1-1'] [<= '1988-1-30'];

This example starts Interactive SQL and instructs it to process a fictitious file that uses a specific OEM codepage:

dbisql READ ENCODING 'cp437' myfile.sql

READ statement [Interactive SQL]

Syntax

Parameters

Remarks

Privileges

Side effects

See also

Standards and compatibility

Example