[Estimated Reading Time: 2 minutes]

As of the XE7 release of Delphi/RAD Studio, the long deprecated BDE is finally dead. And almost properly this time.

From the “What’s New in XE7” page:

BDE, our oldest database solution, has reached the final stage of deprecation, and has been removed from RAD Studio. This includes the Bde.DBBdeWeb and Bde.DBTables units. Instead, use newer database technologies such as FireDAC. For migration, see Migrating BDE Applications to FireDAC.

I have to say that in my experience one of the hardest aspects of living with anything more than a trivial, data-centric Delphi application on an on-going basis is dealing with data module/DFM driven implementations making use of data-aware controls and the attendant stacks of datasets, sources and providers which are the corner-stone of the BDE, DBExpress and now FireDAC.

It’s nothing but a recipe for a constant nightmare world of hunting around in data-modules looking for reference to references to references to find the component whose properties need to be inspected or changed, toggling properties to enable/disable design-time behaviours in order to be able to make necessary changes (and remembering to restore them before re-building your app for deployment) and frustration of an inadvertent or ill-considered property toggle wiping out carefully tuned design time components that need to be painstakingly recreated (or carefully restored from source control without undoing other changes you have made which you do wish to keep).

Which is just one reason that I myself chose never to use the BDE or DBExpress or any other “data aware control” based approach, and have always developed directly against ADO instead (albeit through my own “wrapper” to make the COM API more palateable in the VCL).

Quite apart from anything else, this has meant that as Borland/Inprise/CodeGear/Embarcadero database access technologies have come and gone over the years, the impact on my code has been… nil. Whilst the projects I have been involved with employing the BDE or DB Express and, now I suspect also, FireDAC, have faced a constant stream of issues relating to changes in the frameworks in different versions of Delphi, attendant driver issues, etc etc etc.

Your mileage may vary.

Grumbles From The Grave

But from a supplementary note in the “What’s New” information, it seems that the BDE refuses still to go quietly into the good night after all, and lingers on in the twilight.

If you need to continue using BDE, an external installer is available on the Registered Users site. The BDE help remains in the XE7 help.

So in the unlikely event that you are still using the BDE in a current version of Delphi (or were thinking of migrating to XE7 and putting off BDE migration (again?) until some time in the further future) and/or for some reason you still feel an urge to have the BDE available, even today, you can.

Maybe with XE8 they will finally, finally put the BDE to BED ?

12 thoughts on “The BDE is Finally, Properly (Almost) Dead”

  1. Out of curiosity, if you do not use data-aware controls which approach do you use to make the data visible/available to the user? For CRUD and other operations, I mean.

    1. Good old fashioned coding. My ODBC wrapper had a feature I called ‘Control Aware Data’, which allowed you to reference controls directly in SQL to read/write values from them, which was based on the way Gupta SQL Windows worked, but I never brought that across to my ADO wrapper and can’t say I really missed it.

      Your UI shouldn’t be touching the DB directly and having technologies that actively encourage it just leads to poor app design.

      Being able to create apps quickly is great, and makes for good demos, but often incurs ongoing costs in downstream maintenance complexity in real world apps.

      1. I agree you should not allow your UI to touch you DB. Actually, I only “allow” myself to have such code in a legacy app I sometimes have to work with inside my company.

        In the newer application we use data-aware controls connected to standalone ClientDatasets. Any DB CRUD operation is done through transactions to a remote server (not DataSnap), having so business logic and UI logic separated. Not exactly MVC or the like, but it’s all I could get allowed to do as this was sort of a cultural shock here. 😛

      2. ” reference controls directly in SQL to read/write values from them”

        Hmm – so your DB touches the UI directly!

        Not sure whether that’s any better myself …. and the advantages of having data aware components out of the box is quite high.

        1. Um, no. Or rather, yes, it did back then (some 15 years ago!!). You appear to have missed the part where I mentioned that I never implemented that part of my ODBC wrapper in my later (ADO) iterations. 😉

          That ODBC wrapper was itself an evolution of my very first (hobby) project in Delphi, which was a wrapper around the Gupta SQL/API. Having come from a SQLWindows background at that time (1992-95) it was an interesting challenge to try to replicate the capabilities of that environment in Delphi and I was very happy with what I managed to achieve.

          However, even then I was becoming aware of the benefits of decoupling the UI and the DB, and although maintaining explicit DB access in code was far less troublesome than maintaining a tangled web of obscure property references, I dropped the practice. As I say, about 15 years ago.

          But in terms of the benefits of “control aware data” vs “data aware components”, there is one big problem with data aware components.

          Yes, you get a bunch of them in the box, and yes there were additional ones available from 3rd party developers. But if you wanted some existing control to be data aware then you had to create a parallel implementation. TEdit is to TDBEdit as TChart is to TDBChart etc etc. And if the control wanted/needed in DB aware form didn’t exist, then creating a DB aware version was decidedly non-trivial.

          With my “control aware data”, if you had some control that you wished to bind directly to your SQL, all you had to do was implement a binder class which implemented (very simple) getter and setter methods, and register that binder class with the wrapper API. And thanks to the magic of OO, if your binder worked with a class that was the basis for other classes, then it would work for those too.

          So if you have a TFilenameEdit which was a specialisation of TEdit, the TEdit binder worked just as well with instances of that as it did for TEdit. Where-as of course, data aware controls would have required a TDBFilenameEdit companion for the TFilenameEdit control.

          Additionally, bindings could support parameters so that you could use a SQL statement to directly either populate a listbox or select an item in one. The default binding on a TListbox added a result value to the referenced list. A parameter could be specified to direct a result to be stored in the Items.Objects[] (which required that the source value was an integer as it was stored as a naive Integer() cast):

          select id, name into :lbCustomers[Object], :lbCustomers from customer

          Then to select some specific item in the list directly from an SQL result, a different parameter could be specified:

          select id into :lbCustomers[selectObject] from customer where name like :edNameSearch

          Parameters could also reference controls and take parameters as well. Which parameters were supported and how they were interpreted was a detail of the specific binder class so you could do an awful lot with them if you wanted.

          I had a demo that built a complete (albeit simple) bar chart, complete with title, axis labels, legend and data series using a bog standard TChart and a single SQL statement.

  2. Well ADO is deprecated as well…. you need to start working on your ODBC wrapper….

    1. Ironically, I already have an ODBC wrapper… It predates my ADO one and had some capabilities that never made it into the ADO version. But if I find myself using Delphi in anything other than legacy mode, I might just dust it off. But I won’t be holding my breath. 🙂

    2. Incidentally, I keep hearing this but can’t find anything from Microsoft that suggests that to be the case. Do you have an official source? I’d be interested.

  3. Hi Jolyon
    of course there has been bad news in the past from Microsoft regarding ADO:

    the following quote is from: http://mcpmag.com/articles/2011/09/01/microsoft-shifting-to-open-database-connectivity-for-sql-server.aspx

    “”OLE DB will be supported for 7 years from launch, the life of SQL Server Code Name ‘Denali’ support, to allow you a large window of opportunity for change before deprecation,” Microsoft announced in a blog post. “We encourage you to adopt ODBC in any future version or new application development.””

    so sadly you may still have to change your data access code in the near future

    best regards

    Richard

    1. SQL server OLE DB Client <> ADO as a whole, and that article specifically points out that ADO is not affected. But it’s not very important… all my Delphi work these days is ‘legacy’. ADO or not.

      See also my reply to KM.

  4. I just wish it were so easy to get rid of the BDE. We are about to remove it from yet another program and there are still several to go. No, it’s not fun to maintain these programs and it’s no fun to convert them either.

  5. One can compile the source code of the BDE units of XE6 using the object files from XE without problems.
    I was not able to find the download which is mentioned in the official wording.

    But of course we do not want to use the BDE in new projects, but we have to maintain legacy projects. And so its nice to be able to do so in XE7.

Comments are closed.