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

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

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