[Progress Communities] [Progress OpenEdge ABL] Forum Post: Using Progress.Data.BindingSource for non-GUI Purposes (on Windows)

Status
Not open for further replies.
D

dbeavon

Guest
I'm trying to do some research to find out the best way to move data from Ado.Net into ABL datasets via the CLR bridge. Ideally it could be done in a clean way, within process memory, without sending data thru intermediate files on disc. Also it should be done as quickly as possible. I haven't settled on anything yet, primarily because there doesn't appear to be any straight-forward solution. By using the CLR bridge to loop thru a .Net data reader, and copy records one at a time, I can move all my data. This is probably the "cleanest" option but involves quite a lot of CPU - because of all the related CLR interop. Similarly I can move data by exporting it all to XML and parsing that back into an ABL dataset with READ-XML. This is fairly clean and fairly CPU-intensive. The XML approach is only slightly less "clean" than the approach using the data reader. Both are fairly slow. At the moment I'm investigating the "bindingsource" that Progress created for the "GUI for .Net". This could be another avenue for getting my Ado.Net data out of .Net and send it back to an ABL dataset. I found the assembly ( "Progress.NetUI.dll") and some docs ( OpenEdge 11.7 Documentation ). But I have some concerns: Is it a "misuse" of this binding source to build ABL data programmatically from .Net code? I saw a KB where there is some discussion about various things that are considered a misuse of the binding source. I would consider it a fairly natural thing to create data programmatically via the bindingsource. It is certainly less complex than a scenario where there are separate user interface controls that allow users to create data interactively. (Although the interactive scenario is the intended purpose of the bindingsource). Is there a better way? It is easy to see that Progress' BindingSource internally uses Progress.Data.DataSource, which implements IBindingList. Does it make more sense to interact directly with the DataSource class instead of the BindingSource? This would bypass the BindingSource overhead. And it seems like would make sense to *avoid* classes that are found in the "System.Windows.Forms" namespace. Especially if the code is running within PASOE, and not exposing a GUI. Is it supported? If I run into trouble using the Progress.Data.DataSource (via IBindingList interface), will Progress support me right away, or will the force me to recreate my problem in a repro that is based on ProBindingSource and some Telerik datagrid. Is it possible to run this type of code in PASOE? Or will I run into a limitation where PASOE won't allow me to load this assembly at all (Progress.NetUI.dll). Is it going to be fast? I need it to be at least as fast to fill 100,000 rows as it would be to generate a flat file and re-import it using IMPORT statements. Are the classes within the Progress.NetUI.dll assembly commonly used? Out of all OpenEdge customers, a subset of them run on the Windows platform (like us), and among these customers, there is an even smaller subset who are using "GUI for .Net" (not us). I don't want to get too far out into the weeds. As long as there are lots of customers using GUI for .Net then I'm not too worried about using these data binding classes. Any tips would be greatly appreciated. We are moving out of the HP-UX platform and I'm not totally familiar yet with all the features that are available to OE customers on Windows via the CLR Bridge. I have seen few discussions about ProBindingSource, especially outside the context of the "GUI for .Net".

Continue reading...
 
Status
Not open for further replies.
Top