Important Information: In a live database with active users connected, changing an object multiple times or compiling all objects can cause data loss in NAV 2013 R2

Important Information: In a live database with active users connected, changing an object multiple times or compiling all objects can cause data loss in NAV 2013 R2

Rate This
  • Comments 38

You may experience data loss in Microsoft Dynamics NAV 2013 R2 in the following situations, separately or in combination:

  • Changing an application object more than once, for example by two different developers, in the same database connected to the same Microsoft Dynamics NAV Server instance while users are working in the system.
  • Compiling all application objects, and thereby potentially changing objects more than once, in a database that is connected to a Microsoft Dynamics NAV Server instance that users are accessing.

To avoid the problem, we advise that you work according to the following best practices:

  • Application developers must be working on their own database and connect to their own Microsoft Dynamics NAV Server instance. When you deploy changes to the live production database, make sure that no users are working in the system.
  • You must compile objects only when no users are working in the system, including users connecting through NAS. 

With update rollup 5 for Microsoft Dynamics NAV 2013 R2 - KB 2937999, this issue has been fixed and you do not have to take the precautions described above. However, we still advise that you separate development from production databases.

Please note that implementing update rollup 5 will require a database conversion.

 

 

Leave a Comment
  • Please add 8 and 1 and type the answer here:
  • Post
  • This information comes too late. We run four projects on NAV2013R2 this year. We lost data on two of them on PRODUCTION databases in first days after GoLive. Customers lose trust about the NAV. This was the first time in 10 years I experienced this.

  • It feels like its getting worse and worse. Really. Have you considered to take measures to mitigate this unhealthy mixture of bugs, bad design decisions, and lacking eperience? From the RTC on (NAV2009! Released in 2008! 5 years ago!) it is a real risk to sell this product to customers. It is dangerous to your reputation and definitely a business risk. The risk is ranging from performance issues, over business logic errors, to half-baked design decisions leaving you with unusable functionality, and demands by your customer to fix this mess - which could easily bankrupt you. There is a reason that RTC-based product isn't selling well. Add to this really bad fuckups like this one...

    Until NAV2009R2 we had at least a Classic Client where the quirks were known (and weren't so catastrophic). You could create good, workable, easy to maintain solutions with this. And you could fence in the dangerous parts of the product so that you had a pretty stable production system. Now, everything appears to be shot. Talk about Scrum, KanBan, Rapid Release Cycle... doesn't appear to improve things. So what are you doing to clean up this mess?

  • Can we be really sure this severe bug does not apply to earlier RTC versions as well? Did you test that?

  • In case of projects with web services activated, need to be stopped in case of compiling?

  • Hello

    What happends if you import at new object set?

    Is it the same problem?

  • @Daniele Rebussi: Web Services are also considered users.

    @Natalie K: Yes we can be sure. This only applies to NAV 2013 R2 and only if you are doing development in a live production environment.

    @Aleksandar Totovic: I am sorry you had to experience this. We are doing all we can to fix this issue as quickly as possible.

    @Martin Honoré: If you need to compile the imported objects in a live production environment with users working, then there is a risk that you will experience the problem.

    Best regards Martin

  • Lets say it I'm the only developer and I only work with document reports. Will there be an issue then?

  • @Capone: If you are the only user connected to the database, then there will be no issue.

    Best regards Martin

  • Quote: "With the next update rollup for Microsoft Dynamics NAV 2013 R2, this issue will be fixed and you do not have to take the precautions described above"

    Sure?

    Quite sure?

  • .. and only if you are doing development in a live production environment.

    WRONG.

    As you say this also applies if you compile objects in a live environment.

    This happens if the build number you do your development on isn't EXACTLY the same version as the version in live.

    So we have now have to make sure the objects are EXPORTED from the customer test, DONT use the same fob to import into live.

    Because we aren't activly developing in that database we haven't lost any data yet; but it's been close!

    Overheard with a deaf ear ... "WTH is this? Did they do any testing?"

  • what can I say? quite the same: This information comes too late. We run 2 projects on NAV2013R2 actually. We lost data on two of them on PRODUCTION databases in first days after GoLive. Customers lose trust about the NAV. This was the first time in 14 years I experienced this.

  • @Robert de Bath: Quote "This happens if the build number you do your development on isn't EXACTLY the same version as the version in live. So we have now have to make sure the objects are EXPORTED from the customer test, DONT use the same fob to import into live".

    We have not identified any issues in relation to .fob import as described here. If you know something that we don't then please contact MS Support ASAP.

  • @Martin Nielander: I would assume that there is an issue with different build numbers dev <> live. The NAV dev. environment automaticlly triggers a recompile in this case on import, doesn't it? When you do this on the live system, it would come near the scenario where you're saying it can cause data loss.

    with best regards

    Jens

  • What is the coverage of data loss?

    Are there whole records lost, or only some data in fields?

    Are there inserted records affected or/and modified records?

    How many data can be lost? Since last compile, since last login, ... ?

    We will be glad to get some feeling of our risk at GoLive in Production.

  • Folks,

    Let me see if I can clarify this a bit.

    Until we have the fix out, the safe way to isolate you from any risk, is to avoid changes to a live system.  If you need to do a change, make sure all users (or to be precise: all sessions) are logged out – this includes any type of session, being RTC, web-client, web-service, NAS-sessions or other developers.

    I would like to share a more detailed picture of what was happening.

    The bug is an unhandled race condition combined with an update of one or more metadata records (which C/SIDE updates by deleting the metadata record followed by an insert of the new version).

    If all the following is true:

    1) You do a change in C/SIDE, which in turn will delete a row in metadata table 2000000071 followed by an insert of the new row in 2000000071

    2) The change of table 2000000071 is detected by the server which flags all tenants as “need to be checked at next access”

    3) An active user request some data from the tenant tables, which triggers a sync operation

    4) The sync operation now reads all rows from table 2000000071

    The worst case scenario is when the read in step (4) just happens to hit the point exactly between the delete and insert in step (1) of either this change or another change we might encounter a situation where we falsely detect that a table has been deleted and hence we will drop the actual data table.  A few milliseconds later we will discover that the table has been “recreated” and we will re-create the data table but of course as an empty table.

    I would say that the chance of hitting this split second is very slim.  Actually it took quite an effort to write test cases provoking  this situation (could even occur.

    In other less severe conditions the metadata might be updated while a sync operation of a previous change is taking place which might leave the database “unmountable” but in this case all data is intact when the situation has been cleared up.

    The majority of reported issues has been related to “index out of sync” situations, which could be a result of the above bug but also result of earlier situations or even manually created indexes. The problem is if a field is included in an index not known to NAV.  If this field is attempted deleted, the operations will fail since the field is used in an index.

    The hotfix we are just about to release, will fix the race condition scenario described above and recreate missing/wrong indexes.  It also allows certain inconsistencies to exist during a sync operation (e.g. we are just about to delete an index, and we discover it is not there).

    Thomas Hejlsberg

    CTO - Architect

    Microsoft Dynamics NAV

Page 1 of 3 (38 items) 123