ABL2DB

[tamhas]

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.

 

[Cringer]

Our menus are all stored in the programs themselves. You should see our main stub program!

 

[tamhas]

My sympathy, Cringer! While it may take a bit of work, I can see substantial value in simply making the menu tree explicit and easily seen. Perhaps it might even motivate someone to make them data driven!

 

[Cringer]

It's just a little thing, Thomas, and likely not something people should run into, but my source path is invalid, and I get a big fat error in the logs:
"Invalid or inappropriate handle value given to DELETE OBJECT or DELETE PROCEDURE statement. (5425)"
It's coming from the destructor in BuldDirectoryTree.cls that isn't testing whether or not the objects it's deleting are valid.
That may of course be by design...

 

[Cringer]

A more serious issue. I've got this in my df

ADD FIELD "BloObject" OF "BinaryObject" AS blob
  FORMAT "x(8)"
  INITIAL ?
  POSITION 5
  LOB-AREA "miscellaneoustables64"
  LOB-BYTES 104857600
  LOB-SIZE 100M
  ORDER 40

I get:

[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL -- ** Invalid character in numeric input M. (76)
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL -- ** ABL Debug-Alert Stack Trace **
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL -- --> ProcessColumnAdd com.cintegrity.ABL2DB.BuildSchemaDF at line 252  (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\com\cintegrity\ABL2DB\BuildSchemaDF.r)
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL --     ProcessAdd com.cintegrity.ABL2DB.BuildSchemaDF at line 87  (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\com\cintegrity\ABL2DB\BuildSchemaDF.r)
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL --     Process com.cintegrity.ABL2DB.BuildSchemaDF at line 69  (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\com\cintegrity\ABL2DB\BuildSchemaDF.r)
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL --     ProcessSchema com.cintegrity.ABL2DB.Driver at line 101  (C:\Users\jpalmer\Copy\Workspace\ABL2DB\src\com\cintegrity\ABL2DB\Driver.r)
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL --     Process com.cintegrity.ABL2DB.Driver at line 55  (C:\Users\jpalmer\Copy\Workspace\ABL2DB\src\com\cintegrity\ABL2DB\Driver.r)
[14/07/07@10:01:32.228+0100] P-004236 T-008776 1 4GL --     C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\abl2db_launcher.p at line 84  (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\abl2db_launcher.r)

 

[tamhas]

I'll check these out and let you know when fixes are posted.

On the first one, can you explain a bit? Yes, testing that it is valid is a good precaution, but both objects are created in the same class, so how are they invalid at the destructor?

 

[Cringer]

chSourceDirectory was still set to the directory you had defined in the download as I'd missed updating it. So it was pointing at a directory that doesn't exist in the file system I am on.

 

[tamhas]

So, shouldn't that have been caught in the Initialize and thrown an error there? Not in the destructor?

 

[Cringer]

Just reporting back on the line number in the error. I'll try and recreate

 

[Cringer]

Here's the full log file for that one Thomas:

[14/07/07@16:29:37.574+0100] P-005720 T-009904 1 4GL -- Logging level set to = 2
[14/07/07@16:29:37.574+0100] P-005720 T-009904 1 4GL -- No entry types are activated
[14/07/07@16:29:37.574+0100] P-005720 T-009904 1 4GL -- Logging level set to = 3
[14/07/07@16:29:37.574+0100] P-005720 T-009904 1 4GL APPL Start ABL2DB Test
[14/07/07@16:29:47.640+0100] P-005720 T-009904 1 4GL APPL BuildDirTree ERROR: Source Path '\work\IS\DB\src' not found or not readable
[14/07/07@16:29:47.640+0100] P-005720 T-009904 1 4GL APPL End CompileDirectory Tree with 0 exceptions
[14/07/07@16:29:47.668+0100] P-005720 T-009904 1 4GL -- Invalid or inappropriate handle value given to DELETE OBJECT or DELETE PROCEDURE statement. (5425)
[14/07/07@16:29:47.668+0100] P-005720 T-009904 1 4GL -- ** ABL Debug-Alert Stack Trace **
[14/07/07@16:29:47.668+0100] P-005720 T-009904 1 4GL -- --> BuildDirectoryTree com.cintegrity.ABL2DB.BuildDirectoryTree at line 68 (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\com\cintegrity\ABL2DB\BuildDirectoryTree.r)
[14/07/07@16:29:47.668+0100] P-005720 T-009904 1 4GL -- CompileDirectoryTree com.cintegrity.ABL2DB.CompileDirectoryTree at line 38 (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\com\cintegrity\ABL2DB\CompileDirectoryTree.r)
[14/07/07@16:29:47.668+0100] P-005720 T-009904 1 4GL -- Process com.cintegrity.ABL2DB.Driver at line 54 (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\com\cintegrity\ABL2DB\Driver.r)
[14/07/07@16:29:47.668+0100] P-005720 T-009904 1 4GL -- C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\abl2db_launcher.p at line 84 (C:\Users\jpalmer\Copy\Workspace\ABL2DB\run\abl2db_launcher.r)
[14/07/07@16:29:57.333+0100] P-005720 T-009904 1 4GL APPL BuildDirTree: Unable to initialize.
[14/07/07@16:29:57.333+0100] P-005720 T-009904 1 4GL APPL End ABL2DB

 

[tamhas]

So, you haven't set

• chSourceDirectory is a fully qualified path to the directory containing the source.

The path shown is the default one in the distribution. Maybe I should change the distribution to say "\You\Forgot\To\Set\Me"?

 

[Cringer]

Yeah it was my fail, just didn't expect to get those errors. Got the error to screen too.

 

[Rob Fitzpatrick]

Maybe I should change the distribution to say "\You\Forgot\To\Set\Me"?

No, but it's more customary on Windows to construct either a local path (e.g. D:\path) or a UNC path (e.g. \\server\share). A path that begins with a backslash just looks odd.

 

[tamhas]

Well, maybe I'm a *nix bigot, but I think "C:\" looks weird and, of course, no guarantee that people using this code are going to use it on Windows.

I will say that / vs \ caused me more than one headache during development. Nice of ABL to iron out the difference in the code, but it doesn't standardize them in the XREF!

 

[tamhas]

A new version of ABL2DB has been published to http://www.oehive.org/ABL2DB . In addition to some minor fixes in earlier versions (see change log) the new release includes new functionality as follows:

0.59 - Add M support for LOB-SIZE and LOB-BYTES
- Support TABLE-TRIGGER
- Support N separate DBs with their own schema
- Support DB in table links
- Support DB Connect params (including live DBs)
- Fix potential bug in destructor
0.60 - Support sequences in .df

Enjoy and keep those ideas coming!

 

[tamhas]

A new release of ABL2DB has been uploaded to OE Hive ( http://cintegrity.com/content/Databasing-ABL-Code-and-Data-Relationships ). This is a fairly significant transition because it will now support as many source and run directories as you feel like typing. In particular, this means that if you have a base release version and N directories containing customer-specific code, you can make a list of N+1 with all these directories and have all of the code in ABL2DB for analysis at the same time. There are currently no specific utilities for restricting analysis to a specific image, i.e., what is at one customer's site, but since the source directory information is there, this could easily be added to any given analysis.

Specific features added include:
0.70 - Modify path utilities to better handle Windows drives.
- Shift to support multiple sort and run directories
- Change DiskFile.chSourceDirectory to DiskFile.chBaseDirectory.
- Add fields to CompileUnit for RCode, Xref, List, and Debug base directory.
- Add SchemaUtilites class to centralize MetaDB Name logic.
- Add FindTableForBuffer method in SchemaUtilities.cls to match buffer
names to tables with potential site customization.

Enjoy and keep the feedback coming!

 

[tamhas]

Link to the code http://www.oehive.org/ABL2DB

 

[tamhas]

I have published a new version of ABL2DB with the following enhancements
0.71 - Add handling for encrypted source
0.72 - Add handling for reverse slash in .df triggers
0.73 - Add support for SA fields in table and column schema
0.74 - Add support for CLOB-* properties in .df
As always, find the downloads and instructions here http://www.oehive.org/ABL2DB
The documentation changes too!

 

[Stefan]

Well, maybe I'm a *nix bigot, but I think "C:\" looks weird and, of course, no guarantee that people using this code are going to use it on Windows.

I just had a quick peek at PathUtilities.cls since I was curious - if you really are such a *nix bigot - shouldn't your backslash string literals be "~\" to allow this to even compile on *nix?

I dislike the input parameter character checks on <> "" - this allows an unknown value to destroy the rest.

    if ipchPackage <> ""
    then mchFullPath = ipchSourceDirectory + chSeparator + ipchPackage + chSeparator + ipchName. /* ? destroys this one */
    else mchFullPath = ipchSourceDirectory + chSeparator + ipchName.

I prefer > "" which I find reads more fluently and as a bonus also skips the unknown value as a string with a value.

    if ipchPackage > ""
    then mchFullPath = ipchSourceDirectory + chSeparator + ipchPackage + chSeparator + ipchName. 
    else mchFullPath = ipchSourceDirectory + chSeparator + ipchName.  /* ? handling - so nothing destroyed */

Be careful with MATCHES, the following will match more than files with extension cls since the . is the wild card for one character:

if mchRunFile matches "*.cls" then mchRunFile = substring(mchRunFile, 1, length(mchRunFile) - 3 ) + "r".

The . needs to be escaped with two tildes:

if mchRunFile matches "*~~.cls" then mchRunFile = substring(mchRunFile, 1, length(mchRunFile) - 3 ) + "r".

Thanks for opening your source to the public!

 

[tamhas]

Thanks for your input. Keep it coming.