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

Using @bulkapi_option in sf_refresh

I see a new parameter (@bulkapi_option) in sf_refresh starting 2.14.3. Does this move some of the refresh processing out of the SQL Server process like replicate? If so, that is great! How do I use the parameter? Can this parameter also be added to SF_RefreshAll?
1 person has
this question
+1
Reply
  • No. The bulkapi switch tells sf_refresh to use the asynch bulkapi to get the changed rows instead of the web services api.

    Pros:
    - Uses fewer api calls for large sets of changed records

    Cons:
    - Slower because the bulkapi runs as jobs on sf servers.

    I don't understand the sf_refresh running out of SQL Server. Why is that a good thing for you ?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • If I recall in one of our prior conversations, you indicated that sf_replicate executes an external dbamp.exe process meaning the replicate process does not run inside the sqlserver.exe process while sf_refresh uses the linked server meaning the refresh is executed inside the sqlserver.exe process. We are not having any problems with memory, but it is always nice to isolate processes outside of sqlserver.exe when possible. Does the use of @bulkapi_option result in the usage of dbamp.exe instead of the refresh running inside sqlserver.exe?

    If so, how do I use @bulkapi_option? I tried ‘yes’ but that didn’t work.
    If so, can this parameter also be added to SF_RefreshAll?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • OK, three things:

    1. If you want the link server to run "out of process" to the SQL instance, you can do that by turning off the "Allow in Process" switch in the Provider options. DBAmp will run slower because the buffers have to be passed across process boundaries AND there is some alteration in the way security is done with out of process link servers. Send me an email at support at forceamp.com to discuss further.

    2. The bulkapi switch does not change how sf_refresh runs with respect to the sqlserver.exe process. It simply changes the api that the link server code uses to communicate with salesforce.

    3. SF_RefreshAll does not support the bulkapi switch, only sf_refresh. This is because the bulkapi switch makes the refresh run slower and should only be used for particular tables that need it. How do you know you need it ? If the number of changed records per sf_refresh for that table is 50K or greater, then the bulkapi switch would be an option for that table only.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned