isn't THAT interesting.
you rock, T.

Prarie, i'm sure over half of those posts have been thanks for help i've received from you and everyone else, and applause for help i didn't even know i needed.

This message has been edited. Last edited by: susannah,

T, didn't work.
still bombs
my understanding of EXTSORT, which is probably apocryphal, is that EXTSORT gets called automatically when focus needs it.

My understanding is that, on the mainframe, EXTSORT will invoke SYNCSORT or whatever sort is installed. I'm not aware of any external sort package natively part of Windows?

I second ruhan's comment. I thought EXTSORT was only available on mainframe.

Several approaches to try, depending on your data source and the ordering requirement for the result.

a. Look for a way to use TABLEF (rather than TABLE); then there is no FOCSORT involvement. If your source is a database server, "optimize" the request so that the server does the grouping.

b. If the table request can be converted from single-verb to multiple-verb, with a cascade of sorting phrases, the overall size of the internal matrix (really an on-the-fly hierarchical Focus file) may be considerably less than when a single verb is used, so it may beat the 2gb limit.

quote:

ly



IB - Developer Center Forums FOCUS/WebFOCUS whadya do when the focsort gets over 2gig?

I have had success using TABLEF when reaching the 2gig limit.

For those of you without TechSupprt access, the main content (excluding EXTSORT) in the link I gave above is -

SET AUTOTABLEF = ON
SET SAVEMATRIX = OFF

Using TABLEF as a default and avoiding the building of the internal matrix can considerably reduce the focsort requirements, as can reducing the number of BY phrases so that the internal 4 bytes required for each row for each BY field is reduced, thus reducing the total length of a single data row in the focsort.

e.g. If you have 12 BY phrases and you concatenate these fields into one and then sort by that, you could save 44 bytes per data row. If you have 1 million rows then that represents about 42 Mb(?).

If your data source is SQL then achieve all your collating and sorting of the output in your view or database definition so that you can just -

TABLEF FILE viewname (or SQLOUT)
PRINT *
ON TABLE HOLD AS whatever
END

T

I kludged a workaround in a similar situation by concatenating 3 or 4 BY fields into a single field.

Thanks Robin,

It's great to have an actual example of one's ramblings!

The proof of the pudding .......

T

We've worked around this limit on solaris by "chunking" the data. It's a pain. Just enter "chunking" into the find box on this bulletin board to see what we went through.
-James