<MRM> <inner>abcde fghij 12345</inner> </MRM>where the element inner is of type xsd:list, so it has three associated string values, rather than a single value.
<MRM> <str1>abcde</str1> <str1>fghij</str1> <str1>12345</str1> </MRM>it is reasonable to assume that the following ESQL syntax works:
DECLARE D INTEGER; SET D = CARDINALITY(InputBody.str1.*[]); DECLARE M INTEGER 1; WHILE M <= D DO SET OutputRoot.MRM.str1[M] = InputBody.inner.*[M]; SET M = M + 1; END WHILE;
SET OutputRoot.MRM.str1[M] = InputBody.inner.*[M];requests a tree copy from source to target. Since the target element does not yet exist, it is created and its value and type are set from the source.
This is consistent with ESQL's behavior elsewhere, but in the case of elements having values of type xsd:list, this code can produce spurious validation errors.
SET OutputRoot.MRM.str1[M] = FIELDVALUE(InputBody.inner.*[M]);
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ak20820_ |