Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Why does SF_Refresh fail to remove work tables sporadically?

I have a scheduled process that invokes SF_Refresh and SF_Replicate on a regular basis for a series of SF objects. SF_Refresh always uses the 'Subset' option to ignore new columns that might be added. The process has automatic retry and will fail back to an SF_Replicate if SF_Refresh fails, which is good if a new object is added to the processing list that has not yet been refreshed or has not been refreshed in 30 days.

This seems to work well and keep the DB tables in sync, but I do notice on occasion there will be a series of tables named sf_object_DeltaYYYY-MM-DD_timestamp and/or sf_object_DeleteYYYY-MM-DD_timestamp. I am assuming these are created as staging tables when an SF_Refresh is executed, and are normally cleaned up, but may not be if there is an error. Is there a recommended method of troubleshooting for this symptom?

Note that I recently found a current series of these for PermissionSet and PermissionSetAssignment objects, so I deleted them. I then ran SF_Refresh interactively there were no errors and the work tables were not created.
1 person has
this question
+1
Reply