Old versions are not cleared in NAV 2013 R2 Rollup 6

Marco_Ferrari

Hi, I'm experiencing a problem with NAV 2013 R2 rollup 6: on my PC I had a database that I used during one of my development courses. On this database I added some fields in some tables, modified some reports and so on. After the course I deleted the database and created a new one making a restore of the original SQL backup of the DVD. The new database has a different name than the one used in the course and I also changed the NAV service.

Now when I run some objects, NAV stops and tell me that he cannot run the object because the field 50000 is not in table xxx etc. He sees all the modifications made during the course! I don't really know where to see and what to delete... I recompiled all the object, I recreated all the application objects, but this did not solved the problem.

Does anyone knows how to solve this problem?

Thanks,
Marco

SiSt

Maybe a stupid question, but you tried to restart the services?

rsaritzky

There is a new option under "Tools", "Options" in the NAV2013R2 development environment - "Prevent data loss from table changes".

The default value is "Yes". Change it to "No".

I'm still not 100% clear on what this option does, but one thing I know it does is prevent objects from being updated.


Ron

JohnHunter

Never-ever change “Prevent data loss from table changes” to “No”.

http://blogs.msdn.com/b/nav/archive/201 ... 13-r2.aspx

Rob_Hansen

That would be fine and good if the product didn't still have an issue causing the error "The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state" to occur in some scenarios. The only way we are currently able to get around this is to turn the property off (realizing the risk of data loss...but this is in a development environment). I've been waiting ages for Microsoft to address this issue.

rsaritzky

I agree. It would be great if we didn't need this workaround. But the developer best practices section of the above article can be difficult to follow from a practicality standpoint. My reading of this is if you are in a development "mode" and working with one or two users, it seems reasonable to turn the option to No. But we've had issues (even with later builds) where we make changes to objects offsite and then try to import them into customer's databases.

Ron

Marco_Ferrari

I solved it. The problem was not the old modifications made to the database, but the settings of the programs, as the default date on a report or the filters applied to a page. In the classic client those information were stored in the zup file. With the role tailored client they are stored in an XML file called PersonalizationStore. I simply renamed the file PersonalizationStoreOld and now the client runs correctly.

Marco