---

Jeg bruger BULK INSERT til at smide nogle data ind i en tabel. Data er
fx som

55343    0170355-1p    1p    1997-10-02T00:00:00.000
55343    0170355-1q    1q    1997-10-02T00:00:00.000
55343    0170355-1x    1x    1997-10-02T00:00:00.000
55343    0170355-1æ    1æ    1997-11-17T00:00:00.000

Primær nøgle i tabellen er andet felt - svarende til kolonne 2 herover.

Hvis jeg i min CSV-fil lægger de tre første linier, så indsættes de fint -
men hvis jeg indsætter den sidste række også, så får jeg en primary-key
violation

Server: Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'Matrikel_PK'. Cannot insert duplicate
key in object 'Matrikel'.

Hvis jeg ser på de indsatte rækker i databasen _inden_ den sidste række
sættes ind, så er der ingen rækker, hvor indholdet af den primære nøgle
"ligner" den jeg prøver at indsætte.

Jeg troede oprindeligt, at det var et ÆØÅ-problem, men den har ingen
problemer med at indsætte en række med den primære nøgle, hvor der er et
'ø' i.

Jeg har prøvet at kigge på de binære data med sql som

select
   *
from
   Matrikel
where
cast(matrikel_id as varbinary(50)) = cast('0170355-1x' as varbinary(50))

Denne sql returner én række - som forventet - men hvis jeg udskifter 'x'
med 'æ', så returneres intet.

Er der nogen af jer, der kan forklare mig, hvorfor dette sker? Jeg er selv
riiimeligt blank.

--
Jesper Stocholm
http://stocholm.dk
Hvor køber du slik, cola eller smøger online?
Send linket til mig via http://ekiosk.dk

---

Jesper Stocholm wrote:

> Er der nogen af jer, der kan forklare mig, hvorfor dette sker? Jeg er
> selv riiimeligt blank.

Lidt mere info

Collation der er valgt
Feltegenskaber (char/varchar -> nvarchar)
etc

:) Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in news:4448e35a$0$99985
$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>
>> Er der nogen af jer, der kan forklare mig, hvorfor dette sker? Jeg er
>> selv riiimeligt blank.
>
> Lidt mere info
>
> Collation der er valgt
> Feltegenskaber (char/varchar -> nvarchar)
> etc

Sorry, det glemte jeg.

Collation : Lati1_General_C1_AS
Felttype: char(40)

SQL-def for tabel er

CREATE TABLE [dbo].[Matrikel] (
   [JobID] [bigint] NOT NULL ,
   [Matrikel_ID] [char] (40) COLLATE Latin1_General_CI_AS NOT NULL ,
   [Matrikel_Nr] [char] (10) COLLATE Latin1_General_CI_AS NULL ,
   [Bem] [varchar] (250) COLLATE Latin1_General_CI_AS NULL ,
   [Fra_Hus_Nr] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
   [Fra_Kmsten] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
   [Parcel_Nr] [char] (10) COLLATE Latin1_General_CI_AS NULL ,
   [Til_Hus_Nr] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
   [Til_Kmsten] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
   [Deklaration] [varchar] (250) COLLATE Latin1_General_CI_AS NULL ,
   [Frigivelsesdato] [datetime] NULL ,
   [Afmeldelsesdato] [datetime] NULL ,
   [Tinglysningsdato] [datetime] NULL ,
   [Historisk] [bit] NULL ,
   [Valideret] [bit] NULL
) ON [PRIMARY]

--
Jesper Stocholm
http://stocholm.dk

Findes din kiosk på nettet? Se http://ekiosk.dk

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in news:4448e35a$0$99985
$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>
>> Er der nogen af jer, der kan forklare mig, hvorfor dette sker? Jeg er
>> selv riiimeligt blank.
>
> Lidt mere info
>
> Collation der er valgt
> Feltegenskaber (char/varchar -> nvarchar)
> etc

CSV-filen er i øvrigt gemt som Unicode-fil.

--
Jesper Stocholm
http://stocholm.dk

Findes din kiosk på nettet? Se http://ekiosk.dk

---

Jesper Stocholm wrote:
>
> CSV-filen er i øvrigt gemt som Unicode-fil.

Har du overvejet nchar i stedet for char?
(Specielt fordi du forventer "accent sensitive" i din collation)

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in news:44491d23$0$132
$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>>
>> CSV-filen er i øvrigt gemt som Unicode-fil.
>
> Har du overvejet nchar i stedet for char?
> (Specielt fordi du forventer "accent sensitive" i din collation)

Vi har ikke rigtigt overvejet noget endnu. Det er ikke "vores" datamodel
men vores kundes, så vi har ikke kunnet designe den fra bunden. Jeg vil dog
kigge på, om ændring af felttypen vil have nogen effekt.



--
Jesper Stocholm
http://stocholm.dk

Findes din kiosk på nettet? Se http://ekiosk.dk

---

Jesper Stocholm wrote:
>
> Vi har ikke rigtigt overvejet noget endnu. Det er ikke "vores"
> datamodel men vores kundes, så vi har ikke kunnet designe den fra
> bunden. Jeg vil dog kigge på, om ændring af felttypen vil have nogen
> effekt.
>
Hmm jeg har lige prøvet at fedte lidt med det

Hvad er collation på databaseserveren?
select SERVERPROPERTY(N'Collation')

Min databaseserver (development) kører med latin1_ci_as som default og jeg
har ingen problemer med at indsætte data "by hand" eller importere fra en
unicode txt ting kreeret vha notepad

Jeg har ikke prøvet bulk insert (endnu)

Hvad er din kommando for bulk insert?
Specielt hvad du har med i din "with" blok

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in
news:4449f28b$0$184$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>>
>> Vi har ikke rigtigt overvejet noget endnu. Det er ikke "vores"
>> datamodel men vores kundes, så vi har ikke kunnet designe den fra
>> bunden. Jeg vil dog kigge på, om ændring af felttypen vil have nogen
>> effekt.
>>
> Hmm jeg har lige prøvet at fedte lidt med det
>
> Hvad er collation på databaseserveren?
> select SERVERPROPERTY(N'Collation')

Danish_Norwegian_CI_AS

> Min databaseserver (development) kører med latin1_ci_as som default og
> jeg har ingen problemer med at indsætte data "by hand" eller importere
> fra en unicode txt ting kreeret vha notepad

hmmm

> Jeg har ikke prøvet bulk insert (endnu)
>
> Hvad er din kommando for bulk insert?
> Specielt hvad du har med i din "with" blok

BULK INSERT Matrikel FROM 'Matrikel.tab'
   WITH (
       CODEPAGE = 'RAW'
       , DATAFILETYPE = 'widechar'
       , FIRSTROW = 1
       , KEEPIDENTITY
       , KEEPNULLS
       , ROWTERMINATOR = '\n'
       , FIELDTERMINATOR = '\t'
       , CHECK_CONSTRAINTS
       )

Tak for hjælpen indtil nu.



--
Jesper Stocholm
http://stocholm.dk
Hvor køber du slik, cola eller smøger online?
Send linket til mig via http://ekiosk.dk

---

Jesper Stocholm wrote:
>
> BULK INSERT Matrikel FROM 'Matrikel.tab'
> WITH (
> CODEPAGE = 'RAW'

Jeg har prøvet med både Raw samt OEM
Ingen problemer

Mit OS kører med locale 409 (US-English)

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in news:444c6cf1$0$118
$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>>
>> BULK INSERT Matrikel FROM 'Matrikel.tab'
>> WITH (
>> CODEPAGE = 'RAW'
>
> Jeg har prøvet med både Raw samt OEM
> Ingen problemer
>
> Mit OS kører med locale 409 (US-English)

Hvor ser du denne værdi henne?

Jeg har prøvet at lave en restore af vores database på min lokale Sql-
Server (dev ed), og her har jeg heller ingen problemer med det.

Lokalt: Win XP Pro DK, Sql server 2k dev ed, danske regional settings
Server: Win 2003 Svr UK, Sql server 2k, danske regional settings

Collation på begge servere er Danish_Norwegian_CI_AS og collation på de
enkelte databaser er begge Latin1_General_CI_AS.


--
Jesper Stocholm
http://stocholm.dk
Hvor køber du slik, cola eller smøger online?
Send linket til mig via http://ekiosk.dk

---

Jesper Stocholm wrote:
>>
>> Mit OS kører med locale 409 (US-English)
>
> Hvor ser du denne værdi henne?
>
HKEY_CURRENT_USER\Control Panel\International\locale

Local system account tager indstillinger fra default user
HKEY_USERS\.DEFAULT\Control Panel\International

- Peter

--
Hi! I'm a .signature *virus*!
Copy me into your ~/.signature to help me spread!

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in news:444c8599$0$99985$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>>>
>>> Mit OS kører med locale 409 (US-English)
>>
>> Hvor ser du denne værdi henne?
>>
> HKEY_CURRENT_USER\Control Panel\International\locale
>
> Local system account tager indstillinger fra default user
> HKEY_USERS\.DEFAULT\Control Panel\International

Aah - nu forstår jeg, hvorfor det ikke gav mening (dit tal). Tallet i
Locale er i Hex, dvs 409 = 1033. På mit er det 406=1030.



Jeg har lige prøvet at køre lidt kode på de to systemer.

Lokalt system (Windows XP Pro DA):

CULTURE ISO ISO WIN DISPLAYNAME ENGLISHNAME LCID
-----------------------------------------------------------------------------------------
da-DK da dan DAN Dansk (Danmark) Danish (Denmark) 1030

Server (Windows 2003 Svr US):

CULTURE ISO ISO WIN DISPLAYNAME ENGLISHNAME LCID
-----------------------------------------------------------------------------------------
en-US en eng ENU English (United States) English (United States) 1033

Så vidt jeg kan se, så er ovenstående _eneste_ forskel på de to
systemer - men hvorfor har det nogen betydning? BULK-INSERT afvikles
via en stored procedure, der fyres af via noget .Net-kode.

--
Jesper Stocholm
http://stocholm.dk
Hvor køber du slik, cola eller smøger online?
Send linket til mig via http://ekiosk.dk

---

Jesper Stocholm wrote:

> Så vidt jeg kan se, så er ovenstående _eneste_ forskel på de to
> systemer - men hvorfor har det nogen betydning? BULK-INSERT afvikles
> via en stored procedure, der fyres af via noget .Net-kode.

Check internationale settings for locale system account
Jeg regner med at MSSQL servicen kører under locale system account?

Prøv evt med OEM (conversion) i stedet for RAW (no conversion)
Eller plot ønskede codepage ind direkte

Fra BOL

CODEPAGE [ = 'ACP' | 'OEM' | 'RAW' | 'code_page' ]
Specifies the code page of the data in the data file. CODEPAGE is relevant
only if the data contains char, varchar, or text columns with character
values greater than 127 or less than 32.

Dvs ved extended characterset :)

- Peter

--
Hi! I'm a .signature *virus*!
Copy me into your ~/.signature to help me spread!

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in
news:444c9438$0$125$edfadb0f@dread16.news.tele.dk:

> Jesper Stocholm wrote:
>
>> Så vidt jeg kan se, så er ovenstående _eneste_ forskel på de to
>> systemer - men hvorfor har det nogen betydning? BULK-INSERT afvikles
>> via en stored procedure, der fyres af via noget .Net-kode.
>
> Check internationale settings for locale system account
> Jeg regner med at MSSQL servicen kører under locale system account?

Jeps

> Prøv evt med OEM (conversion) i stedet for RAW (no conversion)
> Eller plot ønskede codepage ind direkte

Jeg har siddet og renset data i et forsøg på at finde den konkrete
fejllinie. Det viser sig, at jeg faktisk tog fejl mht værdien, der gav en
primary-key fejl.

Jeg kan gendanne fejlen ved at afvikle disse to linier

insert into e_matrikel (JobID, Matrikel_ID) values (55343, '0170355-1ae')
insert into e_matrikel (JobID, Matrikel_ID) values (55343, '0170355-1æ')

Dvs her er BULK INSERT ikke længere med i billedet.

Disse linier har jeg afvikles ved at logge ind på SQL-server via remote
access og via Query Analyser afvikle dem.

Jeg kan jo godt se - som menneske - at 'ae' kan fortolkes som 'æ', men jeg
kan ikke gennemskue, hvorfor SQL-server gør dette?

Jeg er ked af, at jeg kom til at sige, at fejlen skyldtes linien med 'x' i,
men på en eller anden måde giver problemet med 'ae'='æ' lidt mere mening -
uden at jeg dog kan gennemskue årsagen.

Giver det også mening for dig?



--
Jesper Stocholm
http://stocholm.dk
Hvor køber du slik, cola eller smøger online?
Send linket til mig via http://ekiosk.dk

---

Jesper Stocholm wrote:

> Jeg er ked af, at jeg kom til at sige, at fejlen skyldtes linien med
> 'x' i
>
No problem

> Giver det også mening for dig?
>
Egentlig ikke (havde nok fundet svaret på et tidspunkt)

Jeg kan se at Jens er kommet med løsningen
Der ligger ikke lige til højre fod - men den giver da mening :)

God fornøjelses

- Peter

--
Hi! I'm a .signature *virus*!
Copy me into your ~/.signature to help me spread!

---

Jesper Stocholm skrev:

> Jeg kan jo godt se - som menneske - at 'ae' kan fortolkes som
> 'æ', men jeg kan ikke gennemskue, hvorfor SQL-server gør
> dette?

Det er fordi der ikke er forskel på æ og ae i Latin1_General_CI_AI.


Prøv at køre følgende lille test:

SELECT
   CASE WHEN 'æ' = 'ae' COLLATE Danish_Norwegian_CI_AS
   THEN 'æ=ae' ELSE 'æ<>ae' END as dansk,
   CASE WHEN 'æ' = 'ae' COLLATE Latin1_General_CI_AS
   THEN 'æ=ae' ELSE 'æ<>ae' END as latin

Jeg får:

dansk    latin
æ<>ae    æ=ae    


Du skal rette COLLATION på databasen til en udgave med forskel
mellem ae og æ.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> wrote in
news:Xns97AF77A76F1D4jcdmfdk@gyrosmod.dtext.news.tele.dk:

> Jesper Stocholm skrev:
>
>> Jeg kan jo godt se - som menneske - at 'ae' kan fortolkes som
>> 'æ', men jeg kan ikke gennemskue, hvorfor SQL-server gør
>> dette?
>
> Det er fordi der ikke er forskel på æ og ae i Latin1_General_CI_AI.
>
>
> Prøv at køre følgende lille test:
>
> SELECT
> CASE WHEN 'æ' = 'ae' COLLATE Danish_Norwegian_CI_AS
> THEN 'æ=ae' ELSE 'æ<>ae' END as dansk,
> CASE WHEN 'æ' = 'ae' COLLATE Latin1_General_CI_AS
> THEN 'æ=ae' ELSE 'æ<>ae' END as latin
>
> Jeg får:
>
> dansk latin
> æ<>ae æ=ae

Fabelagtigt ... mange tak til jer begge to.



--
Jesper Stocholm
http://stocholm.dk
Hvor køber du slik, cola eller smøger online?
Send linket til mig via http://ekiosk.dk

---

Jesper Stocholm <j@stocholm.invalid> writes:

> 55343    0170355-1x    1x    1997-10-02T00:00:00.000
> 55343    0170355-1æ    1æ    1997-11-17T00:00:00.000

Er x og æ ikke samme værdi modulo 128 (i iso-latin tegnsæt). Kan det
bruges til noget?

--
Thorbjørn Ravn Andersen