Selecting the right Navision Database

Hello, We’re preparing for a complete new implementation of Navision Attain and I need some advise on which database we should use. I have already searched this site for helpful information – there are lots of good advises (thanks) but most of it is somewhat old and can not be directly compared to our case. I have also talked to Microsoft and local business partners. But they are all “handicapped” by there own business preferences. I need some advice on which database solution (Native or SQL) is the best and if possible minimum HW requirements and basic architecture. Please point out any critical constraints for future growth as well as using data for BI and other business integration. The case: 170 companies – all running on a centrally based Navision Attain accessing via Citrix. We estimate 150 GB of data in 3 years 600 concurrent users distributed across the companies (simple users, doing simple invoicing using bar codes) In maximum work load (worst case): 600 concurrent users 40.000 transactions per hour (about 1 transaction per minute) Given the work load any delay of more than 1-2 seconds will be critical. Average work load (during 1 year): 500 concurrent users 4.000 transactions per hour Thanks, Henning

My preference is Native as it is very reliable, easy to manage og works fast. But with 500 concurrent users and 40.000 transacions/hour I would go for SQL!

With that number of users and that transaction volume I’d even suggest that you take a look at Axapta. If that is not a choice anymore, then obviously you need to go with the SQL option. You will need a HUGE server and a very broad network though. I found these minimum hardware requirement for Navision SQL: • 2-4 CPU’s • 2GB RAM • High bandwidth, well segmented network • 4-6 hard drives, NO RAID 5 • Use RAID 1 + 0 hth

You should really be looking for something else than Navision.

Maybe you can even use Navision Native database. If 600 users are distributed across 170 Navision companies, concurrency should be no problem. When usage is really simple invoice posting routines can possibly be optimized a lot compared to standard Navision. With a possible database size of 512 Gb the amount of data can be handled. When you use BI tools (which of course run on a separate database), native database can be a good solution.

Totally agree with Lars. You have to answer to many questions how you are going to cope wiht this volume whilst other systems (SAP,PeopleSoft,Oracle or may be even Axapta) designed to do so. Problems with Navision will start to appear after fifty concurrent users (or even less with your volume of transactions) and/or 40-50 GB of database regardless whether it is Native or SQL.

Andrei, how long are you working with Navision to give these answers? You posted somethings wrong in the “Sales & Pre Sales Forum” as well. On 31/07/2002 Alexander Schadow form NavisionDamgaard a/s presented a solution with 600 concurrent users (450 via Citrix, 150 ‘normal’ clients) on an Attain version on a SQL Server 2000. Clonclusion: do-able. The posting from Willy hits the point. Optimisation. (And I guess Lars forgot a smiley…) However, Alexanders proposal IS working.

OK. It might be do-able, but at a high risk in my opinion. I totally agree with Andrei. Navision is idaal for up to 100 users and databases up to 50GB. Above those volumes You have to be carful. There might be better solutions and better ways to spend Your time. If You are to run 600 users in Navision You need to do a very careful analysis of what these users are doning. It’s a big diference between posting orders and entering time in a job journal. Maybe some of these users doesn’t have to use the GUI och Navision. Let’s say You employees that only puts in working hours. Then You can have something maybe web-based outside Navision and let NAS take this data periodically and post it in Navision.

Walter, Enough to see quite a lot of projects screwed up because of database size and number of active concurrent users posting documents at the same time (especially this is relevant to SQL option). Regarding posting “something wrong” to Sales forum. It is relatively easy to compete with heavy ERP products on such customers like this one (cheap license fee, easy to customize, not that expensive consultants and developers), a bit of white lie that product can do everything, nice polished presentation from Navision/Damgaard and customer is yours. Problems start later - during implementation or early post-implementation stage. Main problem of SAP projects is undersales of professional services, problem of Navision is overestimation of its capabilities. This is product for middlesize companies not more. Yes, project might be do-able in ideal situation but the chances for that are quite miserable.

I’d say those are pretty aggressive figures, that will really tax a Navision Attain implementation. Of course, if you are super careful and really spend the time to look over the database construction and code, you can get great performance, but you will need to put a lot of time in, and you will need to get a NSC that is very experienced. By the time you are done with these modification, it could very well be cheaper to go with another solution that scales a little better upward. Unless you are stuck with Attain, I would say to look at another solution.