Re: XML-SAX *XML_EXCEPTION event and reported parsed length question

HI Mike

I'm replacing each file-processing unit one at a time, and so far I see performance in the same general frame - for an XML I'm testing with, 400-700 milliseconds.

And that is with the XML-SAX process still running, so there's still that overhead.

XMLTABLE still has to parse the XML data, too - there is no way around that. It does produce a "set". So far as I'm aware, there are a couple parsing methods - SAX and DOM, in probably various flavors.

But the proof is in the pudding - we'll see what I get when the whole thing uses XMLTABLE - I like it so far.

Vern

On 7/12/2017 4:44 PM, Mike Jones wrote:

Hi Vern,

I'd be shocked if XMLTABLE, which uses a SET based approach, doesn't
perform faster. I can't give you intelligent comparison information,
because XMLTABLE is the ONLY way I've ever parsed XML, and likely the ONLY
way I'll parse it in the future.

Mike

On Wed, Jul 12, 2017 at 11:11 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Mike

Thanks, this is encouraging - and others related to the project like what
I showed in one example.

So one question has been, will it perform in less time - I suspect it well
- overall there are around 13 tables that will be populated using data from
the XML. Currently, when there is a parsing error, that goes to someone to
fix manually.

The SQL stuff has automagically put an x'3F' where the "evil woes" reside.
Nice - no manual effort needed at all.

As I said to one of the other developers, "Do I have to work hard to
convince you that no errors is a good thing?" He laughed heartily!

Cheers
Vern