On Thu, 7 Mar 2013, at 18:48:29, Henrik R?tzou <hr@xxxxxxxxxxxx> wrote:
Jon,
lets make this a little more interesting:
d elements ds qualified
d type 50a varying inz('A')
d len 10p 0
d dataalpha 1024a varying
...
That just captures the type, length etc. of an individual element - it isn't storing it in the variable indicated by the element name etc. So you're not comparing like with like.
Given this XML
<Customers>
<Customer>
<Name>Fred</Name>
<Address>Any street, Anytown</Address>
<Balance></Balance>
</Customer>
<Customer>
<Name>Joe</Name>
<Address>Another street, Differenttown</Address>
<Balance>155.99</Balance>
</Customer>
<Customer>
<Name>Jane</Name>
<Address>Another Raod, Newtown</Address>
<Balance>None</Balance>
</Customer>
This code (not tested) will load all elements into the DS where individual fields can be processed by name. Significantly, if I add 5 more elements to the XML I can process it by simply adding 5 more lines to the DS.
D Customers ds Qualified
D Customer LikeDS(Customer_T) Dim(99)
D countCustomer 5i 0
D Customer_T DS Template Qualified
D Name 30a
D Address 80a
D Balance 10a
D Balance s 9p 2 Dim(99)
D i s 5i 0 Inz
/Free
XML-INTO Customers %XML('/wherever/test.xml':
'doc=file countprefix=count');
For i = 1 to Customers.countCustomer;
Monitor;
Balance(i) = %Dec(Customers.Customer(i).Balance: 9: 2);
On-Error; // Signal error identifying element in error and set default.
Balance(i) = 0; // Or choice of default
Dsply ('Invalid Balance element ' + %Char(i) + ' Value '
+ Customers.Customer(i).Balance);
EndMon;
EndFor;
This I believe would handle the issue that the OP raised and also my point about invalid numeric values. It also enables just about every field definition to be made via the LIKE keyword in the DS to match the database defs.
That's what XML-INTO can do.
I have no argument that your solution is better and easier than hand coding XML-SAX - but I think XML-INTO is better suited in many cases.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
midrange.com
