Export/Import auf selber Tabelle schlaegt fehl

Hallo zusammen,

kaum habe ich den FlowHeater mit sehr simplen Aufgaben ausprobiert, laufe ich leider schon in Probleme:

Eine MS SQL 2005 Tabelle habe ich mit Flowheater exportiert. Keine Fehlermeldung, Exportdatei sieht gut aus. Diese sollte nun um einige Zeilen reduziert wieder importiert werden, was leider bei "verarbeitet 141" zu "Konvertierung varchar in datetime" mit "außerhalb gültigen Bereich" abgebrochen wird. Sehr sehr aergerlich hier: Ich sehe weder die beanstandeten Daten, noch die genaue Zeile im Importfile und erst recht kein anstaendiges Logfile des Imports.

Kann mir jemand sagen, wie ich an diese selbstverstaendlichen Daten herankomme und gibt es schon Erfahrungen zu diesen Fehlern? Die Daten in der Datei sehen wie gesagt stimmig aus, aber genauer untersuchen laesst sich das natuerlich nur, wenn ich eine anstaendige Fehlermeldung habe.

viele Gruesse
Frank


P.S.: Ich hatte auch schon Probleme mit dem Export von Daten, wo ja/nein Informationen immer gleich exportiert wurden, auch wenn ich als Ausgabe 0 und 1 konfiguriert habe.

Sie haben zwei Möglichkeiten an die Fehlerhaften Daten heranzukommen.

1. Sie fügen einen Clone Heater in die Verbindung von dem betroffenen DateTime Feld der READ zur WRITE Seite ein und aktivieren hierfür die DEBUG Ausgabe. Nun aktivieren Sie noch die Debug Ausgabe im Test und Ausführen Dialog und starten die Definition im Testmodus. In der unteren Ausgabe auf dem Reiter Debug sehen Sie welche Daten eigentlich über die Verbindung ankommen inkl. der Zeile/Row.
2. Sie aktivieren die SQL Skript Erzeugung und lassen die Definition ebenfalls nur im Testmodus laufen. Über das SQL Skript können Sie die Fehlerquelle weiter einschränken.

Meisten tauchen derartige Fehlermeldungen auf nachdem die ausgelesenen Datentypen im FlowHeater verändert wurden.

Wenn Sie hier mal Ihre Definition Posten sowie evtl. das generiete SQL Skript, können wir evtl. etwas mehr über den Fehler aussagen. Bitte die Dateien als ZIP Archiv hochladen!

Ich habe jetzt einmal ein SQL-Script erzeugen lassen - hilft leider nicht weiter. Als Ergebnis bekomme ich:

danach kommen sechs vollstaendige insert-Zeilen (Ursprungsdatei hat 32062 Zeilen). Die Anzahl finde ich auch sehr seltsam, da die Fehlermeldung erst bei Zeile 141 kommt. Zudem scheint die Reihenfolge sehr zufaellig zu sein - die 6 vorhanden Zeilen im SQL Statement sind Zeilen 19, 20, 39, 40, 74 und 81.

Ich weiß jetzt weder, WO das Problem liegt noch genau, WAS das Problem ist. In der Fehlermeldung fehlt einfach der nicht konvertierbare Wert und der genaue Fundort in der CSV-Datei.

Gerade die Formatierung der Insert Statements wäre Interessant gewesen! Werden bei Ihnen die Datumsfelder wie folgt Formatiert.

'dd.mm.yyyy HH:MM:SS' ? Wenn ja ist das falsch und Sie sind vermutlich so vorgegangen.

Sie haben eine SQL Server Tabelle in eine CSV Textdatei exportiert. Nach erfolgreichem Export sind Sie im Designer auf den Menüpunkt Adapter tauschen gegangen und haben hier für den READ Adapter den TextFile Adapter sowie für den WRITE Adapter den SQL Server Adapter eingetragen. Dann haben Sie an den Adaptern noch einige Einstellungen vorgenommen u.a. im SQL Server Adapter die Verbindung eingetragen und die Tabelle ausgewählt. Da ja durch das Adapter tauschen, vom vorherigen Export, bereits Feldnamen vorhanden waren, haben Sie vermutlich vergessen die Feldinformationen erneut einzulesen! Sollte das der Fall sein, brauchen Sie nur noch die Feld/Schemainformationen erneut einzulesen, danach sollten Datumsfelder so formatiert werden.

'yyyy-mm-dd HH:MM:SS'

Zur Sortierungsreihenfolge:
Der FlowHeater verändert nicht die Sortierung, außer Sie verwenden in der Definition den Sort Heater! Wenn Sie einen Export von einer Datenbanktabelle vornehmen und keinen Order By im SELECT Statement angeben, werden die Datensätze so geliefert/verarbeitet wie Sie im SQL Server vorliegen. Das muss nicht zwingend die Reihenfolge des Primary Keys sein. Schauen Sie sich hierzu mal die Hilfe zu Clustered Index vom SQL Server an.

Es werden nicht alle Datensätze verarbeitet:
Bitte prüfen Sie mal Ihre Definition evtl. haben Sie auf der WRITE Seite angegeben, dass vorhandene Datensätze ignoriert werden sollen? In diesem Fall werden für bereits vorhandene Datensäte keine Insert Statements gebildet. Das würde aber die oben beschriebene von mir angenommene Vorgehensweise widersprechen. Oder verwenden Sie in der Definition den Filter Heater um Datensätze zu filtern?

Zur Formatierung von Ja/Nein (BOOL) Datentyp Felder:
Bit/Boolean Felder werden zu Text Ja/Nein anhand der Format Einstellungen des WRITE Adapters umgewandelt. Sie haben mehrere Möglichkeiten das zu ändern.

1. Sie möchten für JA/NEIN lediglich 1/0 in der CSV Datei stehen haben. Hierzu brauchen Sie den Felddatentyp von STRING bzw. BOOL lediglich auf INT umstellen. Auf der WRITE Seite!
2. Über die Allgemeinen Format Einstellungen des WRITE Adapters. Gehen Sie im Configurator auf den Reiter Format und anschließend auf Bool. Die erste Zeile die Sie hier sehen bestimmt die Formatierung wie BIT/BOOL Werte Standardmäßig in Text Formatiert werden. Die restlichen Zeilen bestimmen nur welche Werte der FlowHeater für BOOL Ja/Nein ebenfalls akzeptiert.

Falls das Ihr Problem auch nicht löst, posten Sie bitte mal Ihre Definition, sowie das SQL Skript um hier eine genauere Analyse vornehmen zu können. Bitte die Dateien in ein ZIP Archiv einbinden!

FlowHeater schrieb:

Gerade die Formatierung der Insert Statements wäre Interessant gewesen! Werden bei Ihnen die Datumsfelder wie folgt Formatiert.

'dd.mm.yyyy HH:MM:SS' ?

Die Formatierung scheint richtig zu sein:
Den Reimport habe ich diesmal manuell konfiguriert, mal aus Ziel-DB ausgelesen und uebernommen, mal aus Kopfzeile. In der Konfiguration steht "dd.MM.yyyy HH:mm", was mit der exportierten CSV-Datei uebereinstimmt. Einzig die großen MM finde ich etwas verwirrend.




Zur Sortierungsreihenfolge:
Ich habe tatsaechlich beim Export manuell ein ORDER BY eingefuegt, da ich nur einen Teilbereich Reimportieren wollte (Sortiert auf Datum). Beim Import allerdings wird nichts umsortiert.



Es werden nicht alle Datensätze verarbeitet:
Es werden keine Filter eingesetzt, vorhandene ersetzen oder nicht macht keinen Unterschied - es gibt keine gleichen.



Zur Formatierung von Ja/Nein (BOOL) Datentyp Felder:

Bit/Boolean Felder werden zu Text Ja/Nein anhand der Format Einstellungen des WRITE Adapters umgewandelt.

Das hilft schon mal weiter, danke. Nicht für diesen Fall, aber wenn 0/1 weiter behandelt werden soll.

Falls das Ihr Problem auch nicht löst, posten Sie bitte mal Ihre Definition, sowie das SQL Skript um hier eine genauere Analyse vornehmen zu können. Bitte die Dateien in ein ZIP Archiv einbinden!

Das wuerde ich oeffentlich nur sehr ungerne, geht das in einer privaten Nachricht?

Ich denke das liegt am SQL Datentyp des Datumsfeldes AbrufDateTime. Welche SQL Datentyp haben Sie denn für die Datumsfelder verwendet? Der SQL Server Datentyp smalldatetime kann nur Datumsangeben bis zum Jahr 1900 speichern!
Im Feld AbrufDateTime steht aber '1899-12-30 00:00' daher kommt vermutlich die Fehlermeldung.

Haben Sie das so wirklich aus der gleichen Tabelle exportiert?

Den Reimport habe ich diesmal manuell konfiguriert, mal aus Ziel-DB ausgelesen und uebernommen, mal aus Kopfzeile. In der Konfiguration steht "dd.MM.yyyy HH:mm", was mit der exportierten CSV-Datei uebereinstimmt. Einzig die grossen MM finde ich etwas verwirrend.

Datumsformat: Die großen MM im Datumsformatstring stehen für den Monat (2 stellig), kleine mm stehen für Minuten. Diese Formatangaben wurden vom .NET Framework von Microsoft übernommen. Weitere Infos dazu finden Sie hier
http://msdn.microsoft.com/de-de/library/az4se3k1(VS.80).aspx

Das wuerde ich oeffentlich nur sehr ungerne, geht das in einer privaten Nachricht?

Sie können die Daten gerne auch an support [a t] flowheater.net schicken.

FlowHeater schrieb:

Ich denke das liegt am SQL Datentyp des Datumsfeldes AbrufDateTime. [...]
Haben Sie das so wirklich aus der gleichen Tabelle exportiert?

Ja, definitiv. Altbestand gesichert mit Flowheater, Daten (ab 10 Tage Vergangenheit bis irgendwann Zukunf) neu erzeugt (wobei Altdaten geloescht werden) und dann den Altbestand Minus der letzten 10 Tage wieder einzuspielen versucht.


Klingt logisch, danke. Irgendwie habe ich große M mit ausgeschriebenen Monatsbezeichnungen verbunden. Aber ich glaube, dafuer muessen es mehr als zwei M sein.

Sie können die Daten gerne auch an support [a t] flowheater.net schicken.

Danke, schicke ich gleich los.

Ihre CSV Daten konnten hier problemlos eingelesen werden. Das Resultat habe Ihnen per Email zukommen lassen. Bitte versuchen Sie mal das generiete INSERT SQL Skript bei Ihnen auszuführen. Getestet wurde auf einem SQL Server 2008 R2 Express Edition.

Versuchen Sie bitte mal eine neue Tabelle (evtl. auch eine neue Datenbank) anzulegen und das Ganze mal hier zu importieren. Ich denke bei Ihnen ist irgendwas korrupt (Index, Datenstruktur, etc.).

Bitte lassen Sie mir mal Ihre FlowHeater Definition zukommen.

Vorab schonmal schoenen Dank fuer den hohen Supportaufwand, der zum Erfolg gefuehrt hat.