Hi,
I seems to be doing what you asked it to do.
The way both client and FLTR tables work, is by filling the table with
data (in memory).
If you tell it to chunk, it apparently reads it that way.
Create a new table-field without chinking, with a single column, and do
the COLSUM there instead.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Doug,
> Since you have been replying to list posts more frequently, I figured I
> would ask you a question real quick.
>
> We have several pieces of workflow that use filter side tables and COLSUM.
> In situations where there are more records in the table than the 'Server
> Table Field Chunk Size', I have noticed that it does a 'select first x' on
> the table columns, and it does it again till it finds a number higher than
> the number of records returned. In our situation we had the setting at
> 1000
> and had over 50K records in the table...so the SQL log shows select first
> 1000, then 2000, 3000, 4000, etc till it hits a value above the count in
> the
> table. This of course kills our performance when we are just doing a sum
> on
> a column....so I converted them to direct SQL doing SUM() and aren't
> having
> problems anymore. Why was this done as a method to perform COLSUM?....it
> doesn't seem efficient to me at all.
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
