Hallo Herr Herbert,

ich vermute mal der Lookup Heater soll anhand einer IF-THEN-ELSE Bedingung nur ausgeführt werden, wenn ein bestimmtes Kriterium erfüllt ist, so kommen Sie auf 780x Lookup Heater?

Das Problem hier ist, der FlowHeater führt immer alle Heater/Funktionen 1x aus die eine Verbindung zur WRITE Seite haben oder aber durch einen anderen Heater (z.B. Set) gerufen werden und das unabhängig ob hier der „Wenn/Then“ bzw. „Dann/Else“ Fall zurückgegeben wird.

Dafür ist doch die Performance nicht schlecht 

Sie können das aber über den .NET Script Heater umsetzen. Wenn Sie hier im Skript die Bedingung einbauen, wird der Lookup bzw. das SQL auch nur ausgeführt, wenn die Bedingung zutrifft.
 

Hallo Herr Herbert,

also wenn es sich nur um ein paar zehntausend Datensätze handelt würde ich pro Feld einen eigenen SQL Heater oder aber Lookup Heater verwenden. Oracle bzw. auch andere DBMS-Systeme können das gut skalieren, der Datensatz ist ja bereist eh schon selektiert bzw. im Cache und es muss nur eine andere Spalte bzw. Feld zurückgegeben werden. Natürlich muss hier immer pro Feld ein erneuter Connect zur Oracle Datenbank aufgebaut werden, was bei sehr vielen Daten sich dann schon aufsummiert.

Alternativ dazu könnte das über den  SQL Heater durchgeführt werden. Hier müssten Sie aber im SELECT die Felder selbst zu einem Feld zusammenführen, da der  SQL Heater nur eine Feld zurückgeben kann. Das ist dann gerade bei nicht Zeichenfolgen mit der Formatierung teilweise nicht ganz so einfach.

z.B. reine Textfelder über: select concat(feld1, ‘#’, feld2, ‘#’, feld3) from ihre_tabelle where pk = ‘$ID$’

Im Anschluss können Sie dann die Rückgabe mit dem String Split Heater und dem Trennzeichen ‚#‘ wieder auseinander splitten.
Sie werden die Daten über einen zusätzlichen Connect zur Oracle Datenbank geholt, sie sparen sich pro CSV-Zeile bei 3 Feldern 2 zusätzliche SQL-Abfragen.

Aus meiner Sicht ist der Kosten/Nutzen Faktor erst bei wirklich großen Datenmengen relevant, ansonsten würde ich immer einfach mehrere  SQL Heater oder aber  Lookup Heater verwenden.
 

Hallo Herr Mundt,

in Ihrem Screenshot lesen Sie auf der READ-Seite die InMemory Adapter Tabelle „hkv_swg“. Wenn Sie von hier lesen können Sie die Felder von der READ-Seite direkt mit der WRITE Seite verbinden. Der SQL Heater ist aus meiner Sicht an der Stelle überflüssig!

Der SELECT, den Sie im SQL Heater verwenden, ist so falsch. Sie können hier lediglich ein einzelnes Feld oder aber eine Aggregatsfunktion wie COUNT, SUM, etc. verwenden, so dass immer nur ein Feld zurückgegeben wird.

    z.B.  select count(*) from [hkv_swg]

Um Ihre Oracle Daten ebenfalls zu verwenden, können Sie diese einmal in die InMemory Adapter Tabellen mit einmischen oder aber per SQL Heater oder aber Lookup Heater in die Definition reinholen. Alternativ und etwas einfacher geht der Lookup auf InMemory Adapter Tabellen auch mit String Replace Heater . Für eine etwas genauere Beschreibung bräuchte ich etwas mehr Informationen was genau gemacht werden soll.

 

Hallo Herr Monschau.

der Lookup Heater ist eine vereinfachte Version vom SQL Heater . Im Lookup Heater geben Sie lediglich die Tabelle, das gewünschte Feld und ggf. eine Einschränkung an was Sie abfragen möchten, hier sind so gut wie keine SQL Kenntnisse erforderlich. Wenn Sie z.B. in MS Access die VBA Funktion DLookup kennen, die funktioniert so ähnlich.

Mit dem SQL Heater können Sie beliebige SQL Statements absetzen, erfordert aber einiges an SQL Kenntnisse.

Wenn Sie auf der READ Seite eine CSV Datei sowie auf der WRITE Seite eine Datenbank haben wohin Sie importieren möchten und Sie benötigen noch weitere Felder für den Import die in dieser Datenbank in anderen Tabellen stehen, dann müssen Sie im SQL bzw. Lookup Heater die WRITE Seite angeben, so wird die Abfrage auf dieser Seite bzw. Datenbank ausgeführt. Wenn Sie in dem Fall die READ Seite auswählen wird es einen Fehler geben, da der TextFile Adapter keine direkten Lookups bzw. den SQL Heater nicht unterstützt.

 

Hallo Herr Stein,

bei der Analyse bin ich auf eine evtl. Erklärung gekommen. Verwenden Sie in der Definition den SQL Heater , Lookup Heater oder aber .NET Script Heater um damit weitere Werte aus evtl. anderen Tabellen von der READ Seite der Oracle Datenbank abzufragen?

Dann ist das Problem, dass der Oracle Adapter in diesem Fall eine Datenbank Transaction über die Gesamte Laufzeit aufspannt. Leider kann das mit der aktuellen Version auf der READ Seite nicht geändert werden.

In der aktuellen Beta Version wurde das Transaktionsverhalten dahingehend geändert, dass das Datenbank Transaktionsverhalten auch auf der READ Seite geändert werden kann.

Die aktuelle Beta Version können Sie über folgenden Link herunterladen: Download Beta Version

Hier bitte mal folgenden Einstellungen, siehe Screenshot unten, verwenden. Falls Sie nur lesend zugreifen also keine Updates, etc. auf der READ Seite verwenden können Sie die Transaktionen auch komplett deaktivieren.

 
 

Hallo Herr Herbert,

hier mal 2 C# Skripte wie das mit dem .NET Script Heater durchgeführt werden kann. Der erste Parameter wird geprüft und nur wenn dieser mit „WAHR“ ausgewertet werden kann wird der Lookup bzw. das SQL abgesetzt.

SQL per Skript Ausführen

Daten Lookup per Skript ausführen  

bitte setzen Sie auf dem Lookup Heater mal einen Haltepunkt. Hierzu einfach mit der rechten Maustaste das Kontextmenü öffnen und „Haltepunkt“ auswählen. Der Lookup Heater wird nun mit einem roten Kreis dargestellt. Wenn Sie die Definition nun im Testmodus ausführen hält die Verarbeitung hier an und Sie können sich die Ein- und Ausgehenden Daten ansehen. Ich vermute, dass hier ein Problem mit der Formatierung vorliegt?

Alternativ könnten Sie auch den SQL Heater verwenden. Hier können Sie den SQL Befehl selbst aufbauen.