Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SQL Express: Import csv-datei - Der Text wurde abgeschnitten
2,184 views
Skip to first unread message
Stefan Paesch
Nov 16, 2011, 3:25:03 PM11/16/11
to
Moin zusammen,
ich versuche über den Import-Assistenten eine CSV-Datei (420 MB; 2 Mio
Datensätze) zu importieren.
80.000 DS werden importiert. Fehlermeldung:
• Fehler 0xc02020a1: 1-Datenflusstask: Fehler bei der
Datenkonvertierung. Die Datenkonvertierung für die Spalte 43-Spalte
gab den Statuswert '4' und den Statustext 'Der Text wurde
abgeschnitten, oder ein oder mehrere Zeichen hatte(n) auf der
Zielcodeseite keine Entsprechung.' zurück.
(SQL Server-Import/Export-Assistent)
• Fehler 0xc020902a: 1-Datenflusstask: Fehler bei 'Ausgabespalte
'Spalte 43' (182)' aufgrund abgeschnittener Daten. Die
Abschneidezeilendisposition in 'Ausgabespalte 'Spalte 43' (182)' gibt
an, dass der Vorgang bei einem Abschneidefehler nicht ausgeführt
werden kann. Es wurde ein Abschneidefehler im angegebenen Objekt der
angegebenen Komponente festgestellt.
(SQL Server-Import/Export-Assistent)
Die einzelnen Felder bestehen aus weniger als 50 Zeichen.
Gibt es seitens des Server eine Importbeschränkung?
Liegt es an einer Registry-Einstellung ? Ich habe so etwas schon
einmal gelesen, finde es aber so in diesem Zusammenhang nicht wieder.
DAnke für Eure Hilfe.
Stefan
SQL Express 2008; WIN XP Pro
ich versuche über den Import-Assistenten eine CSV-Datei (420 MB; 2 Mio
Datensätze) zu importieren.
80.000 DS werden importiert. Fehlermeldung:
• Fehler 0xc02020a1: 1-Datenflusstask: Fehler bei der
Datenkonvertierung. Die Datenkonvertierung für die Spalte 43-Spalte
gab den Statuswert '4' und den Statustext 'Der Text wurde
abgeschnitten, oder ein oder mehrere Zeichen hatte(n) auf der
Zielcodeseite keine Entsprechung.' zurück.
(SQL Server-Import/Export-Assistent)
• Fehler 0xc020902a: 1-Datenflusstask: Fehler bei 'Ausgabespalte
'Spalte 43' (182)' aufgrund abgeschnittener Daten. Die
Abschneidezeilendisposition in 'Ausgabespalte 'Spalte 43' (182)' gibt
an, dass der Vorgang bei einem Abschneidefehler nicht ausgeführt
werden kann. Es wurde ein Abschneidefehler im angegebenen Objekt der
angegebenen Komponente festgestellt.
(SQL Server-Import/Export-Assistent)
Die einzelnen Felder bestehen aus weniger als 50 Zeichen.
Gibt es seitens des Server eine Importbeschränkung?
Liegt es an einer Registry-Einstellung ? Ich habe so etwas schon
einmal gelesen, finde es aber so in diesem Zusammenhang nicht wieder.
DAnke für Eure Hilfe.
Stefan
SQL Express 2008; WIN XP Pro
Peter Lange
Nov 16, 2011, 4:31:20 PM11/16/11
to
Am 16.11.2011 21:25, schrieb Stefan Paesch:
Hallo,
ohne weitere Erfahrungen mit SQL Express zu haben, würde ich meine
Fehlersuche auf
> oder ein oder mehrere Zeichen hatte(n) auf der
> Zielcodeseite keine Entsprechung
konzentrieren.
hth
Peter
Hallo,
ohne weitere Erfahrungen mit SQL Express zu haben, würde ich meine
Fehlersuche auf
> oder ein oder mehrere Zeichen hatte(n) auf der
> Zielcodeseite keine Entsprechung
hth
Peter
Torsten Schneider
Nov 17, 2011, 2:32:49 AM11/17/11
to
Stefan Paesch <n...@paesch.com> wrote:
>• Fehler 0xc02020a1: 1-Datenflusstask: Fehler bei der
>Datenkonvertierung. Die Datenkonvertierung für die Spalte 43-Spalte
>gab den Statuswert '4' und den Statustext 'Der Text wurde
>abgeschnitten, oder ein oder mehrere Zeichen hatte(n) auf der
>Zielcodeseite keine Entsprechung.' zurück.
Sowas kann kommen, wenn du beispielsweise den Import UTF-8 codiert hast,
>• Fehler 0xc02020a1: 1-Datenflusstask: Fehler bei der
>Datenkonvertierung. Die Datenkonvertierung für die Spalte 43-Spalte
>gab den Statuswert '4' und den Statustext 'Der Text wurde
>abgeschnitten, oder ein oder mehrere Zeichen hatte(n) auf der
>Zielcodeseite keine Entsprechung.' zurück.
die Datenbank unter Latin-1 läuft und dort zeichen vorhanden sind, die
man nicht in Latin-1 findet.
Viele Grüße, Torsten
perlsau
Nov 17, 2011, 7:36:11 AM11/17/11
to
Am 16.11.2011 21:25, schrieb Stefan Paesch:
> gab den Statuswert '4' und den Statustext 'Der Text wurde
> abgeschnitten, oder ein oder mehrere Zeichen hatte(n) auf der
> Zielcodeseite keine Entsprechung.' zurück.
> (SQL Server-Import/Export-Assistent)
> • Fehler 0xc020902a: 1-Datenflusstask: Fehler bei 'Ausgabespalte
> 'Spalte 43' (182)' aufgrund abgeschnittener Daten. Die
> Abschneidezeilendisposition in 'Ausgabespalte 'Spalte 43' (182)' gibt
> an, dass der Vorgang bei einem Abschneidefehler nicht ausgeführt
> werden kann. Es wurde ein Abschneidefehler im angegebenen Objekt der
> angegebenen Komponente festgestellt.
> (SQL Server-Import/Export-Assistent)
Ich würde hier so vorgehen:
> abgeschnitten, oder ein oder mehrere Zeichen hatte(n) auf der
> Zielcodeseite keine Entsprechung.' zurück.
> (SQL Server-Import/Export-Assistent)
> • Fehler 0xc020902a: 1-Datenflusstask: Fehler bei 'Ausgabespalte
> 'Spalte 43' (182)' aufgrund abgeschnittener Daten. Die
> Abschneidezeilendisposition in 'Ausgabespalte 'Spalte 43' (182)' gibt
> an, dass der Vorgang bei einem Abschneidefehler nicht ausgeführt
> werden kann. Es wurde ein Abschneidefehler im angegebenen Objekt der
> angegebenen Komponente festgestellt.
> (SQL Server-Import/Export-Assistent)
1. Einlesen bis zum Abbruch
2. Zuletzt eingelesene Zeile anschauen
3. In der CSV-Datei diese Zeile suchen und die darunterliegende Zeile
anschauen, inwiefern dort Zeichen auftauchen, die "auf der Zielcodeseite
keine Entsprechung" besitzen.
4. In der gesamten CSV-Datei diese Zeichen entsprechend ersetzen oder
die Zeichencodierung der Zieltabelle entsprechend ändern.
Stefan Paesch
Nov 17, 2011, 9:49:41 AM11/17/11
to
Hallo Perlsau,
> Ich würde hier so vorgehen:
>
> 1. Einlesen bis zum Abbruch
> 2. Zuletzt eingelesene Zeile anschauen
> 3. In der CSV-Datei diese Zeile suchen und die darunterliegende Zeile
> anschauen, inwiefern dort Zeichen auftauchen, die "auf der Zielcodeseite
> keine Entsprechung" besitzen.
> 4. In der gesamten CSV-Datei diese Zeichen entsprechend ersetzen oder
> die Zeichencodierung der Zieltabelle entsprechend ändern.
... das mache ich gerade ..... 2 Mio Datensätze. Habe bisher leider
nicht den Übeltäter
ausfindig gemacht, da es immer wieder verschiedene Spalten betrifft.
Gibt es eine Import-Option (Codepages), die sehr tolerant ist ?
Die Textdatei in Access einlesen geht ohne Probleme, nur ist die DB
1,9 GB groß ....
und das war es bekanntlich. Deshalb SQL-Server, aber mit "rumgezicke"
habe ich nicht gerechnet.
Na, man lernt eben immer dazu.
Danke Stefan.
> Ich würde hier so vorgehen:
>
> 1. Einlesen bis zum Abbruch
> 2. Zuletzt eingelesene Zeile anschauen
> 3. In der CSV-Datei diese Zeile suchen und die darunterliegende Zeile
> anschauen, inwiefern dort Zeichen auftauchen, die "auf der Zielcodeseite
> keine Entsprechung" besitzen.
> 4. In der gesamten CSV-Datei diese Zeichen entsprechend ersetzen oder
> die Zeichencodierung der Zieltabelle entsprechend ändern.
nicht den Übeltäter
ausfindig gemacht, da es immer wieder verschiedene Spalten betrifft.
Gibt es eine Import-Option (Codepages), die sehr tolerant ist ?
Die Textdatei in Access einlesen geht ohne Probleme, nur ist die DB
1,9 GB groß ....
und das war es bekanntlich. Deshalb SQL-Server, aber mit "rumgezicke"
habe ich nicht gerechnet.
Na, man lernt eben immer dazu.
Danke Stefan.
Claus Reibenstein
Nov 17, 2011, 11:39:29 AM11/17/11
to
Stefan Paesch schrieb:
> Gibt es eine Import-Option (Codepages), die sehr tolerant ist ?
Was spricht denn dagegen, die Tabellenspalten auf UTF-8 umzustellen?
Gruß. Claus
> Gibt es eine Import-Option (Codepages), die sehr tolerant ist ?
Gruß. Claus
Siegfried Schmidt
Nov 17, 2011, 11:48:03 AM11/17/11
to
Stefan Paesch schrieb:
> Die Textdatei in Access einlesen geht ohne Probleme, nur ist die DB
> 1,9 GB groß ....
Wenn das einlesen geht, müsste in Access auch der Import mit TransferText
in eine eingebundene Tabelle klappen.
Anderenfalls ist eine Textdatei zeilenweise lesen, in Felder teilen und an
die DB verfüttern mit einem dutzend Programmzeilen in einer Viertelstunde
erledigt.
Siegfried
> Die Textdatei in Access einlesen geht ohne Probleme, nur ist die DB
> 1,9 GB groß ....
in eine eingebundene Tabelle klappen.
Anderenfalls ist eine Textdatei zeilenweise lesen, in Felder teilen und an
die DB verfüttern mit einem dutzend Programmzeilen in einer Viertelstunde
erledigt.
Siegfried
Marc Santhoff
Nov 17, 2011, 12:07:05 PM11/17/11
to
Am Thu, 17 Nov 2011 06:49:41 -0800 schrieb Stefan Paesch:
> Hallo Perlsau,
>
>> Ich würde hier so vorgehen:
>>
>> 1. Einlesen bis zum Abbruch
>> 2. Zuletzt eingelesene Zeile anschauen 3. In der CSV-Datei diese Zeile
>> suchen und die darunterliegende Zeile anschauen, inwiefern dort Zeichen
>> auftauchen, die "auf der Zielcodeseite keine Entsprechung" besitzen.
>> 4. In der gesamten CSV-Datei diese Zeichen entsprechend ersetzen oder
>> die Zeichencodierung der Zieltabelle entsprechend ändern.
>
> ... das mache ich gerade ..... 2 Mio Datensätze. Habe bisher leider
> nicht den Übeltäter
> ausfindig gemacht, da es immer wieder verschiedene Spalten betrifft.
Viellicht gibt unter Windows(?) ja auch ein Tool wie "recode"[1][2] oder
> Hallo Perlsau,
>
>> Ich würde hier so vorgehen:
>>
>> 1. Einlesen bis zum Abbruch
>> 2. Zuletzt eingelesene Zeile anschauen 3. In der CSV-Datei diese Zeile
>> suchen und die darunterliegende Zeile anschauen, inwiefern dort Zeichen
>> auftauchen, die "auf der Zielcodeseite keine Entsprechung" besitzen.
>> 4. In der gesamten CSV-Datei diese Zeichen entsprechend ersetzen oder
>> die Zeichencodierung der Zieltabelle entsprechend ändern.
>
> ... das mache ich gerade ..... 2 Mio Datensätze. Habe bisher leider
> nicht den Übeltäter
> ausfindig gemacht, da es immer wieder verschiedene Spalten betrifft.
"iconv" o.ä., daß Du drüberlaufen lassen kannst. Eins- und
Ausgangscodierung angeben, Datei durchmangeln, fertig.
Viel Spaß,
Marc
[1] http://www.gnu.org/software/recode/recode.html
[2] http://recode.progiciels-bpi.ca/index.html#id21
Stefan Paesch
Nov 17, 2011, 1:52:06 PM11/17/11
to
Hallo Claus,
> Was spricht denn dagegen, die Tabellenspalten auf UTF-8 umzustellen?
habe ich probiert, gleiche Fehlermeldung.
Die Prüfung der Datensätze der CSV-Datei (bei denen es kracht) hat so
erst einmal
keine Auffälligkeiten ergeben.
Ich bin immer noch der Meinung, das ist ein Bug.
Viele Grüße Stefan.
> Was spricht denn dagegen, die Tabellenspalten auf UTF-8 umzustellen?
Die Prüfung der Datensätze der CSV-Datei (bei denen es kracht) hat so
erst einmal
keine Auffälligkeiten ergeben.
Ich bin immer noch der Meinung, das ist ein Bug.
Viele Grüße Stefan.
Stefan Paesch
Nov 17, 2011, 1:59:23 PM11/17/11
to
> Ich bin immer noch der Meinung, das ist ein Bug.
Beim SQL Express 2005 war es ein Bug!
http://support.microsoft.com/kb/2445326/de
Nun gehe ich mal auf die Suche für den 2008er.
Stefan
perlsau
Nov 18, 2011, 12:09:19 AM11/18/11
to
enthält, verwende ich sie nicht, denn der zeitliche Aufwand, diesen Bug
zu finden bzw. auf ein Update zu warten, ist mir zu hoch.
Spricht was dagegen, in einem solchen Fall eine andere Datenbank zu
verwenden, z.B. Firebird?
Stefan Paesch
Nov 18, 2011, 2:19:35 AM11/18/11
to
Moin perlsau,
> Wenn mir bekannt ist, daß eine Datenbanksoftware regelmäßig Bugs
> enthält, verwende ich sie nicht, denn der zeitliche Aufwand, diesen Bug
> zu finden bzw. auf ein Update zu warten, ist mir zu hoch.
Man muss ja erst einmal daruf kommen, dass es evtl. an dem Server
liegt.
> Spricht was dagegen, in einem solchen Fall eine andere Datenbank zu
> verwenden, z.B. Firebird?
Im Prinzip spricht nichts dagegen.
Ich kenne mich mit SQL-Express ein wenig aus, mit allen andern
Servern
leider nicht. Da ist der Aufwand sich einzuarbeiten auch nicht zu
vernachlässigen.
Stefan
> Wenn mir bekannt ist, daß eine Datenbanksoftware regelmäßig Bugs
> enthält, verwende ich sie nicht, denn der zeitliche Aufwand, diesen Bug
> zu finden bzw. auf ein Update zu warten, ist mir zu hoch.
liegt.
> Spricht was dagegen, in einem solchen Fall eine andere Datenbank zu
> verwenden, z.B. Firebird?
Ich kenne mich mit SQL-Express ein wenig aus, mit allen andern
Servern
leider nicht. Da ist der Aufwand sich einzuarbeiten auch nicht zu
vernachlässigen.
Stefan
Stefan Graf
Nov 18, 2011, 4:14:56 AM11/18/11
to
bekannt, in der nicht solche Fehler enthalten sind. Sowohl bei Oracle,
MS-SQL, PostgreSQL usw. sind viele solche Fehler bekannt, damit muss man
eben leben und sie irgendwie umgehen.
Ich würde da auch empfehlen, nicht ein Importtool zu verwenden, sondern
den Import selber schreiben. Das Problem könnte ja auch beim Importtool
liegen.
--
Stefan Graf
perlsau
Nov 18, 2011, 2:31:18 PM11/18/11
to
Am 18.11.2011 10:14, schrieb Stefan Graf:
> Dann dürftest Du keine Datenbank-Software einsetzen ;-) Mir ist keine
> bekannt, in der nicht solche Fehler enthalten sind. Sowohl bei Oracle,
> MS-SQL, PostgreSQL usw. sind viele solche Fehler bekannt, damit muss man
> eben leben und sie irgendwie umgehen.
Firebird hast du nicht erwähnt, weil ...? Da ich fast ausschließlich mit
> Dann dürftest Du keine Datenbank-Software einsetzen ;-) Mir ist keine
> bekannt, in der nicht solche Fehler enthalten sind. Sowohl bei Oracle,
> MS-SQL, PostgreSQL usw. sind viele solche Fehler bekannt, damit muss man
> eben leben und sie irgendwie umgehen.
Firebird arbeite (gelegentlich auch mit MySQL, bislang nur einmal mit
PostGre und einmal mit MS-SQL-Server), kann ich mit Sicherheit
behaupten, daß mir bei Firebird noch kein einziger Bug über den Weg
gelaufen ist, schon gar nicht diesen Ausmaßes.
> Ich würde da auch empfehlen, nicht ein Importtool zu verwenden, sondern
> den Import selber schreiben. Das Problem könnte ja auch beim Importtool
> liegen.
beim Selberkochen, was man hat ;-)
perlsau
Nov 18, 2011, 2:36:35 PM11/18/11
to
Am 18.11.2011 08:19, schrieb Stefan Paesch:
>> Spricht was dagegen, in einem solchen Fall eine andere Datenbank zu
>> verwenden, z.B. Firebird?
> Im Prinzip spricht nichts dagegen.
> Ich kenne mich mit SQL-Express ein wenig aus, mit allen andern
> Servern
> leider nicht. Da ist der Aufwand sich einzuarbeiten auch nicht zu
> vernachlässigen.
Was aber nützt dir SQL-Express, wenn's nicht funktioniert? Und die
>> Spricht was dagegen, in einem solchen Fall eine andere Datenbank zu
>> verwenden, z.B. Firebird?
> Im Prinzip spricht nichts dagegen.
> Ich kenne mich mit SQL-Express ein wenig aus, mit allen andern
> Servern
> leider nicht. Da ist der Aufwand sich einzuarbeiten auch nicht zu
> vernachlässigen.
Einarbeitung in Firebird ist nichts Besonderes, ich hatte meinen ersten
Firebird-Server innerhalb einer Stunde installiert und die erste
Datenbank gebastelt. Bei Interesse sende ich dir gerne weitere
Einstiegshilfen an deine Email-Adresse.
Lieber gleich was Richtiges anstatt mit Flickschusterei irgendwann auf
die Schnauze fallen ... der größte mir bekannte Anwender von Firebird
ist die Deutsche Presseagentur dpa.
Stefan Paesch
Nov 24, 2011, 11:19:07 AM11/24/11
to
Moin Stefan,
> Ich würde da auch empfehlen, nicht ein Importtool zu verwenden, sondern
> den Import selber schreiben. Das Problem könnte ja auch beim Importtool
> liegen.
Gesagt, getan:
der Fehler tritt immer noch auf, aber er ist genauer zu spezefizieren.
Es muss das Zeilen-Ende-Zeichen sein.
Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server.
Wenn mann diese Datei in einem dafür geeigneten Texteditor öffnet und
sich
die Steuerzeichen ansieht endet jede Zeile mit ¶.
Warum nun alle 10.000 Zeilen Stress aufkommt ... ?
Ich habe in Excel 2010 eine Datei erzeugt mit 1 Mio DS (als txt-Datei
gespeichert),
wird ohne Probleme eingelesen.
Gibt es eine Möglichkeit, den SQL-Server etwas toleranter werden zu
lassen
(per Code im Script) ?
Stefan
> Ich würde da auch empfehlen, nicht ein Importtool zu verwenden, sondern
> den Import selber schreiben. Das Problem könnte ja auch beim Importtool
> liegen.
der Fehler tritt immer noch auf, aber er ist genauer zu spezefizieren.
Es muss das Zeilen-Ende-Zeichen sein.
Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server.
Wenn mann diese Datei in einem dafür geeigneten Texteditor öffnet und
sich
die Steuerzeichen ansieht endet jede Zeile mit ¶.
Warum nun alle 10.000 Zeilen Stress aufkommt ... ?
Ich habe in Excel 2010 eine Datei erzeugt mit 1 Mio DS (als txt-Datei
gespeichert),
wird ohne Probleme eingelesen.
Gibt es eine Möglichkeit, den SQL-Server etwas toleranter werden zu
lassen
(per Code im Script) ?
Stefan
Stefan Paesch
Nov 24, 2011, 11:21:30 AM11/24/11
to
Hallo perslsau,
> Bei Interesse sende ich dir gerne weitere
> Einstiegshilfen an deine Email-Adresse.
Das Angebot nehme ich sehr gern an.
Vielen Dank Stefan.
> Bei Interesse sende ich dir gerne weitere
> Einstiegshilfen an deine Email-Adresse.
Vielen Dank Stefan.
Marc Santhoff
Nov 24, 2011, 12:00:32 PM11/24/11
to
Am Thu, 24 Nov 2011 08:19:07 -0800 schrieb Stefan Paesch:
> Moin Stefan,
>
>> Ich würde da auch empfehlen, nicht ein Importtool zu verwenden, sondern
>> den Import selber schreiben. Das Problem könnte ja auch beim Importtool
>> liegen.
>
> Gesagt, getan:
> der Fehler tritt immer noch auf, aber er ist genauer zu spezefizieren.
>
> Es muss das Zeilen-Ende-Zeichen sein.
>
> Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server. Wenn
> mann diese Datei in einem dafür geeigneten Texteditor öffnet und sich
> die Steuerzeichen ansieht endet jede Zeile mit ¶. Warum nun alle 10.000
> Zeilen Stress aufkommt ... ?
>
> Ich habe in Excel 2010 eine Datei erzeugt mit 1 Mio DS (als txt-Datei
> gespeichert),
> wird ohne Probleme eingelesen.
Sieht ein bischen so aus, als würdest Du bzw. der Server auf ein
> Moin Stefan,
>
>> Ich würde da auch empfehlen, nicht ein Importtool zu verwenden, sondern
>> den Import selber schreiben. Das Problem könnte ja auch beim Importtool
>> liegen.
>
> Gesagt, getan:
> der Fehler tritt immer noch auf, aber er ist genauer zu spezefizieren.
>
> Es muss das Zeilen-Ende-Zeichen sein.
>
> Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server. Wenn
> mann diese Datei in einem dafür geeigneten Texteditor öffnet und sich
> die Steuerzeichen ansieht endet jede Zeile mit ¶. Warum nun alle 10.000
> Zeilen Stress aufkommt ... ?
>
> Ich habe in Excel 2010 eine Datei erzeugt mit 1 Mio DS (als txt-Datei
> gespeichert),
> wird ohne Probleme eingelesen.
Ressourcenlimit laufen. Kannst Du nicht nach 1 Mio zeilen mal die Ausgabe
schließen und neu öffnen (oder flush benutzen, wenn's sowas gibt?
Marc
Siegfried Schmidt
Nov 24, 2011, 1:32:13 PM11/24/11
to
Stefan Paesch schrieb:
> Es muss das Zeilen-Ende-Zeichen sein.
Das würde ich als letztes annehmen.
> Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server.
> Wenn mann diese Datei in einem dafür geeigneten Texteditor öffnet und
> sich
> die Steuerzeichen ansieht endet jede Zeile mit ¶.
Postgres verwendet als Zeilentrenner immer 0x0a (NL).
> Warum nun alle 10.000 Zeilen Stress aufkommt ... ?
Dann kann es ja nicht so schwer sein, die Zeile zu lokalisieren. 10000
Zeilen jeweils halbiert und getestet braucht höchstens 14 Durchläufe.
> Ich habe in Excel 2010 eine Datei erzeugt mit 1 Mio DS (als txt-Datei
> gespeichert),
> wird ohne Probleme eingelesen.
Excel ist in Sachen csv nicht unbedingt als Referenz tauglich.
> Gibt es eine Möglichkeit, den SQL-Server etwas toleranter werden zu
> lassen
> (per Code im Script) ?
Natürlich.
<http://codehighstreet.com/Snippets/parsing_comma_separated_values_into_tab
le_in_sql_server.aspx>
Aber du hast doch geschrieben dass der Import mit Access geht. Warum
verwendest du nicht Access um die Daten auf den Server zu schieben?
Siegfried
> Es muss das Zeilen-Ende-Zeichen sein.
> Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server.
> Wenn mann diese Datei in einem dafür geeigneten Texteditor öffnet und
> sich
> die Steuerzeichen ansieht endet jede Zeile mit ¶.
> Warum nun alle 10.000 Zeilen Stress aufkommt ... ?
Zeilen jeweils halbiert und getestet braucht höchstens 14 Durchläufe.
> Ich habe in Excel 2010 eine Datei erzeugt mit 1 Mio DS (als txt-Datei
> gespeichert),
> wird ohne Probleme eingelesen.
> Gibt es eine Möglichkeit, den SQL-Server etwas toleranter werden zu
> lassen
> (per Code im Script) ?
<http://codehighstreet.com/Snippets/parsing_comma_separated_values_into_tab
le_in_sql_server.aspx>
Aber du hast doch geschrieben dass der Import mit Access geht. Warum
verwendest du nicht Access um die Daten auf den Server zu schieben?
Siegfried
Ralf Bosselmann
Nov 24, 2011, 4:42:17 PM11/24/11
to
Am 24.11.2011 19:32, schrieb Siegfried Schmidt:
> Stefan Paesch schrieb:
>> Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server.
http://www.progress.com/de-de/index.html
Wird z.B. in diversen ERP-Systemen verwendet.
Ralf
> Stefan Paesch schrieb:
>> Die Datei (2 Mio DS) ist ein Export von einem Progress-SQL-Server.
> Postgres verwendet als Zeilentrenner immer 0x0a (NL).
Ich nehme an Stefan meint die hier:
http://www.progress.com/de-de/index.html
Wird z.B. in diversen ERP-Systemen verwendet.
Ralf
Stefan Paesch
Nov 25, 2011, 1:37:52 PM11/25/11
to
> Ich nehme an Stefan meint die hier:http://www.progress.com/de-de/index.html
>
> Wird z.B. in diversen ERP-Systemen verwendet.
So ist es.
>
> Wird z.B. in diversen ERP-Systemen verwendet.
0 new messages