none
ADF Copy Activity Bug: data is messed up for varbinary data (byte []) containing a base64 encoded string RRS feed

  • Question

  • I have a copy activity in ADF to extract data from the EventLogFile table from Salesforce into Azure SQL.

    The table attribute "LogFile" contains an encoded base64 string.

    The input and output datasets created with the copy wizard are assigned the attribute type: byte[]

    The copy process works as expected, except the target attribute in Azure SQL table, defined as varbinary(max), only contains a random content (i.e. an attribute name itself) encoded as base64 but not any source data.
    The same occurs if I do not define any attribute type in the dataset definition. If I use the type string instead, it struggles with unicode and therefore cannot be used as workaround.

    It also doesn't help, to explicitly list all attributes in the activity query statement, instead of using "*".

    The ADF copy activity is messing up varbinary data (coded as Base64).

    Note: if I copy the same table with a 3rd party tool (Skyvia) all data is copied correctly. 
    To me it seems, there is a bug in the ADF copy activity for byte[] data.

    Any help/fix would be appreciated.

    Cheers

    Michael








    • Edited by ibax Sunday, September 17, 2017 9:52 AM
    Saturday, September 16, 2017 4:13 PM

Answers

  • Hi Michael, we are able to reproduce this issue in house and found a bug inside the Salesforce driver.  We will take steps to fix this issue.  Thank you for reporting this bug!

    Shirley

    • Marked as answer by ibax Wednesday, November 29, 2017 4:32 PM
    Tuesday, September 26, 2017 8:31 AM
    Moderator

All replies

  • Hi Michael, we are able to reproduce this issue in house and found a bug inside the Salesforce driver.  We will take steps to fix this issue.  Thank you for reporting this bug!

    Shirley

    • Marked as answer by ibax Wednesday, November 29, 2017 4:32 PM
    Tuesday, September 26, 2017 8:31 AM
    Moderator
  • The bug has been fixed. Thank you
    Wednesday, November 29, 2017 4:33 PM