none
Unicode im SQL Server und SQL Query RRS feed

  • Frage

  • Hallo,

    ist wahrscheinlich schon ein oft gefragtes Thema, konnte aber mit der Suchfunktion und auch bei Google nichts finden.

    Ich habe eine Classic ASP Anwendung von ISO 8859-1 auf UTF-8 ungestellt. Server-Client Seitig klappt auch alles gut, man kann z.B. Japanische Schriftzeichen eingeben und sie werden korrekt HTML Encodiert wieder ausgegeben.

    Die Scripte nutzen z.T. noch Access Datenbanken aber hauptsächlich MS SQL Datenbank (2005 Online / 2008 Entwicklung).

    Die Access Datenbanken können ohne Probleme die Japanischen Zeichen speichern, der SQL Server wandelt sie jedoch in ???? um.

    Gemäß meiner Nachforschung muss man um das zu beheben bei jedem Update und Insert Befehl ein N'...' vorstellen. Funktioniert auch... Wie ihr euch sicher denken könnt, hab ich aber keine Lust 1000 SQL Befehle durchzugehen.

    1)

    Besteht die Möglichkeit entweder vom ASP Script aus oder direkt am SQL Server "einzustellen", dass er alle Abfragen verarbeitet, als wäre dieses N immer da (bei allen Texten). Denn es sind alle Textfelder nvarchar und das dürfte immer klappen.

    2)

    Wenn nein, muss man sie auch beim Select der Textfelder irgendwo einfügen? In meinem Test ging es auch ohne, d.h. im Select wurde nichts geändert, nur im Update/Insert.

    Samstag, 30. Juni 2012 08:34

Antworten

  • um das zu beheben bei jedem Update und Insert Befehl ein N'...' vorstellen. Funktioniert auch... Wie ihr euch sicher denken könnt, hab ich aber keine Lust 1000 SQL Befehle durchzugehen.

    Hallo Jan,

    um es zu präzisieren, bei jeder Angabe von String-Werten, egal ob Du die Werte einfügen (Insert/Update) oder danach filtern (Select) willst.

    Dem entnehme ich mal, das Du sämtliche SQL Statements dynamisch zusammen baust, anstatt parametrizierte Statements zu verwenden; dann hättest Du jetzt das Problem nicht in der Form, den dann setzt die Datenzugriffskomponente es schon selbst automatisch um. Siehe MSDN: SqlParameter-Klasse.

    Zu 1) Nein, gibt es Server Seitig nicht

    Zu 2) Ja, wenn Du auf Textwerte filtern willst, musst Du auch ein N Präfix verwenden.

    P.S.: Das N darf man auch verwenden, wenn man nicht mit Unicode arbeitet.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Samstag, 30. Juni 2012 12:14
  • Hallo Jan,

    dann muss der Code wirklich sehr alt sein, den bereits die MSDE 2000, quasi die Express Edition vom SQL Server 2000, war kostenfrei erhältlich.

    Und auch bei der Verwendung von MS Access / OleDB / ADO kann man mit Parametern arbeiten.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Sonntag, 1. Juli 2012 08:12

Alle Antworten

  • um das zu beheben bei jedem Update und Insert Befehl ein N'...' vorstellen. Funktioniert auch... Wie ihr euch sicher denken könnt, hab ich aber keine Lust 1000 SQL Befehle durchzugehen.

    Hallo Jan,

    um es zu präzisieren, bei jeder Angabe von String-Werten, egal ob Du die Werte einfügen (Insert/Update) oder danach filtern (Select) willst.

    Dem entnehme ich mal, das Du sämtliche SQL Statements dynamisch zusammen baust, anstatt parametrizierte Statements zu verwenden; dann hättest Du jetzt das Problem nicht in der Form, den dann setzt die Datenzugriffskomponente es schon selbst automatisch um. Siehe MSDN: SqlParameter-Klasse.

    Zu 1) Nein, gibt es Server Seitig nicht

    Zu 2) Ja, wenn Du auf Textwerte filtern willst, musst Du auch ein N Präfix verwenden.

    P.S.: Das N darf man auch verwenden, wenn man nicht mit Unicode arbeitet.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Samstag, 30. Juni 2012 12:14
  • Hallo Olaf,

    danke für die Hilfe. Denke es ist so alles klar, also immer wenn Text á la '...' an den SQL Server gegeben wird, braucht man das N vor jedem einzelnen Textstring. Eine Möglichkeit das Universel festzulegen gibt es nicht.

    Wird dagegen (z.B.) nur ein "Select Textfeld where id = 1" durchgeführt braucht man es nicht, das Textfeld wird korrekt übergeben - Zumindest ist das auch das Ergebnis meines Tests.

    Leider sind es "nur" dynamische Statements, das Projekt lief früher zu Zeiten als SQL Server noch nicht umsonst war noch komplett mit Access, daher ist es kein perfekter SQL Server Code aus Sicht eines guten Programmierers.

    Sonntag, 1. Juli 2012 07:58
  • Hallo Jan,

    dann muss der Code wirklich sehr alt sein, den bereits die MSDE 2000, quasi die Express Edition vom SQL Server 2000, war kostenfrei erhältlich.

    Und auch bei der Verwendung von MS Access / OleDB / ADO kann man mit Parametern arbeiten.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Sonntag, 1. Juli 2012 08:12
  • Hallo Jan Alexander 234,

    Ich gehe davon aus, dass die Antworten Dir weitergeholfen haben.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert


    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 1. August 2012 09:14
    Moderator