ProDataSets using an AppServer and .NET

Haikarainen wrote:

All of this is working, but going on from here is a hassle for me. There is A LOT of documentation on the prodatasets members and methods, but very little practical examples. My biggest question right now is: After changing a row in the, say transfergrid, how to update the prodataset effiecently and then send only the changes from that dataset to the appserver so it can be updated in the raw database? I understand you can send the whole dataset but our system is saving everything into the raw database in realtime(when anything has changed basically), so that would be a LOT of data. This also we dont have any "savebutton" so to speak. It would be a huge setback for us to change the direct saving since our system has been around for a big while and that is what our customers expect from us.
Any help is greatly appreciated, Thanks in advance!

There are 2 largish reference/sample applications that show some of this stuff: take a look at the welcome text at the javascript:; project, which links to the AutoEdge Dealer app (procedural code) and AutoEdge|TheFactory app (OO-based).

 I understand you can send the whole dataset but our system is saving everything into the raw database in realtime(when anything has changed basically), so that would be a LOT of data. This also we dont have any "savebutton" so to speak. It would be a huge setback for us to change the direct saving since our system has been around for a big while and that is what our customers expect from us.

There are methods that allow you to only extract the changes made to a dataset: something like below should work.

/* track any data changes */
do iLoop = 1 to phDataset:num-buffers:
  hBuffer = phDataset:get-buffer-handle(iLoop).
  hBuffer:table-handle:tracking-changes = true.
end.
/* do updates to prodataset's temp-tables */
/* Get the change data */
create dataset hTransportDataset.
hTransportDataset:create-like(MasterDataset).
hTransportDataset:get-changes(MasterDataset).

This stuff is probably better discussed in the javascript:; and/or javascript:; communities.

-- peter

Hi Fredrik,

If you do get a chance to look at the AutoEdge application, could you post again and let us know if you found the type of example you were looking for? We are currently looking at our knowledge base and documentation to address some of the difficulties our customers have. Several people have mentioned a lack of examples. It would be great to get a sense of what type of example and level of complexity would make the topics clearer.

Thanks much,

Roberta

I will be out of the office until Monday 11th June with little email access. If you need to contact someone within the office then please phone reception on 01904 727150, otherwise I will reply to your email as soon as I am able.

Thanks, Andrew.

Email Disclaimer

Roberta,  I just spotted your comment and felt the urge to reply.

I found that looking at the code behind the AutoEdge example has sometimes been helpful; but (in my personal opinion) it's a far too complex example to be used as a starting point for introducing OERA concepts and ProDataSet handling. AutoEdge is, I'm sure, a great demonstration of all the different interfaces and principles behind data marshalling; error handling, etc; but to be frank I took one look at all the setup steps required to actually get it running and decided I didn't have the time or inclination; so I just keep the sources as an additional reference point.  Maybe in time I'll view it differently, but right now it's not what I (nor I suspect many others struggling to gain traction in this environent) need.

As a Progress developer with nearly 20 years experience I've searched (without much success) for some VERY SIMPLE  examples I can understand.

Code I can download, run, play with and break; with the minimum of fuss and setup steps - I'm yearning for the times you could simply download an example, connect to SportsDB and run the thing without caring about web services,etc.  I don't understand web services; I know the concept but not the implementation.  Maybe that makes me dumb, but it's not something I've ever worked with and although I'm sure they'll be very important to me one day soon, I'm simply not there yet.

I know the language, I know the database, I've worked with app servers, I've developed ChUI and GUI (ADM) solutions, I know OO principles, I've worked with classes and datasets - I know all of that and I know most of pretty well- but that's all I know.

Over the past couple of weeks I've developed a couple of .NET-based popup windows that are integrated into our existing application (e.g. UltraChart-based popup for displaying dynamic data in graphs) and I could get there by folowing some examples and reading forums; but the thought of developing anything more complex (database access or a more complex UI) is quite intimidating.

What I personally would like to have access to would be a couple of stand-alone applications that start at the simplest possible level; and then gradually increase in complexity.

For example:

(1) .NET Enquiry screen - enter a search string, get dataset back and display it in a grid.  No fancy UI, No AppServers, No batch handling, No web services, No strucutured error handling - the smallest possible application which demonstrates deploying a solution using the OERA model.  The code could still be structured in a way that would be similar to a live environment (business levels, etc) , but able to run "out of the box" on  a single PC without the additional complexity inherent in setting up AppServers, web services, etc.

(2) The same enquiry screen with (for example) structured error handling added.

(3) The same enquiry screen, now with batching.

(4) The same enquiry screen, with contextual data management added.

(5) A web-enabled version of the enquiry screen showing how the business logic is the same but accessed from a different point.

...and so forth.

Then apply the same principles to a data maintenance screen.  Start with the smallest possible application that demonstrates the principles involved and then further examples which slowly build on it.

Ship them as stand-alone applications, complete with a tiny databse, startup files, etc so we can just download them and run them. 

To me, AutoEdge feels like you've reached Step 986 and here's the whole thing - it's simply too large and complex for someone starting out.

The problem which I have run into again and again as we start to move into the .NET and OERA world is finding examples like this.  From reading  the discussions on these forums it's obvious that there's more than one "right" way to implement these principles; but I can't come to the party and fully appreciate the content of these discussions without a starting point - even if half the Progress world condemns it as being wrong, or a poor example of "OO principle 87" I really think you need to publish examples like this.

I'd love to engage in that discussion and learn more about benefits of different implementation models, web services and the like; but without this sort of "leg up" I find myself standing at the base of a very high mountain, enjoying the view of others discussing the best way to manage the final ascent; but I'm still looking for my climbing boots !

Anyway, my sincere apologies to the original poster for hi-jacking his thread - obviously move these comments if you think they are inappropriate here.

Hopefully some of that wall of text is in some way useful feedback.

Sorry for the relatively mislocated post, still pretty new to these forums and progress

Regarding AutoEdge Factory, I began installing this application but got stuck with some problems (on one machine, the NS1 was not installed, on another, nothing except the NS1 was installed etc), but really dont have the time atm to fix this since the whole office is pretty busy merging to OE11 and .NET4.

Also I did a search on that site and found nothing relevant to ProDataSet examples, isn't there any site in wich you can find minimal practical examples of how to use it? To this time I have only found 1 that shows basically how to declare a dataset, fill it and send it to the client as a whole.

Also I've started fibbling around with Get-Changes, but I cant seem to send those over the AppServer-Client connection, I get errors saying there can only be 1 dataset with the same temp-tables. I haven't done it based on the code you provided since im reading this just now but I will continue working on it when I have time and see if I can get some progress.

Fredrik - I'm not sure if you already know about this, but I found the ProDataSet documentation written by John Sadd to be invaluable.

Well wriiten, clear and concise - highly recommended if you haven't already studied it.

Link: http://communities.progress.com/pcom/docs/DOC-16300

Hi Roberta,

I tried to install the AutoEdge-application but ran into some trouble I dont have time to fix atm (read above), It is really great that you are working on providing better examples etc!

From my point of view, the documentation is superb! It documents basically every single method and property and all objects. But you'd have to read through every single one several times to understand how to use datasets.

Examplecode and minimal practical examples would be great I think, something like examplecode for appservers + datasets, effiecently using and sending datasets/rows.

The AutoEdge Factory seems great with its "cardealer-system" to get a realistic example, but it is really a lot to swim throught just to get a practical example, something like a minimal release with only commented sourcecode for a few classes/procedures would be great!

Actually, my code was very much like yours on the clientside.

      DEFINE VARIABLE hDSChanges AS HANDLE NO-UNDO.
      CREATE DATASET hDSChanges.
      hDSChanges:CREATE-LIKE (DATASET KalkylDS:HANDLE).
      hDSChanges:GET-CHANGES (DATASET KalkylDS:HANDLE).
      
      hDSChanges:WRITE-XML("FILE", "C:\Test.xml").
      
      RUN SaveKalkyl IN AppServerHandle(INPUT DATASET-HANDLE hDSChanges).

On the serverside:

     DEFINE VARIABLE hDSChanges AS HANDLE NO-UNDO.
     CREATE DATASET hDSChanges.
     hDSChanges:CREATE-LIKE (DATASET KalkylDS:HANDLE).

     ... Procedure starts here ...

     DEFINE INPUT PARAMETER DATASET-HANDLE hDSChanges.

     DATASET hDSChanges:MERGE-CHANGES(DATASET KalkylDS:HANDLE).
     DATASET KalkylDS:WRITE-XML("FILE", "C:\TESTFILE.XML").

But it errors with:

PARAMETER DATASET-HANDLE FOR hdl not implemented yet (11404)
THe FOR handle phrase in the dataset parameter is to allow a deep copy 

of the caller's set to be appended to a pre-existing (FOR handle) 

dataset.  This is seldom used and not available in version 10.0A. 

Which is funny since I'm tyring to run it on 10.2B

Hi Gareth,

Thanks very much for your detailed comments. The closest thing we have right now to what you're describing is the sample application that goes with OpenEdge Getting Started: Introducing the Progress Developer Studio for OpenEdge Visual Designer. (Substitute "OpenEdge Architect" for "Progress Developer Studio" if you're looking for this manual in OpenEdge 10.2B or earlier.) All the sample code is included in the documentation disk or download, so you can follow the manual as a tutorial. The sample includes an OERA-style data access layer already written, so you can use it as-is to get up and running with GUI for .NET, and then go back and look at the code later to see how it works.

HTH,

Roberta

Thanks, Fredrik. A complete working example using ProDataSets with an AppServer is a great suggestion!

Just wanted to add to Gareth's suggestion that the sample code in the ProDataSets book is also in the documentation disk / download.

HTH,

Roberta

Just wanted to add to Gareth's suggestion that the sample code in the ProDataSets book is also in the documentation disk / download.

If it's not part of EVERY Progress Developer Studio installation people won't find/use it... When Progress has the interest for mass adoption of these techniques, there needs to be a

File -> New Project -> OpenEdge -> GUI for .NET / N-Tier / ProDataset

option in the tool that creates the sample project with all required settings (including Sports2000 DB) and source code in your workspace.

That's an interesting suggestion, Mike. Thanks for posting it. If you want, you could suggest it to Product Management as an enhancement by sending an email to openedge-enhancements@progress.com and including the information listed at http://www.progress.com/en/ers-down.html.

Roberta

That's an interesting suggestion, Mike. Thanks for posting it. If you want, you could suggest it to Product Management as an enhancement

I've been trying to convince product management about this since years at every possible conference

Will formulate it once more.

If it's not part of EVERY Progress Developer Studio installation people

won't find/use it... When Progress has the interest for mass adoption of

these techniques, there needs to be a

File -> New Project -> OpenEdge -> GUI for .NET / N-Tier / ProDataset

The above is slightly different from this:

option in the tool that creates the sample project with all required

settings (including Sports2000 DB) and source code in your workspace.

One is a relatively empty structure within the context of some supporting code (think AppBuilder's SmartWindow that was an empty object in the context of ADM2); the below is a more complete, working example. These are slightly different things in my mind. Are they in yours (not only Mike's)?

There's a mechanism in Dev Studio in 11 that allows you to import code/projects from a zip into your workspace, via the Welcome page (you can see it again via Help > Welcome); especially the Samples section. Granted this is , um, sparsely populated at the moment, but I'd love to hear about the sorts of things you'd want to see there. Clearly a (relatively) simple ProDataSets example is one thing.

-- peter

File -> New Project -> OpenEdge -> GUI for .NET / N-Tier / ProDataset

>

The above is slightly different from this:

Not really different - I should have made this more clearer, but that should be a New Sample project option. Though that was clear because of the menu path under File -> New Project -> OpenEdge ....

PARAMETER DATASET-HANDLE FOR hdl not implemented yet (11404)



THe FOR handle phrase in the dataset parameter is to allow a deep copy 

of the caller's set to be appended to a pre-existing (FOR handle) 

dataset.  This is seldom used and not available in version 10.0A. 





Which is funny since I'm tyring to run it on 10.2B

That's because you're not supposed to do

DEFINE INPUT PARAMETER DATASET-HANDLE FOR hdlDataset.

In 11.0 I get your message above, and also message 11405, which is far more descriptive, and actually useful.

'DATASET-HANDLE FOR hdl' should be 'DATASET-HANDLE hdl' without the *FOR* (11405)
A common typo in the 'DEFINE PARAMETER DATASET-HANDLE handlename'  is to add an unneeded FOR keyword before the handle name.  This is because the DATASET parameter (as opposed to the DATASET-HANDLE parameter) requires the FOR keyword in order to reference the static dataset that the parameter refers to: 'DEFINE PARAMETER DATASET FOR mystaticdataset.'    In the case of the handle parameter, there is no static dataset to be refered to, but only the parameter name.

hth,

-- peter

I found some great examples and managed to implement prodatasets!

I want to recommend the samples zip attached to this documentation: http://communities.progress.com/pcom/docs/DOC-103549

Seems to work well with 10.2b as well, Look under the prodataset folder.

Most minimal yet complete example I've found!

Sounds very promising, and not something I've stumbled into before when searching the morass of online documentation !

I'll definitely be reviewing those when I have a moment. Thank you for posting the info Frederik.