[Gelöst] Technisches Update auf NAV 2009 R2

Hallo NAV Gemeinde,

wir werden hier in Kürze technisch von 4.0 SP3 auf NAV 2009 R2 wechseln, Performance-Tests bzgl. SIFT und Indexed Views etc. wurden erfolgreich abgehakt.
Da wir bei Applikationstest über das geänderte Verhalten bzgl. RecRefs gestolpert sind (nun muss man sauber RecRef.Close absetzen, bevor man mit weiteren OPENs hantieren darf), stellt sich mir die Frage, ob es noch weitere Stolperfallen im Code-Handling gibt.

Habt Ihr hier Erfahrungen, auf welche Code-Konstellationen man ggf. noch achten sollte?

Gruß und schon mal Danke ;)
Meik

PS: Es geht natürlich um den Classic Client

Zuletzt geändert von AlterHase am 20. Februar 2012 18:14, insgesamt 1-mal geändert.

Mit Office und anderen externen Erweiterungen könnte es Probleme geben.

Gruß, Fiddi

Es geht natürlich um den Classic Client

Natürlich

Da wir bei Applikationstest über das geänderte Verhalten bzgl. RecRefs gestolpert sind (nun muss man sauber RecRef.Close absetzen, bevor man mit weiteren OPENs hantieren darf), stellt sich mir die Frage, ob es noch weitere Stolperfallen im Code-Handling gibt.

Keine Stolperfalle, aber aus performancetechnsichen Gründen erwähnenswert: Einsatz von FINDSET anstelle von FIND. Hierzu am besten den C/SIDE Reference Guide aus dem 2009-Client befragen (oder online).

Aber ein ergänzendes Wort hierzu: Nicht wahllos alle FINDs durch FINDSET ersetzen.
FINDSET sollte nur dort verwendet werden, wo die Anzahl der durchschnittlich erwarteten Datensätze kleiner oder gleich des eingestellten Recordssets (Standard: 50) ist.

Hallo Natalie,

danke für den Hinweis, wir arbeiten bereits in der heutigen 4.0 SP3 mit diesem Befehl. Von daher sollte es hier kein böses Erwachen im Livebetrieb geben.

Gruß
Meik

Auf der R2 DVD gibts ein Whats New in R2 für Developer.

Wichtig ist auch das CASE dann case-sensitive ist als Beispiel.

Hallo JanGD,

Danke - das war der entscheidende Hinweis, manchmal kommt man auf die simpelsten Sachen nicht. Für alle, die sich die gleiche Frage stellen:

Es gibt darüberhinaus auch in der Online-Hilfe des C/SIDE Reference Guides einen Abschnitt in dem alle Änderungen bzgl. der Entwicklung aufgelistet sind:
Einfach nach "Development Considerations" suchen und dort dann auf den Link "Changes in C/AL Behavior and Support from Previous Versions of Microsoft Dynamics NAV" klicken.

Stichpunktartig sind folgende Bereiche sensibel

• Binary Data Type: nicht mehr unterstützt
• Code Data Type bei CASE Abfragen nun case-sensitiv
• COMPRESSARRAY Function: nicht bei multidimensionalen Arrays
• COPY Function (Record): Um neuen Parameter ergänzt
• Date Data Type: 0D ist nicht mehr 01.01.0000 sondern 03.01.0001
• DateTime Data Type: der früheste DateTime-Wert ist nicht mehr 01.01.0000, 00:00:00.000, sondern 03.01.0001, 00:00:00.0000000.
• Decimal Data Type: ist nun gemapped auf den Microsoft .NET Framework common language runtime (CLR) Decimal data type
• ISTEMPORARY Function (RecordRef): Neue Funktion bei RecordRefs
• NUMBER Function (RecordRef): geändert in NAV 2009 R2
• READ Function (File): geändert in NAV 2009 R2
• TABLENO Function (RecordID): geändert in NAV 2009 R2
• TEXTMODE Function (File): Datei darf noch nicht geöffnet sein, wenn diese Funktion verwendet wird.
• Time Data Type: Genauigkeit in Schritten von 100 ns
• Variant Data Type: geändert in NAV 2009 R2

Gruß
AlterHase

Einfach nach "Development Considerations" suchen und dort dann auf den Link "Changes in C/AL Behavior and Support from Previous Versions of Microsoft Dynamics NAV" klicken.

Oder wieder online

Aber danke, auf den Artikel bin zumindest ich bislang nicht aufmerksam gemacht worden.

FINDSET sollte nur dort verwendet werden, wo die Anzahl der durchschnittlich erwarteten Datensätze kleiner oder gleich des eingestellten Recordssets (Standard: 50) ist.

Kannst du das mal kurz ausführen? Mein Kenntnisstand dazu ist: wenn mehr Datensätze geholt werden müssen, als das eingestellte Recordset, werden zuerst die 50 Datensätze geholt und dann die restlichen Datensätze mit einem Cursor bearbeitet. Das sollte immer noch weniger Last für die DB bedeuten, da ja sonst schon für die ersten 50 Datensätze drei Cursor hätten erzeugt werden müssen. Und Cursor sind teuer. Aber ich habe nach den letzten Updates nicht mehr ausprobiert, wie sich die NAV und der SQL-Server jetzt verhalten. Insofern mag mein Wissen überholt sein.

EDIT: Was in jedem Fall stimmt: bei jedem FIND('-') muss überlegt werden, ob ein FINDFIRST oder ein FINDSET besser passt. Denn das FIND('-') hatte man früher ja immer verwendet, egal ob man nur den ersten Datensatz brauchte oder eine Schleife folgte.

Noch ein EDIT: Habs gerade in der Online-Hilfe gefunden (C/AL Database Functions and Performance on SQL Server). Dort steht tatsächlich:

If the number of records that is read falls within this range, then all records are read with optimized performance. If there are more records to read than the preset number, then Microsoft Dynamics NAV must establish new commands to SQL Server to continue reading records. Microsoft Dynamics NAV reads all records successfully, but the additional commands are expensive for SQL Server to execute. The FIND('-') operation is more efficient than the FINDSET operation when there are more records to read than the preset number.

Allerdings bezweifle ich, dass das für alle Situationen stimmt. Dort steht schließlich, dass die zusätzlichen Befehle teuer für den SQL-Server sind. Dass natürlich die ersten drei Cursor bei einem einfachen FIND auch teuer für den SQL-Server sind, ist dort nicht erwähnt. Wahrscheinlich wird es in der Praxis in der Regel nur um Millisekunden gehen, aber das werd ich mal in den nächsten Tagen genauer untersuchen.

Hallo,

wenn man Waldo glauben kann, hat NAV allerdings sein Handbuch nicht gelesen .

FINDSET scheint hier immer effizienter zu sein, als ein FIND('-'), obwohl man aktuell statt der 500 Records das ganze mit 50 Records (bei Standardeinstellung) noch einmal neu betrachten muss.

Gruß, Fiddi

Hi Tim,

Du kannst einmal im SQL-Profiler die Statements protokollieren, die Navision absetzt, wenn ein Findset die voreingestellten Datensätze erreicht und dann die darauf folgenden Sätze lesen muss. Mein Wissenstand basiert hier allerdings auf 5.0. Dort war das grausig, wie Navision die SELECTs aufbaut, um tatsächlich den nächsten Datensatz zu finden. Insofern sind die Ausführungen von Natalie und das was Du gefunden hast korrekt.

Ein Findfirst resultiert in einem SELECT TOP 1 und ist damit immer für den Fall gut, in dem man tatsächlich nur einen Datensatz möchte. Ebenso auch der ISEMPTY (soweit ich weiß SELECT TOP NULL), der performanter als ein FINDFIRST ist, da keine Feldinhalte geholt werden müssen. Beginnt man nach einem FINDFIRST eine Schleife wird das wieder grausig.

Gruß
Meik