I think you might have to use Base64Encode (container field value from Table A) when assigning the variable.
Then Base64Decode when setting it into the new container.
Just curious...why not just import the file directly into the container in Table B?
1 of 1 people found this helpful
Interesting. This shows variable have reference of container as its value.
If duplicate record before set variable, the error didn't occur, since same contents remain in another record. (duplicating record also use reference of contents, not duplicate contents.)
If you use global container field in tableA, it will keep the contents after record is deleted.
Until you close the session, I'll bet.
I'm creating tens/hundreds of new records in TableB based on the first record that gets created in TableA - I only need to download the file once so I was performing this in the TableA record.
I'm now storing this in a global container field which is working well in my tests so far.
I had switched to using a global container field as well which looks like it's solved the issue - it does require a new field which I don't really need but not a big deal at the end of the day.
Still curious why the variable doesn't hold it's value after the record is deleted - I'm assuming this has something to do with how container fields are stored/referenced by variables which store a container value/data type?
It may be a bug, deleting object that have reference yet.
You can see the behavior clearer using open external storage.
Insert file to container: there is a file in external storage
Set variable: data viewer show "remote:..." as text representation of reference to container contents
Delete container contents and commit: file removed from storage, but data viewer doesn't change
Set Field using variable: Error(10) Requested data is missing
I played around some while, after that there is a file that is not referred from any record... remain after deleting all records. may be another bug...