Deleting Object Metadata, deletes data in all companies !!!

TomH_DK

Hi all,

I need to know if I am the only one that from time to time, deletes the records in Object Metadata, and recompile in order to have the Object Metadata "rebuilded" ?

Now working on NAV 2013 R2 this procedure has a catastrofic influence on the data.
Deleting a table record in the Object Metadata table in NAV 2013 R2, results in having all data in that table deleted as well, in all Companies.

I just deleted all records in the Object Metadata table and afterwards I have lost all data in all tables.

This is a warning to you, used to delete data i Object Metadata.
Does anyone knows if this is intended or something that have been changed to suit the Multitenant environment ?

Regards
Tom H

fitol

The Object Metadata table has DataPerCompany=No so what you do in that table affects all companies.
It has been so in all RTC versions. Nothing new here.

TomH_DK

I am aware of that, but still it is new that it deletes data in the tables that relates to the records deleted in Object Metadata.

If I delete record for Table 18 in Object Metadata, it will also delete all of my customers in table 18 in all Companies.

To my knowledge, it did not do that in versions prior to 2013 R2. (?)

mohana_cse06

You are right..
It was not like this before NAV2013R2..

It must be a :bug:

Marije_Brummel

Why do you delete metadata? Don't you trust NAV to do a good job?

geordie

Mark Brummel wrote:

Why do you delete metadata? Don't you trust NAV to do a good job?

A couple of times I had to delete object metadata since some modifications done on a table were not "reflected" by RTC and erasing them was apparently the only way to proceed.

mdPartnerNL

geordie wrote:

A couple of times I had to delete object metadata since some modifications done on a table were not "reflected" by RTC and erasing them was apparently the only way to proceed.

I have done this in response from ms too while an update didn't work. So this deleting of data is new to me too and must be a bug..!

Kowa

geordie wrote:

A couple of times I had to delete object metadata since some modifications done on a table were not "reflected" by RTC and erasing them was apparently the only way to proceed.

I had to do that in NAV 2009 often too, but in NAV 2013, the tool "Build Server Application Objects" was introduced in the Development Environment for this. That usually helps in these cases.
http://msdn.microsoft.com/en-us/library ... 71%29.aspx

arcull

Hi,
I wonder if there are any news regarding this problem. We experience the same problem on some installations of NAV 2013 R2 rollup2. But unfortunatelly the table record deletion does not happen on all databases and we can not idnetify what is causing this behaviour. Any feedback much appreciated.

JasminkaT

Just wanted to add a bit more info to this.
As you have noticed there was change in architecture in 2013 R2 changes the behavior when deleting records from this table directly (and not by compiling).
Direct removal of records will remove all metadata and all data.

We have added a limitation to address this, users will no longer be able to remove table metadata by deleting them directly from this table. Other metadata will still be removable.

This has been addressed in KB2907588, available on Partner Source

Regarding data loss, we might not have complete overview over the circumstances here, but similar issue was reported regarding system tables.
Upgrading has caused loss of data in system tables in some scenarios. This applies to system tables that would have been part of tenant data in MT scenario, check product documentation for the list:
http://msdn.microsoft.com/en-us/library ... 1(v=nav.71).aspx

This has been addressed in KB2907589, available on Partner Source.

TomH_DK

Thanks for the info JasminkaT

JasminkaT

Sorry about the bad documentation link (above), here's the right one

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

arcull

Thanks for info JasminkaT. But there are cases when table data deletion occures and cases when it doesn't, has anyone found out the "safe configuration"? I mean, if we can figure out the needed configuration in which deletion doesn't happen, we may be able to bypass this issue. Besides can you please provide the link to KB2907588, I just can't find it on partner source. Thanks again.

JasminkaT

So the two issues above were not really platform issues (to my understanding) but a result of design decisions since we were apparently unaware of how much the two scenarios are used in the channel (customizing system objects and deleting records from object metadata table directly). Later both decisions were reverted after reported issues resulting in the two fixes. One enables (again) modifying system tables (which should prevent data loss caused by block on system object edit in previous builds),
and the other disables deletion of table records from object metadata table, seeing this is often used in the channel (also causing data loss).
Please note that the two scenarios above are the only repro steps provided so far, if you know of any other scenarios, please contact support.

https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYZWLSWZQTLLRPPXLZMZKQRXOOKPXVWZZU

arcull

Thanks JasminkaT, I've just tried the build 35866 which addresses the KB2907588 and it does indeed prevent manual deletion of Table type records in Object Metadata. However I wonder if it does solve also problems which forced us to do so, since deletion was possibly the only solution to the SQL error we encountered sometimes (don't remember the description) when appending new fileds in tables.

JasminkaT

I'd like to add the following, based on my experience with some of these issues lately:

When upgrading to /working with 2013 R2, you should be aware of the following (to avoid schema synchronization issues):

1. Make sure NST has DBO permissions (object change listener might fail otherwise, you'll find records of this in event view log)
2. Make sure you're on later builds (I think that latest build relevant for these issues was 35881, KB 2907589, but if you install KB 2923351 you should be covered
3. Using Import - Replace - SaveAs - Import of the saved fob might result in metadata inconsistency. This is being looked into at the moment, but for the time being, it might be wise not to use it in combination with schema changes.
4. If making schema changes on larger tables that might prompt index rebuild etc.. you might need to increase SQL connection timeout client services parameter. Default value is 30 mins, you might need higher value to complete schema synchronization for larger tables. Should this be the case, you'll find an event similar to this in event view log: Message: A transport-level error has occurred when sending the request to the server. (provider: Session Provider, error: 19 - Physical connection is not usable)

And just to add (though this is really just repeating oneself), in legacy mode schema synchronization will start only at client action (start-up or any action if the client is already running)..