NAV 2009 objects for NAV 5.00 SP1 solution

clarasdk

Hi

We are currently have started development of our next version on a NAV 2009 classic. We now have a customer who needs some of these new developed objects for a NAV 5.00 SP1 database.

Is there are way to the our NAV 2009 database and downgrade it to 5.00 sp1? Or is it possible to export 2009 objects and import them into 5.00 sp1 somehow?

Until now we have had problems with errors when we have tried.

bylle

Hi!

I don't think it is possible to downgrade NAV 2009 to NAV 5.0 SP1 due to the new structure.

But NAV 2009 is basically a NAV 5.0 SP2 - so I think that it will be possible to move some of the functionality – as long it does not contain Pages, Reports with layout defined in Visual Studio or objects that has been transformed for the Role-Tailored Client.

Which functionality are you trying to downgrade? Which Errors do you get?

munib00

Try exporting as a Text. Then import. Then compile.
Importing into previous version from a NAV2009 fob will sometimes crash.

ara3n

After exporting it to text, you need to remove section that are added for 2009.

For example. reports have requestpage and RDLData section.

clarasdk

Is there anyway to make a script or something that removes the unneeded parts form the text file? Anybody have a quick way of doing that?

David_Singleton

Or upgrade the clients to 2009 Classic executables.

clarasdk

Upgrading the client is not an option because they have other systems connected to the database that only work on 5 sp1

ara3n

I'm guessing you understood that David suggested to just upgrade the executable not the whole upgrade.

This just involves, uninstall the client and install the new client. Same for NAS, and connect for the first time to sql db with sa user.

bylle

Since it is not possible for you to do an upgrade (I guess a technical upgrade is also out of the question) - you have to try to "downgrade" the code.

You can do something like this - where you first export the objects to text, then import them again in a temp table, removes 5.0 uncompatible code then writes the objects to text again:

Ex.

//Import the Text file containing the object
inFile.TEXTMODE(TRUE);
IF inFile.OPEN(Filename) THEN REPEAT

  inFile.READ(Line);
  CLEAR(txtObjects);
  txtObjects.Value := Line;

  //mark the different sections in the object

  case Line of
    '  OBJECT-PROPERTIES' : txtID := 'OBJECT-PROPERTIES';
    '  PROPERTIES'        : txtID := 'PROPERTIES';
    '  DATAITEMS'         : txtID := 'DATAITEMS';
    '  REQUESTFORM'       : txtID := 'REQUESTFORM';
    '  REQUESTPAGE'       : txtID := 'REQUESTPAGE';
    '  CODE'              : txtID := 'CODE';
    '  RDLDATA'           : txtID := 'RDLDATA';
  end;
  txtObjects.ID := txtID;
  txtObjects.INSERT;

  if line = '  }' then
    txtID := '';

UNTIL (inFile.POS + 1) > inFile.LEN;
inFile.CLOSE;

//Remove uncompatible section
txtObjects.RESET;
txtObjects.SETFILTER(ID,'RDLDATA|REQUESTPAGE');
txtObjects.DELETEALL;

//Export to file
outFile.WRITEMODE(TRUE);
outFile.TEXTMODE(TRUE);
outFile.create(COPYSTR(Filename,1,STRLEN(Filename)-4) + '_To_5.0.txt');
txtObjects.RESET;
if txtObjects.find('-') then repeat
  outFile.WRITE(txtObjects.Value);
until txtObjects.NEXT=0;

outFile.close;

The txtObjects table is a temp table containing of 3 fields, Entry No (an autoincrement), Value (Text 1024) and ID (Code 20).

This code is just an example - it does for example not consider the changes in the controls, such as the new control "DataSetFieldName".

clarasdk

ara3n wrote:

I'm guessing you understood that David suggested to just upgrade the executable not the whole upgrade.

This just involves, uninstall the client and install the new client. Same for NAS, and connect for the first time to sql db with sa user.

I understood and a "technical" upgrade is not an option.

The wierd part is that if I take a clean 5 sp1 database and import all the 2009 objects as fob there is no error. First when I restart the database it crashes. It is as if there is absolutly no validation on what is imported.

I guess I have to take the hard road and implement the Bylle solution, unless MS answers me back with some other solution (in which case I will post it here)

clarasdk

I just wanted to post a little update on the status for this issue.

We have been in contact with MS support and after a while they have given us feedback that it is not possible to downgrade objects from 2009 to earlier versions of NAV. They say it is because of the new 2009 runtime and so forth. But as we do not give up that fast we have implemented a version of Bylle's proposal (export as text, pass the text files and remove any new thing form 2009, creating a new text file and then importing it with NAV 5 sp1). This approach seems to be working. Furthermore it is only needed to pass tables and reports. Forms and Codeunits works out of the box. We have not tested dataports and xmlports yet.


We will continue testing this and when I am sure that everything is working we will be posting the tool for the community via Bylle's site.

In regards of the importing not working being related to the 2009 runtime is in my opinion not correct. I think it would be VERY easy for MS to either make an update to older clients so that they can read the new format (or just skip the stuff that is not needed) or at least make a downgrade tool. I will keep pushing this at upcoming Microsoft meetings in the Danish NAV community and via our PAM.

On a fun side notice I can tell that Bylle is actually working in the same company that I am so it is funny to talk with colleagues via the Mibuso forum also :P

David_Singleton

Clara you seem to be a little confused. You imply that there is some technical difficulty to convert the objects, and that this technical issue can be resolved. But I think in fact this is purely a marketing issue.

If Microsoft made it possible to use new functionality to run on old executables, then there would be less reasons for people to pay for maintenance. We could simply take every new object hot fix and downgrade to the old executables.

This would have a significant effect on upgrade funding, and probably would leave less funds available to develop new versions of Navision.

Don't get me wrong, I wish you luck in your endeavors, but I don't rank yur chances of success as high.

DenSter

I question the legality as well. The only reason I can think of to not do a technical upgrade is "we are not current on the maintenance fee". If that's the case, then I doubt that it is legal to use objects from newer versions and 'retrofit' them to older versions.

All in all, this approach is a disservice to the end user.

generic

First of all 2009 as MS has stated has no new features and functionally as 5.0 sp1. Thus any object taken from 2009 are bug fixes.

I have taken newer objects from newer version constantly for fixes. This is not a disservice to customer.

MS hasn't added any major new feature from 4, except jobs in 5.0. Major fixes service management or costing are fixes to a product that hasn't been working correctly.

They won't be adding any new features based on road map until version 8. SharePoint client is still a technical feature and not business feature.

MS has the option to control what feature would require a full upgrade by controlling it through license and by adding new objects.

So for the next 2-3 years, most customers will just do that get the objects (fixes) they need and downgrade them until their version is no longer supported and then upgrade.

So this whole disservice to end user argument is a joke.

David_Singleton

Once a customer stops paying the maintenance/upgrade/support plan they have no legal right to any bug fixes or enhancements. I am not talking about the moral issues in which case I agree with you, but from legal stance the bug fixes need to be paid for.

dmccrae

I wanted to add a few points.

Regarding the ability to import fobs from later versions (e.g. 2009) into earlier versions (e.g. 5.0), this will never be supported and will cause problems in general. For specific versions this might work by chance (as an example from 4.0 to 3.7) if the fob binary format did not undergo any changes, which is why I state 'in general'. For 2009 the format has changed significantly and will typically cause a crash or internal error if used by an earlier version. Supporting this scenario, where an old version can understand the format of a later version, would involve porting an immense amount of platform code back to the prior version which is a very de-stablizing and risky undertaking. The small demand for this would never justify the problems caused, and it will never be done.

It is correct that at import time the fob is not validated, so importing succeeds. It is only when the objects are used, that problems will arise.

Regarding the approach for changing the text format. If you remove any references to 2009-specific properties and AL code then you have essentially just created a simple 5.0 compatible text file. That might just have well have been done from scratch using a text editor rather than originating from 2009 (if I e-mailed you such a file, would you know it came from 2009?). So this should of course work but I am not clear about the motivation for doing it.

DenSter

My personal opinion is that when you purchase ANY software, you should be entitled to ANY patch that applies to your version, free of charge. So I do agree that what you're saying *should* be possible. Unfortunately, it is not.

The technical issues we're talking about are pretty easy to overcome, too. Any merging should be done on the text objects anyway, so I'd say that technically, for any NAV developer worth their salt, it's quite easy to get a text object file out of any version ready for any other version.

It's not a moral issue, nor is it a technical issue. It's a matter of licensing, and 'retrofitting' objects is against the license agreement.

generic wrote:

<snip>
I have taken newer objects from newer version constantly for fixes. This is not a disservice to customer.
<snip>
So this whole disservice to end user argument is a joke.

Essentially, when you take an object from a newer version and port those objects into an older version for a customer that has not paid for the legal rights to use those objects, is called "stealing", and where I come from that is a criminal offense. Stealing FOR someone else, however 'moral' your motives are, does not make it any less criminal, and at worst makes the customer liable for the same charges. To me, that is a pretty severe disservice.

generic

The motivation is that there is no document from MS that would say yes this is a support process and we recommend to run on latest executable. Every time I've suggested it, they have asked do you have some documentation on this.
Same about the security model. We have a customer that went live with enhanced mode, and we have told them that you will have issues with syncing, and they have been complaining about it taking 6 hours to sync. We have told them so many times to change to standard, but they keen on insisting that enhanced is more secure. So we can't find any documents that would tell the difference or compare the two.

Uninstalling the old executables and installing the new executables isn't an easy fast task for customers.
Clients view of an exe upgrade just like installing a new OS. Which means they will need to test everything they do and all the environments. Most IT department have your hands tied behind back when doing this.

So to make a choice between loading an fob and testing it in test environment and then load in prod, or doing an exe upgrade the will require a weekend of testing all the systems and integration and computers for compatibilities, removing 2009 tags from a text file is a no brainier.

generic

DenSter wrote:

Essentially, when you take an object from a newer version and port those objects into an older version for a customer that has not paid for the legal rights to use those objects, is called "stealing", and where I come from that is a criminal offense. Stealing FOR someone else, however 'moral' your motives are, does not make it any less criminal, and at worst makes the customer liable for the same charges. To me, that is a pretty severe disservice.

I will agree with the above statement the day MS will refund for a faulty product and lost revenue caused by bugs in the product.
If a car has a bug in it's program to hit the brakes on highway, I'm sure you will expect that from car manufacturer.

Obviously people will argue that software industry is different, but what would happen when MS first released USB functionality in windows it wasn't working correctly , and would expect you to pay to get the patch. And I'm sure MS would have charged if the market allowed it.

Almost all the bug fixes are result of customer opening a tech support incident. So there are KB articles that explain what the fix is. So taking the fix from a KB or from a newer version is no different.
If a customer comes to Mibuso and complains about a bug, and somebody provides the code for the fix, and that fix in future version of NAV would you consider that stealing?

DenSter

generic wrote:

If a customer comes to Mibuso and complains about a bug, and somebody provides the code for the fix, and that fix in future version of NAV would you consider that stealing?

If mibuso would have a policy that says "you get all the patches as long as you pay this periodic fee", and someone decides not to pay the fee because they feel they shouldn't have to, and they would take it even when they don't pay the fee, then yes I would consider it stealing.

I'm not arguing about whether the licensing model is fair or not, I've already agreed with you a number of times. Again, in MY opinion, ALL patches for your version of the software should always be free. The fact remains though that they are not, the license model is what it is. If a customer stops paying the enhancement fee, they forfeit their right to future patches, that's simply the way the model works. If you willfully supply objects that the customer has not paid for, then you can argue from here to Tokyo, but it will always be stealing.

generic

I thought the fees were for future release version not for bug fixes.

DenSter

The way I understand it you lose all your rights to any update, hotfix, patch, as soon as you stop paying the enhancement fee.

generic

Is there a document I can read about this?

David_Singleton

You can read the partner contract you signed, and the support contract you signed. All the information is in those.

clarasdk

David Singleton wrote:

Clara you seem to be a little confused. You imply that there is some technical difficulty to convert the objects, and that this technical issue can be resolved. But I think in fact this is purely a marketing issue.

If Microsoft made it possible to use new functionality to run on old executables, then there would be less reasons for people to pay for maintenance. We could simply take every new object hot fix and downgrade to the old executables.

This would have a significant effect on upgrade funding, and probably would leave less funds available to develop new versions of Navision.

Don't get me wrong, I wish you luck in your endeavors, but I don't rank yur chances of success as high.

I am not confused

There are problems if you want to import objects from 2009 into a 5 sp1. If you do it with fobs it will in the worst case smash up the database. If you do it with txt import you will get errors.

Just to get one thing clear. We are not doing this to cheat microsoft or anybody else. We are ONLY moving our own certified objects down and integrating them with a NAV 5.

In regards of the technical issues behind it, it was microsoft who told me that this is the reason. Personaly I think the problem is that Microsoft did not consider this issue and forgot to make atool for downgrae.

DenSter

clarasdk wrote:

Personaly I think the problem is that Microsoft did not consider this issue and forgot to make atool for downgrae.

Why would that be a problem? Why would any software company create tools to DOWNgrade? What is the sense in that? They're in the business of selling their latest version of the software, why would they want to work on developing tools to go back versions?

I think it is more probable that this "problem" lies somewhere completely different than Microsoft. What I think is that your company developed your product in the latest version, and you 'forgot' to consider that this might not be so easy to port to older versions. Perhaps what your company should do is develop your solution in the lowest common version that you wish to support, and UPgrade that solution to the highest common version. Microsoft even provided tranformation tools and upgrade toolkits for this purpose.

clarasdk

DenSter wrote:

clarasdk wrote:

Personaly I think the problem is that Microsoft did not consider this issue and forgot to make atool for downgrae.

Why would that be a problem? Why would any software company create tools to DOWNgrade? What is the sense in that? They're in the business of selling their latest version of the software, why would they want to work on developing tools to go back versions?

I think it is more probable that this "problem" lies somewhere completely different than Microsoft. What I think is that your company developed your product in the latest version, and you 'forgot' to consider that this might not be so easy to port to older versions. Perhaps what your company should do is develop your solution in the lowest common version that you wish to support, and UPgrade that solution to the highest common version. Microsoft even provided tranformation tools and upgrade toolkits for this purpose.

Well this is the first time that it is not possible to export/import objects without risking a database crash as fare as I know.

We have always had the policy to develop on the newest version and than use that as a baseline for hotfixes and so forth on older version also's. Thereby saving the need for multiple versions of codebase that is independent of the navision areas. On the navision specific objects we offcourse handle differnet versions.

And in regards of why would they build tools that will help moving things backwards. In this case the not being able to use our own objects in the versions we want to might actually lead us to stay on 5 sp1 longer. Eventhough we would like to use 2009 and I guess MS also would like us to. But then we will just have to way until all our customers are ready to use 2009.

But the good thing is that our conversion tool is working. And just to state it one more time. We are ONLY moving back our own codebase, not any thing from the standard.

raj_navision

Hi All,
After reading all this discussion I am curious to know if copying some functionality from other country specific database is also treated as stealing. For example: US database has KITTING functionality whereas Indian localisation doesn't have this functionality, so if someone copies this from US database, will it be treated as stealing?

Regards,

ara3n

copying localization from one country to another is allowed.
MS had released in one of their document on partner source.
I believe you purchase the granule and it's up to the solution center to renumber them.
the renumbering part sucks

nightrod

Hi,

are there technical differences between the objects of Nav 2009 and Nav 2009 SP1?
my devolpment is SP1, the client is nav 2009.
Can i import objects directly?

thx

kine

No, you cannot. SP1 have new properties on tables and pages. If you use them, you cannot import the fob into NAV 2009 w/o SP1