Administration Guide

Federated Database Object Names

Federated database objects include:

• Index specifications
• Nicknames
• Servers
• Wrappers
• Function mappings
• Type mappings
• User mappings

Limits apply when naming federated database objects. A complete list of object names and associated identifier limits and requirements are located in the SQL Reference. In summary, object names:

• Have limits. Mapping, index specification, server, wrapper, and nickname names cannot exceed 128 bytes.

• Must begin with one of the following:
  • A through Z (names without quotes are converted to uppercase)
  • A valid accented letter (such as ö)
  • A multibyte character, except multibyte spaces (for multibyte environments)

• Must follow internal naming conventions. Non-leading characters can include:
  • A through Z
  • A valid accented letter (such as ö)
  • 0 through 9
  • @, #, $, and _ (underscore)
  • Multibyte characters, except multibyte spaces (for multibyte environments)

Keywords can be used. If the keyword is used in a context where it could also be interpreted as an SQL keyword, it must be specified as a delimited identifier. Refer to the SQL Reference for information on delimited identifiers.

For maximum portability, use the IBM SQL and ISO/ANSI SQL92 reserved words. For a list of these words, refer to the SQL Reference manual.

Options (server, nickname) and option settings are limited to 255 bytes.

How Case-Sensitive Values Are Preserved in a Federated System

In distributed requests, you sometimes need to specify identifiers and passwords that are case-sensitive at the data source. To ensure that their case is correct when they're passed to the data source, follow these guidelines:

• Specify them in the required case and enclose them in double quotes.

• If you're specifying a user ID, set the fold_id server option to 'n' ("No, don't change case") for the data source. If you're specifying a password, set the fold_pw server option to 'n' for the data source.

  There is an alternative for user IDs and passwords. If a data source requires a user ID to be in lowercase, you can specify it in any case and set the fold_id server option to 'l' ("Send this ID to the data source in lowercase"). If the data source requires the ID to be in uppercase, you can specify it in any case and set fold_id to 'u' ("Send this ID to the data source in upper case"). In the same way, if a data source requires a password to be in lowercase or uppercase, you can meet this requirement by setting the fold_pw server option to 'l' or 'u'.

  For more information about server options, see Using Server Options to Help Define Data Sources and Facilitate Authentication Processing.

• If you enclose a case-sensitive identifier or password in double quotes at an operating system's command prompt, you need to ensure that the system parses the double quotes correctly. To do this:

  • On a UNIX operating system, enclose the statement in single quotes.

  • On a Windows NT operating system, precede each quote with a backward slash.

For example, many delimited identifiers in DB2 family data sources are case-sensitive. Suppose you want to create a nickname, NICK1, for a DB2 for CS view, "my_schema"."wkly_sal", that resides in a data source called NORBASE. If you're entering the SQL for creating the nickname from a UNIX command prompt, you would type:

db2
'create nickname nick1 for norbase."my_schema"."wkly_sal"'

From an NT command prompt, you would type:

db2 create nickname nick1 for norbase.\"my_schema\".\"wkly_sal\" 

If you enter the SQL from the DB2 interactive mode command prompt, or if you specify it in an application program, you don't need the single quotes or the slashes. For example, from the DB2 command prompt on either a UNIX or NT system, you would type:

create nickname nick1 for norbase."my_schema"."wkly_sal" 

[ DB2 List of Books | Search the DB2 Books ]