Upgrading issue

summerzz

i have a doubt. As we know, NAV 4.0 etc are all in 2-tier architecture...while new Nav will be in 3-tier architecture.

Since the architecture is different, is there any chance of upgrading or will there be re-implementation involved for customers choosing to move from Nav 4.0 to Nav 5.0?

kriki

Some (short) time ago MS decided to split up 5.0 in 5.0 and 5.1.
In 5.0 Navision will have some new goodies and new functionality,but the 3-tier architecture will not be there.
Only in 5.1 Navision will be 3-tier.
Check https://mbs.microsoft.com/partnersource/products/navision/newsevents/news/phased_launch for more info on this.

summerzz

thats right, should be Nav 5.1

so i was just thinking, let say upgrade from Nav 4.0 to Nav 5.1 , will the changed in architecture mean re-implemenation compare to normal upgrading process

Marije_Brummel

IMHO upgrading should always be treated like a (small) implementation.

Biggest issues you will face when wanting to use the new client is upgrading to SQL, which means you'll have to do some tuning and you'll need to think about the roles in your company to use with the new client.

davmac1

My understanding is 5.1 will offer 3 tier in addition to 2 tier. It sounds like we can use both at the same time.
Since 3 tier will use a dll, there will be no more quick changes, we have to compile everything.

Captain_DX4

Mark Brummel wrote:

IMHO upgrading should always be treated like a (small) implementation.

Totally agree. You always end up with new functionality that requires setup or new options that need to be added to security. Upgrading is hardly ever "set it and forget it".

Captain_DX4

davmac1 wrote:

Since 3 tier will use a dll, there will be no more quick changes, we have to compile everything.

And I say that is a GOOD thing, for the most part! *wink*

Alex_Chow

Captain DX4 wrote:

davmac1 wrote:

Since 3 tier will use a dll, there will be no more quick changes, we have to compile everything.

And I say that is a GOOD thing, for the most part! *wink*

At Directions, they said that it was something that they're working on changing. A lot of partners expressed concerns that you're no longer able to do quick changes.

Microsoft also said that if you use the standard Navision database, you won't get the dll compliation problem. So guess what? Native Navision DB it is.

summerzz

compiling? Then will it invovled a change in source code? As far as i know, the way a program is written for 2-tier is slightly different from the way it is written in 3-tier...

Waldo

This is the way I understood it:

5.1 has a new client. This client ONLY works on 3-tier functionality. If you decide that the database server (SQL Server) and the service tier (IIS) runs on the same box, then you still have a 3-tier architecture. This means, that the new client would only run on SQL - and you need te incorporate some SQL tuning, like Mark said.

An upgrade to 5.1 should be as you always upgrade, but then some extra things to take into account. You'll still develop in C/SIDE, so you do your upgrade like in C/SIDE (as you know). Furthermore you should "upgrade" your forms to "pages". This means: no more business logic behind the forms (imho, this is the main reason why the redesigned the item tracking functionality in 5.0). So, I don't see a big issue in upgrading to 5.1. It's just like before, just a little twist to the pages.

I can confirm the statement of deadlizard saying that MS is working on the fact that "quick changes" should still be possible. I also heard this at Convergence.

But again, this is the way I understood it in March at some meeting I had with microsoft. Things have changed since then ... so I don't know if this is still the whole thruth ... 8)

Miklos_Hollender

No more business logic behind forms? That might be bad news.

Basically, I think Microsoft is moving towards the MVC concept, when the data model, the application logic ("controller") and the presentation ("view") are completely separated. This approach has several advantages, basically, it allows different presentation of the same data and logic (on a form, on a report, on the web, in an Excel export) etc. The other advantage is that the application is much more maintainable and code is more reusable. If you ever tried to maintain a PHP application where SQL queries and HTML formatting are in the same file, you know what a big advantage can it be.

However, it makes small, quick changes harder, because you have to do them at two places. For example, in MSCRM, not allowing to save a record based on some criteria in some other record, requires writing a web service that checks that other record, returns the answer in XML and write the JavaScript code to the form trigger that checks this XML and throws an error message. In Navision, you could write it all to the form. Of course, it usually not a good practice, upholding the MVC concept in Navision, which means, writing code mostly to table triggers and codeunits, is generally preferable, because it's much more maintainable and flexible.

But. This all is only valid if we are talking about real developments - f.e. add-ons that we want to maintain for a long time, or heavy customizations for a big client who we expect to support for a long time. In these cases, MVC is a very good approach.

But life is life and sometimes one has to do developments, that are, well, not really developments. For example, you might have an asshole of a client who disagrees with some functionality, and is unwilling to pay to change it, because he's opinion is "you sold me a bad software, repair it". In this case, maintainability and flexibility are not the first concerns - you rather want to minimize your cost. In this case, you can throw a button to a form, quickly write ten lines of code behind it and forget it. I know this is not an ideal situation and needs to be avoided, but life is life, you cannot always pick your customers and cannot always convince them of their long-term interest. Some people are just a pain in the backside. Actually, it didn't yet happend to me here in England, but happened to me at most of the projects back in Hungary. Therefore I expect that part of the world outside the US and Western Europe might experience this problem frequently. And in these cases MVC is a bad concept - you want to be able to do as quick fixes as possible.

David_Singleton

Miklos Hollender wrote:

... . Some people are just a pain in the backside. Actually, it didn't yet happend to me here in England, but happened to me at most of the projects back in Hungary....quote]

NO !!! Basically it means that in Hungary you worked for an NSC that had no idea or concept of how to sell a product, but now in The UK, you work for an NSC that has intelligent sales people, that know what they are selling.

Don't keep blaming "Eastern Europeans vs Western Europeans" for the inabilities of the NSC. Hungarians along with the rest of the CENTRAL European people were opressed, but they are not stupid.

Also even if the sales people messed up the initital concept with the client, then the projet manager should have been able to quickly rectify this.

Waldo

David Singleton wrote:

Also even if the sales people messed up the initital concept with the client, then the projet manager should have been able to quickly rectify this.

Often (in the early days of a company), sales people mess up the concept ... promising something that is not (or difficult) possible in Dynamics. I think every company has to suffer this with new salespeople ... . It is not always easy for the project manager though to rectify this...

David_Singleton

Waldo wrote:

David Singleton wrote:

Also even if the sales people messed up the initital concept with the client, then the projet manager should have been able to quickly rectify this.

Often (in the early days of a company), sales people mess up the concept ... promising something that is not (or difficult) possible in Dynamics. I think every company has to suffer this with new salespeople ... . It is not always easy for the project manager though to rectify this...

I agree, I probably oversimplified by saying "quickly rectify", but more my post was in relation to blaming th e client for mistakes that really were the fault of the sales process, and then making the global statement that "Eastern Europeans" are bad, "western Europeans" are good. I have seen problems like this all over the world, The UK, Germany, THe USA, yes Hungary and Czech Republic, but you can't just blame the country.

Waldo

true...