Skip Headers
Oracle® TimesTen In-Memory Database SQL Reference
Release 11.2.1

Part Number E13070-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

2 Names, Namespace and Parameters

This chapter presents general rules for names and parameters used in TimesTen SQL statements. It includes the following topics:

Basic names

Basic names identify columns, tables, views and indexes. Basic names must follow these rules:

Owner names

The owner name is the user name of the account that created the table. Tables and indexes defined by TimesTen itself have the owner SYS or TTREP. User objects cannot be created with owner names SYS or TTREP. TimesTen converts all owner and table names to upper case.

Owners of tables in TimesTen are determined by the user ID settings or login names. For cache groups, Oracle table owner names must always match TimesTen table owner names.

Owner names may be specified by the user during table creation, in addition to being automatically determined if they are left unspecified. See "CREATE TABLE". When creating owner names, follow the same rules as those for creating basic names. See "Basic names".

Compound identifiers

Basic names and user names are simple names. In some cases, simple names are combined to form a compound identifier, which consists of an owner name combined with one or more basic names, with periods (.) between them.

In most cases you can abbreviate a compound identifier by omitting one of its parts. If you do not use a fully qualified name, a default value is automatically used in place of the missing part. For example, if you omit the owner name (and the period) when you refer to tables you own, TimesTen generates the owner name by using your login name.

A complete compound identifier, including all of its parts, is called a fully qualified name. Different owners can have tables and indexes with the same name. The fully qualified name of these objects must be unique.

The following are compound identifiers:

Namespace

In SQL syntax, each name of an object that share the same namespace must be unique, so that when referenced in any SQL syntax, the exact object can be found.

The following objects owned by the same user share one namespace and so the names for each of these objects must be unique within that namespace: tables, views, materialized views, sequences, private synonyms, PLSQL packages, functions, procedures, and cache groups.

Indexes are created in their own namespace.

Because tables and views are in the same namespace, a table and a view owned by the same owner cannot have the same name. However, tables and indexes are in different namespaces. Therefore, a table and an index owned by the same user can have the same name

However, tables that are owned by separate users can have the same name, since they exist in separate user namespaces.

If the object name provided is not qualified with the user that owns it, then the search order for an object is as follows:

  1. Search for any match from all object names within the current user namespace. If there is a match, the object name is resolved.

  2. If no match is found in the user namespace, search for any match from the PUBLIC namespace, which contains objects such as public synonyms. Public synonyms are pre-defined for SYS and TTREP objects. If there is a match, the object name is resolved. Otherwise, the object does not exist.

Dynamic parameters

Dynamic parameters are used to pass information between an application program and TimesTen. They are placeholders in SQL commands and are replaced at runtime with actual values.

A dynamic parameter name must be preceded by a colon (:) when used in a SQL command and must conform to the TimesTen rules for basic names. However, unlike identifiers, parameter names can start with any of the following characters:

Note:

Instead of using a :DynamicParameter sequence, the application can use a ? for each dynamic parameter.

Enhanced ":" style parameter markers have this form:

:parameter [INDICATOR] :indicator

The :indicator is considered to be a component of the :parameter. It is not counted as a distinct parameter. Do not specify '?' for this style of parameter marker.

Duplicate parameter names

Consider this SQL statement:

SELECT * FROM t1 WHERE c1=:a AND c2=:a AND c3=:b AND c4=:a;

Traditionally in TimesTen, multiple instances of the same parameter name in a SQL statement are considered to be multiple occurrences of the same parameter. When assigning parameter numbers to parameters, TimesTen assigns parameter numbers only to the first occurrence of each parameter name. The second and subsequent occurrences of a given name do not get their own parameter numbers. In this case, a TimesTen application binds a value for every unique parameter in a SQL statement. It cannot bind different values for different occurrences of the same parameter name nor can it leave any parameters or parameter occurrences unbound.

In Oracle Database, multiple instances of the same parameter name in a SQL statement are considered to be different parameters. When assigning parameter numbers, Oracle assigns a number to each parameter occurrence without regard to name duplication. An Oracle application, at a minimum, binds a value for the first occurrence of each parameter name. For the subsequent occurrences of a given parameter, the application can either leave the parameter occurrence unbound or it can bind a different value for the occurrence.

The following table shows a query with the parameter numbers that TimesTen and Oracle Database assign to each parameter.

Query TimesTen parameter number Oracle Database parameter number
SELECT *    
FROM t1    
WHERE c1=:a 1 1
AND c2=:a 1 2
AND c3=:b 2 3
AND c4=:a; 1 4

The total number of parameter numbers for TimesTen in this example is 2. The total number of parameters for Oracle Database in this example is 4. The parameter bindings provided by an application produce different results for the traditional TimesTen behavior and the Oracle behavior.

You can use the DuplicateBindMode general connection attribute to determine whether applications use traditional TimesTen parameter binding for duplicate occurrences of a parameter in a SQL statement or Oracle-style parameter binding. Oracle-style parameter binding is the default.

Inferring data type from parameters

Consider this statement:

SELECT :a FROM dual;

TimesTen cannot infer the data type of parameter a from the query. TimesTen returns this error:

2778: Cannot infer type of parameter from its use
The command failed.

Use the CAST function to declare the data type for parameters:

SELECT CAST (:a AS NUMBER) FROM dual;