Forum Discussion
Thank you. That is definitely useful and I will go that route going forward. In this instance, one important thing that I forgot to mention is that my source is Oracle DB, and my target and lookup tables are in SQL Server. So I am selecting from Oracle, checking a SS table to see if the attribute exists, and if not, then insert / update.
I got it. I’ll use Snaplogic to write the data to a SS temp table, then use the SQL above on the SS side for the upsert. Thanks!
Hi Tim,
The REST GET is setup with response type BINARY which puts the BASE64 encoded data into the entity field with a “_snaptype_binary_base64”, which I can’t decode directly with the Base64.decodeAsBinary($entity) function.
However, if I BASE64 decode it with the Document-To-Binary snap and then re-BASE64 encode it with the Binary-To-Document snap, I end up with the same BASE64 data in a content field, without any “_snaptype_binary_base64”, which then decodes fine with the Base64.decodeAsBinary($content) function.
Hmm… I wonder how the DECODE BASE64 on the lower branch works then?
I’ll mess with it more.
- jayakrishnan_va7 years agoNew Contributor
Hi @christwr , I believe that the base64 encode-decode inbuilt functions has some limitations and the encoding-decoding doesnt support all characters.
In the second approach i guess the data is not being transferred as it is supposed to be even though its working (please verify it).my suggestion: use a script snap with python code for base64 encoding and decoding functionality.
Thanks.
Related Content
- 11 months ago
- 10 months ago
- 2 years ago