SF_Refresh


SF_Refresh


Usage

SF_Refresh compares the current, local replicated table with the contents of the same object at Salesforce.com. Any changes are detected and the local table is updated. Use SF_Refresh when you need to sync your local copy with Salesforce.com.

You can only use SF_Refresh on objects in Salesforce that contain the necessary timestamp columns for tracking changes.

Syntax

      SF_Refresh ‘LinkedServerName’,’ObjectName’,’SchemaError’,’ErrorMessagesOnly’,’Verify’,’bulkapi’

In this syntax, LinkedServerName and ObjectName are placeholder values for the actual linked server and object names.

SchemaError Options

Set the optional parameter SchemaError to Yes if you want SF_Refresh to call SF_Replicate automatically when there is a schema change to the Salesforce object.

You can also set SchemaError to Subset. If there is a schema change to the Salesforce object, SF_Refresh tries to determine a valid subset of columns that exist in both the local table and the table on Salesforce.com. It then refreshes the local table based on that column subset. Subset implies that new fields added to the Salesforce object are not captured by SF_Refresh. In addition, deleted fields still remain in the local table. To alter the local table and immediately delete columns no longer in the Salesforce object, set SchemaError to SubsetDelete.

To synchronize the schemas, either run SF_Replicate or SF_Refresh with SchemaError set to Yes.

To alter the method used for incrementally updating the local tab, set SchemaError to Repair.

The Max(SystemModstamp) of the local table is used to set the start time of the interval (as opposed to the last time SF_Refresh ran). In addition, deleted records are determined by comparing a list of the ID’s locally with a list of ID’s from the Salesforce.com table (as opposed to using the GetDeleted function).

If SchemaError is not provided, SF_Refresh prints an error message and throws an error if the two schemas do not match.

Error Message Options

You can set the optional parameter ErrorMessagesOnly to Yes to suppress any output from DBAmp other than error messages. This is useful when you want to focus only on errors without other informational output. The default value is No, which includes standard output alongside error messages.

SkipDeleted Option

By default, the optional parameter SkipDeleted is set to No. However, if you want to skip the retrieval of deleted records from the specified Salesforce object, you should set it to Yes.

To use this yes option, add it to the list of SF_Refresh parameters, as shown below:

EXEC SF_Refresh 'Salesforce', 'Account', 'No', 'No', 'No', null, 'Yes'

Verify Options

You can set the optional parameter verify to No, Warn or Fail. The default value is no. If you set the verify parameter to warn or fail, SF_Refresh compares the row count of the local table with the row count of the table on Salesforce and reports any difference. If you set the parameter to Fail, SF_Refresh fails.

BulkAPI Options

The optional parameter bulkapi allows SF_Refresh to use the bulkAPI instead of the Salesforce web services API. You should use this option only if you have problems with SF_Refresh. Using the bulk API is always slower, but it might be the only way to download the rows from Salesforce.com. Normally, you should not set this option. To use the bulkAPI, add bulkapi to the list of SF_Refresh parameters:

EXEC SF_Refresh 'Salesforce','Account','Yes','No','No','bulkapi'

Refresh Example

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

EXEC SF_Refresh 'Salesforce', 'Account'

Using the DBAmpTableOptions Table

Use the DBAmpTableOptions table to provide replicate options for tables when using SF_Refresh. When a schema change is detected on a table that is being refreshed by SF_Refresh, and the Yes parameter is set to replicate the table, you can specify options to tell SF_Replicate how to replicate the table locally. See Using the DBAmpTableOptions Table for more information.

Notes

The table must contain a SystemModstamp column in order to be refreshed. A local copy of the table must exist and be less than 30 days old. If the table does not exist, use SF_Replicate to make a local copy before you refresh the table.