D
dbeavon
Guest
I use REFERENCE-ONLY, BY-REFERENCE, BIND all the time. These allow logic classes to have shared data without keeping their own internal instances of the data in memory (or overflowing them to temporary disk). The only weird thing where classes are concerned is that you may only define/declare static TT/DS at the *class* scope. This means you either need separate instances ({1}, {2}, {3}) of REFERENCE-ONLY datatypes that play select roles within your class or, alternatively, you need to fork a new instances of the same logic class to use the same data in a slightly different way There was a bug in 11.6 where, if you used the same datasets and temp-tables in two procedures, you needed to make sure they were defined in the same sequence in both procedures (ie. the includes for these weren't ever rearranged). But that was fixed in 11.6.3.x at some point. That's the only true bug that comes to mind. Beyond that it is a matter of trying to interpret the awful Progress messages you get at runtime if you try to re-assign a REFERENCE-ONLY static TT/DS that has previously been assigned to a (different) underlying instance of the TT/DS. The whole ROWID thing from Progress is something to generally avoid, or use on an extremely short-term basis. Even when working with database tables, they say to not persist any ROWID references for future use. I suspect you need to be even more cautious with ROWID's for TT/DS data - since the data is potentially just as transient as the ROWID's. What I typically do is use my own surrogate-integer keys as much as possible, preferably something right out of the database, or if nothing is available there, then I introduce something new into my TT's themselves. The custom surrogate keys can be passed along with a TT to identify one row among many. It is troubling that an ABL programmer with many years of experience can still have trouble with the way the Progress ABL manipulates temporary data tables. I think a huge problem with Progress ABL is the language syntax surrounding static TT/DS data. It is *truly* strange how these things are passed as parameters, and the references are transferred from one program to another. And there is no notion of separation between "classes" of data and *instances* of them. IE. creating a new instance of the *same* static TT/DS is not actually possible. You basically redefine the whole thing with a different name (possibly with the help of an include file). And then by passing a TT named one thing into a parameter accepting a diferent TT name, you rely on the runtime to do tons of on-the-fly schema comparisons between them. It is clear that Progress developed this technology incrementally without a coherent master plan. FYI, One alternative to static data constructs is DYNAMIC data (handles), but the language syntax for that is worse yet. I wonder if its too late to go back to the drawing board?
Continue reading...
Continue reading...