tamhas
ProgressTalk.com Sponsor
There are a couple of reasons for using the .df. One is that I wanted to decouple from the compile phase since some people will manage the compiling through their normal build process and thus want to skip it in the ABL2DB build. The empty schema DBs are presently only used in the compile phase. Another reason is that the tables actually used by an application may include metaschema files or it may not, so it seemed like providing that explicitly in the .df would be an easy way to cover that eventuality.
Which said, if there was demand for it, I could certainly create an alternate version of the Schema load module which worked from the DBs used for the compile. Indeed, the version of the schema load I originally did in ABL2UML worked that way. So, it isn't hard.
The current design would not accommodate the same table name in two different DBs. If that is a requirement, I would have to add a DB table and a leading DB field on the schema tables. And, of course, that would require doing something different with the .df load. All doable and something I will tackle if there is a need (despite the fact that I think it is bad practice ).
The menu stuff is only needed if you want to ask questions from that starting point. I.e., if you want to work on the XYZ posting function and would like a list of all of the code referenced by that function, you would want that functional unit defined and that happens in the menu load.
Is you menu embedded in the individual programs here and there rather than being driven by a DB table or some such? I am aware of that being a possibility, but was hoping not to run into any real cases. It seemed to me that most flavors could just whip up little programs to export the three files, regardless of how the data was stored.
Thanks for your input.
Which said, if there was demand for it, I could certainly create an alternate version of the Schema load module which worked from the DBs used for the compile. Indeed, the version of the schema load I originally did in ABL2UML worked that way. So, it isn't hard.
The current design would not accommodate the same table name in two different DBs. If that is a requirement, I would have to add a DB table and a leading DB field on the schema tables. And, of course, that would require doing something different with the .df load. All doable and something I will tackle if there is a need (despite the fact that I think it is bad practice ).
The menu stuff is only needed if you want to ask questions from that starting point. I.e., if you want to work on the XYZ posting function and would like a list of all of the code referenced by that function, you would want that functional unit defined and that happens in the menu load.
Is you menu embedded in the individual programs here and there rather than being driven by a DB table or some such? I am aware of that being a possibility, but was hoping not to run into any real cases. It seemed to me that most flavors could just whip up little programs to export the three files, regardless of how the data was stored.
Thanks for your input.