ss_ReplicaB provides high-volume replication of Salesforce objects into SQL Server using Salesforce Bulk API 2.0.
The core replication functionality is the same as ss_Replica including field subsets and exclusions, custom replica tables, WHERE clauses, Top queries and the retrieval of soft-deleted and archived records.
Bulk API 2.0 differs from the conventional Salesforce REST/SOAP query APIs in that queries are processed asynchronously by Salesforce. SQL-Sales therefore provides several execution methods which control how a Bulk API Query job is submitted, monitored and retrieved.
Bulk API 2.0 is particularly suited to large data volumes. Salesforce recommends Bulk API 2.0 for large-scale asynchronous data operations and continues to focus enhancements on Bulk API 2.0.
Prerequisites
- A working Environment and the SQL Sales Daemon is running (see Environment Setup)
- SQL Server
- Compiled stored procedure ss_ReplicaB (see DatabaseEnabling)
ss_Log replication log
Replication is logged in table ss_Log which is automatically created and maintained for all ss_ReplicaB runs and the same for ss_DeltaB runs.
Note, the table is created within the schema from which you are running ss_ReplicaB, hence if you ran with uat.ss_ReplicaB the resultant entry for the given object will be to table uat.ss_Log.
| Field | Purpose |
|---|---|
| ReplicaName | The Salesforce object name or a Custom table name if one has been specified, created as a replica table in the given enabled Database |
| ObjectName | Source Salesforce Object of this replication log (will be the same as ReplicaName if no customisation has occurred with the Table: switch) |
| CustomReplica | Indicates if the Replica is Custom (i.e. not a basic replication of a Salesforce Object Name but ReplicaName is a custom table name) |
| TableCreatedDate | Serves no functional purpose, is for information purposes only |
| MaxSystemDate | This is how the ss_DeltaB process determines how to delta replicate |
| LogDate | Last log datetime |
| TopRow | Captures any Top commands, for example Account:Top100 |
| Subset | Captures any Column Subset or Exclude commands, for example Subset(Name,BillingCountry) or Exclude(Name,BillingCountry) |
| Status | Possible values include FAILURE, FULL and DELTA |
| WhereInput | Captures any Where clause commands injected into the replication |
| Detail | Success or Failure detail |
ss_Log_Working detailed replication log
For more granular detail of every replication run, each step is logged in ss_Log_Working which can be helpful in monitoring longer-running processes involving millions of rows.
| Field | Purpose |
|---|---|
| Environment | The specified Salesforce Environment, defined in the SQL Sales Configuration tool |
| Task | ss_ReplicaB |
| ObjectName | Source Salesforce Object of this replication log |
| PreProcessPoint | The process which is about to be started |
| Detail1 | The Salesforce object name or a Custom table name if one has been specified |
| Detail2 | The contents of parameter @Special1 |
| Detail3 | The contents of parameter @Special2 |
| Detail4 | Logs progress information associated with the replication |
Parameters
| Parameter | Purpose |
|---|---|
| @Env | SQL Sales Environment Name |
| @ObjectName | Salesforce Object Name, for example Account. Can be accompanied with :TopXXX, where XXX is a number. Can have an _All suffix to return soft-deleted and/or archived data. |
| @BAPIMethod | Optional Bulk API execution method. Valid methods are WAIT, WAIT(n), BACK, GET and CHECK(n). Default is WAIT. |
| @BAPIJobId | Optional Bulk API JobId. Normally SQL-Sales automatically identifies the appropriate outstanding job. This parameter can be used to specify a particular JobId where required. |
| @Special1 | Optional. Supports Subset(field1,field2,field3) Subset(A-M) – for example Column names beginning “A” to Column names beginning “M” Subset(A-A) – for example Column names beginning “A” to Column names beginning “A” (i.e. just “A” in this case). Subset(L-T,Website) – combine column first characters and explicit column lists Exclude(field1,field2,field3) Table:CustomTableName. |
| @Special2 | Optional. Supports a SOQL Where clause, for example Where StageName = ‘Closed Won’ |
Simple Example
By default ss_ReplicaB uses the WAIT Bulk API execution method (i.e. does not have to be provided as below).
exec ss_ReplicaB 'DEMO', 'Account'
SQL-SALES Replica BAPI run date: 2026-08-30 ---------------------
21:23:37: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
21:23:37: Using Env|Schema: prod|dbo
21:23:37: Starting Full BAPI Replication, from Object Account
21:25:43: Provided Objectname Account is valid, batchsize will be set automatically
21:25:54: Replica schema successfully built using Bulk API 2.0 Query
21:26:10: Data population fully completed
21:26:10: Bulk API Query Job completed, JobId: 750P600000fUXhfIAG
21:26:10: 50084 rows replicated
-----------------------------------------------------------------
Bulk API Execution Methods
ss_ReplicaB uses Salesforce Bulk API 2.0 Query jobs to retrieve Salesforce data. The optional @BAPIMethod parameter controls how SQL-Sales submits, waits for, and retrieves the Bulk API Query job.
Bulk API Query jobs are asynchronous: a query job is submitted to Salesforce, its status can then be checked, and its results become available after the job reaches the completed state.
If no method is specified, WAIT is used by default.
| Method | Purpose |
|---|---|
| WAIT | Submits the Bulk API Query job and waits synchronously until Salesforce completes it. |
| WAIT(n) | Resilient wait mode. Submits and records the JobId, then checks the job every n seconds until complete. Valid values are 1–3600 seconds. |
| BACK | Submits the Bulk API Query job in the background and returns control immediately. The job can subsequently be retrieved using GET or CHECK(n). |
| GET | Checks the latest outstanding Bulk API Query job once. If complete, the results are retrieved and the replication completed. If not yet complete, control is returned without waiting. |
| CHECK(n) | Checks the latest outstanding Bulk API Query job and, if it is not complete, checks again every n minutes until complete. Valid values are 1–59 minutes. |
WAIT
WAIT is the default method and requires no additional parameter.
exec ss_ReplicaB 'DEMO', 'Account'
The following is equivalent:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'WAIT'
SQL-Sales submits the Bulk API Query job and maintains the synchronous process until Salesforce completes the job, after which the results are retrieved and the SQL replica is created.
Salesforce does not provide an SLA for the completion time of asynchronous Bulk API jobs, therefore the time spent waiting is dependent upon Salesforce processing of the submitted job.
WAIT(n)
WAIT(n) provides a more resilient synchronous method for longer-running replications. The Bulk API JobId is recorded immediately after submission and SQL-Sales then checks the job until Salesforce reports that it is complete.
The value of n is the number of seconds between subsequent checks and can be between 1 and 3600.
For example, to check every 10 seconds:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'WAIT(10)'
SQL-SALES Replica BAPI run date: 2026-08-30 ---------------------
21:18:05: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
21:18:05: Using Env|Schema: prod|dbo
21:18:05: Starting Full BAPI Replication, from Object Account
21:18:13: Provided Objectname Account is valid, batchsize will be set automatically
21:18:13: Bulk API Query Job submitted and recorded, JobId: 750P600000XUGiwIAG
21:18:16: Bulk API Query Job is not yet complete, checking again in 10 seconds, JobId: 750P600000XUGiwIAG
21:18:29: Bulk API Query Job is not yet complete, checking again in 10 seconds, JobId: 750P600000XUGiwIAG
21:18:42: Bulk API Query Job is not yet complete, checking again in 10 seconds, JobId: 750P600000XUGiwIAG
21:18:55: Bulk API Query Job is not yet complete, checking again in 10 seconds, JobId: 750P600000XUGiwIAG
21:19:07: Bulk API Query Job is not yet complete, checking again in 10 seconds, JobId: 750P600000XUGiwIAG
21:20:33: Replica schema successfully built using Bulk API 2.0 Query
21:20:49: Data population fully completed
21:20:49: Bulk API Query Job completed, JobId: 750P600000XUGiwIAG
21:20:49: 50084 rows replicated
-----------------------------------------------------------------
Note, SQL-Sales performs an immediate first check after submitting the job. The specified delay is only applied if Salesforce reports that the job is not yet complete.
Because the JobId is recorded immediately, an interrupted WAIT(n) replication can subsequently be recovered using GET or CHECK(n).
For example, for a very large replication you may choose to check every five minutes:
exec ss_ReplicaB 'DEMO', 'Apttus_Billing__InvoiceLineItem__c', @BAPIMethod = 'WAIT(300)'
WAIT(n) specifies the interval in seconds, whereas CHECK(n) specifies the interval in minutes.
BACK
BACK submits the Bulk API Query job to Salesforce and then returns control to SQL Server without waiting for Salesforce to complete the job.
exec ss_ReplicaB 'prod', 'Apttus_Billing__InvoiceLineItem__c', 'BACK'
SQL-SALES Replica BAPI run date: 2026-08-30 ---------------------
14:09:18: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
14:09:18: Using Env|Schema: prod|dbo
14:09:18: Starting Full BAPI Replication, from Object Apttus_Billing__InvoiceLineItem__c
14:09:24: Provided Objectname Apttus_Billing__InvoiceLineItem__c is valid, batchsize will be set automatically
14:09:24: Bulk API Query Job submitted, JobId: 750P600000fTb6JIAS
-----------------------------------------------------------------
The Bulk API JobId is recorded by SQL-Sales so that the job can subsequently be retrieved.
This can be particularly useful for very large objects where you do not want the original SQL process to remain connected while Salesforce processes the Bulk API Query job.
For example, a the job first be submitted with BACK above can subsequently retrieved with GET:
exec ss_ReplicaB 'prod', 'Apttus_Billing__InvoiceLineItem__c', 'GET'
SQL-SALES Replica BAPI run date: 2026-08-30 ---------------------
15:59:37: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
15:59:37: Using Env|Schema: prod|dbo
15:59:37: Starting Full BAPI Replication, from Object Apttus_Billing__InvoiceLineItem__c
15:59:39: Bulk API Query Job located, JobId: 750P600000fTb6JIAS
16:00:04: Provided Objectname Apttus_Billing__InvoiceLineItem__c is valid, batchsize will be set automatically
16:59:59: Replica schema successfully built using Bulk API 2.0 Query
17:13:01: Data population fully completed
17:13:01: Bulk API Query Job ingest completed, JobId: 750P600000fTb6JIAS
17:13:01: 8182599 rows replicated
-----------------------------------------------------------------
or monitored until completion with:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'CHECK(5)'
GET
GET checks the latest applicable outstanding Bulk API Query job previously recorded by SQL-Sales.
If Salesforce reports that the job is complete, SQL-Sales retrieves the results and completes the replication (see BACK example above).
If the job is not yet complete, GET returns control without waiting. The same command can therefore be run again later.
For example here a WAIT(300) for a large long running object has been triggered:
exec ss_ReplicaB 'prod', 'Apttus_Billing__InvoiceLineItem__c', 'WAIT(300)'
SQL-SALES Replica BAPI run date: 2026-08-31 ---------------------
05:12:19: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
05:12:19: Using Env|Schema: prod|dbo
05:12:19: Starting Full BAPI Replication, from Object Apttus_Billing__InvoiceLineItem__c
05:12:25: Provided Objectname Apttus_Billing__InvoiceLineItem__c is valid, batchsize will be set automatically
05:12:25: Bulk API Query Job submitted and recorded, JobId: 750P600000fX8ZaIAK
05:12:28: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:17:31: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:22:33: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:27:36: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:32:39: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:37:42: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:42:45: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:47:49: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:52:51: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
05:57:53: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
06:02:56: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
06:07:58: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
06:13:02: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
06:18:05: Bulk API Query Job is not yet complete, checking again in 300 seconds, JobId: 750P600000fX8ZaIAK
07:24:46: Replica schema successfully built using Bulk API 2.0 Query
07:37:46: Data population fully completed
07:37:46: Bulk API Query Job completed, JobId: 750P600000fX8ZaIAK
07:37:46: 8182599 rows replicated
-----------------------------------------------------------------
Running GET a few minutes later (i.e. “too soon”) simply results in:
exec ss_ReplicaB 'prod', 'Apttus_Billing__InvoiceLineItem__c', 'GET'
SQL-SALES Replica BAPI run date: 2026-08-31 ---------------------
05:23:27: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
05:23:27: Using Env|Schema: prod|dbo
05:23:27: Starting Full BAPI Replication, from Object Apttus_Billing__InvoiceLineItem__c
05:23:29: Bulk API Query Job located, JobId: 750P600000XV8ZaIAK
05:23:32: Bulk API Query Job is not yet complete, JobId: 750P600000XV8ZaIAK
-----------------------------------------------------------------
If there is no applicable outstanding job for the specified object and replica table, SQL-Sales reports that there is no outstanding job and no replication action is performed.
CHECK(n)
CHECK(n) provides the automated equivalent of repeatedly running GET.
The value of n specifies the number of minutes between checks and can be between 1 and 59.
For example:
exec ss_ReplicaB 'prod', 'Apttus_Billing__InvoiceLineItemTaxBreakup__c', 'CHECK(5)'
SQL-SALES Replica BAPI run date: 2026-08-30 ---------------------
21:31:47: v26.3.1.0 Copyright c 2026 SQL-Sales Ltd
21:31:47: Using Env|Schema: prod|dbo
21:31:47: Starting Full BAPI Replication, from Object Apttus_Billing__InvoiceLineItemTaxBreakup__c
21:31:49: Bulk API Query Job located, JobId: 750P600000fUXFrIAK
21:31:51: Bulk API Query Job is not yet complete, checking again in 5 minutes, JobId: 750P600000fUXFrIAK
21:36:52: Bulk API Query Job is not yet complete, checking again in 5 minutes, JobId: 750P600000fUXFrIAK
21:41:55: Bulk API Query Job is not yet complete, checking again in 5 minutes, JobId: 750P600000fUXFrIAK
21:46:57: Bulk API Query Job is not yet complete, checking again in 5 minutes, JobId: 750P600000fUXFrIAK
21:52:15: Provided Objectname Apttus_Billing__InvoiceLineItemTaxBreakup__c is valid, batchsize will be set automatically
22:41:25: Replica schema successfully built using Bulk API 2.0 Query
22:43:36: Data population fully completed
22:43:36: Bulk API Query Job ingest completed, JobId: 750P600000fUXFrIAK
22:43:36: 12000203 rows replicated
-----------------------------------------------------------------
SQL-Sales checks the latest applicable outstanding job. If the job has not completed, SQL-Sales waits five minutes and checks again. Once Salesforce reports that the job is complete, the results are retrieved and the replication completes.
In summary a typical detached replication can therefore be performed as:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'BACK'
followed later by:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'CHECK(5)'
This allows the potentially long-running Salesforce processing stage to occur independently of the process which originally submitted the job.
ss_BulkAPILog
SQL-Sales automatically maintains ss_BulkAPILog to track Bulk API jobs used by ss_ReplicaB and ss_DeltaB.
The table is created within the deployed SQL-Sales schema.
For example, when executing:
exec uat.ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'BACK'
the Bulk API job information is maintained in:
uat.ss_BulkAPILog
The log enables SQL-Sales to identify outstanding jobs submitted using BACK or WAIT(n). This allows a BACK job to be subsequently processed using GET or CHECK(n) and also allows an interrupted WAIT(n) process to be recovered in the same way.
| Field | Purpose |
|---|---|
| ObjectName | Source Salesforce Object |
| TableName | Target SQL replica table |
| Operation | Bulk API operation associated with the job |
| Method | Method/lifecycle status associated with the job |
| JobId | Salesforce Bulk API JobId |
| BatchId | Batch identifier where applicable |
| BatchCreatedDate | Batch creation datetime where applicable |
| LogDate | SQL-Sales log datetime |
For normal operation it is not necessary to manually obtain or pass the Salesforce JobId as SQL-Sales uses the log to identify the appropriate outstanding job.
Specifying a Bulk API JobId
An optional @BAPIJobId parameter is available where it is necessary to explicitly specify a particular Salesforce Bulk API Query JobId.
For example:
exec ss_ReplicaB 'DEMO', 'Account',
@BAPIMethod = 'GET',
@BAPIJobId = '750XXXXXXXXXXXXXXX'
This is primarily intended for recovery, diagnostic or other exceptional scenarios. In normal use, GET and CHECK(n) automatically identify the applicable outstanding JobId recorded in ss_BulkAPILog, including jobs originally submitted using BACK and recoverable jobs from an interrupted WAIT(n) process.
Retrieving soft deleted & archived data (Query All)
By default ss_ReplicaB will automatically exclude IsDeleted = 1/True records as well as IsArchived = 1/True.
To include these records, append _All to the specified Objectname:
exec ss_ReplicaB 'DEMO', 'Account_All'
This causes the Bulk API query to include records available through Salesforce’s query-all behaviour.
Quick Top check
Top can be used to limit the number of records returned.
This doesn’t replicate back to the given object table name as it by default outputs as a resultset to the Management Studio results pane, to facilitate quick checks of data and metadata. The same data is also present in a _Check table, for example Account_Check.
exec ss_ReplicaB 'DEMO', 'Account:Top5'
Combining Top with a custom replica table results in the specified number of rows being written to that custom table instead.
exec ss_ReplicaB 'DEMO', 'Account:Top5', 'Table:AccountTopTest'
With ss_ReplicaB, the Top limit is incorporated into the query submitted to Salesforce; it is not necessary to retrieve the complete object before applying the limit.
Subset or Exclude Example
exec ss_ReplicaB 'DEMO', 'Account', @Special1 = 'Subset(Name,BillingCountry)'
exec ss_ReplicaB 'DEMO', 'Account', @Special1 = 'Exclude(Name,BillingCountry)'
exec ss_ReplicaB 'DEMO', 'Account', @Special1 = 'Subset(R-U)'
exec ss_ReplicaB 'DEMO', 'Account', @Special1 = 'Subset(C-C)'
exec ss_ReplicaB 'DEMO', 'Account', @Special1 = 'Subset(A-C,Website)'
Valid fields — i.e. fields which exist on the specified object and for which you have permission to query — will only be returned, although some basic fields required for the replication logic to function correctly will be imposed, for example Id, IsDeleted and SystemModstamp.
Exclude returns all fields to which you have access except the fields specified in the exclusion list.
Subset(A-M) allows replication to be limited to Salesforce fields whose API names begin with letters A through M (for example), with ranges combinable with individual fields where required – for example subset(A-B,Website).
For larger sets of subset fields, you may prefer to input the fields in list form, which is an acceptable input method to @Special1:
exec ss_ReplicaB 'DEMO', 'Opportunity', @Special1 =
'Subset(
AccountId
,Amount
,CampaignId
,CloseDate
,Name
,NextStep
,OrderNumber__c
,OwnerId
,Pricebook2Id
,Probability
,StageName
,SystemModstamp
,TotalOpportunityQuantity
,TrackingNumber__c
,Type)'
Or:
exec ss_ReplicaB 'DEMO', 'Opportunity', @Special1 =
'Subset(AccountId,Amount,CampaignId,CloseDate,Name,NextStep,OrderNumber__c,OwnerId,Pricebook2Id,Probability,StageName,SystemModstamp,TotalOpportunityQuantity,TrackingNumber__c,Type)'
Combining Subset and Top check
exec ss_ReplicaB 'DEMO', 'Account:Top100', @Special1 = 'Subset(Name,BillingCountry)'
exec ss_ReplicaB 'DEMO', 'Account:Top100', 'WAIT(10)', null, 'Subset(Name,BillingCountry)'
Custom Replica Example
exec ss_ReplicaB 'DEMO', 'Opportunity', @Special1 = 'Table:OppTest'
exec ss_ReplicaB 'DEMO', 'Opportunity', 'WAIT(10)', null, 'Table:OppTest'
In this example, Salesforce Opportunity data will be replicated to the OppTest SQL table.
This can subsequently be maintained with ss_DeltaB if required, independently of a separate Opportunity replica:
exec ss_DeltaB 'DEMO', 'Opportunity', @Special1 = 'Table:OppTest'
exec ss_DeltaB 'DEMO', 'Opportunity', null, 'WAIT(10)', null, 'Table:OppTest'
exec ss_DeltaB 'DEMO', 'Opportunity', @BAPIMethod = 'WAIT(10)', @Special1 = 'Subset(Name) Table:OppTest'
For example, running:
exec ss_ReplicaB 'DEMO', 'Opportunity', 'Table:OppTest'
exec ss_ReplicaB 'DEMO', 'Opportunity'
defines two separate replica tables of Salesforce Opportunity data, one called Opportunity and the other OppTest.
Both can subsequently be maintained using ss_DeltaB, provided the Table: switch is applied consistently to the custom replica.
Combining Top with Custom Replica
If Top is combined with a custom replica instruction, the limit of rows is applied to the custom-created replica table and therefore there is no _Check table output to the SSMS results pane.
exec ss_ReplicaB 'DEMO', 'Opportunity:Top20', 'Table:OppTest'
Where Clause Example
exec ss_ReplicaB 'demo2', 'Opportunity'
,@BAPIMethod = 'WAIT(10)'
,@Special1 = 'Table:OppTest'
,@Special2 = 'Where StageName = ''Closed Won'''
Syntax must be in SOQL format.
In this example a WHERE clause has been added which will be applied to the replica and can subsequently be applied to ss_DeltaB. It is entirely optional to apply this to a custom table or against the full Salesforce object name.
For example, the corresponding Delta would be:
exec ss_DeltaB 'demo2', 'Opportunity'
,@BAPIMethod = 'WAIT(10)'
,@Special1 = 'Table:OppTest'
,@Special2 = 'Where StageName = ''Closed Won'''
Any custom Replica created with a Where clause must continue to have that same identical Where clause applied to subsequent ss_DeltaB calls. Otherwise the Delta logic will be compromised as there will be no consistency between the scope of the original ss_ReplicaB and the subsequent delta data retrievals.
A WHERE clause can equally be applied without using a custom replica table:
exec ss_ReplicaB 'demo2', 'Opportunity'
,@BAPIMethod = 'WAIT(10)'
,@Special2 = 'Where StageName = ''Closed Won'''
and Delta subsequently:
exec ss_DeltaB 'demo2', 'Opportunity'
,@BAPIMethod = 'WAIT(10)'
,@Special2 = 'Where StageName = ''Closed Won'''
Combining Top with Custom Replica and Where clause
exec ss_DeltaB 'demo2', 'Opportunity:Top20'
,@BAPIMethod = 'WAIT(10)'
,@Special1 = 'Table:OppTest'
,@Special2 = 'Where StageName = ''Closed Won'''
Combining Top with Field Subset, Custom Replica and Where clause
exec ss_DeltaB 'demo2', 'Opportunity:Top20'
,@BAPIMethod = 'WAIT(10)'
,@Special1 = 'Subset(Name,Type,StageName) Table:OppTest'
,@Special2 = 'Where StageName = ''Closed Won'''
ContentDocumentLink
Due to Salesforce implementation restrictions on querying ContentDocumentLink, the conventional ss_Replica process contains specific handling for this object which is not provided by ss_ReplicaB.
Where ContentDocumentLink replication is required, use:
exec ss_Replica 'DEMO', 'ContentDocumentLink'
See the conventional Replication documentation for the additional LinkedEntityId and ContentDocumentId options available for this object.
Execution method summary
WAIT – For most normal replications, the default is sufficient (default WAIT):
exec ss_ReplicaB 'DEMO', 'Account'
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'WAIT'
WAIT(n) – For a synchronous replication where immediate recording of the Bulk API JobId and resilient polling is desirable
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'WAIT(10)'
BACK – For particularly large or long-running objects where you want Salesforce processing to be detached from the submitting SQL process:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'BACK'
CHECK(n) – and later:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'CHECK(5)'
GET is useful where you simply want to check once and return immediately if the job is not yet complete:
exec ss_ReplicaB 'DEMO', 'Account', @BAPIMethod = 'GET'