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

  • Thread starter Thread starter dbeavon
  • Start date Start date
Status
Not open for further replies.
D

dbeavon

Guest
I abandoned my strategy of using the Progress.Data.BindingSource as a way to move data back and forth quickly between ABL Temp Tables and ADO.Net DataSets. It isn't designed to address that type of problem. I know that it can quickly supply some tabular data to .Net controls (ie. grids). In other words, sending data from ABL to .Net controls is very efficient. But when we are modifying data in .Net and sending it back to ABL Temp Tables, that side of things is quite slow. This is based on the internal implementation of the underlying Progress.Data.BindingSource. It isn't designed to be automated or to change numerous TT records at a time. The best approaches I've found for moving data back and forth are to use XML and JSON (and the corresponding methods for these on ProDataSet ). I had also evaluated the ABL "IMPORT" format but that has a lot of limitations. It is probably a good choice when you are EXPORTING/IMPORTING data from ABL to ABL and the schema format isn't changed between the EXPORT operation and the IMPORT operation. However if you are not using the ABL language for both of the operations, or if the schema isn't identical, then the ABL "IMPORT" format won't work well... because the format is very proprietary, and it doesn't play well with non-ABL technologies. The ABL "IMPORT" format is especially inflexible if the schema is quite different between the side that is serializing data and the side that is deserializing it. Eg. if the fields are in the wrong sequence, or if the set of fields mismatch each other on one side or the other then the ABL "IMPORT" format will fall apart. Both JSON and XML work well, but there is a bit of a penalty for picking XML over JSON. In general XML is about 3x slower for the types of scenarios that I was working with and, in PASOE, there is a concurrency bug that can further increase the penalty of using XML. It appears that only one ABL session (within the agent process) can be doing parsing operations on XML data at any given moment of time. Apparently that is a result of the way PASOE interacts with a third-party xml library (the xerxes parser). In summary, I've abandoned the idea of using Progress.Data.BindingSource for non-GUI purposes. I'll be using XML or JSON for serializing and deserializing data between the ABL and .Net runtimes (where .Net is running within the CLR Bridge).

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