Does modifying the query of a SDO before initializing it aff

The full source code for each version is available and could be helpful:

http://communities.progress.com/pcom/search.jspa?q=%22Development+Tools+Source+Code%22&resultTypes=BLOG_POST&resultTypes=DOCUMENT&resultTypes=MESSAGE&resultTypes=BLOG&resultTypes=COMMUNITY&resultTypes=PROJECT&resultTypes=SOCIAL_GROUP&resultTypes=COMMENT&peopleEnabled=true&dateRange=all&communityID=&username=&numResults=15&rankBy=10001

Depending on the OE version you are using, you can activate logging for the duration of the call and see what is going on:

LOG-MANAGER:LOGFILE-NAME = "myLog.log".
LOG-MANAGER:CLEAR-LOG().
LOG-MANAGER:LOG-ENTRY-TYPES = "4GLTrace".
LOG-MANAGER:LOGGING-LEVEL = 4.

LOG-MANAGER:CLOSE-LOG().

If ever "Rebuild dataset on reposition" is false and the query is opened and then repositioned far in the result list, you may end up with a lot of records, but I suspect that this wouldn't occur just in your single call to 'serverSendRows'.  I'd try to check the number of records just before and just after the call just to be certain that most of the 1199 records aren't there *before* you call 'serverSendRows'.

You may have run into a bug, but it is also possible that this is  explainable/expected behavior, depending on parameters or how the SDO is  being deployed or called. I believe one of the requirements is that the SDO is running on an AppServer and being called from another client.

I would generally recommend not using serverSendRow and the equivalent temp-table based save/submit API.  Maybe they still are useful if you have  a Java client that use proxies to communicate with an AppServer?  (Even  then I suspect there are better alternatives. (remote* methods)). If you have a Progress client then you are most likely better off using the SDO also on the client. The client side SDO have extensive logic to manage all possible variations of requests, batching and transactions (undo, cancel, error and more). In  addtion to the fact that you will have to implement your own client  logic, these APIs are outdated and do not benefit from AppServer (stateless mode) improvements to retrieve data for multiple SDOs in one request and general context management improvements including the ability to pass context back and forth with the data request.

I have defined RowObject and RowObjUpd temp tables in my program(as explained in John Sadd's paper on 'Working with the Version 9 ADM: Using SmartDataObjects from Outside the ADM').
I would like to thank John for his efforts. His paper has helped a lot to understand the concept of RowObject and RowObjUpd temp tables.

Note that the internal concepts are still the same, so you have not wasted your time.

Hi David,

Thanks for the reply.

RebuildOnRepos is set to TRUE.

Even if it is FALSE, i think the temp table would retrieve 1199 records only if a reference is made to records between 1191 to 1199(since RowsToBatch is 10)

Also, since i am just creating the temp table just before the call to serverSendRows the temp table can not have any data in it.

Kindly correct me if i am wrong.

I tried logging the activity and had an extensive list of execution flow through the ADM procedures. I think this log will help me understanding the way how ADM procedures/super procedures/events work.

Thanks for the advice.

Hello Havard,

Thanks for the reply.

I completely understand that the methodology that i use is obsolete, however i started this as an experiment.

I am not using the Appserver since there had been some problem in starting the Admin Service for OpenEdge. But, i run the sdo as persistent.

This was the call to serverSendRows that i used:

RUN serverSendRows IN h_customersdo

     (0 /* no start row */,

     "" /* no start RowId */,

     NO /* no need to do NEXT after getting the first row */,

     10 /* desired number of rows to be returned */,

     OUTPUT iRowsReturned /* number of rows actually returned */,

     OUPTUT TABLE RowObject /* RowObject temp table that i defined*/ ).

In this case i got 1199 records in my RowObject temp table(i cant even understand how only 1199 records were retrieved).

Then i made the following changes in the input parameters:

RUN serverSendRows IN h_customersdo

     (0 /* no start row */,

     "FIRST" /* RowId of the First record */,

     NO /* no need to do NEXT after getting the first row */,

     10 /* desired number of rows to be returned */,

     OUTPUT iRowsReturned /* number of rows actually returned */,

     OUPTUT TABLE RowObject /* RowObject temp table that i defined*/ ).

This command worked fine and retrieved only the first 10 records from the db table.

Previously, i wasn't mentioning the RowNum of Rowid to start with. But by indicating the RowId parameter, everything worked fine. Can you please explain what might have happened?

TIA

The SDO opens the query when you initialize it, so your call to serverSendRows likely just appended another batch to it and returned everything.

When you set the second parameter to "FIRST" the SDO empties the temp-table, since this is a signal to start with a new batch of data.

You can set OpenOnInit false to avoid the query open when you initializeObject. (I'm not sure how sendServerRows handles this). You should also be aware of and check/test the AsDivision property. An SDO running on an AppServer will have this set to "server". I suspect you will get more server like behavior from the SDO if you set it to 'server'.  

Hey Havard,

You were absolutely right about it. Since the OpenOnInit was true. The SDO retrieved the initial data records from the db into the RowObject temp table. The serverSendRows called for the next 10 records(since I asked 10 records in the input parameter) and those were appended to my temp table.

When i set OpenOnInit to false before initializeObject, the only time when the temp tables are populated is when the call serverSendRows is made. And it retrieves the exact number of records,i.e 10, as specified.

Thanks you Havard.

Lastly, could you please explain what 'server like behaviour' were you referring to if AsDivision is set to 'server'.

Lastly, could you please explain what 'server like behaviour' were you referring to if AsDivision is set to 'server'.

I mentioned this because (I believe) the APIs you currently are experimenting with are intended to be called when the SDO is running on the AppServer. It is thus possible that they don't work as intended/expected when you start the SDO in the same session that you call it from. If you set the AsDivision to "server" it is more likely to behave the way it would behave on an AppServer. Note that it may very well be more difficult to make it work when you do this,  since it is expecting "everything" to be initiated by the client.