A replicated stored procedure is an Adaptive Server stored procedure that you have marked for replication using either sp_setrepproc or sp_setreplicate. A function replication definition describes a replicated stored procedure, its parameters, and its location. When you create a function replication definition, Replication Server creates a function, which contains the information in the function replication definition.
When a replicated stored procedure that has its own function replication definition is invoked, its function is transferred from the source to a destination Replication Server. The function passes parameters to a corresponding stored procedure that is invoked in the destination database. A function string translates the function into a syntax that the subscribing database can interpret.
In versions earlier than 15.1, the no-subscription request function delivers a replicated stored procedure from a replicate database to the primary database. The function replication definition’s primary database is defined as primary database, while the database from which the function is originally invoked is defined as a replicate database.
For example, a client application at a remote location needs to make changes to the primary data. The client application first executes a stored procedure, which may or may not make changes at the replicate database, at the remote site. When you run the stored procedure, the replicate Replication Server passes a request function to the primary database, where a corresponding stored procedure is invoked and updates the primary data. No subscription is needed to deliver this request function.
In a primary copy model, a single primary database contains the most recent updates. A client application at a remote replicate site can update the primary database using the request functions. As updates occur at the primary table, the Replication Server captures the updates and sends them to the replicate data servers.
If communication between the primary and replicate databases fails, operations executed in the primary database are stored in the Replication Server stable queues until they can be delivered to the replicate sites. Likewise, operations executed remotely at the replicate database are held in stable queues until they can be delivered to the primary database.
To use a no-subscription request function with versions earlier than 15.1, create a stored procedure in the primary database and a corresponding stored procedure in the replicate database. Then, at the primary Replication Server, create a function replication definition with the same name as the name of the stored procedure created in the replicate database. You do not need to create any subscriptions. When the stored procedure in the replicate database is invoked, it invokes the stored procedure in the primary database.
Replication Server runs the stored procedure in the primary database with the same user that invokes the stored procedure in the replicate database. This guarantees that only authorized users can change the primary data.
In an application, Replication Server may replicate some or all of the data that changes in the primary database. The changes are distributed to the replicate databases, which are managed by Replication Servers that have subscriptions to table replication definitions, or as separate applied functions. Either way, a transaction arrives at the primary database first, and then arrives at the replicate databases.
When you use a no-subscription request function with versions earlier than 15.1, all updates are made at the primary database. This preserves the Replication Server primary copy data model and protects the replication system from network failure and excess traffic.
