Porting an application to Windows 10/Delphi 10.2 (part 5)

Three and a quarter years ago, I wrote about the trials and tribulations of porting a Delphi7 database program to Delphi 10/Windows 10 that has built-in unicode. The subject quietly dropped off my map, but in the past two weeks the OP has had much difficulty with the computer that is designated the database server. So much difficulty that I have been tasked with finding out whether it is possible to port the program to Delphi 10 (Seattle) so that the database can be moved to a modern Windows 10 machine.

I read my blog entries a few times in order to remember what worked from the previous time and what didn't work. The first thing that I did was to define a new database whose charset is UTF8. Then I defined a new table 'people' using the DDL file that I extracted from the old database, taking care to redefine any fields that would hold Hebrew as being 'CHARACTER SET UNICODE_FSS'.

I then copied a conversion program that I had written for my previous tests to a new directory and redefined the databases involved. For some reason, Delphi kept on using the wrong version of the source but I eventually sorted this out. I defined a query qGetPeople as being

select ID, gender, docket, aliya, classa, classb, followup, q400, dob, 
examdate, zehut, 
cast (surNAME as varchar (24) character set  UNICODE_FSS),
cast (FORENAME as varchar (16) character set UNICODE_FSS),
telephone, email,  origzehut,
cast (address as varchar (128) character set UNICODE_FSS),
cast (country as varchar (24) character set UNICODE_FSS),
cast (army as varchar (48) character set UNICODE_FSS),
cast (education as varchar (128) character set UNICODE_FSS),
cast (workplace as varchar (64) character set UNICODE_FSS),
cast (jobname as varchar (64) character set UNICODE_FSS)
from people

Then I used this query to extract records from the old database in order to insert them into the new unicode-aware database. Rubbish was being entered! I tried and tried but couldn't figure out why this once worked and now it doesn't.

I broke off for lunch and a light nap whilst I considered my options. I created a new table in the new database consisting of three fields only: an auto-increment id field, a surname and a forename. I defined the latter two fields with the character set WIN1255 - what might be termed 'old-fashioned' Windows/Hebrew. In order to populate this table, I used a simple query 'select surname, forename from people' as opposed to the complicated query above. Checking the data in the SQL Database manager showed that my new table did indeed hold Hebrew text!

I then put together a simple application with a data module, a form that shows all the data from the new table in a grid and a simple form that allows the editing of one record chosen from the grid. This all works perfectly.

So what's the difference between this time and last time? I think - and I'm not about to test this assumption - that the difference is Russian. The complicated management program that I will have to port over the next year does not contain any Russian, so the simple proof of concept program that I wrote should be sufficient in the technical unicode sense.

---

This day in history:

Blog #	Date	Title	Tags
169	26/04/2009	Knowledge hoarding	ERP, Psychology, Kaizen
170	26/04/2009	The iron law of bureaucracy	ERP
354	26/04/2011	Crocs	Shoes, Copper
833	26/04/2015	Vinyl log 6 - 26 April	Richard Thompson, 1975, Vinyl log, Walking
1126	26/04/2018	Programming text screens in Priority	Priority tips