Archiv für die Kategorie ‘SQL’

Synchronisation via Powershell

Veröffentlicht: 16. April 2014 in SQL, Tipp

Hi NAV Anwender und Entwickler ;),

da wir aufgrund des Paradigmenwechsels in der Synchronisation der Tabellenänderungen (MS Blog Artikel: http://blogs.msdn.com/b/nav/archive/2014/03/27/table-synchronization-paradigm-in-microsoft-dynamics-nav-2013-r2.aspx) nun ja häufiger die Anpassungen manuell transferieren sollten, hier eine kurze Beschreibung wie man Objektänderung aus der NAV 2013 R2 Entwicklungsumgebung via Powershell auf den SQL Server übertragen kann:

1. Logge dich auf dem NST (Navision Service Tier) ein.

2. Starte die Powerstell ISE.

3. Lade das aktuelle NavAdminTool.ps1 aus dem Service Ordner des Service Tiers.

4. Starte das NavAdminTool.

5. Führe dort „set-executionpolicy unrestricted“ aus und bestätigte den Dialog.

6. Synchronisiere NST mittels Sync-NAVTenant <DeinNSTServerinstanzName>

7. Starte NST-Dienst neu

Dies ist auch der Empfohlene Weg von Microsoft selbst J
In diesem Zuge möchte ich auch auf Waldos Blogartikel bezüglich Umnummerierung von Tabellen hinweisen: http://www.waldo.be/2014/04/16/renumbering-tables-in-nav-2013-r2-be-careful/. Hier ändert sich aktuell sehr viel. Ich bin gespannt was auf uns Entwickler noch zu kommt.

Mit freundlichen Grüßen
Matthias König

SQL-Datums-Befehle: Erster und/oder Letzter Tag

Veröffentlicht: 15. November 2011 in SQL, Tipp

​Hi,

evtl. benötigt man mal den ersten und/oder den letzten Tag eines Monats in einer Stored Procedure, View oder einem Datengesteuerten Abonnement. Da ich keine Standard Funktion gefunden habe, habe ich dafür nun zwei kleine Snippets entwickelt:

Erster Tag:

DATEADD(
 dd, -- der Tag soll verändert werden
 CASE DAY(@CurrentDate) WHEN 1 THEN 0 ELSE -DAY(@CurrentDate-1) END, -- aktueller Tageswert -1 soll abgezogen werden
 @CurrentDate -- Berechnung ab diesem Tag
 )

Letzter Tag:

DATEADD(
 dd, -- der Tag soll verändert werden
 -DAY(@CurrentDate ), -- aktueller Tageswert soll abgezogen werden
 DATEADD(mm,1,@CurrentDate )-- Berechnung ab diesem berechneten Tag
 )

Das @CurrentDate muss natürlich vorher gefüllt werden. Wenn es das aktuelle Datum sein soll, verwendet man am besten GETDATE();.

Alternativen, Kritiken und bessere Ideen nehme ich gerne auf 🙂

Mit freundlichen Grüßen Mattias König

Datensatzwert in SQL vergleichen

Veröffentlicht: 2. März 2011 in SQL, Trick

Wie schon angekündigt, hier der SQL Befehl um Datensätze, bzw. bestimmte Felder zweier zusammengehörender (selber Primary Key) Datensätze in unterschiedlichen Tabellen auf Differenzen zu überprüfen:

(Beispiel der Customer Tabelle in Live und Dev Datenbank)

SELECT
 'DevDatabse' TableID
 ,[No_]       
 ,[Name]       
 ,[Quantity]
FROM [DataBase_Dev].[dbo].[Company$Customer] as TableOne
WHERE
 BINARY_CHECKSUM(
 TableOne.[Name]
 ,TableOne.[Post Code]
 ,TableOne.[City]
 ,TableOne.[Fax No_]
 ,TableOne.[E-Mail]
 ,TableOne.[Home Page]
 <>
 (SELECT BINARY_CHECKSUM(
 TableTwo.[Name]
 ,TableTwo.[Post Code]
 ,TableTwo.[City]
 ,TableTwo.[Fax No_]
 ,TableTwo.[E-Mail]
 ,TableTwo.[Home Page]
 )
 FROM DataBase_Live].[dbo].[Company$Customer] as TableTwo
 WHERE TableTwo.[No_]  = TableOne.[No_]

Hier wurde die Build-in-Function BINARY_CHECKSUM verwendet. Diese errechnet ein Prüfsummenwert aus den angegebenen Werten, der zum Vergleich verwendet werden kann. Innerhalb dieser Funktion, können die zu überprüfenden Felder eingetragen werden. Leider kann man sich hier das Leben nicht einfach machen in dem man ‚*‘ eingibt weil hier der in SQL intern verwendete Timestamp fast immer unterschiedlich sein wird ;).

Mit freundlichen Grüßen,

Matthias König

Tabelleninhalt in SQL vergleichen

Veröffentlicht: 9. Februar 2011 in SQL, Tipp, Trick

Oder auch „Ist der Datensatz in beiden Tabellen vorhanden?“

Um einen Automatismus per Webservice zu steuern, musste ich DataPorts in Codeunits umschreiben (NAS und Webservice :D) und in diesem Zuge wollte ich am Ende die Importierten Daten im Vergleich zum DataPort überprüfen. Zu allerersteinmal wollte ich kontrollieren ob alle Datensätze importiert wurden, also ob beide Varianten die selben Datensätze erzeugen. Dafür habe ich den Dataport in einem Mandanten gestartet und die Codeunit in einem anderen Mandanten. Nun können diese per SQL einfach gegenübergestellt werden, sodass verglichen werden kann, wo ein Datensatz fehlt. Da dies allerdings (meines Wissens nach) nicht mit einem Script geht, habe ich zwei kleine gebastelt. Mit den nun folgenden SQL Scripten (natürlich abgeändert 😉 ) können Daten zweier Tabellen verglichen werden:

-- es fehlt etwas in TabelleEins
SELECT *
FROM [DatenBank].[dbo].[MandantEins$Tabelle XYZ] AS TabelleInEins
LEFT JOIN [DatenBank].[dbo].[MandantZwei$Tabelle XYZ] AS TabelleInZwei
ON TabelleInEins.ID = TabelleInZwei.ID
WHERE TabelleInZwei.ID is null
-- es fehlt etwas in TabelleZwei
SELECT *
FROM [DatenBank].[dbo].[MandantEins$Tabelle XYZ] AS TabelleInEins
RIGHT JOIN [DatenBank].[dbo].[MandantZwei$Tabelle XYZ] AS TabelleInZwei
ON TabelleInEins.ID = TabelleInZwei.ID
WHERE TabelleInEins.ID is null

Die Tage wird wohl noch ein „Datensatzwert in SQL vergleichen“ Artikel erscheinen, da ich natürlich noch die Richtigkeit der restlichen importierten Daten überprüfen muss.

Diese Scripte mögen nicht das non-plus Ultra seien aber sie haben mir ihren Dienst erwiesen 🙂 Verbesserungsvorschläge/Alternativ-Scripte gern als Kommentar.

Mit freundlichen Grüßen, Matthias König

Tabellen-Arten

Veröffentlicht: 21. Juni 2010 in Allgemein, Nice-To-Know, SQL

Es gibt in NAV vier verschiedene Arten und von Tabellen (oder auch Tabellenarten).

Hier eine Übersicht:

Name Beschreibung Verwendung
System-Tabellen Diese Tabellen befinden sich im 2.000.000.000 Bereich und werden beim erstellen der Datenbank angelegt. Diese Tabellen sind im SQL-Server, Object Designer und beim erstellen einer Form zu sehen Benutzerverwaltung, Zugriffsrechte
Restore-Tabellen Während eines NAV-Backups bzw. während eines imports dessen, werden die Tabellen zwischengespeichert. Die Restore-Tabellen ID wird berechnet in dem die normale ID + 1.000.000.000 gerechnet wird. Sie können im SQL-Server, Object Designer und beim erstellen einer Form gesehen werden. Dies wird gemacht damit die Objekte überprüft und dann richtig importiert werden können. Nach dem erfolreichen Import sind diese nicht mehr vorhanden.
Virtuelle-Tabellen Dies sind Hilfs-Tabellen, die nicht im Object-Designer oder im SQL-Server zu finden sind, allerdings sind sie beim erstellen einer neuen Form Verfügbar. Die Tabellen-Struktur wird in der fin.stx (Sprachabhängig) definiert und kann deswegen auch Versionsabhängig unterschiedlich sein. Diese können verwendet werden um Daten wie in NAV gewohnt zu verarbeiten allerdings kann auf diese Tabellen kein Update oder Insert ausgeführt werden (READONLY). Hier folgende Beispiele: Printer, Date, Integer und mehr
Normale-Tabellen Dies sind Tabellen im Bereich 1..1.000.000.000. Tabellen im 50000..80000 Bereich sind Kundentabellen und 80000..100000 sind Entwicklertabellen. Speicherung von Daten