ProDataSet, SDO and DataView to read & update Progress D

The DataView SmartObject is available since 10.1A.

Anyway, it would not help you much in your ASP.NET environment. It's written in ABL (4GL) and supposed to be an interface (adapter) to ProDatasets for other objects written in ABL (SmartObjects).

You should have a look at the OpenClient for .NET Guide (part of the Progress Documentation) for connecting your Progress AppServer app to ASP.NET. ProDatasets do work very well in the environment. You just can't use a single line of ABL code on your IIS. The OpenClient stuff will connect you using appserver calls.

Mike

Hi Mike,

Thanks for your reply.

If use only the ProDataSet, I am not sure whether I need to recode the business logic in C#.Net or can I just use the existing logic that coded in SDO.

I am reading the OpenClient for .Net Guide (first few chapters) , and I am still not sure whether ProDataSet can work with our existing SDO or not ? Or do we need to write new ABL procedure to be called from IIS ?

I am still blur about ProDataSet , please forgive for my stupid question. Thanks.

The short answer is: ProDatasets and SDOs don't work together.

The ProDatasets has many concepts similar to the SDO implemented in the ABL core (i.e. tracking changes). But it's not a trivial task to reuse SDO business logic (most time coded against the RowObject temp-table) within a ProDataset.

I'm pretty sure, that would mean to rewrite...

The alternative would be to talk to the SDO directly using the adm2 API procedures and the OpenClient proxy. But you should know a lot about internals of the SDO (i.e. filtering, initialization, etc.) - especially when doing updates. In your ASP.NET code you'd be dealing with an ADO.NET DataTable and not with a Dataset as SDOs have a single table interface.

Mike

Thanks again .

I read in the White Paper named "Introduction to DataView 1: Basic Concepts" that, ProDataSet is passing data row through temp-table while SDO's is using RowObj, RowObjUpd . This is the reason why DataView is introduced (which use temp-table) , to work with ProDataSet at client side.

To my understanding , DataView is unlike SDO (which is single table interface), has a lot similarity to ProDataSet, it seems like Progress create it to work with ProDataSet.

However, as far as I have read , I have not noticed the white paper mentioning about .Net client . This lead me to ask in the forum because I am not sure I am in the correct direction or not.

After all, I hope to get some advice on the following

If in our case, can we do like this way,

1. Code the UI in ASP.Net

2. Rewrite the business data logic using DataView

3. Use ProDataSet to "bind" to DataView to read/write to Progress DB.

Thanks .

CG

1. yes

2. No. The DataView object is a client side component written in ABL. In your situation you HAVE to rewrite something similar in C# or VB.NET. So forget about the DataView unless you are using a ADM2 client.

3. Yes and no. You will use the Prodataset as the glue between ASP.NET and the Progress DB. Again, no DataView.

To expand your understanding of ProDataSets, check out this great new offering at OE Hive http://www.oehive.org/node/947

> I read in the White Paper named "Introduction to

DataView 1: Basic Concepts" that, ProDataSet is

passing data row through temp-table while SDO's is

using RowObj, RowObjUpd . This is the reason why

DataView is introduced (which use temp-table) , to

work with ProDataSet at client side.

This is correct, but the overall goal is really to enable the ADM2 as the presentation layer in a Service Oriented Architecture.

> 2. Rewrite the business data logic using DataView

You are very likely to need to rewrite and/or migrate your business logic from the SDOs to your Service Provider. The OERA suggests that this is implemented in Business Entities.

The DataView is in principle just a simple data/query object that sits on top of the ProDataSet and should not have any business logic whatsoever.

Moving the business logic to a Service Provider should allow the logic to be reused both by your ADM2 client and your ASP.net UI.

Thanks for all the replies.

-- Deleted

Message was edited by:

Cyber Koa

Please ignore my previous message, I found I got a totally wrong concept of ProDataSet.

After reading more chapters in ".Net Open Client Development Manual", now I found that we can use Open Client API to talk directly to Appserver to launch a ABL program to do data modification/reading.

However, I am still confuse what is the role of ProDataSet in an .Net Open Client.

Another doubt , is the proxy generated actually a Data Provider in .Net ?

Re PDS and .NE Open Client:

This may help, if you have not looked at it yet: '.NET Open Client Properties for Mapping ProDataSets and Temp-tables in 10.1A'

http://www.psdn.com/library/entry.jspa?externalID=489&categoryID=233

Re Data Provider in .Net:

Use the Microsoft ODBC .NET Data Provider

However, I am still confuse what is the role of

ProDataSet in an .Net Open Client.

The ProDataset only exists on the ABL AppServer. When a procedure launched on the AppServer returns a ProDataset the OpenClient for .NET Proxy converts it to an ADO.NET DataSet.

Another doubt , is the proxy generated actually a

Data Provider in .Net ?

No. It's not an DataProvider (as an ODBC Database connection). But you can implement the required interfaces on your own and use the OpenClient for .NET for the back-end communication with the AppServer.

The OpenClient for .NET let's you execute any logic on the AppServer. It's more flexible than a data provider would be. But the Dataset returned for the ProDataset can be used in combination with a BindingSource to populate any UI Control with Data.