Navision vs SQL

Baz

My company is seriously considering buying Navision to replace our aging manufacturing software, and now the discussion is what database to run it on. As I understand it, Navision can run on its own database or on SQL. My first instinct would be to keep it on something that is standard (SQL) and will play nice with other applications, but I'm hearing that Navision on the native db is much more stable. Has anyone here had any trouble running it on SQL?

Any other advice, horror stories or comments would be much appreciated.

Thanks,
Baz

Sbhat

Hi,

I have done many SQL implementations and i havent seen any issues with Navision on SQL. The bottom line is SQL installation must be accurate and must be configured properly for Navision to run smoothly.

Thanks
Regards
SB.

shobha_sub

Long term, it might be wiser to go in with SQL. Considering the Microsoft takeover, the future of the Navision database is ... er ... a bit uncertain, to say the least

MuzzyDawg

Be aware that the vast majority of Navision database installs are on the "native" database. This is a tremendously stable and fast database...not to say SQL is not. However, "native" is certainly a faster database unless you start getting into larger user numbers and around 25 and up hitting it at the same time.

SQL also requires a bit more maintenance than the "native". As far as a benefit though, with SQL you can begin to take advantage of some of it's own functionality and even enable field level security within Navision. This is something that was not available previously unless you purchased the Lanham "add-on".

Either one is a good choice, but it really has to do with the number of concurrent users and what kind of maintenance staff you have in-house. Bother are extremely friendly in integrating with other systems so that's not really an issue.

Baz

Thanks for all your replies.

From what I'm hearing, the Navision db is really the way to go. We're looking at 10-15 concurrent users. I've heard one of the reasons Microsoft bought Navision was for some of the patented technologies in the database, which they will eventually incorporate into SQL. I'm also hearing there is a good, reliable utility that converts Navision to SQL, or SQL to Navision, should the need arise in the future. That make the decision easier.

Now all I have to do is convince the boss and write the check!

baz

MuzzyDawg

You're really in a win - win position with either database. The main reason I'd go with the "native" database is the lack of administrative issues associated with it that you'd have with SQL. The darn thing just plain works!

kriki

[Topic moved from Navision DOS forum to Navision forum]
I know! But better late then never

Mbad

May as well go SQL from the beginning. Native is dead after version 5.0.

Marije_Brummel

Mbad wrote:

May as well go SQL from the beginning. Native is dead after version 5.0.

This is not true! 5.0 still supports Native and plans are to do this also for future versions.

Moving to SQL however can be the wisest decision.

Waldo

If you're going to run the new Dynamics Client of 5.1 ... then it's a better idea to start migrating to SQL Server...

Miklos_Hollender

Actually you can get into performance problems with the native database with a low number of users too if 4-5 people are doing the same thing (like selling with just Invoices, like something sort of a POS). Native database does table level locking so while somebody is posting an invoice nobody else can do the same.

But I'd say go with the native first because it's easy to upgrade to SQL. It's just a question of backup and restore into SQL - OK, usually there is some tuning to do but that can wait, you can move from native to SQL overnight, so you can go with the native at first and see how it goes.

Marije_Brummel

Miklos Hollender wrote:

...Native database does table level locking so while somebody is posting an invoice nobody else can do the same...

SQL has a similar issue with transaction serilisation. Simultanious posting is a delusion.

Miklos Hollender wrote:

...because it's easy to upgrade to SQL. It's just a question of backup and restore into SQL...

Please. Never do this. :shock: There are many many code structures and index/SIFT issues even with NAV out of the box. Always review your code before moving to SQL and do heavy stresstesting.

Waldo

Mark Brummel wrote:

There are many many code structures and index/SIFT issues even with NAV out of the box. Always review your code before moving to SQL and do heavy stresstesting.

Amen ! O:)

Just spent a day of rewriting standard C/AL to optimize for SQL (MRP and purchase invoice posting - ](*,) ).
Difficult, but "doable"

DenSter

Miklos Hollender wrote:

...it's easy to upgrade to SQL. It's just a question of backup and restore into SQL ...

Which is a very clear indication that you have done this once, maybe twice, and were LUCKY enough to not run into any issues.

Waldo

Look at the posts on the SQL Server Performance forum
Look at the purpose SQL Sunrise
Look at my favorite: SQLPerform Tools and its purpose

Never underestimate the impace of a SQL migration

David_Singleton

Miklos Hollender wrote:

... Native database does table level locking
...

No. Actually Navision uses optomistic concurrency. When you do a forced lock, you are doing this for a reason, such as to prevent another user from getting the same invoice number as you. There is no way of getting around this with some other type of locking. You need to redesign the application.

Look at the Navision Turbo Add-On as an example of how to post without locking.

Waldo

Navision Turbo Add-On ??
You have a link?

Ian_Piddington10199

Mark Brummel wrote:

Mbad wrote:

May as well go SQL from the beginning. Native is dead after version 5.0.

This is not true! 5.0 still supports Native and plans are to do this also for future versions.

Moving to SQL however can be the wisest decision.

Thats interesting. I was talking to the guys from MS Singapore about 4 weeks ago and they indicated that from V6.0 the C/Side database would be gone, although C/AL would still be the development enviroment.

Ian

Marije_Brummel

:shock:

5.0 is only just released, 6.0 can be anything.

Lets not speculate and focus on 5.

Waldo

Indeed ... v6 is still too far away.
We talked to the development team of MS in San Diego, and they couldn't confirm that it wouldn't be supported anymore... .

DenSter

I can confirm that nothing has been confirmed

David_Singleton

Mark Brummel wrote:

:shock:

5.0 is only just released, 6.0 can be anything.

Lets not speculate and focus on 5.

Actually at Convergence they confirmed that at least the next two versions would support native DB, and it was stated at Tech Ed specifically that 6 would support Native.

Native still accounts for more than 2/3 of systems out there. And that means a lot of support revenue.

Yes move to SQL if you can and it makes sense, but if you are on Native, don't panic.

David_Singleton

Waldo wrote:

Navision Turbo Add-On ??
You have a link?

I really don't know who owns the Add-On now, it came from Iceland, but its so long ago I can't remember if it was Strengur or Landsteiner. I know that Dansoft were heavily involved though.

Mind you I was not suggesting take a look at the Turbo Add-On to use, I was using it as an example of what it takes to get around locking.

Waldo

Yes, but I'm always interested in solutions like that ... .
Google doesn't give me much, so may be this is out-dated ... ](*,)

David_Singleton

Waldo wrote:

Yes, but I'm always interested in solutions like that ... .
Google doesn't give me much, so may be this is out-dated ... ](*,)

Well as you know, Locking during posting is not "a Navision thing", its a part of the business logic. The big issue is to know the next invoice number, the next G/L ledger entry number, item ledger entry number etc.

The turbo module worked in batch mode. Thus the task running the posting did not need to lock, since it could just reserve the numbers it needed.

As you can imagine, even though the principle is simple, it was a HUGE integration with the base app. It was most useful where you have a team of order entry people that post invoices as they enter orders.

Waldo

I can imagine...
Thanks, David!

David_Singleton

Waldo wrote:

I can imagine...
Thanks, David!

We can discuss it further next month if you want.