DAtentypen in Kriterienausdruck unverträglich

Hallo Herr Stark,

bisher haben wir den Datenimport immer nur als Testlauf gestartet.
Da wir nun mit unserer Definition zufrieden sind, wollten wir einen "echten" Test starten und die Daten in unsere dafür gestaltete Access Tabelle importieren.

Hierzu haben wir den Haken "Testlauf" entfernt und die Anzahl der gewünschten Zeilen angegeben.

Es erscheint die im Betreff genannte Fehlermeldung.

Für mich klingt das so als wären Quell + Zielformate nicht kompatibel. Beim Testlauf erhielt ich auch eine Fehlermeldung:

"Der Wert () kann nicht in DATE umgewandelt werden" jedoch wurde mir in der Tabelle alles korrekt abgebildet.
Evtl ist das dass Problem.
Ansonsten sollten alle Formate übereinstimmten (Integers, Strings + DATE/Time).

Können Sie mir helfen das Problem einzukreisen?

Vielen Dank vorab!

Gruß

Mario Brunner
Spedition Fink

Hallo,

klicken Sie mal im Read-Adapter auf die Feldbeschriftung und kontrollieren unten im Fenster unter Common welcher Datentyp dort eingetragen ist. Der sollte kompatibel mit dem im Writeadapter sein. Ändern Sie dort ggf. den Datentypen.

Gruß
Monschau

Hallo Herr Brunner,

das kann eigentlich nur auftreten wenn Sie nach dem Einlesen des Tabellenschemas auf der WRITE Seite manuell einen (oder auch mehrere) Datentypen geändert haben.
Versuchen Sie mal auf der WRITE Seite das Schema der Tabelle erneut einzulesen, evtl. ist das Problem damit schon behoben. Sollte das nicht klappen wäre es hilfreich wenn Sie hier kurz Ihre Definition posten.

Zur Warnung "Der Wert [] konnte nicht zu Date umgewandelt werden" die Sie erhalten:
In diesem Fall würde der FlowHeater versuchen DBNULL in das Datenbankfeld zu schreiben. Das sollte nicht das beschriebene Problem sein. Sie können das umgehen, indem Sie einen DefaultWert für dieses Feld vorgeben; im Designer über die Eigenschaften. Das Eingabeformat muss dem des jeweiligen Adapters entsprechen!

Herr Monschau schrieb:
klicken Sie mal im Read-Adapter auf die Feldbeschriftung und kontrollieren unten im Fenster unter Common welcher Datentyp dort eingetragen ist. Der sollte kompatibel mit dem im Writeadapter sein. Ändern Sie dort ggf. den Datentypen.

Das sollte eigentlich nicht notwendig sein. Der FlowHeater wandelt Datentypen dynamisch um.
Z.B. genügt es beim CVS Import auf der READ Seite alles auf den Datentyp STRING stehen zu lassen. Wenn im READ Adapter das eingehende Format richtig angegeben ist, wird das während der Transformation zur WRITE Seite dementsprechend umgewandelt.

Sollte die Datentype/Format Umwandlung nicht klappen erscheint oben stehende Warnung und DBNULL wird anstelle des Feldinhaltes verwendet. Wichtig ist nur, dass beim Import auf der WRITE Seite keine Änderungen an den Datentypen des Tabellenschemas vorgenommen werden.

Hinweis: Eingeschränkt kann das Sinn machen (z.B. nur Time, nur Date, Ganzzahlen anstelle von Zahlen mit Dezimalstellen, …), deshalb ist das hier auch nicht deaktiviert.

Hallo Herr Stark,

vielen Dank für Ihre Information.
Ich habe die Tabelle auf der Write Seite neu eingelsen,
leider wurde das Problem dadurch nicht gelöst, es erscheint nach wie vor die Fehlermeldung wie im Betreff.

Zu Testzwecken haben wir nun eine ganz simple Definition erstellt, bei der lediglich ein Wert in unsere Access Tabelle geschrieben werden soll (selbe Tabelle wie in der eigentlichen Definition)
Auch hier erhalten wir diese Fehlermeldung, obwohl hier definitiv nichts an den Eigenschaften an der Write Seite geändert wurde.

Kann das Problem an der Tabelle an sich liegen?
Kann es etwas mit den Adaptereinstellungen zu tun haben?

Vorab schon Dank für Ihre Hilfe!

Gruß

Mario Brunner
Spedition Fink

...anbei die entsprechende simple Test-Definition

...und hier die eigentliche Definition die wir gerne so verwenden würden:

Hier kann ich nichts ungewöhnliches Feststellen. Können Sie evtl. noch Testdaten (Import Datei sowie Datenbank) posten damit ich das nachstellen kann?

Anmerkung zu DPD_Def.fhd) Die mehreren Replace Heater nacheinander können Sie mit nur einem Replace Heater mit Ersetzungsliste ablösen.

Es hat sich herausgestellt dass das Problem am Atribut Sendungsnummer lag. Der Datentyp war wohl nicht passend, nachdem dieser auf String geändert wurde, konnten wir die Definition ohne Probleme ausführen.
Im Prinzip handelt es sich zwar bei der Sendungsnummer um eine Zahl, da mit dieser aber nicht gerechnet werden muss, können wir wohl mit einem String leben. Bislang gibt es zumindest keine Probleme.