In Tiburon, the next versions of Delphi and C++Builder, there is full support for Unicode throughout the language, the compiler, the runtime library, and the VCL. The basic String type is now a UnicodeString. As part of the Unicode support, there is also full support for Unicode characters in databases and database components. While Delphi and C++Builder have supported Unicode characters at the database level for some time, you know can use all of the VCL components to display and manipulate the Unicode characters.
I have an InterBase database from demos I did back when we first added support for Unicode in our DBX3 driver days. The database contains English, Greek, Hebrew, and Chinese strings in the CharField column. I create a VCL application with some database components: SQLConnection, SQLDataSet, DataSetProvider, ClientDataset, DataSource, DBGrid and DBLabel.
There are two ways to get a program to work with the Unicode database. 1) Open SQLConnection’s "params" property in the Object Inspector and create the name=value pair "ServerCharSet=UTF8". Then right mouse click on the SQLConnection component and choose "Refresh Connection String". Set the Connection active and now I have Unicode Characters in the DBGrid. 2) Modify the DBXConnections.xml file for your database connection to add "ServerCharSet=UTF8".
Here is the resulting VCL application form at design time:
Stay tuned to the developer network for Tiburon video previews. Also stay tuned to the CodeGear blogs for other employees who will preview Tiburon technologies.
{ 20 } Comments
This may need to be re-published to the main web site, blogs.codegear.com? The design-time image is called image10_656.jpg in the main blogs page and 404’s.
-Brion
David - can you say whether the Unicode support will (or does) extend to the full range of COM features in Tiburon, e.g. type library import, ActiveX control development?
Mike –
The entire product is "Unicodified" — top to bottom, left to right, front to back.
Nick Hodges
Delphi Product Manager
Oh, come on, you still haven’t updated the painting of the columnheaders of the TDBGrid? I know better than to use TDBGrid on big(ish) projects, but on smaller ones it often makes sense to use it, except that it looks completely out of place on XP and Vista. It’s not that hard to fix either - you allready have a solution in CodeCentral (http://cc.codegear.com/item.aspx?id=24021)
Hi David, great news. But could you please change the theme of your blog? The color scheme really hurts eyes.
As i comment on nick blog, i expect teh announced plans to cross compiling be a reality. Linux servers are all a marketplace for big companies. Delphi user’s are losting that market, without sense.
Best regards.
Hi,
I wonder how you are testing Unicode capability on all those enhanced VCL controls and inside the various units?
I assume that just copying and pasting some text from a Russian or Chinese website is not enough, correct?
cu,
Michael
Michael - we have testers all over the world. In my testing, I have installed the Japanese language keyboard software and can use the Hiragana keyset to put Japense characters throughout the product - IDE, property editors, component editors, runtime, etc.
We also have international members of our QA team doing testing and localization.
I also use Google Language Tools to translate text and paste it in but just for some demos.
And for applications where their schema is NOT Unicode? And for applications that are using ANSI string data over file/comms interfaces to external systems?
This automagic Unicodification is a benefit how precisely?
Are the sorts of people seriously using TDBGrid REALLY the sorts of people for whom Unicode is even on the radar?
CodeGear really dropped the ball on this one - suddenly the fire-sale price for the company starts to make sense.
If the end result of Unicodification is similar to the Delphi.Net string handling, I see no problems. I already used VCL.NET to create file interfaces and worked OK (remember that .NET framework is all Unicode).
Jolyon Smith -
>And for applications where their schema is NOT Unicode?
>And for applications that are using ANSI string data over
>file/comms interfaces to external systems?
Nobody mentioned ANSI string is absolute.
>This automagic Unicodification is a benefit how precisely?
In a way that your application won’t crash just because the customer decided to install another non Unicode application that requires different code page than yours to work.
>Are the sorts of people seriously using TDBGrid REALLY
>the sorts of people for whom Unicode is even on the radar?
No, we have already scrapped that a long time ago because it did not support Unicode.
Гет Лост, хе хе
This is great to see! Thanks for posting it.
(I would agree you could theme the grids, though… I know that’s a long-standing gripe among those who use them, and if I did I would probably feel that way too.)
What about .Net roadmap.Will Tiburon support ECO V or force people to shift to VS ?Please see the ECO newsgroup to see what people are commenting about .Net expectations
The order of the word in hebrew is not correct
I’ll second stanleyxu2005 about the colour scheme. The standard colour is too light and it’s irritating to have to put the cursor over each individual paragraph to make it darker.
Nice David, Thanks a lot!
Can I put a problem for you? If you solve it, I promise that I’ll try to grab for you the best virtual full-colored shirt to be found arround…
The problem:
We have 100 clients which use a central DB (charset WIN1253 - Greek) through a Delphi fat client. In the above DB we have (let’s say) a table T1 with two fields F1 and F2. We want to convert the data from F1 to Unicode (eg. it’s a name of a person etc.) and F2 to leave ‘as is’ (let’s say that inside we have RTF data). We have in our application in 300 places F1.AsString and F2.AsString and in 200 places F1.Value and F2.Value where in those F1 and F2 are parameters passed as TField or FindField(’F1′).Value, hence will be a variant which will be converted from/to string.
Quiz:
How we upgrade the above system to Tiburon without any problems, knowing that from 100 clients 10 will upgrade immediately, 20 at different dates in the next month, 30 /might/ update, 25 are in vacantion/sick etc. and will open their client after a prolonged period of time and 15 will "never" upgrade?
IMO, m.Th.’s problem is not as much related purely to Tiburon as it would be a database schema version problem. Changes to a schema may be as application breaking as changing from Ansi to Unicode in the application.
A possible workaround: Create an F1U field as Unicode. Write two triggers that translate WIN1253 to Unicode from F1 to F1U on change, and vise versa: from F1U to F1. Leave the current application as is (assuming that it will not barf on the F1U field anywhere). In the Tiburon version, change all F1 references to use the F1U field.
This way, the old and the new can coexist to a certain degree. On the other hand - it is advisable to write your client contracts in such a way that they are obliged to upgrade to the latest production version within reasonable time. If you don’t, you will end up with a version compatibility nightmare.
Write "Grace period" functions that warn the user that his application will cease to function withing 30 days unless he upgrades to the latest version. Make sure you can override such a function per user if you have users with unreasonable incompetence levels.
@Lars: Thanks very much! Nice idea. But we have way too many fields to duplicate, to refactor views, SPs, reports etc. Of course my example can be misleading. …but I’ll take your idea and we’ll force our users to upgrade by using a ‘DB Version’ field somewhere (it will be a generator, most probably).
On Tiburon’s side, in order to have a smooth upgrade path, imho, what would be a nice thing would be a property Encoding: TEncoding read… write… ; on TDataSet and on TField descendants. If Encoding is nil in TDataSet then it will grab the value from a global/project variable. If Encoding is nil in TField then it will take the value from TDataSet’s one. This (combined with DBVersion indicator) will allow a gradual change in DB, thus keeping the code base in a stable state. Of course, ‘Encoding’ applies (AFAIS now) at strings and blobs/memos only… Also if we’ll have in the TDataSet component’s right-click popup menu a choice saying ‘Set all the fields to enconding’ won’t hurt of course…
David?
Delphi is great forever and ever!!!!!!!!!!!!!
I’m using CodeGear Version 11, and it allows me to specify the OBJ files be put in a specified folder, but it doesn’t put the TDS files in that same folder.
The reason this is annoying is because I backup my source code by copying the entire folder and its subfolders, and these gigantic TDS files are in those folders.
Could you make newer versions of the compiler put the TDS files in the same folder as the OBJ files? That way we can easily backup our source code without these temporary files wasting our time or space.
{ 2 } Trackbacks
[…] like Generics and Anonymous Methods, IDE enhancements, and much more. You can get a taste on David I’s blog. There will be videos and articles online, as well as events around the […]
[…] Unicode database support in Tiburon for Delphi and C++ http://blogs.codegear.com/davidi/2008/07/15/38895 […]
Post a Comment