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 is located in the SQL Reference. In summary, object names:

• Have limits. Nicknames, mapping, index specification, server, and wrapper names cannot exceed 128 bytes.
• Must begin with one of the following:
  • A through Z (names without quotation marks 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.

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

How Case-Sensitive Values Are Preserved in a Federated System

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

• Specify them in the required case, and enclose them in double quotation marks.
• If you are specifying a user ID, set the fold_id server option to "n" ("No, don't change case") for the data source. If you are 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 uppercase"). 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 a password in double quotation marks at an operating system command prompt, you must ensure that the system parses the double quotation marks correctly. To do this:
  • On a UNIX based operating system, enclose the statement in single quotation marks.
  • On the Windows NT operating system, precede each quotation mark 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.

  At the command prompt for a UNIX based system, you would type:

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

  At a Windows NT command prompt, you would type:

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

  If you enter the statement from the DB2 interactive mode command prompt, or if you specify it in an application program, you do not need the single quotation marks or the slashes. For example, at the DB2 command prompt on either a UNIX based system or Windows NT, you would type:

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