migrating from navision mbs 3.70

amaurys.torres

i need to know how to migrate from navision mbs 3.70 ,

1- i use still native bbdd management

2- bbdd size is 132 gb

3- the database dividied into 3 disks of 50, 40 and 40 gb

4- used space reached 68 % and grows 1 % every 3 days .

5- how can i compact or save space ? ( i am already optimizing bigger tables and it is working fine...)

6- pos is infostore, recommendations i got is to migrate to sql 2000, nav version 5.01 and ls retail as pos, any better recommendation ?

7- i manage a central office , a warehouse and 17 remote stores.

Alex_Chow

If you want to migrate to SQL, then use at least SQL 2005. Not SQL 2000 where it's going to be discontinued by Microsoft.

DenSter

You should go with the current version of SQL Server, which today is 2008.

garak

u should use the SQL Server 2005 (Lastbuild) or the SQL Server 2008 (LastBuild). I would use the 2008.
How to migrate a native DB to a SQL Server?

Read this link:

viewtopic.php?f=23&t=30050

David_Singleton

I would not migrate/upgrade to LS Retail. Keep your old Infostroe system running as is. Build a new Nav 2009sp1 / LS Retail system from scratch. Import ACTIVE ONLY customers and Items. Create journals for all your opening balances. Keep history in the old InfoStore DB and going forward the new one.

If it was any other system, I would always recommend to upgrade and bring all the data across, but from Info Store to LS is a big jump and you will make a mess of the LS database if you try to bring all the Info store stuff over.

generic

I would look at little further and move to another system. Maybe look at AX or GP.
Nav can't handle large databases.

If you do an upgrade, it will take a week of downtime and probably more.
Migration to SQL will take about half as much. 3 to 4 days of downtime.
You will need to get people to tune your Sql server.
Data Director is peace of $h*t in LS. You will need somebody to monitor it 24/7.
And who ever gave you the recomendation to move to sql 2000 with nav 5.0 lives under a rock.

KYDutchie

@Generic,

I just want to know, what your problem is with Navision? I have customers with 200Gb plus databases and they run fine! I just upgraded one within a weekend with time to spare (2.6 Native to 2009SP1 SQL2008, 150Gb Database). If you know what you are doing, you can easily upgrade a big customer database without problems and or down time.

I don't know if I am in my right to ask you this, but please do everybody a favour and stop posting only negative comments about NAV.

Thank you,

Willy

David_Singleton

KYDutchie wrote:

I just want to know, what your problem is with Navision?

Have you not heard the phrase "A poor workman blames his tools".

KYDutchie

David Singleton wrote:

Have you not heard the phrase "A poor workman blames his tools".

I have now! Amen =D>

I just cannot understand his attitude. There are many ERP products out there and they all target a specific vertical and or market segment. The choice of an ERP product should not be decided on database size, but on a best fit to the business processes of the customer. "Performance" issues can be fixed easily but chosing the wrong ERP product is usually a costly mistake and very difficult to correct.

"That's all I have to say about that." (Forrest Gump)

Regards,

Willy

generic

The tools are available, but MS NAV doesn't want to make them available. What tools am I referring to? SQL. This powerful tool is right under your nose but we can't use it in CAL.

NAV should have stopped releasing Native server when MS bought them and moved just to SQL.
This was ~5 years ago. They could have introduced new function to be able to write SQL query.
But no, now we are stuck with backward compatibility because NAV is supporting Native db. And they are still supporting it in 2009. What difference does it make to stop releasing it in next version and not in 2009?

I guess David, if you lived in Stone Age, you would still throw stones instead of using bow and arrow.

@KYDutchie
Not all Performance issues can be fixed easily. If they did, NAV would be supporting more than 50-100 users. And they would release white paper with hardware spec that you could duplicate at customer site.

viewtopic.php?f=16&t=35983

KYDutchie

:-# :?:

You can't argue with someone who has made up his mind.

generic

It's funny in every argument the subject changes to personal attack.
I guess you can't add anything useful, after all NAV is what it is, and there isn't much you can do with that.


As for making up their mind, look who is talking.


I'm sure many of you have many things that you would change in std NAV, but you don't because of conflict of interest. Mainly because NAV supports your living.

amaurys.torres

thank you all, very very much, all your replies are highly usefull for me, and yes,including the disagreements between some of you.

i will take my time to answer and comment some specific replies.

Eugene

NAV should have stopped releasing Native server when MS bought them and moved just to SQL.

The reality is as follows:
1) Microsoft bought NAV when it was version 3
2) some customers outgrew the maximum native database limit and had to migrate to MS SQL
3) Microsoft took very conservative way to migrate from native to MS SQL database and i belive they could not do it any other way SERIALIZABLE transaction isolation, C/AL code not optimized for SQL but for native etc etc
4) finally starting with NAV5.0 Microsoft managed to fine-tune the C/AL for MS SQL

Anybody complaining about Navision performance on MS SQL using version below NAV5.0 should upgrade to NAV5.0 or higher no matter which SQL server version (s)he uses (but preferably SQL 2005 or higher). And by upgrade i mean C/AL code upgrade