Hi everyone, One of our users (a very high-ranking one, so denial was not an option [;)]) wanted to have a certain report sorted by a Decimal field of the underlying table. So I created the appropriate key and ran the report using this key. It started printing the first few entries and then repeated the same block of entries (5 or so) over and over again. I tried sorting the table’s overview form and another, “card-type”, report by the new key: No problem. Then I found out that the error was caused by the Decimal field in question also being used as a total field in the footer of the erroneous report. When I removed the total field, sorting by the new key worked fine. I then resorted to calculating the field totals in C/AL code using a total variable. It seems that fields being used as total fields can not also be used for sorting. Is this a mere bug or some technical limitation? And does this only occur with Decimal fields or also with Integers? It’s also a bit strange that there was no crash or error message, but instead an endless stream of the same group of records.
Because you are referring to the Decimal field in the footer, you are actually changing the value on the current record. When you go to read the next record, it finds the one after the “Total” record. This behaviour is not limited to decimal fields. It works the same way with any type. The easiest example is if you want to find all Items with a blank vendor No. and change it to 10000. If you create a processing report, sort by Vendor No., and Filter on = ‘’, you will see only one record gets updated. This is because after you find the first record, change the Vendor to 10000, it looks for the next record past 10000,Item No. (appended primary key), and finds nothing left in the filter. Hope this clears things up a bit rather than confusing them more. 
Chris, thanks for your explanation - the only thing which actually is confusing is the fact that no more records are printed after the footer… there is no “next record”. Or maybe I didn’t fully understand what you wrote 
Heinz, The point is that GroupTotals or CREATETOTALS change the decimal value in your record, and as this decimal value is part of your key, the systems starts jumping around in the records and does not maintain the initial ordering. As you say, there is no “next” record, because the total that has been calculated on the last record exceeds any other decimal value in the table, so when trying to move to the next “decimal value”, it returns next=0, because there is no higher decimal value in the table that has just been summed up for the total. Of course, the easiest way to solve your problem is to sum up the decimal values in a seperate variable and not via the built in functionality (GroupTotal, CREATETOTALS). Saludos Nils
Nils, I still don’t seem to get it. (Maybe I’m a bit slow today Let’s say I have a bunch of records sorted by some field (which is also to be summed up using the CREATETOTALS feature). The report loops over these records and, for each record, prints its original field value into the body section. There is a single footer section to be printed after all single records have been printed (that’s what I meant with “no next record” - once the footer is printed, we are done). Now, do you mean that after the current record has been printed, the field value of the previous record is then added to its own field value, thus building the sum of all values in the record which was just printed? (At least this is the only way I can imagine how things can possibly work [;)]) For record 3, record 2 would then already hold an accumulated value in its field and so on for all subsequent records. If this were actually the case, then things become clear - once the previous value is added to the current record, the current record moves to another position in the record set. I never trusted the CREATETOTALS function right from the start. I guess I knew why… [;)]
Hello Heinz, you’re almost there… [;)] though I am also assuming on how Navision handles this summing up - in any case, you are correct that Navision uses internally the same fields of the records to build the sum, I guess after printing the value of the current record it simply adds the value to the xRec value, which itself is the sum of the records before… When you take a simple report, with a simple footer, omit the summing, and add a total field in the footer (e.g. amount), you will notice that the value in the footer is simply the value of the last record, therefore there must be some relation to the xRec in that internal summing. Saludos Nils