Some more weird XMLPort behavior

Miklos_Hollender

When importing a lower level Table does not see an upper level table i.e. importing Sales Line temporary tables does not see the Sales Header temporary table above it. I.e. TSalesLine."Document No." := TSalesHeader."No." leaves it empty.

Then I set global variables in the upper level one and read it in the lower level one (both cases OnBeforeInsertRecord) and find that the global variables were also somehow cleared, reseted.

I guess I could try LinkField properties but setting things by code is usually more reliable especially when it is just a bunch of temp tables to process later.

Are XMLports even tested with large, complicated, dynamical structures? Like converting an EDIFACT D96A to XML and importing it?

Build AT 6.00.29626

kriki

I have had some issue like yours. Lines being imported before the header when run in servicetier. When run in classic, it was ok.

Posted a bugreport in Microsoft and the answer was that I had to write the XML-port like in their example (and they gave me some link). They also wrote it down in their internal problem system but nothing in the documentation.

BTW: did I tell you they would NOT fix it....

ta5

Just my 2 cents:
Because of issues with xmlPorts we switched to use xmlDOM objects, although it puts quite a big load on Memory usage. But anyway, with xmlDOM Object and xpath you can do what ever you need, including validation against schema, using namespaces, etc.

Thomas

Miklos_Hollender

kriki wrote:

I have had some issue like yours. Lines being imported before the header when run in servicetier. When run in classic, it was ok.

Posted a bugreport in Microsoft and the answer was that I had to write the XML-port like in their example (and they gave me some link). They also wrote it down in their internal problem system but nothing in the documentation.

BTW: did I tell you they would NOT fix it....

I'm still using Classic and it does not work right there - I don't think issuing bug reports for Classic would be of any use today...

Miklos_Hollender

ta5 wrote:

Just my 2 cents:
Because of issues with xmlPorts we switched to use xmlDOM objects, although it puts quite a big load on Memory usage. But anyway, with xmlDOM Object and xpath you can do what ever you need, including validation against schema, using namespaces, etc.

Thomas

Yes, did that in the past but now have huge schemas I must validate against because they will be transformed to EDIFACT and hand coding it instead of generating the xmlport would be more work than what interface is worth in the sense of manual work saved.

BTW would Classic type COM XMLDOM work in the RTC or I would have to recode everything when I upgrade?

ta5

XMLPort vs DOM Doc: You are right, it's always to decide between development speed of a "wizard" and the full control of manually developed code. COM-Automation Objects work in 2009 Client side and server side, on 2013 I'm not fully sure, but anyway on 2013 I would migrate to .NET datatype, but the code will be quite similar, so the XML part would not change too much.

Regards
Thomas