Upgrading issue

summerzzsummerzz Member Posts: 29
edited 2006-11-24 in NAV Three Tier
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?

Comments

  • krikikriki Member, Moderator Posts: 9,086
    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.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • summerzzsummerzz Member Posts: 29
    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_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    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.
  • davmac1davmac1 Member Posts: 1,283
    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_DX4Captain_DX4 Member Posts: 230
    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".
    Kristopher Webb
    Microsoft Dynamics NAV Developer
  • Captain_DX4Captain_DX4 Member Posts: 230
    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*
    Kristopher Webb
    Microsoft Dynamics NAV Developer
  • Alex_ChowAlex_Chow Member Posts: 5,063
    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.
  • summerzzsummerzz Member Posts: 29
    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...
  • WaldoWaldo Member Posts: 3,412
    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)

    Eric Wauters
    MVP - Microsoft Dynamics NAV
    My blog
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    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_SingletonDavid_Singleton Member Posts: 5,479
    ... . 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.
    David Singleton
  • WaldoWaldo Member Posts: 3,412
    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... :|

    Eric Wauters
    MVP - Microsoft Dynamics NAV
    My blog
  • David_SingletonDavid_Singleton Member Posts: 5,479
    Waldo 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.
    David Singleton
  • WaldoWaldo Member Posts: 3,412
    true...

    Eric Wauters
    MVP - Microsoft Dynamics NAV
    My blog
Sign In or Register to comment.