quote:
Originally posted by jordi79
well i have a 8GB installation with 20 users on MS-SQL. customisation is quite heavy, and whenever we tried to open a form with a lot of flow fields, it tooks us 5 seconds. but when we port the database to native c/side, the whole system froze when we tried to open the same form. the system started “counting records”, and you can see some numbers enumerate in the status bar. in this instance, it is clear that SQL is better.
It’s because you’r NSC don’t pay attention for correct building flowfields. Same problems with our NSC. They a fans of “SQL Server Option” programming! [:D] Check your keys at tables where such fields counting! You can use Client Monitor to find out what keys Nav. using during calculations.
Hi Heinz, I have to agree with Konstantin, you can not say that Navision is at fault, just because of poor program skills.
Peter, then consider trying a 3.10A C/SIDE client and looking at changes to this batch job in the 3.10A application code.
Hi All, After I have been reading this post, there is still one question I can’s seem to get an answer to. In a Native DB, if you have for e.g. a 60 GB Database you use like 15 harddrives (60/4GB) for performance issues. It I would to convert such DB to SQL, how many hardrives / processors will that require? Any comment / input would be highly appreciated… Thanks
there is a lot of information to be found by searching this forum with key words sql and performance. you will need at least as many drives in sql, but depending on the number of users, probably more, and the configuration is quite different. the answers to the following questions may help: database increase per month, no of active users, no of key transactions eg sales invoices and lines per invoice core business use in navision eg manufacturing warehouse bins etc serial numbers and dimensions.