Well that was judicious timing (for once)! Just as we decided to take the plunge and do away with ODBCExpress in favour of dbGo, I had an email from Pieter Myburgh at Korbitec. In it, he stated that the management had rejected the proposal to make ODBCExpress open-source and instead have "end-of-lifed" the project.
Now, Pieter has been nothing but helpful and this decision was out of his hands. But what a strange decision. After his personal email to me, another one followed to other developers which was a bit more definitive:
As you know a few of us here at Korbitec have been pushing to get ODBCExpress open-sourced, since there is no ongoing development, and recent changes in Delphi 2009 of the char & string types to Unicode have made ODBCExpress unusable in its current form in this version of Delphi. The bad news is that open-sourcing ODBCExpress has been rejected by management for various reasons. However the good news is that the latest source code is available for download by all of the existing registered users of ODBCExpress. Furthermore you are allowed to modify the source code in any way for your own purposes, or collaborate with other registered ODBCExpress users to port it to newer versions of Delphi if needed. So unfortunately this is the end of the road of Korbitec’s involvement with maintaining ODBCExpress.
Pretty much the same message is available on the ODBCExpress website.
It's an odd decision not to open-source it, as TurboPower did so successfully with its VCL component sets all those years ago. They can't make any more money out of it, they're encouraging developers to collaborate and help each other, they're giving away the source code to registered developers who don't already have the source - yet they won't make the source code available to everyone so that the project might live on.
Bit of a two-fingers up to Delphi really. Pretty sad ending to a good set of components.
You don't have to look very far for people asking the question "Is Delphi Dead?". StackOverflow had a recent question on it, and Delphi developer JamieI recently created a website to answer the question succinctly.
OK, so it was a darling of the 90s and these days it isn't as high profile as it used to be - .NET hurt Delphi badly because it took Delphi's edge away. However, isn't it part of the job of software professionals to keep up to date with what programming languages and tools and available?
I use Delphi exclusively, yet I still know all about the recent versions of Ruby on Rails, C#, PHP, Java, VB.Net, ASP.Net (etc etc) because I make it my job to know about them. I don't read in technical detail about the merits of each and what the new versions provide, but I'm aware of the other tools available in my industry because they are important to the future of software development.
So if I wasn't a Delphi developer, I'd still know that Delphi 2010 was recently launched, that Delphi had a new owner and that the future wasn't over.
Tim Anderson recently posted a blog about the future of Microsoft Access, and he was asked in a comment what development platform he uses, to which he answered "Visual Studio or Delphi". The reply astounded me:
I used Delphi many years ago, I did not realise it was still going.
Now, this was from someone who called themselves "Freelance Access Developer" which may explain a lot about his or her scope of knowledge of the software industry, but surely if you used to use Delphi, you'd notice in passing a headline about the new version coming out or a recent buyout of the company.
Or maybe I just read too much.
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.
