Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 12 total |
Advantage of using NON-UNICODE version or ElevateDB |
Sun, Dec 28 2008 6:12 PM | Permanent Link |
Phil Read | 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, |
Mon, Dec 29 2008 5:03 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Mon, Dec 29 2008 6:03 AM | Permanent Link |
Phil Read | 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. |
Mon, Dec 29 2008 7:12 AM | Permanent Link |
"Malcolm" | 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 |
Mon, Dec 29 2008 7:25 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Mon, Dec 29 2008 7:35 AM | Permanent Link |
Roy Lambert NLH Associates 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 |
Mon, Dec 29 2008 2:47 PM | Permanent Link |
"Malcolm" | 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 |
Mon, Dec 29 2008 3:17 PM | Permanent Link |
Phil Read | 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. |
Mon, Dec 29 2008 3:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Dec 30 2008 5:31 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
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 |