first of all “Create Thread” is deprecated and shouldn’t be used.
Regarding SQLite: it’s designed to handle concurrent reads well but does not handle concurrent writes at all. As soon as one thread acquires a write lock, all others are blocked (SQLite has only file-level lock) until this thread releases the lock (usually by committing its transaction). You could try committing the transaction after each insert but that would a) have a really bad performance, b) interfere with the internal transaction handling, so I recommend against it.
I’ll open an internal ticket for the problem, however, I cannot promise when and if it will be changed. Those functions have evolved historically and we first have to assess risks of breaking anything.
If you want to simply copy an array, use:
set array2 = array1.copy();
That is correct. No output values exist when an exception is thrown.
I will create a feature request on our tracking system. I cannot promise anything though.
A way to work around the issue is to manually compose (and later parse) SOAP and use URL Adapter.
Unfortunately, this is an error in the documentation. Currently it’s not possible to ignore protocol errors for SOAP adapter.
One has to catch the exception.
The log files are always written to a subdirectory “logs” of the service directory and there’s no way to change it other than editing service files manually. It’s not recommended / supported though as every service deployment will erase your changes.
The behaviour you’re observing is correct. The Bridge uses object references to avoid copying potentially large amount of data. With just a few exceptions data items are always referenced.
To get the desired behaviour, you’d have to either use separate variables like this:
create local options1 using rFC_DB_OPTReference; set options1.TEXT = "IDOCTP = 'DELVRY01' AND"; append options1 to optionstable; create local options2 using rFC_DB_OPTReference; set options2.TEXT = "MESTYP = 'DESADV' AND"; append options2 to optionstable;
or use one variable and a copy() operation like this:
create local options using rFC_DB_OPTReference; set options.TEXT = "IDOCTP = 'DELVRY01' AND"; append options.copy() to optionstable; set options.TEXT = "MESTYP = 'DESADV' AND"; append options.copy() to optionstable;
Since it’s causing troubles, I’ll increase the priority. Hopefully it’ll make its way to the next release.
I wouldn’t call it a bug, but it is quite a big inconsistency. And one *almost* never care if the field is null or undefined.
Nevertheless, I’m opening tasks regarding this.
currently there is no way to configure this behaviour. The current implementation indeed preserves leading null fields and skips trailing ones.