Hi Tim & Team,

I bit the bullet and moved from DBISAM V4 to ElevateDB and have never
had a need to worry about UNICODE in any programs produced before. So my
question is this...

Q: Is there are advantage to NOT using the UNICODE version of ElevateDB
? Some of the programs I'm producing will never be used in different
countries but would I not just stick with the UNICODE version for
evetrything from now on OR is there some advantage in NOT using the
UNICODE version where a program is only for use in say Australia.

Thanks and I hope you all had a safe Christmas,

Phil,

Phil

The answer to that partly depends on which version of Delphi you're using. Pre D2009 you would have to buy or develop controls to use unicode so there could be a major advantage financially. If you have D2009 you've probably had to invest in new controls anyway.

Roy Lambert [Team Elevate]

Hi Roy,

Thanks for the prompt reply... I'm using Builder C++ 2009 which from
what I have read has fully compatible unicode controls is that correct?

Thanks.

Phil

Some random thoughts:

 *  I am not sure why one would want to use Ansi anything if developing in C/D2009 .. all those conversions, even if Tim has hidden them!

 *  OK, U-strings take more storage and longer to transmit over slow links, but if those are your drivers why develop in '2009'

 *  <rant>I have to do Unicode .. but I also have to do serial comms and the serial component developers have not yet 'got' that unicode strings could be transmitted just as easily as ansi ones. </rant>

 *  The future is unicode (I think)

Probably not much help!   

Malcolm

Phil

>Thanks for the prompt reply... I'm using Builder C++ 2009 which from
>what I have read has fully compatible unicode controls is that correct?

And how would a D2006 user be able to answer that

On a more serious note go 100% unicode - you'll find it easier.

Roy Lambert [Team Elevate]

Malcolm

> * <rant>I have to do Unicode .. but I also have to do serial comms and the serial component developers have not yet 'got' that unicode strings could be transmitted just as easily as ansi ones. </rant>

Its more that the hardware developers and the whole infrastructure would have to change. Try communicating with your friendly email provider using unicode command strings. They HAVE to be ansi (or possibly ascii).

Roy Lambert

Hi Roy

Yes, in the case of serial in particular, what counts is the
firmware/software at the other end.  But the transport should
not care.

At present I send stuff to two systems, one is, and will
probably stay, plain ascii.

The other is a software system from an international group that
currently can cope only with ansi.  However, my technical contact
tells me they keep talking about unicode so I have hopes they
will eventually switch.  At the Olympics they had to run parallel
systems in order to cope with English and Chinese!

But if they do I will be stuck since the two serial components I
have tried use an ansi string as the Write() parameter.  On
speaking to the authors they have said something like .. but
serial is a byte transport<shrug>!  Well, I thought it was a bit
transport - but even if they work at byte level, a U-string can
be read as bytes.  Anyway I reckon the component should not care
about the interpretation of the data but simply dribble it down
the wire!  Hopefully the authors will come round in time....

I trust you will have a great Hogmanay up there .. and remember
little of it.  
I will probably spend mine wrestling with EDBConfig paths,
Sessions, Scripts, etc.  I don't even want to think about how to
handle schema updates...  

Well .. I might just manage to sip a wee dram or two ..

Malcolm

Malcolm & Roy,

Thanks for your feedback /comments they where more than helpful, UNICODE
it is and I'm not looking back (well not until I fire BCB Version 5 up
to modify my old programs).

Thanks and a happy new year to you both!

Phil.

Phil,

<< Q: Is there are advantage to NOT using the UNICODE version of ElevateDB ?
Some of the programs I'm producing will never be used in different countries
but would I not just stick with the UNICODE version for  evetrything from
now on OR is there some advantage in NOT using the UNICODE version where a
program is only for use in say Australia. >>

I would just go 100% Unicode now.  The benefits are:

1) Delphi is going to be Unicode from now on.
2) The Windows APIs have been Unicode internally for some time now, so the
API calls will be faster.
3) If you need to provide access to your ElevateDB database(s) from .NET,
then you can do so without any problems.  The ElevateDB .NET data provider
only works with Unicode databases, it does not work with ANSI databases
(although the ElevateDB ODBC driver works with both).

--
Tim Young
Elevate Software
www.elevatesoft.com

Malcolm


Have you had a look at Synapse. Since I'm not going unicode I don't know how it copes with it but I think its at least gone D2009 compatible. Good solid software and good support.

Roy Lambert