The grid widget is a mean of data presentation, so it is choosen in design to support user interaction.

Let me repeat my question: what does an enduser wants to do with that monster of lines?
Scroll through it line by line so he has something to do for the next couple of days ??

If you do not have user interaction, there is no justification to use the grid widget.

But it is totally up to you how you cope with this situation.

Uli

BTW. you can filter even in your XMLREADER parsing
and/or stop processing after a given number of records;
XMLREADER is no "do or die".

As the XML document is parsed, the operations in the handler instance are activated based on what the parser encounters in the XML document. When PARSE or PARSEFILE returns, either the entire XML document has been successfully parsed, or a fatal error has occurred, in which case a negative return value is returned.

A fatal error can be caused by:

• An XML document that contains invalid XML
• A handler component's callback operation returning a negative value or setting $status to a negative value.

looks like a memory problem, doesn't it?

And the grid widget may have it's own data buffer so you have to allocat double space.

Any way to reduce these masses of data with some filter (who wants to scroll through 32K of records)?

Using lookup to find the number of hits (without moving data) and then give a nice option:

askmess "Too many hits (nnnnnn) what do you want to do?","add some selections, use another presentation"

Uli

P.S: once upon a time, we implemented a corporate telephone book application.

In acceptance test, one retrieved the data without any profile and claimed that it took far too long to show all the info.

Our reply was: what is the use case to go trough all 30K entries line by line. You have no name, no department, no xxxx?

Of course I can use $hit in case if I read data from Database. But in my case, I try to parse XML file and populate all data directly to my grid.