[progress Communities] [progress Openedge Abl] Support Non-openedge Databases

[MattStickney]

Let me start by saying that this is a thoroughly out-there idea, but I think it has merit. The idea to allow ABL programs to run against non-OpenEdge databases -- natively, not through the DataServer hacks. The Technical Case At first glance, except for a few minor issues like ROWID availability for uncommitted records, there isn't anything in ABL-the-language that requires OpenEdge as a backing database. The DataServer products have demonstrated this pretty well, although doing it as a database hack instead of a language implementation modification causes some maintenance issues (e.g. trying to keep the schema holder up to date). All of the various metadata used for field display and string validation and the like could all be stored in normal metadata tables, instead requiring explicit database support. Table CRC calculation can be provided by stored procedures. A rather large downside of ABL is that you have to use OpenEdge to use it, and OpenEdge is difficult to use with other tools or technologies. There's ODBC, but it's a non-standard dialect and support is iffy. There are DataServers, but they can be finicky to set up correctly[1], they require strange layouts in the target database, and they have the maintenance issues mentioned earlier. There are plenty of product suggestions in the OpenEdge category answered with "you have to remember that OpenEdge isn't really a relational database" -- the logical response to that is "right, but I don't have a choice". [1] I got our product running against PostgreSQL using the ODBC DataServer once, but it required altering and recompiling the PostgreSQL ODBC driver because of a DataServer bug, and many hours of crawling through the Data Admin tool source code to figure out how to create the target schema properly. Schema updates never quite worked properly either. The Business Case Most of Progress' value-add for customers is in their language and their RAD tools, and not their database. OpenEdge is the default choice for Progress programs, but it doesn't stack up very favorably: there isn't much in OpenEdge that isn't as good or better in competitor databases, and OpenEdge has some severe interoperability limitations, in addition to a relatively high maintenance burden for users. Databases are hard to get right, and OpenEdge almost certainly has high development and maintenance costs. Nothing says that OpenEdge couldn't remain one of the supported targets for ABL programs, but otherwise the high-value-add products are dragging around the marginally-competitive dead weight of a database, instead of being able to put those resources into improvements to the core products, which is where all of Progress's competitive advantage actually is.

Continue reading...