issue with calculation

[Hans Nieuwenhuis]

Hi,

We are building a new solution and we use (unstored) calculations on several tables.

for two of these tables we used the same name for the calculation but the contents of the two calculations is different.

This gives weird results. It seems like the loop inside the method goes wrong and the result is wrong.

I gues the servoy answer would be not to use the same name twice (and I agree) , but could there be a test for this ???

Regards,

[rgansevles]

Hans,

Two calcs with the same name on different tables should not clash.
What kind of strange results do you get?
Can you show this in a small sample?

Rob

[Hans Nieuwenhuis]

It is in a big solution now, I'll see if I can build a small sample this evening.

The looping over a foundset within the calculation goes wrong.
It even seems that the calculation runs twice at the same time.

Code :

Code: Select all

function calc_verkoopprijs_totaalhn()
{
   var i;
   var _conr;
   var _tot;

   if(utils.hasRecords(bcom_full_ondh_contracten_to_ondh_contractregels))
   {
      _tot = 0.00;
      application.output('i= ' + databaseManager.getFoundSetCount(bcom_full_ondh_contracten_to_ondh_contractregels))
      for(i = 1; i <= databaseManager.getFoundSetCount(bcom_full_ondh_contracten_to_ondh_contractregels); i++)
      {
         _conr = bcom_full_ondh_contracten_to_ondh_contractregels.getRecord(i);
         application.output('regel= , ' + i + ',' +_conr.ondhconrgl_posno + ',' + _conr.calc_netto_prijs)
         if(_conr.calc_netto_prijs != null)
         {
            _tot += _conr.calc_netto_prijs;
         }
      }
      return _tot;
   }
   else
      return 0;
}

Application.output

Code: Select all

i= 181
i= 181
regel= , 1570,
regel= , 1580,0
regel= , 1570,0
regel= , 1590,0
regel= , 1580,0
regel= , 1600,0
regel= , 1590,0
regel= , 1610,0
regel= , 1600,0
regel= , 1610,0
regel= , 1620,0
regel= , 1620,0
regel= , 1630,0
regel= , 1630,0
regel= , 1640,0
regel= , 1640,0
regel= , 1650,0
regel= , 1650,0
regel= , 1670,0
regel= , 1670,0
regel= , 1680,
regel= , 1690,0
regel= , 1680,0
...
...


Application.output gives two (same) lines where I would expect only 1.
===> the line i= 181 should only be there once before the other output
===> The same numbers appear twice, this shoud never be the case


We renamed one of the calculations and the error has gone ...

Maybe Johan has an idea where this could go wrong ?

Regards

[rgansevles]

Hans,

Calcs are executed within the UI event thread, so they are executed after each other, not in parallel.
An exception to this is when calcs are calculated from a table view, in that case they can be calculated at the same time.
But then you need to show the same calc for the same record twice if they are calculated multiple times for the same record.

Why is it an error? Is the calculated total wrong?

Btw, you code uses databaseManager.getFoundSetCount() as a loop condition.
This can be very slow.
If the foundset is fully loaded, this call just returns foundset.getSize().
However, if the foundset is not fully loaded yet, this call generates an sql query for each run of the loop (foundsetcount is not cached).
It is better to use foundset.getSize() as loop condition.

Rob

[Hans Nieuwenhuis]

The calculation gives the wrong result.

And as You can see in the output, the code is not executed as expected.

Regards,

[jcompagner]

you calculation gives wrong results because you don't declare "i" as a local variable:

for(i=0;i<xxxxxx)

change that into

for(var i=0;i<xxxxxx)

Because you are sharing your loop variable over all methods/calcs

In 6.0 we added a warning for that.

[Hans Nieuwenhuis]

Hi Johan,

as you can see in the code at the top we do declare i

Code: Select all

function calc_verkoopprijs_totaalhn()
{
   var i;
   var _conr;
   var _tot;

  ....


[jcompagner]

ah missed that, but what is then exactly the problem?
the output you show me is not wrong, yes it is calculated twice and maybe +/- at the same time (when using it in a tableview)
But the output seems fine to me.

[Hans Nieuwenhuis]

The problem is that the result of the calculation was wrong as long
as there where two calculations with the same name ( different code en different tables )
(at least it seemd to be the problem)

When we changed the name of one of the the calulations the result was correct again.

Regards,

[jcompagner]

that looks very weird to me, there is no clash what so ever between tables with calculation names. (as far as i know)
(except when using none declared variables)

But if you have something that does reproduce weird results if you have 2 calcs on different tables with the same name, please make a case.

[Hans Nieuwenhuis]

Hi Johan,

These unstored calculations used other unstored calculations in related tables ( 1 level an two levels deep )

I gues that that caused our problem.
Most of the time the result of the calculation was wrong and also different when restarted.
I gues that has to do with the use of other unstored cals which are calculated out of sync with
the main calculation.

because the calculations used al lot of database roundtrips, I replaced them with
a stored procedure. Something that we use frequently and works excellent !!

Regards,

[jcompagner]

i still don't get what the actual problem was now
was it calling a calc from a different table but with the same name as the current one?

Or are you saying you have unstored calcs depending on each other and that one unstored should have been recalculated? But it didnt and because of that the other calculation that uses it didn't recalculate correctly?