Trailing spaces i MS SQL INDEX - giver duplicate key

Claus, why do you have these values as a unique key in th efirst place? Wasnt it an idea to do something with this while you convert your system?

Claus,

sådan er livet - Du kan ikke have trailing spaces i en VARCHAR kolonne i MSSQL, hvis denne er indexeret, idet trailing spaces IKKE kommer med i indexet.
Hvorfor vil du også have varenumre med tailing spaces ??
En ide var at erstatte disse med underscore eller lignende.

Hvorfor egentlig også flytte den fra Oracle til MSSQL ?

Det skal lige siges, jeg er ansat for en måneds tid siden, og har ikke haft noget med data diciplinen at gøre, i har fulkommen ret, hvorfor have varenumre med traling spaces!, med sådan er cituationen nu, og det er hvad jeg har at forholde mig til.
Hvis verden er sådan at man ikke kan, så må jeg scanne hele mit system efter felter med trailing spaces og erstatte dem med en anden karakter.
Det er bare underligt at man har taget højde for det i Oracle og ikke i MS SQL,
men sådan er det måske bare?

To Terry, I suppose you read danish, since you answerd my Question?

Mvh.
Claus.

Du kan overveje at ændre datatypen på dine varenumre til CHAR fremfor VARCHAR.

Varenumrene bruges som fremmednøgle i mange andre tabeller, det er derfor hasarderet at søge at erstatte efterstillede blanktegn.

Jeg vil i stedet foreslå at du gør følgende:
- Find alle de unikke index der er og dokumenter dem grundigt (MEGET VIGTIGT)
- Fjern dine unikke index
- Lav din migrering
- Læg dine index på med ignore duplicate key, det vil betyde at du ikke i fremtiden kan lægge varenumre med efterstillede blanktegn

Jeg ville personligt rydde op i databasen enten før eller efter migreringen - det er uhyre kompliceret at kende forskel på "123" og "123 " især for brugerne.

ishoey>Yes I read danisg just fine, just takes far too long to write!

If possible I would suggest that you replaced the trailing space with someother character. In my opionion it is NOT good practice in having them in a key field, or any other for that matter.

Lets just say that this field was also used visually!

waht is the difference (visually) between

12345
and
12345 

? Believe me, I did enter a space in one of them :o)

Ishoey - Du har 2 muligheder, enten at fjerne de trailing spaces (stort arbejde, men IKKE uoverkommeligt - Kan faktisk programmers på nogle få timer i XAL), eller gå tilbage til Oracle, der normalt er en noget bedre database til XAL end MSSQL er, med mindre du er på en af de seneste versioner, så er MSSQL næsten lige så god som Oracle.

trer - Det kan han IKKE - XAL bestemmer datatypen, og det skal DB folk ikke blande sig i (efter XAL's mening). XAL forventer VARCHAR !

Terry - You are perfectly right - And thats why they managed to get those trailing spaces in there at the first place, it's impossible to see them.
As I proposed in my first comment - Replace it with ie. underscores.

Ishoey - Hvis du kan lidt XAL kodning, så kik på DataExport.XAL kørslen, den giver et hint om, hvorledes man traverserer alle tabeller (og sammenhænge er dokumenteret i DBD'en)

Hvoffor jeg spørg til enmulig hed for at importer i MS SQL er at det jo nødvendigvis ikke kun er i varenummer der er trailing spaces

Der er tilsyneladende ingen vej uden om, at den eneste løsning er hårdt arbejde?
Der var desvære det jeg frygtede!

larildsen> Ærgerligt - men det må man jo så leve med :-)

Jeg ved ikke lige hvordan jeg skal give point her, men larildsen var vel egentlig den der først kom med det indlæg der blev konklutionen, eller hvad?

Du fik jo egentlig ikke noget svar på dit spørgsmål, så ...

OK, jeg er ny i dette forum, så jeg vil ikke træde nogen over tæerne,men tak for inputtet, jeg vil gå i krig med projektet.

21/03-2004 16:07:28>"Wasnt it an idea to do something with this while you convert your system?" !

Terry, i don't think that changing the Unique Index on StockId on StockTable to be non-Unique is a good Idea. The reason for having a Unique Index, is to have a Unique Constraint = Not to have duplicates.
The reason ishoey is getting duplicate keys, is that they moved from Oracle to SQL Server, and Oracle does do all indexing litterally.

--

Ishoey - Du er måske ny i dette forum, og der er folk i dette forum der har en meget høj point score, men hvad skal man brude det til.
Jeg forsøger at hjælpe folk, når jeg kan og har tid, og der er sommetider meget interessante problem stillinger, som jeg også kan lære af. Derfor svarer jeg på det jeg kan, men point er helt uinteressante - Hvad skal jeg bruge dem til ?

Men Ishoey, jeg ved at der er mange der er meget interesserede i point - Så de får en HØJ status herinde, og jeg har set at der er meget større interesse for at komme med svar på spørgsmål der giver 100-200 point, end på spørgsmål der kun giver 30 point.
Men jeg kan kun spise det brød jeg kan købe for min løn, idet mit lokale supermarked IKKE modtager point fra eksperten som betaling for mine varer - Så det jeg gør her, er kun af interesse.

I'm not saying it has to be none unique, I am saying he needs to do something with this when it gets imported into SQL Server. What he does here is up to him, but an idea would to change it to somthing logical! This would very likly also have effect on foreign keys in other tables too!

Terry - Sadly enough there is no such thing as foreign key constraints used in this application.
THe application solely rely on Unique constraints, other indexes and the application's own knowledge of the structure of the database.

It's very hard to get a consistrent model out of it, as the Applications kernel does all the maintenance of tables and indexes.

so ther is NO problem then :o) It is just a case of deciding what value to change space to!

Terry - I agree with your last comment - In my opinion this is the only way out

Jeg har puttet noget kode i DataImport.xal, så nu checker den hvert felt i hele databasen, der har typen STR.