Reasons to move from NAV 2013 to NAV 2013 R2

alex9 · 2013-11-11

I am reading R2 release documents and some opinions people are sharing here, and cannot find enough reasons to move from NAV 2013 to NAV 2013 R2. So far, I just see new limitations, not improvements, for example:
- Dev Environment must be installed on the same machine as a mid-tier (not the case in NAV 2013);
- NAV 2013 and NAV 2013 R2 are not fully compatible when installed at the same machine, and some tricks like changing registry are required;
- Copying data between database is getting more tricky as fbk is not an option anymore;

So, what are the benefits for developers and for clients? What do you like most in R2 comparing to NAV 2013? I really want to know. :?

Rob_Hansen · 2013-11-11

Microsoft plans to address the second and third issues in your list. As far as I know the first one (dev environment on same machine as service tier) will continue to be a limitation though. (I'm hoping that changes as well...but haven't heard of it yet)

Alex_Chow · 2013-11-11

Just to answer your question, no. There's no reason to move to NAV2013 R2 if you're on NAV2013.

I would revisit this path when Microsoft releases NAV2013 R2 hotfix 6.

alex9 · 2013-11-12

Alex Chow wrote:

Just to answer your question, no. There's no reason to move to NAV2013 R2 if you're on NAV2013.

I would revisit this path when Microsoft releases NAV2013 R2 hotfix 6.

Interesting... Are things really so bad?

kine · 2013-11-12

As each time - who want to upgrade, will find why, who doesn't want, will find why not.

E.g. much better webclient, addins on both (win and web client), writtable OData (if you need them)... all depends what you need, what you can use, what you are using now, what you will use in the future...

And the first is not true... you can have dev env on different machine too...

andrewt · 2013-11-12

The most benefit in R2 I found from the user's perspective is the sorting behaviour on list pages.
Like known from AX since years, you can now change the sorting of a list page by simply clicking on the header of the column you would like to get the list sorted by.
Current sorting is displayed by a small arrow at the header of the column which owns the active sorting.
This is possible for ALL columns available on the list page - you do not need a sort key.

I think it's these simple things that make the difference...

Cheers
Andrew

Rob_Hansen · 2013-11-12

Kamil - is that a recent change (dev environment on a different machine than the service tier)? Everything I had read said that the dev environment had to be on the same machine.

Good point on the column sorting. Such a little thing, but one users will love. I had a customer request that just last week (they are on NAV 2009) so it's one supporting argument for an upgrade.

alex9 · 2013-11-12

kine wrote:

As each time - who want to upgrade, will find why, who doesn't want, will find why not.

E.g. much better webclient, addins on both (win and web client), writtable OData (if you need them)... all depends what you need, what you can use, what you are using now, what you will use in the future...

That's absolutely true. That's why I created this topic, it may help to create Top 5 or Top 10 best features of R2 based on real life experience. MS release notes and other supporting documents are not informative enough for this version, in my humble opinion. For example, I didn't find any reference to that new page sorting feature (which is really cool), mentioned by andrewt, unless I am missing something.

In any case, if people will share their favorite R2 features (or fixed bugs) here, this will help others. Issues and problems will appear in other topics anyways

thegunzo · 2013-11-13

There is a problem with dev on one machine and middle tier on another. But there is a way around that.

http://www.dynamics.is/?p=1619

Kishorm · 2013-11-14

According to the nav techdays 2013 keynote video it is possible to have the development env on a separate machine to the service tier - you just need to set the service tier details in tools --> options

stefang · 2013-11-15

I think DEV environment has to be on the same machine as the NST or possibly on the SQL Server to do table changes. Changes to other objects can be done anywhere.

I have been using R2 for some time now and it is really cumbersome not to be able to do company backups (fbk). But the web client is really good in this version and for me that is the biggest reason for moving to R2. The sorting is also a nice addition.

Kishorm · 2013-11-15

Download the nav techdays 2013 opening keynote video and go to 54:10 - the speaker does say this issue is not true. They refer to something they mentioned earlier - goto 30:30 and he says what to do if the service is not on the current box I.e. The development box.

This is simply down to Microsoft not explaining what needs to be setup - they admitted this in the mythbuster section of the video. Not sure why they didn't post the answer here in Mibuso though!

Alex_Chow · 2013-11-15

The problem is that it doesn't do any data validation when you use the dev environment that's not on the service tier.

So you can be doing a lot of coding, then run into a ton of errors when you try to import the object to the client site.

Basically, think of this as if you were doing development on the client database without any data in it.

Kishorm · 2013-11-15

Are you referring to the option that allows you to skip the data integrity checks? I'm not referring to that but to the service tier settings in the options - if you set this info then the dev environment gets the service tier to do the data checks (e.g. that data won't get deleted) I.e. the stuff that it used to do directly in SQL itself.

I haven't used 2013R2 myself but this is what was said in the keynote.

Alex_Chow · 2013-11-15

Kishorm wrote:

Are you referring to the option that allows you to skip the data integrity checks? I'm not referring to that but to the service tier settings in the options - if you set this info then the dev environment gets the service tier to do the data checks (e.g. that data won't get deleted) I.e. the stuff that it used to do directly in SQL itself.

I haven't used 2013R2 myself but this is what was said in the keynote.

Yes, that's what I'm talking about. My understanding is that if you set this option off, you don't have to work on the service tier? Is that not the case?

So basically, when you e-mail an object to the customer, they will need to RDP into their service tier computer to import the object.

Kishorm · 2013-11-15

You're right in that turning that option off will stop the dev env from trying to use the service tier to check whether data will be lost but I think this is a bad / dangerous idea. I would suggest you leave that option as it is - the problem with this is that if the dev env is not on the same server as the service tier then you get an error. To avoid this you set the other options in tools/options to tell the dev env where the service tier is, this way when you make any table changes the dev env can get the service tier to do the checks even when the dev env is on a different machine to the service tier.

Well, I'm sure this is what was said in the "mythbusters" section of the keynote - although it was late when I watched it :-)

ThomasHej_MSFT · 2013-11-15

Kishorm, you are absolutely right - that was what I said.

So the short answer is: The NST does not need to be on the same box as C/SIDE.

Here is the (long) detailed explanation:

Let’s assume you are deleting a field from a table and you press CTRL+S (save), this is what happens:

1) C/SIDE will check ProtectAgainstDataloss is turned on (as set in Tools/Options).

If not, metadata will be saved and C/SIDE will not attempt validation, but leave the rest up to the NST at first opportunity (either immediately or at next mount). This does not mean that any change is enforced, but simply that C/SIDE will not check before saving the metadata. Depending on how the tenants are mounted on the server(s) you are still protected against deletion of a non-empty field.
Anyways, assuming the ProtectAgainstDataloss is on…

2) C/SIDE will check if any of the Server/Instance/Port/Tenant/Company etc fields have been specified in the Tools/Options

If so, C/SIDE will try to connect to the specified server
If not, C/SIDE will look into the server-instance table in the App Database (the one that C/SIDE already “talks to” that also contains the application) – in here is expect to find at least one NST that is connected to the server and that NST in turn will know the tenant database, default company etc.

3) C/SIDE now try to connect to the NST

If the NST is not on local machine, you will need to be a NAV user in the database – and the only authentication-mechanism that works here is windows authentication.

Provided a successful connection is established C/SIDE will ask the NST if there are more than a single tenant mounted. This translates into two options will allow the check to be done: A legacy configuration with only a single database containing both App+Data or a multi-tenant system but with only one tenant mounted (a single App database and a single tenant database).

If the number of tenants is not exactly 1 – the NST will refuse to do the check and C/SIDE will show an appropriate error.

Provided we have only 1 tenant:

4) The NST will check if the field is empty

If not, an error is returned to C/SIDE that will show the error.

Otherwise:

C/SIDE will save the metadata in the two metadata tables (2000000001 and 2000000071) and do nothing more.
The NST will immediately pick up that a metadata change happened (typical RAD scenario) and will do the schema-change.

I hope that clarified the mechanics of this scenario.

Thomas (Mythbuster) Hejlsberg

dmc-dk · 2013-11-16

Alex9, to answer to your original question (and I bet you have seen it already) these links were meant to explain the changes on the dev and app sides in R2:

http://msdn.microsoft.com/en-us/library ... 7(v=nav.71).aspx
http://msdn.microsoft.com/en-us/library ... 4(v=nav.71).aspx

Would indeed be interesting to collect the real life arguments to move to it, which are missing on these pages and which could be added there.

Kind regards,
DMC

Kishorm · 2013-11-16

Thomas, thanks for that detailed explanation - hopefully this should clear up a lot of the confusion around this area. On a related note, you said that a "mythbuster" document for 2013R2 would be available to download soon - is this available yet?

Regards
Kishor

P.S. Great opening keynote - very informative

Michael_Nielsen_[MSFT] · 2013-11-20

The document will be part of the NAV 2013 update 1 release which should be availible for download on partner source this week

Michael

Alex_Chow · 2013-11-20

"Michael wrote:

"]The document will be part of the NAV 2013 update 1 release which should be availible for download on partner source this week

Michael

You said that last week...

Michael_Nielsen_[MSFT] · 2013-11-20

I know:) validation has taken a bit longer

alex9 · 2013-11-20

One of the reasons for all those confusions is information in "Release Notes for Microsoft Dynamics NAV 2013 R2". I assume this is official document:
https://mbs.microsoft.com/downloads/cus ... lingTables
It reads: The development environment and Microsoft Dynamics NAV Server must be running on the same computer.

The issue could be considered as a myth, but it still does exist in the official MS document.

ThomasHej_MSFT · 2013-11-20

Michael and I discussed this briefly and we both would like to share the followup document that we mentioned in the keynote.

Here is a link to the document (pdf file): http://sdrv.ms/1fWiW9Q

If the link does not work, it is because the document has been officially released and you can find it elsewhere.

Thomas

alex9 · 2013-11-22

Thanks a lot, this document is very helpful.

TonyDuarte · 2014-07-30

It is ok to move to 2013 R2, but only if you plan to move already to at least the Cumulative Update 6.

There are a few "grave errors" that can occur, for example loosing complete data from tables.
It's easy to find everywhere dev's complaining about this issue, and a few other problems.

The Dev vs. Application in the same machine is that there are some cases were you loose sync from dev to application and you'll receive an error so that's why it's was recommended for people to install dev in same machine as app server.

Howdy, Stranger!

Quick Links

Categories

Reasons to move from NAV 2013 to NAV 2013 R2

Comments