In reading the docs it appears Progress recommends using the ProDataset to feed the ProBindingSource. Is this still the case if trying to write a simple file maintenance procedure against one table?
I am trying to figure out if I should use ProDataSets for all file maintenance procedures or use TempTables for simple maintenance and ProDataSets for any multitable views.
The docs seem to indicate there may be more overhead when using ProDatasets. Since I have yet to implements ProDatasets I do not have much experience with them as our application is completely ADM2.
Any suggestions would be appreciated.
I am facing the same question at an ADM II customer site here but for me the answer is definitely to use ProDataSets in all cases. I doubt if you will ever be able to measure the overhead, but the advantages are numorous.
Have you ever regretted that you can only define one main table and one query with SDOs? Even though in the beginning when creating the original SDO you were convinced that your were only ever going to do simple table maintenance. Have you ever needed to create more than one SDO for the same table? All of these limitations are gone.
If you use two different mechanisms for table maintenance, you not only paint yourself in a corner with single table maintenance code but you will also need to maintain two different development methodologies. That does not sound attractive to me at all.
Of course ProDataSets (and indeed business entity classes) have many many more advantages and you can start reaping those benefits once you have made up your mind about the above.
Yes to both of your questions on SDO's. I agree with your assessment on the two different methodologies is not a good sdolution.
Thanks for the input and great job on the presentation last week!!
I agree 100%.
I also suspect the ProDataSet fill mechanism is faster than what you could achieve with code that uses buffer-copy to copy a single temp-table. I have not tested this though, mostly because I would never consider using temp-tables without ProDataSets for application data. The fill is most definitely faster than the SDO, but more than 25% of the SDO overhead is, however, attributed to the update of "meta" columns like RowMod and RowNum used to keep track of changes and data. This highlights another benefit of the ProDataSet; the built in ability to keep track of changes, reject and merge changes and extract a new dataset to pass to the server with only changes. All of which is very useful functionality also with a single temp-table.
If you use two different mechanisms for table
maintenance, you not only paint yourself in a corner
with single table maintenance code but you will also
need to maintain two different development
methodologies. That does not sound attractive to me
at all.
This is probably the most important reason.