The road to Delphi 2009 - Part 1 (v)

A new year and time to make a decision about how we are going to move our ten year old codebase from Delphi 6 up to Delphi 2009. If you've followed my other posts in this "road to Delphi 2009" thread then you'll know that I hit a stumbling block when migrating a third-party component, ODBCExpress. This is a third-party database connectivity component that was well written, well documented and had good reviews and articles in Delphi Informant (which dates it a bit for those who remember that magazine).

At the time we chose it, our product was based on the Access database and we were looking to add SQL Server support, so we chose it as a good option to handle any database type. I explained this back in June 2007.

Unfortunately, the product was no longer actively developed from Delphi 2006 and despite help from its main developer to at least get it compiled into Delphi 2009, it didn't work properly thanks to all the Unicode changes.

Seeing as we bought Delphi 2009 in June 2009 and haven't migrated to it yet, a decision has been made. We are going to move all the code away from ODBCExpress, and to the dbGo ADO components provided as standard with Delphi (from Delphi 5 through to the current Delphi 2010).

Presciently, in June 2007, I also said this:

I've thought about moving to one of those bundled Delphi offerings in order to save myself the worry should ODBCExpress go tilt. But I haven't...because the database architectures offered with Delphi keep changing and I'm not sure I want to run the risk of changing everything over only to have it "deprecated" like the BDE.

Well the dbGo components are still going strong and they made the effort to Unicode-enable them for Delphi 2009, so I'm classing this as a low-risk option.

I wrote some test programs using the ODBCExpress components and then migrated it to ADO to see what conversion issues I'd have. I made notes and it wasn't as bad as I thought. I can now do everything I could do with the ODBCExpress components, even if I have had to write a function that does what a component used to do. If anything, it has been an interesting exercise in the back-end of SQL Server.

What was particularly pleasurable was doing all the work in Delphi 6 and then simply recompiling it in Delphi 2009 to see what happened. The answer: it compiled and ran just as it did in Delphi 6 (give or take a few string cast warnings in my own code which is part of the Unicode migration, and expected). Perfect.

For those who may ask why I'm not going for dbExpress instead (which is also standard with Delphi and developed by CodeGear/Embarcadero), it was a couple of things. It was initially my preferred choice but the extra DataSetProvider/ClientDataSet layer required to use it visually gave me the creeps, and I've been reading some frightening problems that people are having with it with Delphi 2010 and SQL Server. Plus the architecture of dbGo more closely matches that of ODBCExpress, facilitating the migration.

So now we have a path, a light at the end of the tunnel. It's not going to be pretty, and I know it will be tedious, but it will be another third-party component set that I can drop which, as I said in another posting in June 2007:

that the less third-party tools I can get away with using the better, purely for future-proofing purposes. If Delphi then provides that same component as standard in its next version, I'll use that one and thus reduce my dependency.

I'm now looking forward to the journey again.

The road to Delphi 2009 - Part 1 (iv)

So it has been a while since I last updated on my progress with the migration from Delphi 6 to Delphi 2009. There's a reason. I'm still on Delphi 6 and I've got nowhere fast with ODBCExpress!

To be fair to its developer, Pieter Myburgh, it isn't his project anymore and he has been very good in keeping in touch with me and letting me know how the open source status is coming along. Very slowly, it would seem. He created a project on SourceForge and that is the only activity there has been. I think legal red tape is giving him a bit of a headache.

I know I'm not the only one really hoping we can get ODBCExpress moved up to Unicode-enabled Delphi 2009. But I'm starting to come under a bit of pressure now to look at alternatives. It is understandable - we paid a lot of money of the new version (as it was then) of Delphi, under my recommendation, only to find we can't use it.

I've looked at changing to dbGo (ADO) or dbExpress, and have participated in some interesting discussions on Stack Overflow about the merits of both. But ultimately, the thought of having to change to the core database connectivity components of 10 years worth of software (including nearly 50 plug-ins) makes me shudder. Not least because we use a great deal of the intricate little details of ODBC and ODBCExpress, which we'd have to find alternatives for - if, indeed, an alternative is available.

On the upside, we would have had to buy Delphi 2009 or 2010 this year anyway, because of Embarcadero's decision to only allow upgrade prices for users of Delphi 2006 and later from 2010.

And also I have got all the other component sets that we use installed in Delphi 2009, and the main application compiles. So small steps are being made.

The road to Delphi 2009 - Part 1 (iii)

Still calling this Part 1 (Act 3) as I'm not actively pushing anything forward until I've overcome the ODBCExpress hurdle. I've had some positive steps forward with this.

I have been in regular contact with Pieter Myburg, its original author. Even though he is no longer actively developing it, he has very helpfully made some changes to 3 files that allow the packages to compile and install into Delphi 2009.

Even more helpfully, he has agreed to Open Source it and is looking for moderators. I have agreed to help (as has another user this morning) but we need more, as I can't honestly say with full confidence what I know what I'm doing with the code! I don't want to give out his email address on a blog but the newsgroup for ODBCExpress is news.korbitec.com.

So now I can connect my data and view it. I've already noticed that nvarchar fields (SQL Server) display with non-printable characters so that is my first area of investigation.

I have also come across another peculiar one. If I connect within the IDE, everything displays in a DBGrid. If I run the executable, when the database connects, the debugger pops up and shows me the CPU Window on ntdll.DbgBreakPoint. This used to happen to me in Delphi 6 when I pressed F12 in my software, which I understand was a bug left in the IDE. However, this happens when the database connects so I'm guessing it must be something in code.Whether that is ODBCExpress code or native VCL code, I'm unsure.

Slowly moving forward.

The road to Delphi 2009 - Part 1 (reprise)

So I haven't really got any further yet because I'm waiting to hear back from the author of ODBCExpress whether or not he will look to upgrade the packages for Delphi 2009. He's emailed to say he is "looking into it". From the newsgroup I can see I'm not the only one crossing my fingers.

If he doesn't then D2009 will be put on hold while I port 10 years of software to another database connectivity tool, so I can even open it in D2009. If he does, well then we'll be all set for moving onwards.

After I posted about having less screen real-estate, I found that using the push-pins gave me my entire screen. Nice touch. Those palettes now float into view if I need them, otherwise they float away. Very nice.

The road to Delphi 2009 - Part 1

OK, so I started with the easy stuff. Installing third-party components.

Raize Components - Check
TMS Component Pack - Check
ReportBuilder Enterprise/Server - Check

OK, these were easy because they were designed for Delphi 2009.

ODBCExpress - Oh. Well, according to its lead developer Pieter Myburg on the support newsgroup, "we have stopped active development of ODBCExpress, and we won't be porting it to future versions of Delphi ourselves".

The last support was for Delphi 2006 which, as I understand, compiles fine in Delphi 2007 as that was a non-breaking release. But not Delphi 2009, oh no. So if anyone out there has any experience with bringing this component set up to Delphi 2009, I would love to hear from you. Without this, we're stumped. It'd be a case of going back through 10 years of software and rewriting it to use dbExpress or ADOExpress. And I seriously don't think we can afford that time.

By the way, bearing in mind I have come from Delphi 6 and have only seen screenshots of the IDE from Delphi 2005 onwards, I really like the IDE. Although I seem to have less code editing space because of all the other (really very useful) palettes that surround it.

Bit the bullet: Delphi 2009!

So, I finally bit the bullet and purchased a Delphi upgrade, to D2009. The offer was too tempting and I have started to become frustrated with being left too far behind with Delphi 6.

Thanks to one of the distributors in the UK, Grey Matter, we got the D2009 upgrade for 20% off. This was a promotion they were running for those who didn't want to take advantage of June's "Buy Delphi and get RAD Studio free" promotion. Apart from a slight, but only curious interest in Delphi Prism, there wasn't enough to tempt me, in these economic times, to not take the 20% off instead.

And so I will chronicle my journey to take our 10 year old product, written in Delphi 5 then Delphi 6, to Delphi 2009. The challenges I forsee are more to do with API headers written for some of the hardware devices (clocking terminals) that we support with our T&A product, but time will tell.

To start with, it will be a case of getting the main part of the software converted and see how that goes. I have the latest versions of all our third-party products such as Raize Components 5, TMS Component Pack, ReportBuilder Server & Enterprise 11 and TsiLang Translation.

Could have some fun with older components like the Crystal Reports VCL component for Delphi (for Crystal Reports 7). Anyone got any experience with that?

Should be "interesting"...!

Delphi 2009 Sneak Peek Videos

I've just watched Nick Hodges go through some of the VCL enhancements for Delphi 2009, and two things struck me.

Firstly, I can't understand why the PasswordChar feature on TEdit was being demonstrated; I was running Delphi 6 side-by-side with the video, and was changing this property with the same results. So why is this being advertised as a VCL enhancement when, if I recall correctly, it's been there since Delphi 1.

The other thing is how many of these new controls are similar to the Raize Controls, especially the TButton with images from an imagelist (TRzBitBtn), the TButtonEdit with 2 buttons in the edit control (TRzButtonEdit) and the group bar (TRzGroupBar).

That said, it's nice to have these as standard components, and if I do move to Delphi 2009 then I'd have to think twice about renewing my Raize Components.