|
Prior to this service pack it was possible for an invalid amount to be stored in an index record. NewViews has continuous integrity checking and this integrity checking would subsequently encounter the invalid amount and would report it as a bug. The particular bug that was reported depended on the operation currently being performed, but the underlying cause was always the same; on-going integrity checking had detected the invalid amount that was originally stored in the index record during some previous operation.
Typically the bug was reported when deleting a transaction, when re-totaling an account, or sometimes, just by displaying a table. The integrity of index records is checked under all of these circumstances so the problem would appear to occur under different circumstances.
The invalid index record amount would also be detected by nvcheck. Either the third (index record integrity) or the fourth (index record references) check might detect different variations of invalid index records.
nvcheck may still detect the problem if invalid amounts were introduced into a database when running a version of NewViews prior to service pack 3, since the invalid amounts will still be in the database. Running nvcheck will determine if this is the case.
nvreorganize will fix the problem.
The problem did not compromise the integrity of accounting data. Invalid amounts introduced by the bug were limited to index records which are auxiliary to the original data entered into the database.
The problem was relatively rare and would make nvreorganize appear to hang near completion of either the first or second progress bar. In fact, nvreorganize had encountered an exceedingly large block paste buffer and was taking an inordinately large amount of time to process it due to a correct but inefficient algorithm. This algorithm could also result in failure due a memory problem in underlying software.
This problem in nvreorganize has been fixed and should not recur.
Entering 36-12 resulted in value -3612 instead of the expected 24. NewViews negated the number each time a minus was encountered regardless of where or how many were encountered, except in more complex expressions. Now the number is negated in this way only when encountered at either end of the entered value and the result returned in the example above is 24 as expected.
This release includes all corrections from Service Pack 1 and Service Pack 2. New features and corrections issued in the initial 2.08 release can be found here.