Create a new server for Sybase - Connect_CDC - connect_cdc_mimix_share - 6.x

Name

Use alphanumeric characters to specify a unique server name for use in the model.

DBMS Type

Select Sybase from the dropdown list.

DBMS version

Server name

Specify the name of the server that you want to model. Often, the value you enter here is the same as the Name value.

DBMS instance port

Check the interfaces file in the Sybase directory. The following has an instance of 8050.

<db instance name> 5 5
query tcp ether <machine name> 8050
master tcp ether <machine name> 8050

JDBC Driver

Select the JDBC Driver from the dropdown:

• Sybase. This is the default.

Driver Version

View the JDBC Driver version. This information is obtained each time a connection to the database is made (including a Test Connection).

DBMS logon IDs and DBMS logon password

Specify the Default and Rep user IDs.

1. Input the user login ID for accessing this server.

2. Specify the owner of the metabase on this server (for Windows and UNIX servers, this is typically rpuser).

3. Select Default and Rep user (they may be different).

• The Default user is what Connect CDC Director uses to connect to the server.

• The Rep user is what the kernel uses to connect to the server.

Specify additional IDs.

1. In DBMS logon password, enter the logon password for the ID.

2. In DBMS logon IDs, for the second user ID, select Type in a new ID.

3. Specify an ID that can access and query the source or target tables on this server for testing or informational purposes.

   Note: Do not select Default or Rep user.

4. Specify the ID password in DBMS logon password.

Metabase schema

Set to the owner of the metabase. It is the qualifier of the metabase tables, in the format qualifier.tablename. You cannot edit this field. This field is pre-filled with dbo.

Meta database

The name of the database Connect CDC Director uses to create its metabase objects. This field is pre-filled with omnirep.

Enable Prepared Statements

If selected, prepared statements are enabled for the entire database server. A prepared SQL statement is a statement in which the steps to parse, analyze, validate, and determine the access path are only done once, when the statement is first prepared. On subsequent executions of the statement, the database has this information stored in memory and can skip the initial preparation steps. After a statement is prepared, only the column values change from one execution of the statement to the next.

Each table can have as many as seven prepared statements: one for insert, up to five for update, and one for delete. The first time an insert, update, or delete is encountered, the statement is prepared, added to the cache, and is used to update the table. The statements are kept in the cache until removed.

Using prepared statements provides a significant performance improvement when the same SQL statement is executed over and over. However, in some cases data for unchanged columns will be captured and sent across the network.

Individual tables can disable prepared statements. This is useful for managing the size of the cache file.

Database limit

Displays the maximum size allowed by the database for open statements in the cache. The Specified limit, below, cannot exceed this value. The correct value is provided after you run a Test Connection. To do so, right-click the server name, then select Test Connection.

Specified limit

Enter the maximum size allowed for open statements in the cache. When the statement cache is full, the least recently used statement is removed from the cache, closed, and destroyed. If Journal batching is enabled, prior to removing the statement, pending batch updates are executed, If the statement that was removed is later referenced, a new prepared statement is created and added to the cache.

Note the following:

• The default is 700.

• The minimum value is 7.

• The maximum value is specified in Database limit, above. If you set the specified limit to a value lower than the number of prepared statements in the model, performance may decrease.

Max TRANS row

The maximum number of transaction rows that can be allocated in each users pool of rp_trans rows. If the Max TRANS rows limit is reached, the trigger will fail. Each user is assigned a pool of rp_trans rows based on the user's session id. When a new transaction is created in the trigger, the transaction attempts, when possible, to re-use the rp_trans rows already allocated in the pool. Rp_trans rows are marked as free and available for re-use after the transactions have been successfully applied on all mapped targets. If there are no free rows available, a new block of rp_trans rows is allocated and added to the user's pool. The default is 400000.

Model using metabase

Displays the name of the model. (Informational only)

Model version

Displays the version number, updated after each commit. (Informational only)

Metabase version

Displays the version of the metabase (for example, 40d). (Informational only)

GMT offset (minutes)

Displays the amount of time, in minutes, that local time differs from Greenwich Mean Time (GMT). For example, Boston is 300 minutes less than GMT. (Informational only)