performance difference 3.01 vs. 3.7

We are upgrading from Attain 3.01 to Navision 3.7. We notice that the response times of the 3.7 system overall is less then with 3.01. We are running 3.7 on the same SQL server as 3.01. Does 3.7 ask considerable more resources then 3.01? Gerrit Zanen

There should be only improvements, for the same application code. What exactly is performing slower? 3.7 has limited its resources - meaning client and SQL server memory usage - since 3.01 where it was using far too much on the client. OK, this could have an affect on very long running batch jobs because there are less cursors held open by the client - but it should be very small - really not noticeable. Can you give more details?

We have solved the puzzle. The converted database needed to be optimized. After the database was optimized we had our normal response times. Gerrit Zanen

We observed the same “SQL is slower after an upgrade” behavior on an upgrade from v2.6 to v3.6. The customer had created a report to list all customers and their “Balance (LCY)” (a flowfield). In v2.6 SQL, this report ran in 15 seconds across 17,000 customers and 168,000 customer ledger entries. Right after the upgrade, the report took over 8 min. to complete. After poking around a bit, we ran the Optimize operation on the Customer, Customer Ledger Entry and Detailed Customer Ledger Entry tables – and voila – performance returned to pre-upgrade times. It seems that SQL statistics were missing from the primary key of the SIFT tables after restoring from an fbk. To see this, compare DBCC SHOWSTATISTICS output on the primary key of a v2.6 SIFT table vs the same v3.6 table, immediately after restoring from an fbk. We remain mystified why a v2.6 restore creates the necessary statistics, but the v3.6 restore does not. However, the Optimize operation (? = DBCC DBREINDEX ?) adds the missing statistics back. So, now we must remember to do this step after every SQL restore operation (and have to remember to remind our customers to do likewise). Fritz Brande