D
dbeavon
Guest
Wow, I was able to get ClientTestMethod1 to work by changing BomLogic TestMethod1 as follows below (note the BIND qualifier that is now in the input parameter): /* ********************************************************************* */ /* Init the reference only data from input */ /* ********************************************************************* */ METHOD PUBLIC VOID TestMethod1(INPUT DATASET DS_AsmBom BIND): FOR EACH TT_BomHeader NO-LOCK: DISPLAY TT_BomHeader.BomCode. END. END METHOD. I also had to change the caller so that it specified "BIND" instead of using the "BY-REFERENCE" qualifier on the INPUT dataset. The original example should have behaved the exact same way as this. Not sure why the change made a difference in how "sticky" of a dataset I would send to BomLogic. As a matter of course I always try to avoid "BIND" since the scenarios where it is required are fairly unusual. I was hoping this would not be one of them, but it appears to be. The BY-REFERENCE and BIND keywords both pass along a dataset reference to the class via TestMethod1. Given the similarities between the two, are there any diagnostic features in OE to generate output that distinguishes the fact that one sends a "sticky" reference and one sends a reference that is not sticky and will be pulled away again when the method ends? This behavior is pretty obscure and would be nice if I could turn on some logging that explained how my data is being treated at the boundaries of my method calls. It would also be nice if there was a way within TestMethod1 to tell the AVM that I want the dataset to be "sticky" after-the-fact (even though it didn't get passed in with BIND). It would be nice to understand this stuff a little better. I often spend a lot of time scratching my head when working with reference-only data in OE.
Continue reading...
Continue reading...