I came to that conclusion by reading the description:
An XML API that allows developers to take advantage of event-driven XML parsing. Unlike the DOM specification, SAX doesn't require the entire XML file to be loaded into memory. SAX notifies you when certain events happen as it parses your document. When you respond to an event, any data you don't specifically store is discarded. If your document is very large, using SAX will save significant amounts of memory when compared to using DOM. This is especially true if you only need a few elements in a large document.

Although it may not mean it's only good for that situation, memory isn't a problem. As I said, the FOPEN() works great. And opening the file with MODIFY FILE in the command window is very quick. I just find that XML seems to be inherently slow.

I understand that the W3C is working on a binary XML standard. It may be fast, but wouldn't that kind of break a lot of existing xml imports? Just a thought. I suppose people are fed up with the slowness.

Anyway, thanks again for your input, Sergey. It's always a pleasure. I will look at SAX for consideration in future projects. It would be a lot of work to redo this one for what may turn out to be little or no improvement in speed. Especially since it is working so well right now.

Dana

>>Thanks, Sergey. I'll keep that in mind. Unfortunately it probably will not do much for me, since I actually need all of the data, not just small amounts of it.
>>
>
>I'm not sure how you came to that conclusion because it isn't correct.