Unicode Zeichen in Query-Komponente

[hsdkit]

Hallo,
ich habe ein Problem. Ich möchte Unicode-Zeichen, in diesem Fall persiche Zeichen (Farsi) an einen Query übergeben und nach diesen Eintrag in einem MSSQL-NVARCHAR Feld suchen.

1. Ich setze ADO ein
2. Ich setze tnt-Controls zur DB-Anzeige ein, diese sind Unicode-fähig
3. Ich setzt MS-SQL 2000 ein

Kann mir jemand einen guten Tip geben??

Vielen Dank im voraus für sinnvolle Beiträge.
Hermann

[Bernhard Geyer]

Entweder du setzt deine Abfragewerte als Parmeter oder Du probierst mal ein N vorzusetzen:

select * from mytable where myColumn = N'UnicodeWert';

[hsdkit]

Danke für den Tip, funktioniert allerdings nicht.

Ist schon seltsam mit den arabisch/persichen Zeichensätzen.

Nochmals Dank
Hermann

[Bernhard Geyer]

Natürlich muss der komplette Weg bis zum Absender der Query mit Widestrings arbeiten. Sobald einmal eine Wandlung nach (Ansi-)String erfolgte ist dein String kaputt (Statt Unicode kommen Fragezeichen). Check deine Query mal mit dem SQL-Tracer von M$ ob wirklich der String mit den persischen Zeichen überhaupt bis zur DB ankommt.

Auch würde ich dir meinen Artikel in der Ausgab 5.2003 von der Zeitschrit der Entwickler empfehlen (We are one World). Dort wird auf einige Aspekte der Unicodeentwicklung mit Delphi eingegangen.

[skyware]

...hab das selbe Problem...

folgendes konnte ich mittels Profiler auslesen:

exec sp_executesql N'select * from ttest where test_unicode = @P1
', N'@P1 char(50)', '''?''

@P1 sollte eigentlich ein chinesisches Zeichen sein...

es scheint als kommt das Zeichen nicht korrekt bei der DB an.
Aber woran könnte dies liegen?

[alzaimar]

Es gibt einige Fehler im ADO-Wrapper (D6) von Borland hinsichtlich den Unicode-Strings. Googel mal nach patches. Einen habe ich im Web gefunden (der dürfte für Dich reichen), den Anderen nicht: Da musste ich mir selbst helfen. NVarchars werden fälschlicherweise innerhalb Delphi als NChars interpretiert, was dazu führt, das alle NVarchar(X)-Spalten -durch Delphi gefüllt- genau X Zeichen (mit Blank aufgefüllt) haben: Ärgerlich. Gleiches gilt für Parameter.

Hast Du eine Delphi Version mit Quellcodes? Dann kann ich Dir den Patch geben.

[skyware]

Hallo,

ja habe den Source Code..Delphi 6 Enterprise.
Wäre super wenn Du mir den Patch senden könntest,
war jetzt schon den ganzen Nachmittag dran dieses
Problem zu lösen..leider bisher noch ohne Erfolg.

Bin also gespannt obs mit dem Patch läuft...

[alzaimar]

Schau Dir in ADOdb.pas die beiden Funktionen 'ADOTypeToFieldType' und 'FieldTypeToADOType' an. In Letzerem war der Fehler, glaub ich, drin. Aber das ist auf den ersten Blick zu sehen: Check die Case of und die Abbildung von ftWideChar zu adWChar. Ich habs natürlich schon korrigiert, aber ich meine, der Bug war in FieldTypeToADOType, da stand nämlich

Delphi-Quellcode:

...
  Case FieldType Of
...
    ftString, ftWideChar : Result := adVarChar;
...

und richtig muss es ja heissen:

Delphi-Quellcode:

...
  Case FieldType Of
...
    ftString : Result := adVarChar;
    ftWideChar : Result := adVarWChar;
...

Falls Du Stored Procedures mit NVarChar Parametern hast, bekommst Du den von mir schon beschriebenen Bug: Übergabe z.B. von 'Foo' an einen NVarChar(10) Parameter landet in SQL als N'Foo ' (also mit Leerzeichen auf 10 Zeichen aufgefüllt). Dieser Bug ist wohl in ADO selbst. Da hilft dann nur ein Workaround.

Melde Dich, falls DAS bei Dir auftritt. Dann musst Du im OnWillExecute-Ereignis der TADOConnection den ADO-Typen des Items per Hand setzen:
Ich habe eine Stringlist von Parameternamen, die ich umbiegen muss, und dann geht's so:

Delphi-Quellcode:

Var
  i : Integer;

Begin
  with Command.Parameters do
    For i:=0 to Count - 1 do
      If fWideCharParams.IndexOf(AnsiUpperCase (Item [i].Name))<>-1 Then
        Item [i].Type_ := adVarWChar;
end;