Property TEMPORARY bei Recordvariable prüfen

Eine Recordvariable, die eigentlich temporär sein sollte, es dann aber durch eine falsch gesetzte Temporary-Property dann doch nicht ist, kann spätestens beim DELETEALL böse Folgen haben. MIt Hilfe eines RecordRef's kann man vorher prüfen, ob man nicht versehentlich auf der physischen Datenbanktabelle operiert, hier steht in RecRef.Number als fester Wert die Tabellen-ID, bei der temporären ein variabler Wert über 2000100000 (den Wert habe ich empirisch ermittelt )

Code:

RecRef.GETTABLE(TempRecVariable);
IF RecRef.NUMBER >= 2000100000 THEN
  TempRecVariable.DELETEALL;
...

ist ja genial

putzig ist, dass da nicht etwa ein konstanter Offset dazwischen liegt (z.B. Tabelle Item 27 -> temporär 2000100027), sondern bei wiederholten Aufruf meines Test-Dreizeilers RecRef.NUMBER immer größer wird.

Torsten

Die von Kowa beschriebene Variante gilt nur für NAV <= 5.0.

Ab 2009:

Code:

RecRef.GETTABLE(TempRecVariable);
IF RecRef.ISTEMPORARY THEN
  TempRecVariable.DELETEALL;
...

Referenz: http://msdn.microsoft.com/en-us/library/ff477102.aspx

... und Kowa war noch so stolz darauf, den Wert 2000100000 empirisch ermittelt zu haben.

Ein konstanter Offset wäre nicht praktikabel, da NAV intern diese ID zur Referenzierung dieser speziellen temporären Instanz nutzt.

Und die 2000100000 ist ein Sicherheitsabstand für die in NAV "7" zu implementierenden ca. 99500 neuen Systemtabellen

Naja, das ist wohl eher was für RecordRefs, die je nach Ausführung mal temporär und mal nicht temporär sein können. Bei festen Record-Variablen sollte man wissen (oder zur Not nachgucken können), ob die Eigenschaft gesetzt ist. Ansonsten sollte man nicht damit hantieren.

Aber interessant ist es schon, wie NAV das intern macht. Ich habe das mal vor Jahren festgestellt und wenn ich mich richtig erinnere, dann setzt NAV die ID sogar in 2er-Schritten hoch, also 2000100000 für die erste temporäre Instanz, 2000100002 für die zweite, usw. Ist das immer noch so und wenn ja, warum?
Außerdem gab es doch mal diesen Fehler in einer Version... Wenn man zwei unterschiedliche, temporäre Record-Variablen von der gleichen Tabelle erstellt hat, hatten die zwar unterschiedliche IDs, enthielten aber den selben Recordset (oder so ähnlich). Was ist denn daraus geworden und warum war/ist das so?

Außerdem gab es doch mal diesen Fehler in einer Version... Wenn man zwei unterschiedliche, temporäre Record-Variablen von der gleichen Tabelle erstellt hat, hatten die zwar unterschiedliche IDs, enthielten aber den selben Recordset (oder so ähnlich). Was ist denn daraus geworden und warum war/ist das so?

Davon hatte ich noch nie gehört bzw. nichts dazu gefunden.
Ich habe aber diese Aussage zum Anlass genommen, in der Knowledge Base zu suchen und bin auf ein Hotfix zum Thema ISTEMPORARY (also für 2009) gestoßen: siehe KB975655.

Wer mit ISTEMPORARY arbeiten möchte, sollte mindestens Build 29735 (für 6.0) oder 29958 (für 6.0 SP1) benutzen.

Ich glaube, das war in einer 5er-Version. Ich versuche es auch gerade noch mal nachzuvollziehen...

Ich hab es wiedergefunden. Es betrifft temporäre Record-Arrays. Und wenn ich mich nicht irre, hast du sogar Kommentare dazu abgegeben.
Offiziell war es wohl mal ein Bug, aber mittlerweile wird es als Feature verkauft.
http://dynamicsuser.net/blogs/mark_brummel/archive/2010/05/05/tip-27-using-temp-tables-in-arrays.aspx

Naja, das ist wohl eher was für RecordRefs, die je nach Ausführung mal temporär und mal nicht temporär sein können. Bei festen Record-Variablen sollte man wissen (oder zur Not nachgucken können), ob die Eigenschaft gesetzt ist. Ansonsten sollte man nicht damit hantieren.

Temporäre Recordvariablen sollten eigentlich "Temp" oder "Buffer" im Namen haben, nicht-temporäre nicht. Leider trifft man immer wieder auf Code, wo das nicht eingehalten wurde (auch im Standard) , und die Namen sind hier auch nur Schall und Rauch weil nur die Property ausschlaggebend ist. Fehlerquellen wie Mergevorgänge und Copy&Paste sind schnell passiert, auch Funktionen wie FindSalesPrice in CU 7000 sind ohne Codeprüfung mit Vorsicht zu genießen weil man dem Parameter nicht ansieht, dass hier nur eine temporäre Instanz übergeben werden darf. Zur Laufzeit gibt es leider keine andere Möglichkeit, das direkt vorab zu prüfen, um Datenverluste zu verhindern, was natürlich wünschenswert wäre.

Also ich sehe da immer noch keinen tieferen Sinn für feste Record-Variablen. Wenn ich in der Lage bin den von dir oben genannten Code einzufügen, dann bin ich auch in der Lage das Property nachzugucken. Das Einzige, was ich gelten lassen würde, wäre, wenn man immer alle seine Konstrukte mit temporären Record-Variablen so aufbaut, um evtl. vorhandenen Merge- und Konvertierungsfehlern vorzubeugen, bei denen das Property nicht ordentlich mitgezogen wurde. Nur wann wird schon mal eine Konvertierung oder ein Merge durchgeführt? Bei Updates und Hotfixes. Sollte man das nicht sowieso vorher testen?! Wenn das durch einen Merge entstanden ist, wird man dann nicht noch viel mehr Probleme haben? Außerdem deckt man so zwar die individualisierten Stellen ab, aber was ist mit den vielen Stellen, die im Standard oder in einem Add-On vorhanden sind? Alle Stellen vorher bearbeiten?! Nein, nicht wirklich!
Also, ich finde, man sollte das schon wissen, aber dem praktischen Nutzen bei festen Record-Variablen stehe ich doch sehr kritisch gegenüber. Das Verhältnis von Aufwand zu Nutzen stimmt da einfach nicht. Wie gesagt, bei dynamischen RecordRefs ist das etwas anderes.

Wer mit ISTEMPORARY arbeiten möchte, sollte mindestens Build 29735 (für 6.0) oder 29958 (für 6.0 SP1) benutzen.

Ein andere Möglichkeit ab 6.0 ist der neue zweite Parameter ShareTable bei der COPY Funktion.
Beide Recordvariablen müssen dann temporär sein, sonst erfolgt Abbruch zur Laufzeit.

Code:

Record.COPY(FromRecord [, ShareTable])


ShareTable
Type: Boolean
Specifies whether the function creates a copy of the record or creates a reference to a temporary record.
If FromRecord and Record are both temporary and ShareTable is true, then the COPY function does not create a new copy of the record. Instead, the COPY function causes Record to reference the same table as FromRecord.
The default value is false. If you specify false, all records are copied to Record from FromRecord.

Ein konstanter Offset wäre nicht praktikabel, da NAV intern diese ID zur Referenzierung dieser speziellen temporären Instanz nutzt.

Und die 2000100000 ist ein Sicherheitsabstand für die in NAV "7" zu implementierenden ca. 99500 neuen Systemtabellen

Nunja, da du ja auf der MSDynamics Konferenz NAV 7 kurz vortragen wirst, bin ich gespannt, was aus den 99'500 Systemtabellen geworden ist ... *grins*

Ein andere Möglichkeit ab 6.0 ist der neue zweite Parameter ShareTable bei der COPY Funktion.
Beide Recordvariablen müssen dann temporär sein, sonst erfolgt Abbruch zur Laufzeit.

Code:

Record.COPY(FromRecord [, ShareTable])

Übrigens eine sehr coole Funktion in manchen Situationen, wenn man zwei oder mehr Instanzen auf das selbe temp. Recordset benötigt.

Ein konstanter Offset wäre nicht praktikabel, da NAV intern diese ID zur Referenzierung dieser speziellen temporären Instanz nutzt.
Und die 2000100000 ist ein Sicherheitsabstand für die in NAV "7" zu implementierenden ca. 99500 neuen Systemtabellen

Nunja, da du ja auf der MSDynamics Konferenz NAV 7 kurz vortragen wirst, bin ich gespannt, was aus den 99'500 Systemtabellen geworden ist ... *grins*

Ich plane schon, Dynamics NAV 7 nicht nur kurz sondern eher länger zu präsentieren
Zu 99.500 Tabellen hat es denn aber doch nicht gereicht, auch wenn sich in dem Bereich einiges getan hat...

Ab NAV 2016 ist es ja integriert, aber für ältere Versionen hier eine Lösung mit einer eleganten Kombination von Funktionen.
https://klemmensen.ca/2015/07/24/is-my-record-temporary

Ab BC 22 ist es endlich im Quellcode direkt erkennbar:

TemporaryRecord.jpg

Passend dazu: AppSourceCop Warning AS0109

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.