Temp. Tabelle

Hallo

Kann mir jemand mit den temp. Tabellen ein wenig auf die Sprünge helfen. Wo kann es darüber etwas nachlesen bzw. wo und wann sollte man diese verwenden.

mfg
stony

Du kannst aus jeder existenten Tabellen eine temp. Tabelle machen, indem du unter den Variablen-Eigenschaften diese auf Temporary = YES setzt. Ab diesem Augenblick enthält die Variable nur solche Datensätze, die du selbst im Quelltext mit Record.INSERT füllst bzw. änderst oder löschst. Daher solltest du darauf achten, sie ggf. zu leeren (z.B. erst mit Record.RESET, dann Record.DELETEALL).

Diese Tabellen werden vor allem in Reports verwendet, siehe z.B. Report 111. Ansonsten findest du sie in zahlreichen Codeunits. Dort speichern sie bestimmte Datensätze, wofür man in anderen Programmiersprachen dynamische Arrays verwenden würde.

Hi!

Durch die Verwendung von temporären Tabellen kann man auch die Perfromance (tw. erheblich) steigern - insbesondere mit SQL Server! - da soz. Last vom Server auf den Client verlagert wird und Sperren verkürzt werden!

Vom Prinzip her ist dabei wie folgt zu verfahren:

- Einlesen der zu verarbeitene Daten in die temporäre Tabelle (Load)
- Änderung der Daten in temporärer Tablelle (Work)
- Übertragen der Änderungen von temporärer nach "echter" Tabelle (Dump)

Hier wird der Server zunächst während der "Load" Phase beansprucht, da aber nur lesend zugegriffen wird, werden keine Sperren gesetzt.
Währen der "Work" Phase wird hauptsächlich der Client beansprucht - je nach Transaktion sollte der PC entsprechend ausgestattet sein - der Server "kann sich um andere Dinge kümmern".
Da nur während der "Dump" Phase Sperren gesetzt werden, ist das Risiko von Konflikten/Blockaden minimiert.

Ergo: Die System Performance kann insgesamt gesteigert werden!

Aber Vorsicht: Das Ganze ist natürlich je Einzellfall zu betrachten!

[Kowa]

Wichtig
Bei jedem DELETEALL prüfen , dass es sich tatsächlich um eine Recordvariable mit TEMPORARY - Property handelt. Diese Eigenschaft ist leider viel zu versteckt ( müsste eigentlich in der Übersicht mit erscheinen) und führt gelegentlich zu ungewollten Löschungen der Inhalte von Tabellen, die dann das ganze System lahmlegen können.

Zuletzt geändert von Kowa am 27. Februar 2007 15:18, insgesamt 1-mal geändert.

Wichtig
Bei jedem DELETEALL prüfen , dass es tatsächlich um eine Recordvariable mit TEMPORARY - Property handelt. Diese Eigenschaft ist leider viel zu versteckt ( müsste eigentlich in der Übersicht mit erscheinen) und führt gelegentlich zu ungewollten Löschungen der Inhalte von Tabellen, die dann das ganze System lahmlegen können.

Guter Hinweis
Ein anderer Nachteil dieser Implementierung ist, dass gerade Neulinge sich einen Ast absuchen, wenn sie nach der Einstellung für temp. Tabellen suchen! *ärger*

Hallo zusammen,

zu diesem Thema hätte ich auch eine Frage: Um was für temporäre Tabellen handelt es sich hier genau?
Ich weiß von unserem NSC, dass einige echte Tabellen angelegt wurden um diese bei Bedarf zu füllen. Das hat natürlich den Nachteil, dass diese Tabellen lizenziert werden müssen. Allerdings gibt es auch bei Globalen Variablen vom Typ Record eine Eigenschaft die sich Temporary nennt. Ist diese Eigenschaft hier gemeint und kann ich das z.B. dafür verwenden um die Struktur einer Tabelle zu verwenden ohne die eigentlichen Datensätze zu verwenden? Ich bin da ein bißchen vorsichtig, weil mit DeleteAll würde ich ja alle Datensätze löschen und da ist es mir zu gefährlich, das zu testen, wenn dann auch die nicht-temporären DS weg sind

Gruß
Alez

Ich weiß von unserem NSC, dass einige echte Tabellen angelegt wurden um diese bei Bedarf zu füllen. Das hat natürlich den Nachteil, dass diese Tabellen lizenziert werden müssen.

Das stimmt (nach meinem Kenntnisstand) nicht. Temp. Tabellen müssen nicht lizensiert sein, da sie nur clientseitig verwendet werden.

Allerdings gibt es auch bei Globalen Variablen vom Typ Record eine Eigenschaft die sich Temporary nennt.

Genau das ist eine temp. Tabelle.

Ich bin da ein bißchen vorsichtig, weil mit DeleteAll würde ich ja alle Datensätze löschen und da ist es mir zu gefährlich, das zu testen, wenn dann auch die nicht-temporären DS weg sind

Solange (und nur) Temporary = yes ist, kannst du dir sicher sein, keine Echtdaten zu löschen.

Hi zusammen,

irgendwie verstehe ich das jetzt nicht. Temporäre Tabellen gibt es doch gar nicht. Es gibt doch nur die Möglichkeit eine Record-Variable als "Temporär" zu deklarieren.

Wenn ich also eine neue Tabelle haben will muss ich diese lizensieren. Egal ob ich die später über eine Record-Variable temporär oder nicht temporär einbinde.

Gruß, Marc

Zur Laufzeit müssen die temp. Tabellen nicht lizensiert sein, während der Entwicklung aber schon. Ein MBSP kann z.B. eine Tabelle 66666 anlegen und der Kunde diese im Report temporär verwenden, ohne dass sie lizensiert ist. Mit der Kundenlizenz alleine kann diese Tabelle aber nicht erstellt werden, auch wenn sie nur temporär verwendet werden soll. Die Property hängt ja nicht an der Tabelle , sondern an der Recordvariable.

Wir verwenden auch oefters mal temp. Tabellen, allerdings war mir das mit der Lizenz gar nicht so bewusst. :)

Danke fuer die Info.

Gruesse
feri

Hallo zusammen,

da habe ich ja was losgetreten
Was ich meinte, ist, dass unsere NSC Tabellen angelegt hat, die z.B. ein "temp." oder auch "temp 2" im Namen haben, und somit deutlich als temporäre Tabellen deklariert sind. Aber so wie ich das jetzt verstehe, kann ich in einem Report auch hergehen und z.B. die Tabelle Item nehmen, als temporary einstellen und anschließend die Struktur und die Funktionen dieser Tabelle nutzen, ohne aber mit den echten Daten zu arbeiten. Das würde zum Beispiel bedeuten, dass ich alle DS aus der echten Tabelle einlesen und für diesen Report beliebig verändern kann, ohne dass es Auswirkungen auf die Stammdaten hat.
Ist das richtig so?

Gruß
Alez

Das würde zum Beispiel bedeuten, dass ich alle DS aus der echten Tabelle einlesen und für diesen Report beliebig verändern kann, ohne dass es Auswirkungen auf die Stammdaten hat.
Ist das richtig so?

Ja!

Das würde zum Beispiel bedeuten, dass ich alle DS aus der echten Tabelle einlesen und für diesen Report beliebig verändern kann, ohne dass es Auswirkungen auf die Stammdaten hat.
Ist das richtig so?

Ja!

Vorsicht! Der Trigger-Code greift weiterhin auf die physikalischen Tabellen zu, also solltest du genau wissen, was in den OnValidate, OnModify, OnInsert, ... passiert, sonst könntest du ein riesiges Problem bekommen.

Was ich meinte, ist, dass unsere NSC Tabellen angelegt hat, die z.B. ein "temp." oder auch "temp 2" im Namen haben, und somit deutlich als temporäre Tabellen deklariert sind.

Auch die Variante wird genutzt. Es kann vorkommen, das die Vorhandenen Tabellen für die gewünschten Zwecke nicht geeignet sind.
In diesem Fall erstellt man sich eine Tabelle *temp oder *Buffer.

Allerdings geht eine Tabelle "Flöten"

Vorsicht! Der Trigger-Code greift weiterhin auf die physikalischen Tabellen zu, also solltest du genau wissen, was in den OnValidate, OnModify, OnInsert, ... passiert, sonst könntest du ein riesiges Problem bekommen.

Das war mir auch noch nicht bekannt, danke für die Info


Gruß Mikka

Timo hat völlig recht; der Grund, warum ich nicht daran gedacht hatte war:
Die temp. Tabellen werden eigentlich fast immer in der Form

Code:

Temp.RESET;
Temp.DELETEALL;
Temp := Beispielrec;
Temp.INSERT;

verwendet. Zumindest habe ich noch keine temp. Records angetroffen, in denen auch nur ein Trigger ausgeführt worden ist.

[...]
Was ich meinte, ist, dass unsere NSC Tabellen angelegt hat, die z.B. ein "temp." oder auch "temp 2" im Namen haben, und somit deutlich als temporäre Tabellen deklariert sind.
[...]

Da würde ich mich nicht 100%ig drauf verlassen, dass diese Tabellen wirklich für die temporäre Nutzung gedacht sind, denn ich erlebe es häufig, dass Programmierer eine (Sicherungs-)Kopie des Objektes mit "Objektname Temp", "Objektname Backup" oder dergleichen anlegen und später vergessen, es zu löschen.

Diese Unart macht dann besonders freude, wenn diese Backup-Objekte auch noch im vom Kunden lizenzierten Bereich liegen und somit echtes Geld kosten, obwohl sie nicht genutzt werden.
Da darf man sich dann stundenlang mit dem NDT beschäftigen und für jedes Objekt einzeln recherchieren, ob es nicht doch irgendwo noch referenziert wird.

Wenn schon kein CVS-System eingesetzt wird, dann sollte man Backups von Objekten immer durch Export in ein entsprechendes Verzeichnis vornehmen.

Im Navision-Standard sind Tabellen, welche ausschließlich temporär genutzt werden, immer mit "Buffer" (DEU: Puffer) im Objektnamen gekennzeichnet.
Der Übersichtlichkeit halber sollte man sich auch weiterhin an diese Namenskonvention halten.

Diese Unart macht dann besonders freude, wenn diese Backup-Objekte auch noch im vom Kunden lizenzierten Bereich liegen und somit echtes Geld kosten, obwohl sie nicht genutzt werden.
Da darf man sich dann stundenlang mit dem NDT beschäftigen und für jedes Objekt einzeln recherchieren, ob es nicht doch irgendwo noch referenziert wird.

An dieser Stelle möchte ich auch das "Geliebte Dokumentieren" erwähnen.
Ich könnte jeden Entwickler der nicht Dokumentiert "erschlagen" (Natürlich nicht wirklich!)

Ich habe bereits mehrfach DB´s mit umfangreichen Anpassungen vorgefunden, in denen gerade mal das hier geschrieben war

Code:

// 001 xyz +++
    ...Hier irgendwelcher Code
// 001 xyz ---


Leider nirgens eine weiter Info, was die Änderung soll oder Dokumente in schriftlicher Form.

Gruß Mikka

Hallo zusammen,

war leider kurzzeitig krank, hätte aber noch Fragen

Da würde ich mich nicht 100%ig drauf verlassen, dass diese Tabellen wirklich für die temporäre Nutzung gedacht sind, denn ich erlebe es häufig, dass Programmierer eine (Sicherungs-)Kopie des Objektes mit "Objektname Temp", "Objektname Backup" oder dergleichen anlegen und später vergessen, es zu löschen.[...]

Das habe ich leider auch schon erlebt, auch so Spielereien, dass die Tabellen "Reserviert für [Firmenname]" hießen. Damit tauchen sie nicht mehr in den freien, lizenzierten Tabellen auf, weil sie ja schon "verwendet" wurden.
Was diese Puffertabellen betrifft habe ich schon fast vermutet, dass sie erstellt wurden, um eine geeignete Tabelle zur Hand zu haben. Leider kann ich nicht in alle rein schauen um zu prüfen wie die aufgebaut sind und leider sind die auch nicht alle nach den Namenskonventionen, aber jetzt weiß ich zumindest wofür die sind.


Danke auch für die Hinweise mit dem Trigger, d.h. also ich sollte aufpassen, dass ich keine Validates oder ähnliches mache, aber wie schaut es z.B. mit etwas in dieser Form aus:

Code:

IF Einheit = 'Meter' THEN
  Item."Base Unit of Measure" := 'Meter'
ELSE
  Item."Base Unit of Measure" := 'Stück';

Gruß
Alez

Selbstverständlich darfst du alles mit den temporären Tabellen machen, du solltest nur sehr vorsichtig bei dem Umgang mit VALIDATEs sowie der Ausführung der OnInsert-, OnModify-, ... -Trigger sein.
Sofern in dem Trigger nur Felder desselben Datensatzes modifiziert werden ist das kein Problem, erst wenn aus diesen Triggern auf andere Tabellen zugegriffen wird, wird es gefährlich, da diese Referenzierungen wieder auf die physikalischen Tabellen zugreifen.

Leider kann ich nicht in alle rein schauen um zu prüfen wie die aufgebaut sind und leider sind die auch nicht alle nach den Namenskonventionen, aber jetzt weiß ich zumindest wofür die sind.

Das stimmt, du kannst nur noch sehen welche Felder vorhanden sind (jedoch ohne Typ oder Grösse!).
Den Zugriff auf diese Tabellen bekommt man wie zuvor Beschrieben nur, wenn die Tabelle als Temporär in den Variablendefinitionen deklariert ist!.
Gruß Mikka