In a replication system with only Sybase databases, case sensitivity is not a major issue because Sybase databases all use the same object name case conventions. In Sybase databases, uppercase and lowercase are both allowed, with the default being all lowercase.
Non-Sybase data servers have different object name case conventions. Like Sybase, both Informix and Microsoft SQL Server default to all lowercase. Both DB2 and Oracle default to all uppercase.
Because Replication Server follows the case conventions of Sybase databases, the default for database object names (for example, in replication definitions and subscriptions) is all lowercase.
Replication Server object names (connections, tables, procedures, columns, subscriptions, and replication definitions) are case sensitive. The exact case must be provided whenever you identify or reference those objects.
In a heterogeneous replication system, you must be aware of object name case conventions in all of the components to ensure that the connection attempts from the Replication Agent to the Replication Server, and the LTL generated by Replication Agent, match the connection names and replication definition object names known to Replication Server.
Sybase Replication Agent uses a configuration parameter (ltl_character_case) to specify the case used when communicating with Replication Server. For more information, see the Sybase Replication Agent Administration Guide.
In a heterogeneous replication system, it is possible to have a variety of servers with different case sensitivity or different default display formats. If the primary and replicate data servers store database object names in different cases, you may have to explicitly specify the proper “replicate name” to be used for table and column names when you create replication definitions in Replication Server. The following example illustrates this.
By default, Oracle processing of object names is not case sensitive, however, object names are physically stored in all uppercase. The statement create table test1 (col1 int) creates a table named “test1,” which is identified in the Oracle system catalog with name “TABLE1.” The following SQL statements both return the same result from the same table:
select from TEST1
and
select from test1
As Replication Server processes information, it requires the LTL from the Replication Agent to match the character case of the table and column names specified in the replication definition. As the data moves to the replicate site, the commands created by Replication Server to be applied to the replicate database use the case specified in the replication definition for table and column names (for example, insert into TEST1 (COL1) values (1)).
If the replicate database is case sensitive, the commands presented by Replication Server may be rejected with an “object not found” error. In this example, if the replicate database is Adaptive Server (and the Adaptive Server is installed as case sensitive) and the replicate table was created with the statement create table test1 (col1 int), the following statement would fail: insert into TEST1 (COL1) values (1)
The LTL generated by the Replication Agent must refer to table TEST1 and column COL1 to be accepted by Replication Server. For the Sybase Replication Agent, the value of the ltl_character_case configuration parameter must be set to asis to send LTL object names in the same case as they are returned by the primary database.
If no other changes are made, an insert into table test1 with a value of “1” results in the following command sent to the replicate database:
insert into TEST1 (COL1) values (1)
This statement may fail if the replicate table name is case sensitive and the name of the table is not TEST1 with a column named COL1.
Ideally, if all the data servers in your replication system are not case sensitive, no special consideration is required.
The following items can be used to help in a situation where some of the servers are case sensitive:
Use the replicate as clause in replication definitions. When you create a replication definition, either manually, you can specify a separate replicate name for table and column names. Use this feature to specify the case required by your replicate database.
If your primary data is replicated to more than one
replicate site, you might have to create a separate replication
definition for each unique replicate table name.
Configure the Replication Agent accordingly. If the option is available, you can configure the Replication Agent to send object names in the same case as the primary database stores them. You can force the case to be anything you like, as long as the LTL generated by the Replication Agent matches the case used in the replication definition.
Use an alias at the replicate site. As an alternative to creating replication definitions with the replicate as clause, you can create an alias at the replicate database that matches the case in the primary database and points to the desired replicate table name.
