MSSQL probleem met Turkse karakters

[ArnoldSmit]

Ik heb een probleem met specifieke Turkse karakters goed op te halen met een select query.
Specifiek deze 'ğ' , zelfs met een select query gaat het niet zoals het hoort.
SELECT 'Çallioğlu.pdf'
Wordt Çallioglu.pdf

Alleen met de N ervoor, word het resultaat wel goed weergegeven
SELECT N'Çallioğlu.pdf'

Nu wil ik direct via een select statement de informatie direct uit de database halen.
Weet iemand hoe ik dit kan realiseren?

[Anoniem: 36835]

met een N ervoor.

[D4NG3R]

https://learn.microsoft.c...sql?view=sql-server-ver16

Without the N prefix, the string is converted to the default code page of the database that may not recognize certain characters.

Dus inderdaad zoals @Anoniem: 36835 aangeeft; met een N ervoor.

[J2pc]

Wat is nu precies je vraag?

de N ervoor geeft aan dat het een unicode string is.
https://learn.microsoft.c...sql?view=sql-server-ver16

code:

select * from tabel where veld = N'Çallioğlu.pdf'

[ArnoldSmit]

De N ervoor werkt prima als ik het zo doe
SELECT N'Çallioğlu'

Echter hoe gebruik ik dit als het een veld moet zijn zoals:
select [Bestandsnaam]
from [tabel]

?

Anoniem: 36835 schreef op dinsdag 5 maart 2024 @ 13:57:
met een N ervoor.

[J2pc]

Begrijp ik goed dat het speciale karakter in een kolomnaam zit?

[Anoniem: 36835]

ArnoldSmit schreef op dinsdag 5 maart 2024 @ 14:03:
De N ervoor werkt prima als ik het zo doe
SELECT N'Çallioğlu'

Echter hoe gebruik ik dit als het een veld moet zijn zoals:
select [Bestandsnaam]
from [tabel]

?

[...]

Je bedoelt een variabel? Dan concat je die N ervoor bij het definieren van je variabel.

[ArnoldSmit]

J2pc schreef op dinsdag 5 maart 2024 @ 14:06:
Begrijp ik goed dat het speciale karakter in een kolomnaam zit?

Nee het speciale karakter zit in de output ervan, en ik heb geen idee hoe ik het karakter mee krijg in de output

[J2pc]

Ah, dus als ik 't goed begrijp:

hoewel er 'Çallioğlu' in het veld/de kolom staat (of moet staan), de output van de select 'Çallioglu.pdf' teruggeeft

Die C lijkt erg op een Franse [ç], Ik weet niet of dit ook daadwerkelijk hetzelfde karakter is. Maar ik vind het opvallend dat deze wel terugkomt, maar de g met dakje (die ik niet zomaar ken uit m'n Frans) niet.

Dat doet me denken aan taal/encoding settings. Systemen hebben nog wel eens de neiging om karakters die niet passen in de settings ter vervangen voor gelijkende unicode karakters die wel passen (misschien een turkse -> franse ç?)

Ik zou even naar de collation en codpage etc. settings kijken
https://learn.microsoft.c...ort?view=sql-server-ver16

[Opifex]

J2pc schreef op dinsdag 5 maart 2024 @ 14:55:

Die C lijkt erg op een Franse [ç], Ik weet niet of dit ook daadwerkelijk hetzelfde karakter is. Maar ik vind het opvallend dat deze wel terugkomt, maar de g met dakje (die ik niet zomaar ken uit m'n Frans) niet.

De Franse ç is een geldig karakter in extended ASCII. Die speciale g niet.

[sig69]

Is je kolom varchar of nvarchar?

[ArnoldSmit]

@sig69 De kolom is het type varchar

[sig69]

Dan zou ik er even nvarchar van maken.

[ValHallASW]

Opifex schreef op dinsdag 5 maart 2024 @ 14:59:
De Franse ç is een geldig karakter in extended ASCII. Die speciale g niet.

"extended ASCII" zegt niets in deze context, want dat kan even goed Windows-1254 zijn, waar zowel de ç als de ğ valide karakters zijn. Het gaat hier (vermoedelijk) specifiek om Windows-1252.

[Voutloos]

Als je code of data gaat migreren maakt het uit of het Windows-1252 of Windows-XXXX is, maar hier is het mierenneuken: Het is 1999 geweest, de charsets met 1 byte per karakter volstaan niet meer.

Korter: Veel strings, en zeker persoonsnamen, moeten in unicode. The end.

[HenkEisDS]

Ğ =
G met een breve =
Yumuşak in het Turks =
‘Zachte G’.