SF_Replicate

Syntax
Example
Options
Notes

SF_Replicate

The SF_Replicate stored procedure creates a local table that is replicated from the corresponding object in Salesforce. The name of the local table matches the name of the Salesforce object (for example, Account). Any schema changes in the Salesforce object are reflected in the replicated table.

In addition, SF_Replicate creates a primary key on the ID field of the table.

Syntax

EXEC SF_Replicate 'linked-server', 'object-name', 'options'

In this syntax:

The linked-server parameter specifies the name of your linked server.
The object-name parameter specifies the object name.
The options parameter can specify either batchsize(n), pkchunk, queryall, bulkapi, or nodrop (see Options for details). However, by default, this parameter is null.

Example

The following example replicates the local Account table with the current data on Salesforce.com by using the Salesforce linked server.

EXEC SF_Replicate 'Salesforce', 'Account'

Options

The section describes options that you can use with the SF_Replicate stored procedure.

batchsize(n): SF_Replicate uses the maximum allowed batch size of 2000 rows. You might need to reduce the batch size to accommodate APEX code on the Salesforce.com server. To specify a different batch size, use the batchsize(n) option, as shown in this example:
```
EXEC SF_Replicate 'Salesforce', 'Account', 'batchsize(50)'  
```
bulkapi: By default, SF_Replicate uses the Salesforce.com Web Services API. To use the Salesforce Bulk API instead, add the optional bulkapi switch. When you specify this option, SF_Replicate submits a Bulk API job and polls every minute for completion. Use this option only for large tables, where the Bulk API can improve performance.

The following example uses bulkapi, and it polls every minute for completion:
```
EXEC SF_Replicate 'Salesforce', 'Account', 'bulkAPI'
```
pkchunk: By default, SF_Replicate uses the Salesforce.com web services API. If you want to use the Bulk API with the PK chunking header enabled, add the optional pkchunk switch. Use this option only for large tables, where chunking improves performance and reduces the likelihood of timeouts.

The following example uses pkchunk, and it polls every minute for completion:
```
EXEC SF_Replicate 'Salesforce', 'Account', 'pkchunk'
```
The default batch size is 100,000. You change this value by using the batchsize(n) parameter, as shown in this example:
```
EXEC SF_Replicate 'Salesforce', 'Account', 'pkchunk,batchsize(50000)'
```
queryall: By default, SF_Replicate does not include archived and deleted records from the Salesforce object when it creates a full copy of Salesforce data. To include those archived and deleted records in the full copy of Salesforce data, use the queryall switch, as shown below:
```
EXEC SF_Replicate 'Salesforce', 'Account', 'queryall'
```
Note: You can use the SF_ReplicateIAD stored procedure as an alternative, which performs the same operation as using the queryall option with SF_Replicate.
nodrop: By default, SF_Replicate drops the local table. To use SF_Replicate without dropping the local table, add the optional nodrop switch, as shown in the following example:
```
EXEC SF_Replicate 'Salesforce', 'Account', 'nodrop'
```

Notes

The SF_Replicate stored procedure creates a full copy of the object and downloads all data for that object from Salesforce. To download only the changes that have been made since the local copy was created, use the SF_Refresh stored procedure instead.

A primary index on the ID column is automatically created when the table is replicated.
By default, DBAmp does not download the values of Base64 fields and instead sets those values to NULL. This behavior improves performance. If you require the actual values, change the Include Binary Field Values setting to True on the Settings page of the DBAmp Configuration application.