D
dbeavon
Guest
Yes, I would do the looping in .Net and compile that into a custom assembly that would be referenced by ABL (PASOE). The surface area that is exposed to ABL would involve only a single round-trip into the CLR bridge; and that round-trip would do all the work for an entire dataset (sending .Net data back into ABL temp-tables via the BindingSource). >It sounds like you just want this written in the AVM [sic] rather than in the ABL, which I think would make it somewhat faster. If could be faster, then that is encouraging. Using the standard interfaces (the ones on ProBindingSource) seems like a safe bet, and hopefully this has a potential to be faster then EXPORT/IMPORT. I was originally pretty eager to take a stab at an EXPORT/IMPORT approach ... but I realized that I would need to invest a lot of time building my own home-grown c#.net code around the proprietary "EXPORT" file format that is used by OpenEdge. That is not so appealing. Whereas the public interface to ProBindingSource is more standardized (and is not entirely text-based like XML/JSON, and doesn't require data to be sent to intermediate files on disk, and hopefully has better performance than EXPORT/IMPORT). Doing all this from within PASOE may be a trick. One concern I have is based on the fact that a PASOE msagent can be such a long-lived and high-volume process. Typically most winforms components are made for a GUI process. The GUI is a single-user process, and the user may work all day long but not nearly as hard as an msagent. And eventually the GUI process is stopped and restarted, flushing away any potentially rooted memory-references. And in any case even if there are rooted-memory-references they are isolated to a single-user process and they cannot affect other people. But a PASOE msagent, on the other hand, is very susceptible to memory-related problems, even minor ones. That ProBindingSource had better not leak a single byte of memory or there will be support cases! 
Continue reading...
Continue reading...