Hmmm. I wasn’t quite clear in that old post. It’s true You get one cache for each file, but only if You put them on separate physical disks. And I wouldn’t say 75 users is to much for native DBMS, but it with so many users one have to lookout very carefully for locking problems (and make sure the server has very and many fast disks and controllers)

Calulation is simple: 150000 per 13 h workday => 3.2 transactions per s. on stable load, which don’t exists in real life. ~10 high load (posting orders, invoices …) sessions. Another isue is reporting. 36000000 transactions per year. Making such reports as Item Valuation will terrible thing.

I should clarify something; we sell schoolbooks, so we have a peak season in which these numbers occur, this only is for about two months, before and after the numbers are <10% overall

BTW Lars, what is better one big cache or two smaller, if total size is the same ?

Harmen it’s a good news. Maybe reporting will be better [:I]

Two smaller, since these can work in paralell. That’s the whole idea with splitting up the database on many files and disks. You get more s/w processes to take the load of the DBMS and more HW to work with the data. Read the appendix in the developers guide on the product CD. I think it will straighten out some questionsmarks.

Yes, two processes are able to get more CPU time. But if we are talking about situation where weakness is HDD write/read time. No matter, how often RAID controler are checked for availability. There is only one important thing - cache hit, which depends only on cache size. So, if we are talking about critical load and with low cache hit rate, CPU time is hopeless. Table locks decreasing cache refresh => cache hit rate is lower. Less locking isn’t only less lock wait times, but better cache hit too. Returning to Navision, NF 2.6 is more stable to table locks than NA 3.60. NA granules have more common data tables than NF. Dimensions is terror for perfomance. Harmen’s best solution is isolation of different kind transactions, it’s more effective than HW tunning. Maybe, Navision developers has never programmed in assembler as wasting HW recources [:(]