webForumDet fria alternativet

Skilja på W och V i utsökningar

Databaser & SQL

6 svar · 362 visningar · startad av ulfe

Medlem sedan mars 200348 inlägg
Frågan#1

Databas: SQL Server 7.0
Konfiguration:
- Locale ID = 1053
- Character Set = 2, cp850
- Sort Order = 60, scand_nocase
- Code Page 850 (Multilingual) character set.
- Case-insensitive Scandinavian dictionary sort order, without case preference for collating purposes. Uses the Code Page 850 character set.

Jag har ett problem med utsökningar innehållande W och/eller V

SELECT pid FROM person WHERE pid = 'P999AWI'
(fältet pid är unikt och kan inte innehålla dubletter)

Har jag en post med "P999AWI" returneras den såklart, men har jag en post med "P999AVI" så returneras den.
Har jag två poster "P999AWI" och "P999AVI" returneras båda posterna

Hur skall jag göra för att kunna särskilja W och V så att jag kan komma åt unika posterna?

Medlem sedan dec. 200012 464 inlägg
#2

Kanske

SELECT pid FROM person WHERE cast(pid as varbinary(10)) = 'P999AWI'

med lämplig längd

Medlem sedan mars 200348 inlägg
#3

LarsG:
Tyvärr det ger samma resultat, jag får ut båda posterna med den sökningen.

Medlem sedan dec. 200012 464 inlägg
#4

jaha. En mindre bra lösning är att du gör en extra kontroll i applikationen men just nu ser jag inget alternativ om det inte fungerade med binary.

Medlem sedan mars 200348 inlägg
#5

Verkar inte vara så att SQL 7 stöder separationen av W och V (V=W) när man egentligen vill att det skall vara (V<W)

Medlem sedan dec. 200012 464 inlägg
#6

I svenska är det ingen skillnad mellan V och W så jag tycker att beteendet är korrekt med den sorteringsordning som du har. I version 8 (sql 2000) finns det möjligheter att styra detta i SQL-frågorna, men i version 7 så måste man byta sorteringsordning vilket inte är en enkel operation.

Medlem sedan mars 200348 inlägg
#7

Har fått en lösning och testat fram en annan lösning:

SELECT pid
FROM person
WHERE (CONVERT(varbinary(100), pid) = CONVERT(varbinary(100), 'p999awi'))

Denna lösning måste man sedan modda med UPPER och LOWER eftersom den är case-sensitive

Jag hittade en lösning själv, som klarar upper/lower problemet.

Bytte fälttyp från varchar(7) till nvarchar(14) då funkar det perfekt, nackdelen är ju att fältet tar upp dubbelt så mycket utrymme, men det är inga gigantiska mängder data jag har i detta fallet.

(Så det blev två "lösningar" på detta problem) =)

261 ms totalt · 4 externa anrop · v20260731065814-full.1dc6f849
124 ms — deklarationer (db)
0 ms — hämta statistik (cache)
127 ms — hämta tråd, inlägg och bilagor (db)
131 ms — ändringar (db)