---

Vi bruger Bulkload til at loade en masse data ind i en SQL-server (pt. er
det TSV-filer). Vi har dog problemer med at få indlæst rækker med danske
tegn i - dvs æøå. Jeg har en mistanke om at problemet skyldes noget UTF-8
problematik, men jeg er ikke sikker på, hvordan det helt præcist skal
løses.

Er der nogen af jer, der har lidt erfaringer at øse ud af?



--
Jesper Stocholm
http://stocholm.dk

Japo stole sælges - http://japoarmstole.stocholm.dk

---

Jesper Stocholm wrote:

> Vi bruger Bulkload til at loade en masse data ind i en SQL-server (pt. er
> det TSV-filer). Vi har dog problemer med at få indlæst rækker med danske
> tegn i - dvs æøå. Jeg har en mistanke om at problemet skyldes noget UTF-8
> problematik, men jeg er ikke sikker på, hvordan det helt præcist skal
> løses.
>
> Er der nogen af jer, der har lidt erfaringer at øse ud af?

Er dine TSV filer i UTF-8?
Hvis de er, er det nok nemmest at lave/finde en 'forbrænder', der
konverterer til eks. ISO 8859-1/15.
Hvis de kommer fra andre systemer, er det ikke umuligt, de kører med et
PC8-et eller andet.

Kunne du evt. smide et hex-dump af et udsnit af filen?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <stig_johansen_it_at_=(@)hotmail.com> wrote in
news:42e3e287$0$18649$14726298@news.sunsite.dk:

> Jesper Stocholm wrote:
>
>> Vi bruger Bulkload til at loade en masse data ind i en SQL-server
>> (pt. er det TSV-filer). Vi har dog problemer med at få indlæst rækker
>> med danske tegn i - dvs æøå. Jeg har en mistanke om at problemet
>> skyldes noget UTF-8 problematik, men jeg er ikke sikker på, hvordan
>> det helt præcist skal løses.
>>
>> Er der nogen af jer, der har lidt erfaringer at øse ud af?
>
> Er dine TSV filer i UTF-8?

Ja

Vi har kigget lidt mere på filerne (og resultatet af upload) , og
problemet skyldes at SQL-server ved bulkupload laver danske tegn om
fra ét tegn til to - fx æ = 'ÿ+' (eller lign). Det giver problemer,
hvis vi forsøger at upload'e strengen "træ" i et varchar(3)-felt, da
strengen bliver 4 lang og derfor trunkeres.

> Hvis de er, er det nok nemmest at lave/finde en 'forbrænder', der
> konverterer til eks. ISO 8859-1/15.

Jeg vil se, om vi kan fixe noget i den retning.



> Hvis de kommer fra andre systemer, er det ikke umuligt, de kører med
> et PC8-et eller andet.
>
> Kunne du evt. smide et hex-dump af et udsnit af filen?

Jeg skal lige have lavet filerne igen, så smider jeg det til dig.

Men - vi har fået et andet problem med BULK INSERT ... den loader ikke
alle rækker ind i systemet - men det er ikke konsekvent. Et eksempel på
en fil, der loades fint ind er [0] og et eksempel på en fil, der ikke
loades ind korrekt (den sidste linie mangler) er [1]. Den kommando vi
bruger til at loade filen ind er

BULK INSERT <tablename> FROM <filename> WITH (CODEPAGE = 'RAW', DATAFILETYPE = 'char', FIRSTROW = 2, KEEPIDENTITY, KEEPNULLS, ROWTERMINATOR = '\n', FIELDTERMINATOR = '\t')

Pft,




[0]
00000000h: FF FE 30 00 09 00 31 00 09 00 32 00 09 00 33 00 ; ÿþ0...1...2...3.
00000010h: 09 00 34 00 09 00 35 00 09 00 36 00 09 00 37 00 ; ..4...5...6...7.
00000020h: 09 00 38 00 09 00 39 00 09 00 31 00 30 00 09 00 ; ..8...9...1.0...
00000030h: 31 00 31 00 09 00 31 00 32 00 09 00 31 00 33 00 ; 1.1...1.2...1.3.
00000040h: 09 00 31 00 34 00 09 00 31 00 35 00 09 00 31 00 ; ..1.4...1.5...1.
00000050h: 36 00 09 00 31 00 37 00 09 00 31 00 38 00 0A 00 ; 6...1.7...1.8...
00000060h: 33 00 36 00 31 00 35 00 09 00 36 00 31 00 09 00 ; 3.6.1.5...6.1...
00000070h: 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 ; ................
00000080h: 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 ; ................
00000090h: 0A 00 33 00 36 00 31 00 36 00 09 00 36 00 31 00 ; ..3.6.1.6...6.1.
000000a0h: 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 ; ................
000000b0h: 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 ; ................
000000c0h: 09 00 09 00 ; ....

[1]
00000000h: FF FE 30 00 09 00 31 00 09 00 32 00 09 00 33 00 ; ÿþ0...1...2...3.
00000010h: 09 00 34 00 09 00 35 00 09 00 36 00 09 00 37 00 ; ..4...5...6...7.
00000020h: 09 00 38 00 09 00 39 00 09 00 31 00 30 00 09 00 ; ..8...9...1.0...
00000030h: 31 00 31 00 09 00 31 00 32 00 09 00 31 00 33 00 ; 1.1...1.2...1.3.
00000040h: 09 00 31 00 34 00 0A 00 33 00 37 00 37 00 33 00 ; ..1.4...3.7.7.3.
00000050h: 38 00 09 00 36 00 31 00 09 00 37 00 37 00 35 00 ; 8...6.1...7.7.5.
00000060h: 38 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 ; 8...............
00000070h: 09 00 09 00 09 00 09 00 09 00 0A 00 33 00 37 00 ; ............3.7.
00000080h: 37 00 33 00 39 00 09 00 36 00 31 00 09 00 37 00 ; 7.3.9...6.1...7.
00000090h: 37 00 35 00 39 00 09 00 09 00 09 00 09 00 09 00 ; 7.5.9...........
000000a0h: 09 00 09 00 09 00 09 00 09 00 09 00 09 00 ; ..............

--
Jesper Stocholm
http://stocholm.dk

---

Jesper Stocholm <j@stocholm.invalid> wrote in
news:Xns96A05A35CDD27jstocholminvalid@62.243.74.162:

> Men - vi har fået et andet problem med BULK INSERT ... den loader ikke
> alle rækker ind i systemet - men det er ikke konsekvent. Et eksempel
> på
> en fil, der loades fint ind er [0] og et eksempel på en fil, der ikke
> loades ind korrekt (den sidste linie mangler)

tja - problemet skyldtes en manglende row-delimiter efter sidste linie -
efter indsættelse af et linieskift loades data nu som de skal.



.... problemet med danske tegn er stadig ikke løst - men det kommer nok.

--
Jesper Stocholm
http://stocholm.dk

---

Jesper Stocholm wrote:

[snip utf-8 m.v.]

> [0]
> 00000000h: FF FE 30 00 09 00 31 00 09 00 32 00 09 00 33 00 ;

FF FE = 'UTF-16 Little endian' aka 'UNICODE'.
( Hver eneste karakter består af 2 bytes)

Jeg skal lige over og boote min WinPC......... yeps tilbage igen.

Nu plejer jeg selv at bruge bcp, og der kan man specificere diverse code
pages osv.

Her benyttes -w til at indikere unicode.

Du kan eksperimentere lidt med:
- Bruge bcp med -w switch (Jeg har ikke selv brugt unicode).
- Tjekke om BULK INSERT understøtter -w
- Forsøge at importere til en NVarchar ( = UNICODE)
- Eller som nævnt, lave/finde en conversion utility.

--
Med venlig hilsen
Stig Johansen