Options

Doubt about SumIndexField

Hi friends... I have a doubt about SumIndexField in a Table Key....
I tried to find it on internet but I can't, so I hope one of you can clarify my doubt...

I have one table (Table A) with many keys with diferent fields... and many of them have specified the same field as SumIndexField (Field "Total Importe producción" a.k.a Total Production Amount)... that is why we need to Totalize this field applying different filters in many places of the program:

f1d9yxb6lhcz.png

In other table (Table B) I have a CalcField that totalize our field Field "Total Importe producción" from the Table A... applying different filters.

ubq6fn5jcscu.png


My doubt is... how I know the program is applying the optimal Key from the Table A? is it a dogma of faith? Does exist any way to specify mannually the key from "Table A" I want to use to my CALCFIELD?

The thing is I consider it takes long time to calculate the information I want... I know my table is a big one with thousands of registters... but I have the feeling that it is not applying the right key... (just my impression)

Thank you

Best Answers

  • Options
    bbrownbbrown Member Posts: 3,268
    Answer ✓
    When the flowfield (Table B) is calculated it will use the first key from table A that supports all of the applied filters. Even if not the most optimal for calculating the SumIndexField.

    In older versions, you had to have a key in table A that both included all the fields for applied filters plus the desired SumIndexField. Neither of these is a requirement in newer versions. But can still help performance.
    There are no bugs - only undocumented features.
  • Options
    bbrownbbrown Member Posts: 3,268
    Answer ✓
    vaprog wrote: »
    Does this mean calculating the Item."Net. Change" field without any FlowFilter fields set, other than "Date Filter", would use the key "Item No.","Posting Date" and sum up without any SumIndexFields, or are keys with the used SumIndexField at least preferred over other keys?

    It will use the first key that supports the applied filters and the SumIndexField.
    There are no bugs - only undocumented features.

Answers

  • Options
    bbrownbbrown Member Posts: 3,268
    Answer ✓
    When the flowfield (Table B) is calculated it will use the first key from table A that supports all of the applied filters. Even if not the most optimal for calculating the SumIndexField.

    In older versions, you had to have a key in table A that both included all the fields for applied filters plus the desired SumIndexField. Neither of these is a requirement in newer versions. But can still help performance.
    There are no bugs - only undocumented features.
  • Options
    vaprogvaprog Member Posts: 1,118
    bbrown wrote: »
    When the flowfield (Table B) is calculated it will use the first key from table A that supports all of the applied filters. Even if not the most optimal for calculating the SumIndexField.
    Does this mean calculating the Item."Net. Change" field without any FlowFilter fields set, other than "Date Filter", would use the key "Item No.","Posting Date" and sum up without any SumIndexFields, or are keys with the used SumIndexField at least preferred over other keys?

    pewvf4t28spd.png
  • Options
    bbrownbbrown Member Posts: 3,268
    Answer ✓
    vaprog wrote: »
    Does this mean calculating the Item."Net. Change" field without any FlowFilter fields set, other than "Date Filter", would use the key "Item No.","Posting Date" and sum up without any SumIndexFields, or are keys with the used SumIndexField at least preferred over other keys?

    It will use the first key that supports the applied filters and the SumIndexField.
    There are no bugs - only undocumented features.
  • Options
    LLOSETILLOSETI Member Posts: 2
    Thanks guys!!
Sign In or Register to comment.