Ok, this is a well known issue. The R in "progress RDBMS". Does it deserve the R in it's name? Many will say no (I've heard them, the buzz seems to stem from at least almost ten years ago).
Different ERD tools support the generation of df's and vice versa. Marian Edu has just written an eclipse-plugin, there is PCase and maybe an old erwin version. And I am using an opensource plugin, ERMaster (not adapted for use with progress, but it is good enough for what I need and I can create incremental df's from the output).
But wouldn't it be great if psc took up the task of creating an ERD plugin? And add some tables to the metaschema like for tablerelations (with properties like parent and child cardinality, cascadedelete)? Maybe it could even be be possible to create a kind of T4BL to maintain models graphically and maintain the database via them also (next to the normal ERD plugin). In the DevExpress framework you can find such an utility.
There was a new CEO that wants to revitalize openedge, wasn't there, wouldn't this be a step in the good direction too, besides the developments in the arcade area etc.? You can hardly sell openedge to new customers without at least upgrading outdated parts I think (not so? then give me a list of new developing customers from the last year in Holland at least), and I know some existing customers stopping new development in progress (in Holland). They are not naive and see what the neighbours do.
+1
As well as updating the user interface of the db maintenance tools.
I'm all for improving the schema tools and even adding to the schema, but I'm not sure what that has to do with the DB being relational.
Enterprise Architect can also be used for modeling the schema.
Ok, this is a well known issue. The R in "progress RDBMS".
But wouldn't it be great if psc took up the task of creating an ERD plugin? And add some tables to the metaschema like for tablerelations (with properties like parent and child cardinality, cascadedelete)?
+1
Maybe it could even be be possible to create a kind of T4BL to maintain models graphically and maintain the database via them also (next to the normal ERD plugin).
Not another dead born child! T4BL was nice for Progress' demo videos. But not a single step beyond that. The code generator needs to be customizable by ABL developers. T4BL wasn't event customizable by Java developers at all.
(not so? then give me a list of new developing customers from the last year in Holland at least)
This thread started serious. But I don't think you'll ever get a customer list from Progress for good reasons....
+1 ( Progress should provide an ERD plug-in )
We use Sybase's PowerDesigner which I have been able to customize so that I get a perfect data definition file out of it. But the Sysbase PowerDesigner is a commercial product which is not exactly cheap ...
Regards, Richard.
> Not another dead born child!
No, please not. I would like to get a healthy child.
T4BL was nice for Progress' demo videos. But not a single step beyond that. The code generator needs to be customizable by ABL developers. T4BL wasn't event customizable by Java developers at all.
> Yes, but I'm hoping for a usable T4BL. Thanks for the requirements.
>>(not so? then give me a list of new developing customers from the last year in Holland at least)
> This thread started serious. But I don't think you'll ever get a customer list from Progress for good reasons....
I think I know the answer to my question. It is not a positive one for psc shareholders.
I think I know the answer to my question. It is not a positive one for psc shareholders.
You think it would be in the interest of PSC's shareholders if Progress would get into conflict with data privacy regulations? Not the kind of marketing they are looking for.
OK I'll bite.
OpenEdge is probably relational in the old E.F. Codd sense of "relation," which is just a logical grouping of tuples (rows); in other words "relation" is just a table. If you asked a modern programmer what "relational" means in RDBMS they would probably be thinking of inter-table relationships, of which OpenEdge does nothing for (no tracking of foreign keys). If you need to perform a join you'll be doing it purely in the application layer using longform field mapping (it should be noted that FOR EACH table1 OF table2 is just ABL syntactic sugar that relies on the tables having a specific field naming structure; it doesn't take advantage of special knowledge the DB has of the schema). Perhaps this deficiency is related to the fact that a table need not have primary keys / tuple uniqueness?
I'll go back to my "toy" SQL database now...
