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;