>Wow! I do not envy your task. I suppose there is no way to re-evaluate some business process or rule in all this? This is not sounding very efficient, but then I can not be privy to your objectives, requirements, etc. Good luck.

>That works as long as the user is constantly querying looking at data, making adjustments and doing more queries. My idea is to let the user sort on ANY column in the grid simply by clicking on it. I would have to create too many indexes to do that (close to 240).

I've seen this done in an Access (gasp!) environment. Users then expect to be able to instantly sort huge databases by clicking the column headers.

As Mark said, that's a lot of work. It's more likely that you have 10-15 fields that will always get sorted, and some will never be sorted. I would propose that(as designer of the compilation) you identify the most useful sorts, and create those indexes. Ideally you could create the compilation, index it, and leave an off-line version for query, then update it nightly/weekly/etc. If you must have up-to-date information at all times, it'll be the indecisive user who has to wait.

Have the header click event check if an index exists. If it does, set the order to that tag and refresh; otherwise tell the user to wait while the index is created. During your table maintenance, delete those tags that make little/no sense. (anything not indexed by you up front) If you log the tags you're deleting, you can establish better tag usage. This gives quick sorts for normal sorts, provides the sort for less-used sorts, and helps maintain the table's efficiency. If the indexes are active between maintenance, the results will be quickly reproducible when the manager asks for "that last sort you did"

I've rambled enough on this friday after-hours ... more|less on monday.