I have just built my first system with EDB Set to Unicode rather than ANSI.

I am writing with Delphi XE8. Thinking I will have to upgrade to the new release sooner or later.

I have found a few issues, but so far it actually seems easier than I was expecting.

1. All DB definition "COLLATE ANSI" changed to COLLATE UNICODE
2. In Delphi engine & session started with Unicode Character set.

--

I can see some fairly minor-seeming issues with displaying data.

In my own code I use "String" everywhere, and never "ANSIString", but I can see some of the libraries I use contain references to ANSIString. (I use libraries like DevEx, Raize, VirtualStringTree and a couple of others).

--

I realise this is not strictly on-topic for EDB, but what other gotchas am I going to hit?

(just when I thought the conversion was going to be easy)

Obviously EDB and database focused ones first, but happy to hear about others as well.

Adam,

I don't anticipate serious problems with automatic conversion, for the most part automatic, between unicode and ansi strings, unless you have to deal with alphabets other than Latin. In that case, I don't know.

Anyway, I have migrated 2 big DBISAM applications to EDB Unicode and apart from some minor issues because of testing if a Char is in a set, and a review of places where size of buffers is important,  everything went well.

There is an issue that you might encounter with Delphi, when you open unicode and ansi projects without closing Delphi in between:
TEDBEngine sometimes reverts the "Unicode" setting to "Ansi". That is something that you can do nothing to avoid, it has to do with the way Delphi deals with singleton objects. The workaround is easy: just close Delphi when you want to open another project that doesn't use unicode.


--
Fernando Dias
[Team Elevate]

Fernando

Thank you for this, my initial work has been good, EDB has done a perfect job of storing and managing extended characters and Delphi has not caused huge issues.

My main problem is that I am actually converting an application to work with an Indian script, so all roman-alphabet goes right out the window!

I am still worried about issues like reliability of reproduction of characters on different computers (ie whether Windows will really manage the process of displaying the characters well for a moderate number of users on different hardware).

Also, I will be exporting from EDB into other applications via ODBC ... again I am somewhat worried about whether the export process will be totally reliable.

Any more feedback from EDB Developers with experience of this would be gratefully received, even if just to say that you have done it without problems.

Adam

Fernando,

<< I am still worried about issues like reliability of reproduction of characters on different computers (ie whether Windows will really manage the process of displaying the characters well for a moderate number of users on different hardware). >>

It all hinges on whether the user is typically using the same character set/language as their main system locale in Windows.  As long as that is the case, then any transparent conversions that are made to Unicode will be correct.

Tim Young
Elevate Software
www.elevatesoft.com

As an update to this post, I am at the stage of later-testing with UNICODE conversion of my Delphi Application now, and thought others might be curious about how it turned out.

It was actually extremely easy. The main issue was adding "ftWideString" and "ftWideMemo" field-type options to a variety of points in my code where UI was auto-generated from data-sets. This allowed all UI creation to handle UNICODE effortlessly.

Third party components (Fast Reports, Developer Express, Raize) all slotted in with no re-coding at all, and seem to display / load / save UNICODE perfectly well.

The only component that has given me any problems has been the SynEdit SQL Editor. I hold many SQL and XML resources that are used by the application within my database (ie for populating views, grids, trees etc.) and allow these to be edited within the application.

With a UNICODE database, the SynEdit SQL Editor has simply failed to display or allow editing of data. Data is displayed incorrectly, and attempts to edit it just mess it up.

The SQL / XML data is stored perfectly by EDB, but editing it is no longer as easy. I have reverted to editing it in a simple TMemo type control, which is a definite backwards step.

I am looking at branches of the SynEdit open-source code-base now for solutions ...