I am currently modifying ABL2DB to use Proparse to assist in relating a buffer name to a DB table name as follows:
In BuildTableLinks.cls, as each compile unit comes up for analysis, I use Proparse to find all the define buffer statements and create a lookup table which has the buffer name, table name, and whether or not the table is a DB or temp-table. Then, as I encounter buffer references in the XREF, I will be looking them up and building the link for any DB tables.
Now, there are a couple of other things I could be doing, but am not presently intending to do, so I'd like to through them out and see if people think they have any value.
One, I could be building database table(s) of temp-table definitions - potentially table, field, and index just like there is for DB tables.
Two, I could be building links between compile units and these temp-table definitions, just like I do for DB tables.
Three, I could be creating a database table of buffer names for DB tables with links to the table.
Four, that table could also link buffer names to temp-tables.
Note that one might think of making the buffer name a property of the link between compile unit and db table except that more than one buffer name might be used in a compile unit, so it would have to be part of the index.
I am not immediately moved to do this since it seems to me that buffer naming can be pretty arbitrary and temp-tables, unlike DB tables, are local implementation artifacts, not something potentially shared across the application.
So, let me know what you think.
Maybe you could expand on what you think the benefits/drawbacks of the alternatives might be?
Keeping closer track on temp tables and their definitions would be useful for assessing if coding standards are adhered to.
I wonder if it might also enable tracking of temp tables that have redundant fields, and are therefore wasting memory. Obviously not a massive impact, but in some scenarios it could be crucial?
Note that I am proposing elsewhere to track shared temp-tables and buffers, but this would not include any passed as parameters. Maybe later I can check parameters and having them already captured would give me something to point to. But, the real question here is whether people can imagine going to the database to find such things or are they always just going to go to the code.
Note that one use is to decide that one is going to work on a particular function and then to dump everything known about that function as a kind of high level roadmap of what's there.
[quote user="Thomas Mercer-Hursh"] But, the real question here is whether people can imagine going to the database to find such things or are they always just going to go to the code.[/quote]
Something like this would be vital for doing an impact analysis on TT changes, and it couldn't be readily done just by looking at the code.
Given all of the crap I am now tracking for shared objects, perhaps a few more unshared ones might be worth it! :)