I've been working with this version of Delphi (D12CE) on the
new computer1 for the past few weeks. The increased speed and large screen
make this pleasant. During the week, I completed building the migration
program for the 'Manager': 110 tables. Some of these have only a few rows
and some have thousands. Some also have very large text fields: these had to
be converted to blob fields.
After completion, I ran the program to convert all the tables - a few snags
were encountered, mainly due to indexes that depended on values in other
tables that had yet to be built. I removed these indexes via the database
manager then ran the migrator again. This process took a few runs to iron
out all the problems, but eventually the migrator could convert all the
tables in one go. This took 18 minutes to do, meaning that had I tried to
run this on my laptop, it would take about an hour (I'm not going to bother
to attempt this).
Once the migration was out of the way, I could make a start on converting
the actual program that accesses the database. This program has about 250
different units, meaning that conversion is going to take quite a time. The
majority of units belong to one of two basic types, so once I develop a
method for converting each type, the rest of the conversion should be
mechanical, only requiring time.
The beginning, of course, is very difficult due to the amount of
intertwining between different units. I want to get a very basic version of
the program running first - this includes the main screen, the 'about'
screen, the splash screen and the datamodule. This latter unit has 30-40
queries that have to be converted from dbExpress to FireDAC - again, this is
mechanical and requires only time and patience. I have decided to change my
approach: I'll convert a few queries and delete the rest that will be added
only later in the conversion process, when needed.
Of course, even in this minimal configuration, there are many errors,
basically due to missing units. Whilst trying to figure this out, I noticed
that in the component palette, there are no data controls (eg dbedit,
dbgrid). Are they missing due to configuration errors, I wondered? As
always, CoPilot has the answer:
🧨 The Delphi 12 Community Edition is missing the Data Controls palette
This is not your fault.
This is not a bug.
This is not something you broke.
This is Delphi 12 Community Edition’s licensing restriction.
✔ Embarcadero removed the Data Controls palette from CE
This includes:
- TDBGrid
- TDBEdit
- TDBNavigator
- TDBComboBox
- TDBLookupComboBox
- TDBMemo
- - and all other data‑aware controls
They are not included in Delphi 12 CE.
This is intentional. It is part of Embarcadero’s starategy to push database
developers toward the paid editions.
✔ That’s why you see no “Data Controls” tab
It’s not hidden.
It’s not disabled.
It’s not a configuration issue.
It’s simply not included.
🧩 Why you saw them in older versions
Delphi XE, XE2, XE7, 10.2, 10.3 CE — all included data controls.
Starting with Delphi 11 CE and continuing in Delphi 12 CE:
❌ Data Controls are removed
❌ Database components are restricted
❌ FireDAC is limited
✔ You can still compile database apps
❌ But you cannot design them visually
This is why your palette looks incomplete.
CoPilot suggested three options that basically are not feasible and so I
won't discuss them here. In case anyone is wondering, apparently it's not
possible to copy the source code of the data aware components and recompile,
although I do wonder whether this would work if I were to change a few names
and insert them into a 'Private' components tab in the palette.
Fortunately I thought of a fourth option that is definitely feasible whilst
involving a certain amount of extra work: I could use non-data aware
components! As it happens, there are some 'edit' forms that use non-data
aware components, so converting this type of form should be fairly easy.
Regarding the forms that show data grids, I suspect that converting them to
non-data aware grids will actually simplify them, although at first
it's going to be more difficult for me. I suspect that the complications that I
described2 a month ago (when not using D12CE) are going to
disappear in the new configuration.
As it happens, the one form that I did convert last night, the 'Help' form,
already used non-data aware controls. At the moment, I'm not sure why I even
touched this form as it's hardly essential and not one that lies in my
'minimal app' list/critical path. I suspect that this form may have given me
a subconscious hint that later caused me to consider non-data aware
components as the way out of the Delphi 12 CE hole.
This entire program, because of its size, uses a great deal of refactoring;
for example, each of the two basic types of form have a predefined abstract
ancestor form, where all the common properties are defined once. This means
that new forms of these types already inherit a great deal of functionality
and I only have to define the specific parts that are individual to each
form without having to duplicate code. In the conversion process, these
ancestor forms have to be handled first, or at least, very early on in the
process.
Regarding D12CE itself, I have a licence for a year. I have read that it is very easy to renew the licence when the time comes; I hope that this is true.
Internal links
[1] 2065
[2] 2066
This day in blog history: