Objekt verändern+speichern geht nicht (Gewinn STERNE-Essen)

@Carsten: Auch an dieser Stelle noch einmal ein ganz herzliches Dankeschön für dein Engagement! Gehe vor, wie telef. besprochen und wir sehen uns dann

hatte das gleiche Problem. Habe diese Antwort von MS bekommen:

War das eine Supportanfrage an MS? Von wann war die Auskunft?

Werde die neuen Erkenntnisse mit ausführlicher Doku an MS senden und hier von dem Ergebnis berichten.

Jetzt brauch ich eine Pause

ja, war an MS. Ist vom 30.10.

ja, war an MS. Ist vom 30.10.

OK, dass ist noch nicht so lange her. Werde auf jeden Fall berichten, sobald ich eine finale Antwort auf meinen MS-Case habe.

Hier nochmal die Auflösung: http://www.dynamics.is/?p=1619

There are two methods to get around this error.

• Start a Server Instance on your Developement machine using domain user account
• Start a Server Instance on your SQL server using Network Service

Für die Suchmaschine:
Die Änderungen an der TAbelle konnten nicht verifiziert werden. Zum Überprüfen der Änderungen an der Tabelle auf möglichen Datenverlust muss Microsoft Dynamics NAV Development Environment mit einem ausgeführten Server kommunizieren. Der angegegeben Microsoft Dynamics NAV Application Server kann nicht erreicht werden.
Unable to verify table changes. To validate table changes for potential data loss, Microsoft Dynamics NAV Development Environment must communicate with a running server. The specified Microsoft Dynamics NAV Application Server cannot be reached."

AKTUELLER STAND:

Ich kann nicht empfehlen, in einer 3-Tier Umgebung aus der Entwicklungsumgebung heraus, die NICHT auf dem Dynamics NAV Server Computer läuft, "Prevent data loss from table changes" auf "No" zu setzen, da damit nicht geprüft wird, ob eine Schemaänderung durchgeführt werden kann. Auf dem SQL Server in der Tabelle ändert sich dabei nichts (gut), aber die Objekt-Metadaten werden geändert und aus Objektsicht hat diese Änderung stattgefunden.

Bedeutet aktuell also, lösche ich ein Feld mit der Option deaktiviert, wird dieses aus den Metadaten gelöscht und das Feld, obwohl auf dem SQL Server in der Tabelle noch vorhanden, nicht mehr in Dynamics NAV angezeigt. Ein erneutes Hinzufügen des Feldes unter gleichem Namen korrigiert diese Schieflage dann wieder.

Neue Tabellen können immer angelegt werden, da keine Schemaänderungen stattfinden.

Ich denke aber Dominik wird sich dazu später noch einmal melden.

Sebastian (Röttel) hat mir letzten Freitag die Option (Prevent data loss from table changes) des Dev Clients noch vorgestellt. Das geht aber nur in legacy Datenbanken.
Ich habe das Problem auch, aber kann es umgehen, indem ich die Umgebung auf dem Server nutze.

Sebastian (Röttel) hat mir letzten Freitag die Option (Prevent data loss from table changes) des Dev Clients noch vorgestellt.

Das hatte ich aber auch schon in meiner ersten Antwort hier geschrieben

Ich habe das Problem auch, aber kann es umgehen, indem ich die Umgebung auf dem Server nutze.

Das wiederum steht so bereits in den Release Notes (beim Produktdownload).

Hat jemand schon Gunnars Lösungsansätze probiert? Ich nämlich noch nicht ...

Hallo Dominik,

wenn du einen DomainUser nutzt, hast du dann auch die passenden SPNs gesetzt?

Standard:
DIENST/STCOMPUTERNAME:PORT
DIENST/STCOMPUTERNAMEFQND:PORT

Beispiel:
DynamicsNAV/ComputernameST:7045
DynamicsNAV/ComputernameST.domain.local:7045
&
DynamicsNAV/ComputernameST:7046
DynamicsNAV/ComputernameST.domain.local:7046

Hat jemand schon Gunnars Lösungsansätze probiert? Ich nämlich noch nicht ...

Hierzu kann ich sagen, dass beide Varianten bei mir funktionieren :)

----
Gunnars Lösungsansätze sind für uns aber auch nur temporöre Lösungen.
Die Vermutung liegt nahe, dass für den DomainUser SPNs auf den Management Port und NAVST benötigt werden!
Änderungen an Tabellen werden in NAV2013R2 über das ST (Service Tier) gesteuert, was ich rauslesen konnte.
Es sei denn, das neue Flag (Prevent data loss from table changes) ist auf No gesetzt! Damit können auch Tabellenfelder gelöscht werden, die noch Daten enthalten. Dies kann da nützlich sein, wo woher ein Report oder CU dafür gesorgt hat, dass das Feld geleert wird. Das ist somit nicht mehr notwendig.
Da wir aber generell dieses Flag auf Yes lassen wollen, muss es einen anderen Weg geben.
Leider konnte ich die SPN Lösung selbst noch nicht testen, unser SPN Admin ist erst morgen wieder verfügbar.

Falls es also jemand vorher testen könnte, kann dies gerne tun!
Aber vielleicht hat einer von euch sogar schon eine Lösung gefunden :)

Viele Grüße
Carsten 2 ;)

Guten Abend,

Carsten 2 liegt nicht ganz falsch, allerdings haben wir auch ein zusätzliches Problem festgestellt: Active Directory bzw. Kerberos kann so konfiguriert werden, dass bei Verbindungen (Security Support Provider Interface (SSPI)) eines Clients (WCF), SPNs auf jeden Fall erforderlich sind. Die Prüfung der Layoutänderungen einer Tabelle von der Entwicklungsumgebung aus ist bisher in solchen Domänen nicht möglich gewesen. Die Entwicklungsumgebung hat, im Gegensatz zum Windows Client, nur versucht eine Verbindung ohne SPN aufzubauen, nicht aber mit. Das wird im kommenden Build 35778 [EDIT: Build 35784] (wahrscheinlich ab kommender Woche verfügbar) korrigiert und an das Verhalten des Windows Client angepasst.

Der Punkt ist also mal gegessen dann

Weiterhin gibt es Unterstützung für Visual Studio 2013 bzgl. Report-Entwicklung und auch eine Korrektur für Parallelinstallationen von 2013 und 2013 R2, um Objekte problemlos aus beiden Versionen aus dem Object Designer starten zu können. Für Dynamics NAV 2013 dauert es aber eventuell noch ein paar Tage mehr.

Natürlich noch vieles mehr...

Ich kann nicht empfehlen, in einer 3-Tier Umgebung aus der Entwicklungsumgebung heraus, die NICHT auf dem Dynamics NAV Server Computer läuft, "Prevent data loss from table changes" auf "No" zu setzen, da damit nicht geprüft wird, ob eine Schemaänderung durchgeführt werden kann.

Der Microsoft Dynamics NAV Team Blog wird da sogar noch deutlicher:

IMPORTANT NOTICE:

Setting the “Prevent data loss from table changes” C/SIDE switch to “No” has been intended to be used as last resource in a pure multitenancy scenario and in Test or Staging environments when partners does not have any business data database mounted against the application database. All other usages that deviate from this statement might lead to unpredictable results and even undesired data loss scenarios in upgrades or, even worse, production environments.

Never change for any reason this parameter to “No” when developing against a single-tenant / Legacy mode database.

Edit:
Weiter unten nochmal als schöne Zusammenfassung:

Development Environment best practice

thinking about potential data loss and synchronization issues is a brand new big challenge in the development environment, and so some consideration and following best practice might be advisable. These applies to developing solutions for both single- and multitenant deployments.

1. Do not use Build No. lower than than 36310 KB 2934572
   As a partner, you take this as the "RTM Build No." starting point for NAV 2013 R2 and deploy this platform hotfix in the future projects while you also convert existing installations.
   NOTE: As per common best practice, we recommend that you download / request / test and deploy the latest platform hotfix for Microsoft Dynamics NAV 2013 R2. This will contain correction for minor issues not directly or just slightly related to synchronization scenarios.
2. Never-ever change “Prevent data loss from table changes” to “No”.
   This have been noticed as one of the major source of potential data loss and missing synchronization for NAV 2013 R2 databases.
3. Make sure that the Microsoft Dynamics NAV Server service account has been granted the “db owner” role in SQL Server.
4. Increment the SQL Server Command Timeout parameter in the Microsoft Dynamics NAV Server configuration file that you use in development to a very high value (such as 10:00:00)
5. For large Microsoft Dynamics NAV objects OR a high number of table modifications, do NOT use a Microsoft Dynamics NAV client action to prompt for synchronization but it is warmly preferable to use the Sync-NAVTenant Windows PowerShell cmdlet. (This is a typical scenario related to upgrades).
6. For big batch of FOB files that are making a high number of table modifications, be sure to have this tested on a safe staging environment and import, where possible, the Table Objects in smaller chunks and synchronize them after importing every single chunk of Microsoft Dynamics NAV objects.
7. For important changes in several table structures, such as when upgrading from previous version, it would be good to run a SQL Server Profiler trace after prompting for synchronization to check what is running on the SQL Server side and keep the synchronization monitored until it ends.
   
   Recommended Events:
   •SP:StmtCompleted
   •SQL:StmtCompleted
   
   Recommended Column Filters:
   •DatabaseName Like <DatabaseName>
   •TextData Not Like SELECT %