FlowHeater Demo Video
 
Der Daten Import / Export Spezialist
 
Willkommen, Gast
Benutzername: Passwort: Angemeldet bleiben:
×

Erweiterte Suche

Suche nach Stichwort
×

Suchoptionen

Finde Beiträge von
Ergebnisse sortieren nach
Suche zu einem bestimmten Zeitpunkt
Zu Resultat springen
Suche in Kategorien
×

Suchergebnisse

Gesucht wurde: SQL Lookup
03 Nov 2011 07:36
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Herr Dr. Schwindler,

der Datenbank Lookup Heater ist zugegegen etwas schwierig in der Anwendung. Deshalb gibt es seit Version 2.2.1 den neuen SQL Heater . Hier können Sie das SQL Statement

select max(date) from dates

eintragen um das letzte Datum aus der SQLite Tabelle DATES zu lesen. Als Ausführungszeitpunkt wählen Sie "Start" den Rückgabewert müssen Sie noch in einem Parameter zwischenspeichern. Diesen Parameter rufen Sie dann mit dem ebenfalls neuen Parameter Heater ab und weisen den Wert Ihrem Datumswert zu.

In der Anlage habe ich Ihre Definition um diese Funktionalität erweitert.

PS: SQLite unterstützt keinen Datumstyp. Evtl. müssen Sie noch das Format Ihres Datums umstellen, damit das SQL MAX Statement auch den richtigen (aktuellen) Datensatz erwischt. Z.B. Format (yyyy-mm-dd)!

Anhang excel_import_sqlite_2.zip wurde nicht gefunden.

Kategorie: Excel Adapter
20 Aug 2011 11:42
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Der Lookup Heater benötigt in der WHERE Bedingung

z.B. ARTIKELID = $1

In diesem Fall müssen Sie die Artikel-ID von der READ Seite mit dem Lookup Heater verbinden. Der Lookup Heater nimmt dann diesen WERT und tauscht dann $1 mit dem Eingangsparameter aus.

Ich denke das wird die Verarbeitung nicht beschleunigen, da hier bei jedem Datensatz ein zusätzlicher SQL SELECT auf die externe MySQL Datenbank durchgeführt wird. Wahrscheinlich wird dieser Lösungsweg noch länger benötigen.

Hier 2 mögliche Ansätze wie sie das evtl. beschleunigen können
  1. Sie fahren immer einen kompletten Abgleich. Verbinden Sie für das UPDATE aber lediglich den Primary Key der Tabelle (ArtikelID) sowie das Feld das Sie aktualisieren möchten (Bestand). Hierdurch werden wesentlich kleinere SQL Update Statements gebildet.

    z.B. UPDATE IHRE_TABELE SET BESTAND = 123 WHERE ARTICLEID = 5000

    Das wird zwar auch keine Wunder vollbringen aber ca. 1/3 sollte das schneller durchlaufen als vorher.
  2. Sie fügen in Ihrer lokalen Tabelle ein neues Feld z.B. "OnlineBestand" ein. Dieses Feld der READ Seite aktualisieren sie in der Update Definition über einen .NET Script Heater jedes Mal mit dem aktuellen Wert. So können Sie schon auf der lokalen Seite prüfen ob Sie was aktualisieren müssen

    z.B. select * from lokale_tabelle where bestand <> onlinebestand

    So werden nur wirklich geänderte Datensätze in der MySQL Datenbank aktualisiert.

    Ein ähnliches Beispiel finden Sie hier: Datenvergleich beim Import
    Im Skript müssten Sie hier AdapterWrite mit AdapterRead ersetzen!
Falls Punkt 2) in Frage kommt, kann ich Ihnen dazu auch ein kleines Beispiel anfertigen.
Kategorie: ODBC Adapter
19 Aug 2011 11:29
  • derIch
  • derIchs Avatar
Hallo,

ich komme in dieser Sache nicht weiter. Bei einem Abgleich zwischen einer ODBC-Tabelle auf der Read-Seite und einer MySql-Tabelle im Netz möchte ich nur dann den Wert auf der SQL-Seite verändern wenn dieser ungleich dem auf der ODBC-Seite ist.

Es geht um den Abgleich von Lagerbeständen zwischen diesen beiden Seiten. Blindes abgleichen funktioniert zwar dauert aber knapp 40 min.
Vorhanden ist auf beiden Seiten eine eindeutige Artikel-ID und auf ODBC-Seite das im Adapter berechnete Feld Bestand. Auf SQL-Seite existiert ein vorhandenes Feld für den Bestand.

Ich probiere es mit 2 x Lookup und einmal IfThenElse dazwischen. Ich bekomme aber nur die Fehlermeldung "Lookuo Error! select products_quantity from products where".

Mir fehlt der Eintrag in Where. Ich weiß nicht welche Angaben dort rein müssen wenn es keine festen Werte sind sondern ein Feld verglichen werden soll.

Für die Mühe besten Dank im voraus!
Kategorie: ODBC Adapter
07 Jul 2011 05:34
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Ja, da haben Sie Recht, der ist hier durchaus verbesserungswürdig. Was auch nicht ganz schön gelöst ist, ist dass der Lookup Heater Eingangsparameter anhand des Typs in das SQL WHERE Statement formatiert.

z.B.
Eingangsparameter ist Integer WHERE "ID = $1" wird zu ID = 1001
Eingangsparameter ist String WHERE "ID = $1" wird zu ID = '1001'

Bei Datumsangaben ist es noch schwieriger, da hier Datenbanken die meisten Unterschiede aufweisen.

Da es nicht ganz einfach ist an dieser Stelle alle erdenklichen Datenbanken (Access, MS SQL Server, MySQL, Oracle, ODBC bzw. OleDB) abzubilden wurde das bisher nicht weiter angegangen.

Ihr Verbesserungsvorschlag wurde mit auf die TODO Liste gesetzt, demnächst wird der Datenbank Lookup Heater deutlich verbessert.

Für Spezial Lookups können Sie auch den .NET Script Heater mit folgendem Skript verwenden. Datenbank, Schema etc. können hier frei definiert werden.
public object DoWork()
{
  if (InValues.Length != 1)
    throw new Exception("1 Eingangsparameter erwwartet");

  // ersten Eingangsparameter holen
  string sID = (string)InValues[0].GetString();
  if (sID == null)
    return null;

  // folgendes SQL Statemnet falls ID als (Ganz)Zahl in der Tabelle definiert ist
  string sql = "select IHR_WERT from IHRE_TABELLE where ID = " + sID;

  // folgendes SQL Statemnet falls ID als CHAR/VARCHAR in der Tabelle definiert ist
  //string sql = "select IHR_WERT from IHRE_TABELLE where ID = '" + sID + "'";

  return AdapterWrite.Execute(sql, true);

  // oder für ein Datenbank Lookup auf der READ Seite
  return AdapterRead.Execute(sql, true);
}
Kategorie: Anregungen
06 Jul 2011 14:10
  • Stephan Sempert
  • Stephan Semperts Avatar
Im Feld "Tabelle" des Loopup-Heaters kann prinzipiel auch eine Tabelle in einer anderen als der aktuellen Datenbank angesprochen werden. Allerdings macht es eine Automatik von FH etwas, ... unhandlich?.

Die Schreibweise (mindestens beim MS-SQL-Server) für solche Verweise lautet:

Datenbank.Schema.Tabelle
also z.B.
Kundenverwaltung.dbOwner.Adressen

Das Problem: FH schreibt um den Tabellennamen die optionalen " [ ] " . Das ist einerseits gut, weil damit eventuelle Leerzeichen im Namen keine Fehler im SQL-Code verursachen.

Beispiel [Adressen alt]

Andererseits ist das nicht so gut, weil dass bei Verweisen ausserhalb der aktuellen Datenbank nicht funktioniert.

Beispiel:
[Kundenverwaltung.dbOwner.Adressen] -> falsch!
[Kundenverwaltung].[dbOwner].[Adressen] -> richtig!

Als Workaround kann man Verweise ausserhalb der aktuellen Datenbank so schreiben:

Kundenverwaltung].[dbOwner].[Adressen

FH macht dann daraus die korrekte Syntax:
[Kundenverwaltung].[dbOwner].[Adressen] -> richtig

Vielleicht könnte man die Eigenschaften im Heater LookUp um optionale Felder "Datenbank" und "Schema" erweitern und so eine "korrekte" Syntax ermöglichen?

BG
Stephan
Kategorie: Anregungen
07 Mär 2011 15:22
  • Ugo Romolini
  • Ugo Romolinis Avatar
Guten Tag

Ich bin neu hier und habe Ihr Programm erst kürzlich erworben und bin fleissig daran Daten in ein MS-SQL-System
zu importieren.
Der Import von Kundenstammdaten aus verschiedenen Systeme
habe ich bereits realisiert.

Nun bin ich daran die Umsatzdaten zu importieren.
Da habe ich folgendes Problem.
In der Datenbank befindet sich das Feld [BELART] für
Belegart und das Feld [Gesamtwert] für Umsatz.
Wenn die Belegart="G" ist (für Gutschrift) muss
ich das Feld [Gesamtwert] mit -1 multiplizieren

Das .Net setze ich auf die Linie Gesamtwert und
im Script möchte ich den Inhalt des Feldes [BELART]
abfragen und dann mache ich die Kontrollstrukturen mit IF oder CASE.
Wie frage ich den Inhalt BELART in VBScript ab?

Ich möchte dies mit dem VB Script lösen, da ich einige Erfahrungen mit VBA habe.

Könne Sie mir da weiter helfen?
Besten Dank im Voraus.
Ugo Romolini
Kategorie: SqlServer Adapter
20 Jan 2011 20:00
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Herr Höning,

die Verarbeitung geht immer von links nach rechts. Ich beschreibe das jetzt mal anhand der zweiten Filterbedingung im Beispiel. Die ERP Nummer brauchen Sie nicht in die WRITE Seite aufnehmen, der Lookup Heater kann auch auf andere Tabellen der READ/WRITE Seite zugreifen.

Pro Datensatz/Zeile wird folgendes aufgerufen:
  1. Der Lookup Heater erhält als 1. Paramater die aktuelle ERP Nummer zugeteilt
  2. Anhand der gemachten Vorgaben im Lookup Heater wird folgender select ausgeführt
    select erp from t_erp where erp = '100'
    Wenn Sie hier die andere Tabelle verwenden, wird die ERP Nummer auch in dieser Tabelle gesucht!
  3. Der Wert dieser Abfrage wird zum If-Then-Else Heater weitergereicht. Hier wird geprüft ob der WERT DBNULL bzw. NULL ist. Sie wollten ja prüfen ob der Wert vorhanden ist.
  4. Anhand dieser Bedingung wird entweder JA/TRUE/1 oder NEIN/FALSE/0 an den Filter Heater weitergereicht. Schauen Sie sich hierzu mal die Hilfe zum If-Then-Else Heater an.
  5. Der Filter Heater entscheidet nun lediglich anhand des Wertes ob die Zeile gefiltert wird oder nicht.
    JA/TRUE/1 = die Zeile/der Datensatz wird gefiltert
    NEIN/FALSE= = die Zeile/der Datensatz wird normal verarbeitet

Beim Wert 100, würde der Lookup Heater DBNULL liefern = (in der Datenbank nicht vorhanden) dies wandert zum If-Then-Else. Hier wird geprüft "ist der Wert vom Lookup Heater = (gleich) DBNULL" und es wird TRUE an den Filter Heater weitergereicht. So wird der Datensatz gefiltert bzw. nicht weiter verarbeitet.

Werte nur Updaten wenn anderer Wert vorhanden ist.
Hierzu habe ich Ihnen wiederum 2 kleine Beispiele erstellt, siehe Anlage update_mit_bedingung.zip

Hier wird die Bezeichnung in einer Tabelle gesucht, nur wenn diese gefunden wurde wird die Kundennummer auf der WRITE Seite gesetzt bzw. aktualisiert.

Der Lookup Heater sollte jetzt klar sein. Schauen Sie sich den ersten If-Then-Else Heater an. Hier sehen Sie, dass der Heater einen 2. Eingangsparameter hat. Dieser Parameter wird zurückgeleifert wenn die Bedingung zutrifft. Der Ausgang wandert dann zum Feld Kundennummer der WRITE Seite. Ist die Bedingung "Wert vom Lookup Heater != (ungleich) DBNULL" wird das Feld Kundennummer zur WRITE Seite durchgereicht. Wurde der Wert nicht gefunden, wird auf der WRITE Seite der Wert auch nicht gesetzt bzw. verändert. Sie können Sich das mal anschauen, indem Sie die erste Beispieldefinition im Testmodus mal ausführen. Hier sehen Sie den Eintrag [FH:not set] bei der ERP Nummer 400. Schauen Sie sich auch mal das SQL Skript an, hier sehen Sie, dass hierfür kein SQL Update Statement erzeugt wurde. Wenn Sie aus dieser Definition den X-Value Heater mal löschen und anschließend die Definition erneut starten werden Sie feststellen, dass due Fehlermeldung "Die Update Anweisung hat keine Daten generiert …" erscheint. Dies hat den Grund, dass hier in dem Beispiel bei der ERP Nummer 400 weiter keine geänderten Daten vorhanden sind.

In der 2. Definition lasse ich diese Zeile/Datensatz wiederum über den Filter Heater filtern, so dass keine Fehlermeldung erscheint.

Anhang update_mit_bedingung.zip wurde nicht gefunden.

Kategorie: Allgemein
17 Jan 2011 20:56
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Herr Höning,

Wenn Sie nur Datensätze der READ Seite importieren wollen wo die ERP Nummer auf der WRITE Seite noch nicht vorhanden ist, lässt sich das denke ich ganz einfach lösen.

Sie brauchen dazu auf der WRITE Seite im Configurator lediglich die Option "Daten anfügen (Insert)" sowie "vorhandene Datensätze ignorieren" aktivieren. Zusätzlich müssen Sie dann noch auf dem Reiter "Felder / Datentypen" den Primary Key nur auf das Feld "ERP Nummer" umbiegen. Feld anklicken und die Option "Primary Key" aktivieren bzw. deaktivieren.

Hinweis: Hiermit wird das Tabellenschema nicht verändert, Sie teilen dem FlowHeater damit lediglich mit anhand welcher Werte er evtl. Update SQL Statements generieren muss bzw. wie in diesem Fall prüfen soll ob ein Wert bereits vorhanden ist.

Falls das Ihr Problem nicht löst, können mittels des Lookup und If-Then-Else Heaters noch wesentlich komplexere Filter Kriterien gebastelt werden. Gerne erstelle ich Ihnen dazu auch ein kleines Beispiel.
Kategorie: Allgemein
17 Dez 2010 06:26
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Herr Maul,

dazu benötigen Sie in diesem Beispiel zusätzlich einen .NET Script Heater und folgendes kleines C# Skript.
bool bFirst = true;

public object DoWork()
{
	// nur beim 1. Aufruf und nicht im Testmodus!
	if (bFirst && AdapterWrite.OnlyTest == false)
	{
		bFirst = false;
		
		// alle Datensätze mit L vorbelegen
		// hier die Tabelle uns das Feld anpassen
		AdapterWrite.Execute("update t_Vergleich1 set FeldP = 'L'");
	}

	// Eingangsparamter für die weitere Verarbeitung wieder zurück
	return InValues[0].GetValue();
}

Das Skript führt vor dem eigentlichen Import lediglich einen Update auf der Zieltabelle aus. Es werden alle Datensätze mit einem 'L' vorbelegt. Danach startet die Definition und aktualisiert diese Werte mit dem Inhalt 'A' falls der Datensatz gefunden wurde. Neue Datensätze werden beim Import dann mit einem 'N' hinzugefügt. In der CSV Datei nicht mehr vorhandene Datensätze haben somit den Wert 'L' durch das SQL Update Statement vom .NET Script Heater.

Um das Skript verwenden zu können. Müssen Sie das SQL Update Statement an Ihre Tabellen und Feldnamen anpassen (s. dazu auch den Kommentar im Skript).

PS: Die 2 Beispiele wurden im Anhang angepasst.

Anhang Lookup-20101217.zip wurde nicht gefunden.

Kategorie: Access Adapter
08 Nov 2010 20:48
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Herr Warth,

Für Ihr Problem gibt es 2 mögliche Fehlerquellen:
  1. Sie haben den Parameter $1 in einfache Hochkommas eingeschlossen z.B. PtMRN = ‚$1‘, dafür spricht die Fehlermeldung die Sie gepostet haben.
  2. Das Feld PtMRN ist kein Alphanummerischer Datentyp (SQL Datentypen char, nchar, varchar, nvarchar, text) sondern ein Zahlen Datentyp (SQL Datentyp int, long, float, numeric, …). In diesem Fall müssen Sie den FlowHeater Datentyp des Eingangsparameters für $1 auf INT (oder Double bzw. Currency) umstellen. Dafür spricht die WHERE Klausel die Sie gepostet haben.

Ich denke Ihr Problem liegt an der 1. Möglichkeit. Sie haben bei der WHERE Bedingung den Parameter $1 in einfache Hochkommas gesetzt!

Falsch = PtMRN = '$1' -> wird aufgelöst nach PtMRN = 'N'ihre daten''
Richtig = PtMRN = $1 -> wird aufgelöst nach PtMRN = N'ihre daten'

Hintergrund:
Der Lookup Heater formatiert automatisch den/die Parameter anhand des eingehenden Datentyps. Kommt z.B. eine Zeichenkette an wird der Parameter automatisch mit einfachen Hochkommas umschlossen. Das N' vorneweg zeigt der Datenbank an, dass die Daten/Zeichen die geliefert werden als UNICODE Daten/Zeichen interpretiert werden sollen. Das N' ist Adapterabhängig und kann über die Adapter Eigenschaft "UseUnicodeStrings" angepasst werden. Im Normalfall brauchen Sie hier keine Änderungen vornehmen.

Ist der eingehende Datentyp eine Zahl, formatiert der Lookup Heater die WHERE Klausel so, dass die Datenbank z.B. auch Nachkomma stellen und Tausendertrennzeichen (Punkt oder Komma) richtig verarbeiten kann. Dieses Vorgehen ist unabhängig von der Formateinstellung vom WRITE Adapter.

Bei Datumsangaben ist das Problem am gravierendsten. Hier werden je nach Datenbank komplett unterschiedliche WHERE Klauseln gebildet.

z.B.
MS Access = where feld = #2010-11-08#
MS SQL Server = where feld = '2010-11-08'

Aus diesem Grund dürfen Sie bei den Parametern der WHERE Klausel keine Hochkommas, oder Ähnliches mit angeben.
Kategorie: SqlServer Adapter
08 Nov 2010 11:11
  • Rainer Warth
  • Rainer Warths Avatar
Hallo,
ich komme mit dem LookUp heater nicht zurecht. Ich konnte den Heater einamal erfolgreich einseitzen für ein LookUp auf der Read Seite. Für ein anderes Problem mit einem LookUp auf der Write Seite bin komme ich nicht weiter.

Situation:
Read Seite: MS-Access Tabelle: SA10_Patienten
Write Seite: SQL-Server, Database:Caisis, Tabelle: Pathology
Heater: LookUp - Write
Tabelle - Patients
Field - PatientId
WHERE - PtMRN = $1

Die Variable $1 kommt von dem Datenfeld BbsNumber auf der ReadSeite. Ich würde gerne den Wert von BbsNumber in der Tabelle Patients (SQL-server, Database:Caisis) in dem Datenfeld PtMRN nachschauen und dann den Wert der PatientID zurückgeben. Wenn ich Definition ausführe erahlte ich:

LookUp Error

select [PatientID] from [Patients] where PtMRN = 'N'7609''

Mir ist nicht klar wo das 'N' herkommt und was es bedeutet.
Wenn ich das SQL satatement

select PatientId from patients where PtMRN = '7609'

in SQL Managment Studio eingebe erhalte ich den richtigen Wert = 1.

Anbei noch ein Screen shot. Vielen Dank schon mal,
Rainer
Kategorie: SqlServer Adapter
27 Sep 2010 06:33
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Herr Leonhard,

das kann ich leider nicht nachvollziehen. Ich hab eben mit einer MySQL 5.1 Datenbank getestet. Ich kann beliebige Groß/Kleinschreibung der Feld bzw. Tabellennamen verwenden, es funktioniert immer :)
Es könnte allerdings sein, dass der verwendetet MySQL Treiber zusammen mit ihrer MySQL Server Version (3.x) hier etwas anders zu hanfhaben ist?

Was am Datenbank Lookup Heater geändert wurde ist, dass die Felder in der SQL WHERE Klausel anhand des FlowHeater Typs formatiert werden. Strings mit Hochkomma und Zahlen ohne Hochkommas!
z.B.

select Feld from Tabelle where key = 1
oder
select Feld From Tabelle where key = 'test'

Hier hätte ich nach Ihrer Beschreibung den Fehler vermuhtet. Wenn Ihr Feld RECORD_ID in der MySQL Datenbank als Integer/Zahl definiert ist und Sie den Datentyp von dem FELD der CSV Datei nach dem einlesen nicht auf INT umgesetzt haben würde der select nach dem 2. Beispiel gebildet werden. Manche Datenbanken werfen hier dann bereits einen Fehler. In diesem Fall brauchen Sie nur den Datentyp der CSV Textdatei im Textfile Adapter von STRING auf INT umsetzen und die SQL WHERE Klausel wird wieder korrekt gebildet.
Kategorie: MySQL Adapter
26 Sep 2010 19:19
  • Ingo Leonhard
  • Ingo Leonhards Avatar
PROBLEM SELBST GELÖST

Da muss man erst mal hinterkommen:

Während ich in der 0.6er Version alle Bezeichnungen, so auch die Tabellennamen in den LookUp-Heatern klein geschrieben habe, müssen es nun lustigerweise solche in Großbuchstaben sein. B)
Dann funktioniert alles wieder!
Ist das schön!

Nach wie vor:

Ein Superprogramm!!!!

Gruß
Ingo
Kategorie: MySQL Adapter
26 Sep 2010 17:51
  • Ingo Leonhard
  • Ingo Leonhards Avatar
Hallo Herr Stark,

der Zugriff mit dem Update von 0.6x auf 1.2.3. klappt jetzt über den Tunnel. Ein reverser Test, also lese MySql und schreibe CSV klappte einwandfrei.
ABER: Beim "richtigen Zugriff" taucht eine neue Fehlermeldung auf:

Lookup Error!

Ich muss dazu sagen, dass ich bislang nichts geändert habe, die Funktion ist noch genau die, die ich unter 0.6 eingesetzt habe. Ich erkläre hier, was der Lookup Heater machen soll. Vielleicht finden wir gemeinsam die Lösung?

1. Ich lese eine CSV-Datei ein.
2. Dann soll der LookUp Heater in der Tabelle Adressen der Datenbank des WAWI schauen, ob es schon einen Kunden mit dem gleichen (einmaligen!!) Matchcode gibt.
3. Dazu habe ich den Eingang des Heater mit dem CSV Matchcodefeld verbunden und den Ausgang mit dem RECORD_ID-Feld der DB.
4. Im Heater ist "Feld" = RECORD_ID und
5. "Where" = Matchcoder=$1
Das Feld Matchcode auf der Write-Seite ist neben dem Feld RECORD_ID ebenfalls PrimaryKey.

So, mit dieser Einstellung lief es in der 0.6er Version einwandfrei.
Jetzt kommt diese Fehlermeldung:

LookUp Error!
select RECORD_ID where Matchcode="richtig eingelesener Matchcode-Name der CSV-Datei".

Ich hoffe, dass ich mich einigermaßen verständlich ausgedrückt habe.

Gruß
Ingo
Kategorie: MySQL Adapter
24 Jun 2010 05:27
  • FlowHeater-Team
  • FlowHeater-Teams Avatar
Hallo Reiner,

Um das abzubilden gibt es 4 Möglichkeiten.

1) Über den Primary Key der Tabelle:
Dein Ansatz mit (Insert + vorhandenen Datensätze ignorieren) war/ist schon richtig gewesen. Ich vermute mal du hast im Primary Key zusätzlich noch einen AutoWert oder ein Datumsfeld mit Sekunden oder so. In diesem Fall ist der gerade bearbeitete Datensatz natürlich unterschiedlich und wird wiederum in die Tabelle geschrieben. Sollte der Datensatz gleich sein, würde die Datenbank bei einem weiteren Insert/Import einen Fehler melden.

Du kannst auf der WRITE Seite im Configurator für den Datenbank Adapter die Felder auswählen anhand der FlowHeater Updates vornimmt bzw. prüft ob der Datensatz bereits existiert. Beim einlesen des Schemas der Tabelle sind das automatisch die Primary Key Felder. Diese können nach dem einlesen geändert werden. Bitte prüfe das nochmal und entferne einfach die Hacken für Primary Key bei den nicht gewünschten Feldern bzw. füge weitere hinzu, das ganze sollte eigentlich klappen.

2) Über eine Gruppierung:
Auf der READ Seite sortierst du die Datenquelle anhand der Felder die für dich dem Kriterium entsprechen dass der Datensatz gleich ist.

select * from deinetabelle order by feld1, feld2, …

Diese Felder ziehst du dann in der Definition alle auf einen GroupBy Heater. Hiermit werden bereits alle gleichen Datensätze auf der READ Seite zu einem Datensatz zusammengefasst, an der WRITE Seite kommt dann lediglich ein SQL Insert an. Dies hat bei großen Datenmengen den Vorteil, dass nicht (massenhaft) unnötig geprüft werden muss ob der Datensatz bereits existiert.

WICHTIG: Für eine Gruppierung im FlowHeater muss die Datenquelle sortiert sein! Sollte die Datenquelle keine Sortierung unterstützen, kannst du dafür auch den Sort Heater verwenden.

3) Über den Lookup Heater:
Hiermit kannst du dir ein (am besten immer gefülltes) Feld aus der WRITE Datenquelle zurückliefern lassen. Als Kriterium musst du wiederum alle Felder, anhand du den Datensatz identifizierst auf den Lookup Heater ziehen und eine SQL Where Klausel bilden. Den so zurückgelieferten Wert prüft du über einen IF-THEN-ELSE auf ungleich NULL, das Ergebnis dieser Prüfung muss dann noch mit dem Filter Heater verbunden werden.

Hiermit werden diejenigen Datensätze gefiltert/übersprungen, bei denen die Bedingung:
Wert vom Lookup Heater ungleich NULL = TRUE bzw. WAHR = Datensatz wird gefiltert.

4) Über den .NET Script Heater:
Ähnliches Vorgehen wie bei 3, nur können hiermit wesentlich komplexere SQL Statements gebildet und abgesetzt werden. Hierzu wird es demnächst ein eigenes Beispiel geben.



Ich würde dir die Lösung 2) vorschlagen. Ist am einfachsten zu implementieren sowie Performance technisch am günstigsten.

Hoffe damit weitergeholfen zu haben!
Kategorie: Anregungen
46 - 60 von 60 Ergebnissen angezeigt.
Ladezeit der Seite: 0.333 Sekunden

andere Sprachen

en

FlowHeater Home

de en

Impressum/Kontakt

Datenschutz

Copyright © 2009-2021 by FlowHeater GmbH.
Alle Rechte vorbehalten.

Follow us on

twitter  facebook

YouTube

 de en