Hi Steen,

Based on your example code, I infer that, you are using a nested "FOR" because you are doing some more processing in it. But, if this wasn't the case, I would suggest to fill that column in the query during the RETRIEVE. (ie: SELECT a, b, mycolname = 'some data' FROM mytable WHERE a BETWEEN 1 AND 500). That way you may be able to avoid the use of a FOR cycle of 350,000 iterations.

On the other hand, if you find that a particular part of the function is causing this, then I would recommend you open a support ticket for this case. It may be something with the internal processing of the info.

I hope this helps and please do share your results here.

Regards,

Try getting the rowcount into a long first instead of having it part of the For statement.

Hi Steen;

    Can you try the following ....

1. Create a PB.INI file in your App's work folder
2. Add the following to the INI ...

[DataStore Behavior]
UseHwnd=no

Let me know if that helps!

Regards ... Chris

Hello

Seems like we are encountering the same issue in multiple places when processing large data sets.   This is a likely cause for multiple reported failures.  Since "loop retrieve, setitem, update" is a common processing pattern code refactoring is not practical.  I saw the case https://www.appeon.com/standardsupport/search/view?id=535

Was a fix implemented in R3 or 2019?

Thanks

yakov.werde@iongroup.com

Well, Appeon's answer on this reported bug has been clear: they won't fix it as they don't know how much other stuff they might break in doing so.

"Wow", is all I can say !

The Retrieve function returns the number of rows so you should get it into a variable and use that in the for-next.

The RowCount function is being executed every time through the loop.

This is the won't-fix bug I'm referring to, as Steen J. reported this before as a bug:

https://www.appeon.com/standardsupport/search/view?id=535

Hi Steen,

I think that 3 possible workarounds were suggested when you reported bug 535.

One of them would be to do "

lds.resetupdate() //to release memory

" 

If your MyDatastore would be a standard user object datastore, like n_ds of the pfc's, maybe a possible solution would be to do a ResetUpdate() in the RetrieveStart() event of the ancestor class of MyDataStore.

Just an idea, don't know if it would really work, this workaround.

regards,

Has anyone tried replacing the hundreds of SetItem calls performed inside of the inner loop with a single statement outside of the inner loop that sets the data values in a column for all rows at once?

Integer li_x
Long ll_rowcount, ll_f
String ls_columndata[], ls_emptyarray[]
DataStore lds

lds = Create DataStore
lds.DataObject = "d_abc"
lds.SetTransObject(SQLCA)

For li_x = 1 To 500
   // Flush, then populate the DataStore.
   lds.Reset()
   ll_rowcount = lds.Retrieve('some_id')
   if ll_rowcount > 0 then
      // Clear column data array, then load it with new column data values.
      ls_columndata = ls_emptyarray
      
      For ll_f = 1 To ll_rowcount
         ls_columndata[ll_f] = 'some data'
      Next
     
      // Replace column data in the DataStore for all rows at once.
      lds.Object.mycolname.Primary.Current = ls_columndata
      // or
      //lds.Object.mycolname[1,ll_rowcount] = ls_columndata
   end if
Next

MessageBox("","Before destroy")
Destroy lds

Disclaimer: I have NOT tested the above code, and I do not claim it will solve the memory utilization issue. However, syntactically it looks like it should work correctly. The technique is documented in the DataWindow Reference, section 4.3.1 "Syntax for one or all data items in a named column".

HTH,
John

Guys,

There are reasonable workarounds and arguably better ways of writing the code.  PowerBuilder product is composed of many millions of lines of code that we didn't write and have to be very careful how we change so our customer's mission critical apps don't break when they upgrade, many of which are Fortune 500 companies. 

Plus we need to balance our R&D resources between fixing Sybase's old bugs that customers have tolerated (i.e. worked around) over the years with bringing long overdue features to market.  Hope you guys take a moment to look at this from our side as well that we are trying to do the best we can for PowerBuilder customers and their projects.

But even with that said we aren't passing the buck and have fixed or are currently releasing fixes for a number of such legacy bugs that Sybase ignored, such as bug ID # 150, 173, 186, 190, 199, 219, 234, 237, 256, 309, 314, 316, 341, 354, 381, 415, 437, 509, 535, 589, 717, 819, 896, 990, 1037, 1153, 1233, 1345, 1360, 1392, 1693, 1718, 1729, 1745, 1757, 1783, 1814, 1825, 1856, 1982, 1999, 2278, 2443, 2467, 2576, 2743, 2753, 2834, 3077, 3504, 3513.

Thanks,

Armeen Mazda
CEO, Appeon