D
dbeavon
Guest
As Thomas mentioned, much of the reason for the dynamically-compiled ABL source is to generate temp table results from conditions that are formulated at runtime. Other times it is because there is a datagrid in the U/I that needs to be bound directly to a very large OE datatable and this U/I needs to be conditionally sorted based on one OE index or another. Finally I would add that many of the programs that generate reporting output are not precompiled as a matter of course because of similar reasons to the ones already mentioned. Can anyone point me to a warning or announcement about the deprecation of the runtime compilation features of ABL? While I am personally aware of how to use dynamic queries, my reasoning for doing so is typically related to performance optimization (ie. to eliminate the extra fractions of a second that are required to compile ABL at runtime). I would imagine that many ABL programmers are still taking advantage of runtime compilation features, and are unaware that these features are disallowed if/when their stuff is ever deployed to certain production licenses, such as production PAS. I'm still a bit surprised by the whole concept of R-code-only ABL. It seems a bit abrupt for Progress to change the rules of the game without any forewarning. It was not until I started reading about the production license of PAS that I first learned that large portions of our legacy ABL ERP would not be supported to run as-is.
Continue reading...
Continue reading...