Info on PDS?

Have you had a look at the ProDataSets document part of the OpenEdge Development Collection in the PDF docs of 10.1A?

I find that's quite usuable information.

Do you have specific questions?

Some examples of actual usage in code would be a good start.

Have you looked at AutoEdge?

If you have not already, you may want to start checking the Data Access Layer of AutoEdge. It uses ProDataSets extensively.

I saw your reply just after I posted mine. AutoEdge it is!

I've seen some PDS stuff in AE, which gives me an idea of what it looks like.

It doesn't quite explain what's going on though.

In one the PDF's I found:

There's reference to a /src/prodoc/prodatasets

I've looked over my system (which should have a full install of everything), and don't see that directory anywhere.

Where would I get this documentation CD? Is this something only found on the EDS?

Tim Kuehn

Tim,

check out this page on PSDN, I think this is what you are looking for: http://www.psdn.com/library/entry.jspa?externalID=483&categoryID=193

Also, if you are looking for an introduction (and advanced techniques) to ProDatasets, and you want something with concrete exmaples and code snippets, check out the ProDataset book in the Expert Series:

http://www.psdn.com/library/entry.jspa?externalID=473&categoryID=239

Tim,

check out this page on PSDN, I think this is what you

are looking for: > http://www.psdn.com/library/entry.jspa?externalID=483&

categoryID=193

Tried that - got this:

I was logged in (or was it looking for an EDS login?), so I don't know what the issue is.

Also, if you are looking for an introduction (and

advanced techniques) to ProDatasets, and you want

something with concrete exmaples and code snippets,

check out the ProDataset book in the Expert Series:

http://www.psdn.com/library/entry.jspa?externalID=473&

categoryID=239

I have downloaded the entire 10.1A PDF set, and have looked at that book. While it does go into extreme detail about each piece of the puzzle, there isn't much to "tie" things together - they all seem to be pretty well in isolation from each other.

The problem for me is that - in order to do anything with PDS's, you need to have all the pieces (DATASET, DATA-SOURCE, etc.) working together. So far, I haven't been able to find any examples that demonstrate something simple and shows how it works, that I can then run, and then, as I "get" things, try different techniques as I figure out the different pieces of the puzzle.

There are some PDS examples in the AE, so I can see some ways that they're used, but that hasn't been enough so far.

The book does reference some code that, so far, I haven't been able to find. Maybe if I had that, things would be clearer.

Instead of clicking on the link in the table, scroll down a little farther and download the .zip.

Instead of clicking on the link in the table, scroll

down a little farther and download the .zip.

bingo!

Those other links either need to be fixed, or removed.

There are some PDS examples in the AE, so I can see

some ways that they're used, but that hasn't been

enough so far.

Not enough!! Ok, one other place which may be simpler is the standard OERI material as well, which was used as a starting point for some of the AutoEdge work. So try here..

http://www.psdn.com/library/entry.jspa?externalID=93&categoryID=289 (plus all the related docs)

with the code base here ..

http://www.psdn.com/library/entry.jspa?externalID=1442&categoryID=289

HTH

Mike

Not enough!!

Let me put it this way - I've worked in a lot of different languages over the past 30 years, and have been devoted to the Progress 4GL / ABL since 8.1. In all those years doing development I've been able to figure and use most of the language elements of anything I've run into and even do some pretty neat stuff with it. I've even written code to do things similar to what the PDS is for.

In all the time I've worked with the 4G/ABL, I haven't needed anything beyond the books and PEG to figure out what different elements of the language did, and then tie them together to get the job done.

Until now.

While I "get" what the PDS is supposed to do, to me this has got to be the most cryptic, hard to understand, conceptually impenetrable set of language elements I've run into so far. And that's including the socket elements that just about required the user to know how TCP/IP and interrupt vectors work in order to write a safe implementation.

Now, after repeatedly trying to get my head around the docs, or find examples I can play with over the past year, I've finally located some example code that just might make it possible for me to figure out what these things are all about.

Sure AE shows it being used, so I can get some ideas about what it looks like in a real application, but I have yet to get a single PDS to do the equivalent of "hello world", much less all the other things the docs hint at.

So if I seem a bit frustrated, it's because I am. This should not be this hard.

Tim, is it possible that you are making these harder than they really are? All a PDS is is a sort of poor man's object with a bunch of standard methods that you can override to get special behaviors. There is some neat stuff built in to the basic functionality, like the before and after image, but there is nothing particularly exotic about the functionality. Just think of what you might have written as a sort of generic superclass for containing data and the various stub methods you would have defined so that subclasses could override them with custom behavior.

To be sure, it does seem like it can be a bit tricky to get them to behave properly in all circumstances ... at least according to some PEG reports, but that may or may not apply to the latest versions.

Perhaps if you posted a specific mystery or two?

Tim, is it possible that you are making these harder

than they really are?

I'm not trying to. I usually start with something simple, then tweak it to see what'll happen. Eventually I've gotten my head around the whole implementation.

So far, the examples I've seen have been significantly more complicated than that.

All a PDS is is a sort of poor

man's object with a bunch of standard methods that

you can override to get special behaviors.

I get that.

There is

some neat stuff built in to the basic functionality,

like the before and after image, but there is nothing

particularly exotic about the functionality. Just

think of what you might have written as a sort of

generic superclass for containing data and the

various stub methods you would have defined so that

subclasses could override them with custom behavior.

Actually, I have written code that does stuff like that, so it's not that I'm unfamiliar with that concept.

To be sure, it does seem like it can be a bit tricky

to get them to behave properly in all circumstances

... at least according to some PEG reports, but that

may or may not apply to the latest versions.

Perhaps if you posted a specific mystery or two?

To me, the "hello world" version would be to load some data in to a TT (or set of TTs), fiddle with it, and then write it back out somewhere.

Now, after repeatedly trying to get my head around

the docs, or find examples I can play with over the

past year, I've finally located some example code

that just might make it possible for me to figure out

what these things are all about.

.....

So if I seem a bit frustrated, it's because I am.

This should not be this hard.

Well, firstly I'm pleased you've found some example code that helps. Secondly, we're currently in the phase of planning work to hopefully address some of the issues you've raised, and to post material that is simpler in it's nature. Don't all jump on me and ask when, as it's still in the planning, but just to say we are working on trying to make this stuff easier and more accessible.

To me, the "hello world" version would be to load some data in to a TT (or set of TTs), fiddle with it, and then write it back out somewhere.

So, if you set one up and override nothing, doesn't the FILL give you some data to play with? Where are you getting stuck?

So, if you set one up and override nothing, doesn't the FILL give you some data to play with? Where are you getting stuck?

I was getting stuck on how one sets a PDS up in the first place. What I was looking for was something simple and straightforward like the following code block:

/* Procedure Temp-Tables */

DEFINE TEMP-TABLE tt-src NO-UNDO

FIELD i1 AS INTEGER

INDEX i-i1 i1

.

DEFINE TEMP-TABLE tt-tgt NO-UNDO LIKE tt-src.

/* Procedure Variables */

DEFINE VARIABLE cur-cnt AS INTEGER NO-UNDO.

/* Procedure Data-sources */

/* Procedure Datasets */

DEFINE DATA-SOURCE ds-1 FOR tt-src.

DEFINE DATASET ds-1 FOR tt-tgt.

/* Put something in the src TT */

DO cur-cnt = 1 TO 100:

CREATE tt-src.

ASSIGN tt-src.i1 = cur-cnt.

END.

/* Attach DS to PDS */

BUFFER tt-tgt:ATTACH-DATA-SOURCE(DATA-SOURCE ds-1:HANDLE).

/* "Fill" tt-tgt */

DATASET ds-1:FILL().

/* Detach DS */

BUFFER tt-tgt:DETACH-DATA-SOURCE().

/* What do we have? */

FOR EACH tt-tgt

NO-LOCK,

EACH tt-src

WHERE tt-src.i1 = tt-tgt.i1

NO-LOCK:

DISPLAY

tt-src.i1

tt-tgt.i1

WITH DOWN.

END.

As you go through the PDF docs as they stand right now, they describe the DATA-SOURCE, DATASET, etc. language elements in excruciating detail. This is probably fine as reference docs for someone who knows what these statements are, how they work together, and need to figure out something specific. However, this level of detail completely obscures what should be a simple process of how one establishes the various elements of a PDS and link them together in the first place.

Similarly, the prodoc zip file I download has what looks like application-structured code with PPs, dynamic-functions, dynamic PDS, ADM windows, and stuff like that. While they're probably good examples of what "real-world" use would look like, they're overly complicated for people who are just starting out and trying to figure out the basics of how to put some simple records into a PDS.

It wouldn't surprise me if the sample code for marshaling data out of a PDS is equally complex.

I'd compare it to getting comprehensive instruction in how to use a brand-new car, but not being told where the keys to it are.

At least I'm making some progress now....

Well, firstly I'm pleased you've found some example

code that helps.

They helped a bit, but it was too hard to find in the first place, and appear geared more towards application-level integration and demonstrating all the bells and whistles, but not how one sets up a minimal-case example in the first place.

Secondly, we're currently in the

phase of planning work to hopefully address some of

the issues you've raised, and to post material that

is simpler in it's nature.

And how long have PDS's been out?

Don't all jump on me and

ask when, as it's still in the planning, but just to

say we are working on trying to make this stuff

easier and more accessible.

What planning is required to create examples like the I came up with and posted here?

I've been thinking about your complaint a bit and it occurs to me that the problem in documenting PDS is that they are very rich and that richness is not simply ordered. By this I mean that once one goes beyond the very simple core which you have illustrated, one may need any one of or a combination of methods in order to accomplish a particular goal and there is no intrinsic pattern of which methods are the most common or likely or should be used first. On top of which, it is probably also the case that the methods are structural, not task oriented, so it isn't necessarily easy to figure out which point of action is the right one for any given purpose.

Which said, it seems to me that the ideal solution to the first problem is to create a set of hyperlinked documentation so that one can start with a very high level, simple view and then drill down into the various components to get the detail about that component. Sounds like a great Hive project, if someone felt like writing a bunch of documentation ... especially if PSC would give its blessing to some cut and paste from the manuals to speed it along.

For the second problem, I would think that the ideal solution would be a PDS tips and techniques documentation which provided a series of documented examples of accomplishing various purposes. Again, I think this should be hyperlinked so that one can start with a list of problems and drill down into the specifics of individual problems with cross links to similar or related solutions. Again, sounds like a good Hive project.

I would surmise the docs need to be divided into a few sections:

• A minimal-case example to show the structure of how the different elements of a PDS is put together, ala the code sample I posted.

• Different ways to marshal data into the PDS.

• Different ways to marshal data out of the PDS.

• The different ways of marshalling data in and out of a PDS, how they can interact, with more examples.

• Extensive details on how the data-source and dataset object methods & attributes, ala what's there already.

Right now the docs are very language statement-centric, which is good if you know the inter-statement structures already. But if you don't know the structure, trying to figure it out can be an exercise in frustration and prevent the technology from being widely adopted.

As for making docs to explain things a Hive project, if PSC is willing to sponsor some people in the community to do it before it makes it to the official doc release, I think it'd be a great idea (they can use this as a way to test docs before releasing a polished "official" release).

Unfortunately, this isn't a trivial effort, and really should've been done by PSC in the first place. Also, the last time something 'complex' came out (socket objects) it took a long time - and a significant amount of lobbying - to get some reasonable docs / examples in the KB, and that came from TS, not the documentation group.

Consequently, I hope for changes, but I'm not holding my breath.

Taking the example code I'd posted earlier in this thread and making it a Hive project is more workable. I'll have to take the code and post it over there.

Another section should probably deal with use of the before table to manage changes.

As for making docs to explain things a Hive project, if PSC is willing to sponsor some people in the community to do it before it makes it to the official doc release, I think it'd be a great idea

I wouldn't hold your breath. But, if a few people who were using ProDataSets were to contribute a bit, I think it might come together anyway. What I think would be really nice is for some of the PSC people to chip in as well.

Taking the example code I'd posted earlier in this thread and making it a Hive project is more workable. I'll have to take the code and post it over there.

I was going to say that I would create a place for it, but I see you beat me to creating the content. Aren't things dynamic? Rather than put this under OERA, however, I have created a new category under OE Development for ProDataSets and supplemented your content with an initial cover page where people can begin to contribute structured content.

Thanks for getting the ball rolling.

Another section should probably deal with use of the

before table to manage changes.

It wouldn't surprise me - I haven't gotten that far yet.

As for making docs to explain things a Hive

project, if PSC is willing to sponsor some people in

the community to do it before it makes it to the

official doc release, I think it'd be a great

idea

I wouldn't hold your breath.

I'm already blue over a number of other things I'm not holding my breath about.

But, if a few people

who were using ProDataSets were to contribute a bit,

I think it might come together anyway. What I think

would be really nice is for some of the PSC people to

chip in as well.

That'd be cool.

Taking the example code I'd posted earlier in this

thread and making it a Hive project is more workable.

I'll have to take the code and post it over

there.

I was going to say that I would create a place for

it, but I see you beat me to creating the content.

Aren't things dynamic?

Rather than put this under

OERA, however, I have created a new category under

OE Development for ProDataSets and supplemented your

content with an initial cover page where people can

begin to contribute structured content.

Why shouldn't it be part of OERA? PDSs have been marketed as a pillar in implementing the OERA, so wouldn't it make sense to have it where people are likely to look?

Thanks for getting the ball rolling.

Welcome!

Why shouldn't it be part of OERA? PDSs have been marketed as a pillar in implementing the OERA, so wouldn't it make sense to have it where people are likely to look?

Because I don't think PDS really has anything specific to do with OERA. One can use them in an OERA-compliant context, but one can also use them in any other architectural context. Similar to my having created a section for OOABL under development .... I think it is important for OERA, but so far we haven't seen any examples.

I'm continuing to work on figuring out these PDS's, and ran into something else.

I thought I could

• write a query,

• associate it with a data-source,

• associate that data-source with a dataset,

• use that query to fill all the TT's in the PDS.

However, it doesn't appear to work that way. It looks like there's a mandatory 1-to-1 correspondence between data-source objects and TT buffers in the dataset, so "aggregating" buffers in a query and then using that to update multiple TTs in a PDS doesn't work.

Is this correct? So far, I've gotten the PDS to load some data out of a query at one buffer level, but it's not in the form I'd written in the query.

Almost right. There's a 1-to-1 mapping between data-sources and temp-table that are to be filled . By defining a relationship between two temp-tables, you (possibly inherently) define what the related fields are. In the child query will automatically add the joining where clause when it gets opened.

DEFINE TEMP-TABLE ttCustomer LIKE Customer.

DEFINE TEMP-TABLE ttOrder LIKE Order.

DEFINE DATASET dsCustOrd FOR ttCustomer, ttOrder

DATA-RELATION relCustOrd FOR ttCustomer, ttOrder

RELATION-FIELDS (ttCustomer.custnum, ttOrder.custnum).

DEFINE QUERY qCustomer FOR customer.

DEFINE QUERY qOrder FOR order.

DEFINE DATA-SOURCE srcCustomer FOR QUERY qCustomer.

DEFINE DATA-SOURCE srcOrder FOR QUERY qOrder.

BUFFER ttCustomer:ATTACH-DATA-SOURCE(DATA-SOURCE srcCustomer:HANDLE).

BUFFER ttOrder:ATTACH-DATA-SOURCE(DATA-SOURCE srcOrder:HANDLE).

QUERY qCustomer:QUERY-PREPARE("FOR EACH Customer NO-LOCK WHERE custnum

QUERY qOrder:QUERY-PREPARE("FOR EACH Order NO-LOCK WHERE ordernum

DATASET dsCustOrd:FILL().

That's what I was afraid of - I'd hoped to do something like:

DEFINE QUERY qcust-ord FOR customer, order.

and then use that as the data-source to load the PDS customer & order TTs from.

Ah well.

That's what I was afraid of - I'd hoped to do something like:

DEFINE QUERY qcust-ord FOR customer, order.

and then use that as the data-source to load the PDS customer & order TTs from.

Ah well.

One problem with filling tables like this is that you don't get the "inner-join" characteristics of a query.

If you add the following code to your example:

for each ttcustomer:

find ttorder

of ttcustomer

no-error.

display

ttcustomer.custnum

ttorder.custnum when available ttorder

with down.

end.

while there's won't be any orders for non-matched customers, there will be a number of customers listed with no orders.

While I don't have an example handy, I am sure you can achieve this kind of result by overriding the appropriate methods.

E.g., I have experimented with using AFTER-ROW-FILL to build a class from the data elements retrieved and then completely discarding the actual data elements in favor of the class and the temp-table of the dataset is a temp-table of Progress.Lang.Object.

It

wouldn't surprise me if you could figure some kind of work-around

to get this behavior. However, having to take that route not only

strays from familiar query behavior ABL developers have used for

years - but having to resort to AFTER-ROW-FILL et al methods gets

away from the general intuitiveness that was once one of ABL's

defining characteristics.

I understand you sentiment, but it seems to me that the design choice here was between simplicity and capability. If they had kept a simpler design, it may have been difficult to make it as capable and ultimately the goal has to make PDS as capable as possible. I think this is probably why you are having some trouble ramping up ... there are so many options that it is hard to know what to do.

But, the potential is very powerful. E.g., when I was looking at PDS a while back in connection with a model for a data access layer I was bothered by the fact that I thought that I wanted a temp-table of Progress.Lang.Object instead of a bunch of columns. Ultimately, one would like to be able to do this semi-automatically, perhaps even as simply as providing a field mapping between the columns in the query and the properties of the object. But, even though this is not available, all one really needs to do is to add an AFTER-ROW-FILL callback that looks something like this:

With method overloading on the constructor, one could eliminate the separate call to setAll and just supply the values as a part of the new. Notice though how the table values are available and then end up not going into the temp-table at all.

I would post the whole thing, but I haven't touched it in months so I'm not sure what works and what doesn't right now. I will be working on this soon in somewhat different form and will post that when I have a working example, but it will have to be after 10.1B FCS since some of what I am doing now depends on 10.1B features.

Can one do TRACKING-CHANGES with just a temp-table, not embedded in a PDS?

Looking at this again, it occurs to me that the result of a query with an inner join is essentially a virtual table with columns from both tables. But, here you are wanting to divide the result back out into multiple tables. I haven't tried it, but I wouldn't be surprised that, if you defined a temp-table with columns from both tables, i.e., a temp-table corresponding to the virtual table resulting from the query, then you might be able to get the job done. Alternatively, it doesn't seem that inappropriate to have to override AFTER-ROW-FILL to create a row in each of the two separate temp-tables, as you would have to do if you were trying to build two tables outside the context of a PDS.

I understand you sentiment, but it seems to me that

the design choice here was between simplicity and

capability. If they had kept a simpler design, it

may have been difficult to make it as capable and

ultimately the goal has to make PDS as capable as

possible.

This doesn't reflect the rest of the language. The UI started out simple, and over time evolved to the point where you could completely render a full UI system in a dynamic fashion. Records updated in a transaction can be updated and rolled back with ease.

The whole premise of the 4GL/ABL was to make the developer's job easier.

I think this is probably why you are

having some trouble ramping up ... there are so many

options that it is hard to know what to do.

My difficulty has more to do with the docs not being clear, not about the number of options. I've written a "Data IO" manager which does a number of things that the PDS does, and was headed down the same direction, so I understand what they're trying to do. It's the actual implementation & behavior details that aren't clear.

No. TRACKING-CHANGES can be used only with ProDataSet' Temp-Tables.

...but of course there's nothing to stop you having single temp-tables in a dataset