delphiXE, tested 2.15b2 , 2.15b3


I'm using double byte in a string field and i input non-english string.

If i open the table with EDBtable , it is ok. But if i use EDBquery, some of ending character is discarded.

Under EDBManager, i could get same result.

value of EDBTable :  홍길동회계(제0000&#48152
value of EDBQuery: 홍길동회계(제

I'm using EDBManager.Characterset and EDBSession.Characterset as Ansi.

I can not use Unicode for some reason.

I have done more test.

If i open EDBTable in dbgrid, I can input/modify any string without problem but if i use EDBQuery with Params(String value), I always got wrong string.

Above result is the same in DBISAM.

I think there is some problem in handling Params string in EDB(Ansi verion) and DBISAM.

Hyun,

<< I have done more test.

If i open EDBTable in dbgrid, I can input/modify any string without problem
but if i use EDBQuery with Params(String value), I always got wrong string.

Above result is the same in DBISAM.

I think there is some problem in handling Params string in EDB(Ansi verion)
and DBISAM. >>

Can you send me a project that demonstrates the issue that you're seeing ?
Also, is this a new issue in 2.15, or something that existed prior to it ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

I have sent sample project.

"Tim Young [Elevate Software]" wrote:

Hyun,

<< I have done more test.

If i open EDBTable in dbgrid, I can input/modify any string without problem
but if i use EDBQuery with Params(String value), I always got wrong string.

Above result is the same in DBISAM.

I think there is some problem in handling Params string in EDB(Ansi verion)
and DBISAM. >>

Can you send me a project that demonstrates the issue that you're seeing ?
Also, is this a new issue in 2.15, or something that existed prior to it ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Hyun,

<< I have sent sample project. >>

Thanks.

The issue is that the TParams.AsString property is a *Unicode/WideString*
property, while the TField.AsString property is an *AnsiString* property.
So, when you assign the fields directly using the TField.AsString property,
the AnsiString-to-UnicodeString conversion is being done implicitly using
the current default locale.  With the TParams.AsString property, the strings
remain as UnicodeStrings until they are converted to AnsiStrings by the
ElevateDB engine, and it does so using the collation, and subsequently the
locale/code page, of the column to which the string value is being assigned.
In your case, the first column was defined with the KOR (Korean), while the
others were defined, most likely accidentally, using the AFK (Afrikaans).
So, the first column assignment was being string-mapped (with the params
assignment), whereas the other two were not because they didn't know how to
treat any of the special characters.

You can make the field assignments behave like the parameter assignments by
using the following code:

uses edbenv;

procedure TForm6.Button2Click(Sender: TObject);
begin
 EDBtable1.Append;
 EDBTable1.FieldByName('namekor').AsString :=
MapStringToAnsi('Çѱâ»ó»ç',949); // 949 is Korean code page
 EDBTable1.FieldByName('nameafk').AsString :=
MapStringToAnsi('Çѱâ»ó»ç',949);
 EDBTable1.FieldByName('note').AsString := 'inserted using Table';
 EDBTable1.Post;
end;

I know that this isn't what you want, but it helps illustrate what is
happening.

As to a solution, there really is no easy solution other than to convert the
database to using the Unicode character set instead of the ANSI character
set.  This is just simply a "hole" in the way that the TStringField/TParam
classes work because there is no way to specify the locale/collation for
them when dealing with AnsiStrings.  This causes strings to be mapped using
the default locale instead of the one assigned to the column in ElevateDB.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks for replay.

Currently I'm using local db.

Why don't you change params handling like TField handling?

I think if TField.asString  converts string as automatically default charset, TParams.asString can do same handling in Ansi.

edbquery1.FieldByName('xxx').AsString  := 'yyyy'; //works well

edbquery1.ParamByName('xxx').AsString := 'yyyy'; //not work properly

Hyun,

<< Why don't you change params handling like TField handling? >>

I can't - it's the TParam class in the common DB.pas unit provided with
Delphi/C++Builder.  Plus, the two (TParam and TField) work completely
differently - params use variants, whereas fields use low-level character
buffers that must be loaded/saved in raw format.  That's why TField string
assignments never get mapped - they are specified as AnsiString via the
AsString property, and they are never converted back and forth to Unicode
strings like the TParam values.

<< I think if TField.asString  converts string as automatically default
charset, TParams.asString can do same handling in Ansi. >>

What you're asking me to do is have the ElevateDB engine ignore the
collation defined for the column when storing a Unicode string (default
string type for newer Delphi compilers) in an ANSI database table column.  I
can't do that.

Let me ask you a question, since I'm not familiar with the Korean
characters, etc.:  why not just define the column as ANSI, and not KOR ?
That will prevent ElevateDB from mapping the strings, and will do what you
want.

Tim Young
Elevate Software
www.elevatesoft.com

I already tested with ANSI field but it is not work.

Anyway thanks for kind explanation.

Hyun,

<< I already tested with ANSI field but it is not work. >>

What do you mean, exactly ?  I tried it here and it worked fine - it
reproduced the same results as the TField assignments.

Tim Young
Elevate Software
www.elevatesoft.com