For example, selectables and the references within square brackets of
select clauses are not case sensitive when in case insensitive mode. However,
regardless of what you put inside the square brackets, in most cases the system
returns the name as it is stored in the database. For instance, with a type
called "test" that has an attribute "testattr", the following command returns
the output shown below.
print type test select attribute[TESTATTR};
attribute[testattr]=TRUE;
Also, when case sensitivity is turned off, the query operators "match"
and "matchcase" become indistinct, as are "!match" and "!matchcase."
Some exceptions apply and are discussed below. Before turning
case-sensitivity on, custom code should be checked to see if any routines check
user input against database strings. These routines may need to be reworked to
achieve the expected results.
Square Brackets
As stated above, in most cases the system returns the name of a
selectable as it is stored in the database, regardless of what you put inside
the square brackets. Actually, this applies only to database, regardless of
what you put inside the square brackets. However, things like file names, state
names and signature names are returned as entered in the square brackets. For
example, consider the following:
An object has an attribute Att1 and a checked in file name File.txt:
temp query bus * a2 * select format.file[file.txt] format.file[file.txt].name attribute[att1].value;
businessobject A a2 0 format.file[file.txt] = TRUE
The spelling of the filename in the brackets is not corrected.
format.file[file.txt].name = File.txt
The name of the file is output as recorded in the database.
attribute[Att1].value = 2
And the attribute name (an admin type) is corrected.
One exception to this rule is properties on administration objects.
Properties on administration objects always come back with the database name of
the property.
Attribute Range Values
Before turning off case sensitivity, you should check all attributes
for ranges that may disobey the rules of case insensitivity, such as having 1
range value for initial capitalization and another all lowercase (for example
"Pica" and "pica" for Units attribute). In this example, one of these ranges
should be deleted. In a case-insensitive environment, the equals and match
operators are identical; that is "Ea" is the same as "EA" and so entering the
attribute value as "Ea" will succeed even if the range value is set to "EA".
Revision Fields
When creating objects using a policy that defines an alphabetical
revision sequence, the revision field is case sensitive, regardless of the
system setting (that is,
Collaboration and Approvals
follows the revision rule exactly). Be sure the rules are defined
appropriately.
However, queries on the revision field do follow the rules for the
system
casesensitive setting. So if your query specifies "A"
for the revision field with case sensitivity turned off, objects that meet the
other criteria are found that have both "A" and "a" as their revision
identifier.
File Names
File names remain case sensitive, regardless of the case sensitivity
setting. So, for example, if the object has a file "FILE.txt" checked in, the
following command will fail:
checkout bus testtype testbus1 0 file file.txt;
And the following will succeed:
checkout bus testtype testbus1 0 file FILE.txt;
For checkins, if you check in a file called "FILE.txt" and then check
in another file called "file.txt", there will be two separate files checked in
(using append).
User Passwords
You cannot have distinct objects with the same spelling but different
capitalization (that is, "Bill" and "bill" are interpreted as the same thing).
However, user passwords remain case sensitive. For example, a user named "Bill"
with a password of "secret", can set context with:
set context user Bill pass secret;
or:
set context user bill pass secret;
but not with:
set context user bill pass Secret;
Adaplet Usage
When an object name is explicitly specified in the name field of a
query, objects returned via an adaplet are shown with the name in the case as
entered in the query, and not necessarily as it exists in the database. The
same is true when explicitly specifying object names to be exported—adaplet
objects are referenced in the export file with the name in the case as entered.