Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Teradata RDBMS forUNIX SQL Reference - NCR

NCR Teradata RDBMS forUNIX SQL Reference - NCR, 1997. - 913 p.
Download (direct link): teradataforunix1997.pdf
Previous << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 241 >> Next


5-32

Teradata RDBMS for UNIX SQL Reference
Data Definition

Case Sensitivity of Character String Literals

Case Sensitivity of Character String Literals5

Character string literals may occur in the text of SQL queries, in the text defining views and macros, and the text of CHECK constraints.

In all of these instances, execution of queries using these literals involves parsing the literals and assigning case sensitivity attributes at that time.

IF the session is in this mode . . . THEN all character string literals are . . .
ANSI CASESPECIFIC
Teradata NOT CASESPECIFIC

This means that for views with WHERE constraints and for CHECK, if character string literals are included, they compare differently when executed by users with sessions in ANSI and Teradata mode.

You should modify existing views with WHERE constraints to explicitly control case sensitivity in comparisons.

Refer to Chapter 8, “Teradata SQL Syntax Guide,” “ALTER TABLE” and “CREATE TABLE” for explanations on the use of CHECK. Also refer to Chapter 6, under “Comparison Operators”

You should explicitly control case sensitivity in character string comparisons.

Teradata RDBMS for UNIX SQL Reference

5-33
Data Definition

Character String Definitions in the USING Phrase

Character String Definitions in the USING Phrase

In prior releases, a designation of CHAR or VARCHAR with no explicit CASESPECIFIC declaration, meant that for comparisons,

the values processed were to be designated NOT CASESPECIFIC.
IF the session is in this mode . . . THEN the values default to this declaration . . .
ANSI CASESPECIFIC
Teradata NOT CASESPECIFIC

The explicit designation NOT CASESPECIFIC can be added to the definition of a CHAR or VARCHAR field in the USING phrase to override the default. Refer also to “USING Modifier” in Chapter 8, “Teradata SQL Syntax Guide.”

NOT CASESPECIFIC has been added to ease transition to ANSI mode of operation, but instead of using this transitional feature, you should instead use the ANSI UPPER function to perform case blind comparison.

5-34

Teradata RDBMS for UNIX SQL Reference
Data Definition

Case Sensitivity in Comparisons

Introduction

Defaults

Domain Checking

Defaults for Non-English Collation

Case Sensitivity in Comparisons

All character data accessed in the execution of a Teradata SQL statement has an attribute of CASESPECIFIC or NOT CASESPECIFIC, either as a default or by explicit designation. This is not an ANSI compatible attribute, as ANSI does ALL character comparisons as the equivalent of CASESPECIFIC.

Columns of tables carry the attribute assigned, by default or explicitly, at the time the column was defined unless a non-ANSI type modification phrase is used in their access. Provision is made when the user logs on and uses the .SET SESSION command in BTEQ, or uses the equivalent session control command in other applications, to declare a session as operating in ANSI or Teradata mode.

IF a session is in this mode . . . THEN the default for character data in a CREATE or ALTER statement is . . .
ANSI CASESPECIFIC
Teradata NOT CASESPECIFIC This attribute persists unless the column definition is modified by a later ALTER statement.

Character Literal strings in queries, view and macro definitions, CHECK constraints and data accessed via the USING phrase have defaults determined at session logon unless explicitly modified. The default attribute exists only for the life of the session.

Expression operands must be of the same data type before a comparison can occur. If the operands data types are different, one of them must be converted.

If you find that your applications are comparing data from different domains, you need to review your database design to ensure that column data is properly typed.

On a European or a Japanese character site, which support diacritical or Japanese character sets, respectively, the default collation can be set to a sequence that is compatible with your session’s character set. Use the HELP SESSION statement to find the settings of your current session.

Teradata RDBMS for UNIX SQL Reference

5-35
Data Definition

Case Sensitivity in Comparisons

Comparing Character and Graphic Strings

Comparison Rule for Two Character Arguments, CHARA and CHARB

The attribute of your site, the availability of diacritical or Japanese character sets, and your default collation sequence are under the control of your database administrator. For collation details, see the “SET SESSION COLLATION” in Chapter 8, “Teradata SQL Syntax Guide,” the “ORDER BY Clause” of the SELECT statement in Chapter 7, and also Appendix G.

Comparison of Japanese character graphic strings is based on logical characters. If the strings are of different lengths, the shorter string is padded with one or more graphic pad characters (double byte zeros). The prepared strings are compared byte-by-byte; trailing pad characters are included in the comparison.
Previous << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 241 >> Next