In a Sybase replication system, the purpose of an ECDA database gateway is to apply transactions from a Replication Server to a non-ASE replicate database.
To accomplish this, Replication Server logs in to the ECDA gateway using the information specified for a Replication Server connection. Replication Server logs in to the server using the user_name and password, and issues a use database command for the database defined in the connection.
For Replication Server, there is nothing to distinguish an ECDA gateway from an Adaptive Server replicate database. Replication Server delivers the same commands—and expects the same results—from any DSI thread it communicates with.
This has the following implications:
A valid user ID, which the Replication Server uses to log in to the replicate database, must be defined in a Replication Server connection.
This user ID must be granted permissions to update replicate tables and execute replicate procedures.
The replicate database must be able to maintain a RS_LASTCOMMIT table and a RS_TICKET_HISTORY table and support rs_get_lastcommit functionality.
Replication Server provides sample connection profiles to set up the tables and functions required for a replicate database in DB2 UDB, Microsoft SQL Server, and Oracle databases.
For an overview of the expectations of a replicate data server and gateway, see Chapter 6, “Replicating Data into Foreign Data Servers,” in the Replication Server Design Guide.
Datatype representations must be translated to match the native datatypes of the replicate database. Replication Server provides sample connection profiles to set up the function strings, function-string classes, and base datatype definitions and translations necessary to support replication into DB2 UDB, Microsoft SQL Server, and Oracle data servers.
The Replication Server command resume connection attempts to initiate activity with the DSI thread of the specified connection. For an ECDA, this is logging in to the DirectConnect server, accessing the RS_LASTCOMMIT table in the replicate database, and then applying transactions to the replicate database. Any failure in this sequence is recorded as a failure in the Replication Server log.
