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
| Title | Tags | ||
|---|---|---|---|
| 158 | Increased production | Programming, ERP | |
| 336 | One flew over the cuckoo's nest | Films, Literature, Tom Wolfe, Ken Kesey | |
| 676 | Carole Bayer Sager - one | Carole Bayer Sager | |
| 677 | This day in music | Carole Bayer Sager | |
| 812 | Changes in fortune, continued | ERP, DBA | |
| 1112 | Left joins in Priority | Priority tips | |
| 1472 | Finishing "You hold me" | Home recording | |
| 1722 | Mike Procter, RIP | Obituary, Milton family |
No comments:
Post a Comment