Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread DBISAM 4 and Unicode
Tue, Dec 15 2009 4:14 PMPermanent Link

"Alessandra"
I'm going to move some D6 projects to D2010 in january, and am dealing with
the Unicode matter.
I've read that the "string" type now is unicode. Can i use unicode strings
(actually with only plain ascii or ansi characters inside) and write them
into a char field in dbisam just like i did before, or have i to change
something in the code, converting them to ansi or defining everything in my
code as "ansistring" instead of "string"?

And, aside dbisam: does a "hello world" string uses more memory in a unicode
string than in a classic string?
I have some procedures with do some intensive processing (search, replace,
delete, etc.) on strings, used as temporary storage for some data. My fear
is that a 1000 bytes "old styled" string could become a 4000 bytes long one,
and the processing time could dilate as well. I hope not. Is anyone dealing
with these matters?

Thanks for any advice
A.
Tue, Dec 15 2009 5:16 PMPermanent Link

"Raul"
Alessandra,

There are number of discussions in this NG regarding DBISAM and Unicode -
you should be able to find them. Basically DBISAM is still ANSI so ansi
strings should work just fine. If you want true Unicode you need to move to
EDB unicode.

That being said most of the ANSI stuff should continue working just fine in
D2010 as long as you update your code - especially string handling and
operations.

There have been number of post on Codegear/Embaracadero website regarding
this including Nick Hodges one (I think part 1 is here :
http://edn.embarcadero.com/article/38437 but there are also parts 2 and 3)
as well as some white papers (Marco Cantu did one I think) and even eBooks
(again Marco Cantu has a Delphi 2009 handbook that was given away with
Delphi for a while so you might have it already - and he's releasing a 2010
version soon).

Delphi 2009/2010 uses UTF-16 I believe as default so the "storage cost"
doubles (your 1000 byte string consumes 2000). You could use AnsiString
instead of string to keep the storage down but generally overall moving to
unicode is not a big deal. You need to review your string handling functions
so that you use the new ones that are unicode aware as well as pointer
handling has changed a bit.  Again lot of info is available for app
conversion like yours - start with the white papers and Nick Hodges posts.

Raul


"Alessandra" <alessandra@sarasoft.net> wrote in message
news:3977DAC2-0010-4D0E-B934-FD38F7CB529A@news.elevatesoft.com...
> I'm going to move some D6 projects to D2010 in january, and am dealing
> with the Unicode matter.
> I've read that the "string" type now is unicode. Can i use unicode strings
> (actually with only plain ascii or ansi characters inside) and write them
> into a char field in dbisam just like i did before, or have i to change
> something in the code, converting them to ansi or defining everything in
> my code as "ansistring" instead of "string"?
>
> And, aside dbisam: does a "hello world" string uses more memory in a
> unicode string than in a classic string?
> I have some procedures with do some intensive processing (search, replace,
> delete, etc.) on strings, used as temporary storage for some data. My fear
> is that a 1000 bytes "old styled" string could become a 4000 bytes long
> one, and the processing time could dilate as well. I hope not. Is anyone
> dealing with these matters?
>
> Thanks for any advice
> A.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4691 (20091215) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


Tue, Dec 15 2009 5:34 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Alessandra,

<< I'm going to move some D6 projects to D2010 in january, and am dealing
with the Unicode matter. I've read that the "string" type now is unicode.
Can i use unicode strings (actually with only plain ascii or ansi characters
inside) and write them into a char field in dbisam just like i did before,
or have i to change something in the code, converting them to ansi or
defining everything in my code as "ansistring" instead of "string"? >>

I would, as a matter of keeping the code straight, modify all String
declarations that you are responsible for as AnsiString, and then only deal
with the AnsiString<-->UnicodeString conversions when dealing with the VCL
controls and classes.  That will keep the amount of work to a reasonable
level, and allow you to be sure that your internal processing has not
changed.  In the TDataSet -> TField layer in the VCL, TField.AsString still
internally calls TField.GetAsAnsiString and automatically converts the
string to a UnicodeString, so that doesn't require any changes.  However, to
avoid the constant conversions, it would be helpful to just call
AsAnsiString instead everywhere instead of AsString.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Dec 22 2009 9:51 AMPermanent Link

"Alessandra"
Your tips have been really precious to me, Raul and Tim! Thanks to both of
you!

Merry Xmas!!
A.
Tue, Dec 22 2009 1:17 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Alessandra,

<< Your tips have been really precious to me, Raul and Tim! Thanks to both
of you! >>

You're quite welcome.  Merry Christmas to you and your family.

Enjoy !

--
Tim Young
Elevate Software
www.elevatesoft.com

Image