Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 12 total |
Ansi character query problem |
Fri, Jan 17 2014 7:56 PM | Permanent Link |
Hyun Ju Yong | 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반 value of EDBQuery: 홍길동회계(제 |
Fri, Jan 17 2014 8:09 PM | Permanent Link |
Hyun Ju Yong | I'm using EDBManager.Characterset and EDBSession.Characterset as Ansi.
I can not use Unicode for some reason. |
Sat, Jan 18 2014 7:08 PM | Permanent Link |
Hyun Ju Yong | 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. |
Thu, Jan 23 2014 5:00 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Thu, Jan 23 2014 7:14 PM | Permanent Link |
Hyun Ju Yong | 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 |
Tue, Jan 28 2014 5:07 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Wed, Jan 29 2014 4:28 PM | Permanent Link |
Hyun Ju Yong | 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 |
Wed, Jan 29 2014 7:55 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Jan 29 2014 9:40 PM | Permanent Link |
Hyun Ju Yong | I already tested with ANSI field but it is not work.
Anyway thanks for kind explanation. |
Fri, Jan 31 2014 6:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |