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 'LS,'object','SchemaError','verify','bulkapi'
where LS is your linked server name and object is the object name.
SchemaError Options
Set the optional parameter SchemaError to 'Yes' if you want SF_Refresh to automatically call SF_Replicate 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.
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 only use this option if you are having problems with SF_Refresh. Using the bulk API is always slower, but it may be the only way to get the rows down 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','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 there is a schema change detected on a table 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 refreshing the table.