Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (5)

Resolved Copying datawindows

  1. How-to
0
Votes
Undo
  1. Maritech Admin
    Maritech Admin
  2. PowerBuilder
  3. Thursday, 6 December 2018 08:06 AM UTC

Hi.

 

We have a function in our application which takes any datawindow, finds all visible columns and copies them to another datawindow for export til Excel using dw_excel.saveas().

This is done because we only want to export the visible columns to Excel.

 

However, yesterday a customer reported that our application quits without any error or message.

I've debugged the code and PowerBuilder quits at this codeline:

 

dw_saveas.object.data = dwo.object.data.current

 

I've tried the following replacements, but I get the same behavior:

dwo.rowscopy(1,dwo.rowcount(),primary!,dw_saveas,dw_saveas.rowcount(),primary!)

And:

dwo.getfullstate(lbl_dw)

dw_saveas.setfullstate(lbl_dw)

 

The datawindow contains about 330.000 rows.

If I change the parameters a bit so that the datawindow contains "only" 290.000 rows, everything works as it should.

Is there any limitation for the size of a datawindow when it comes to copying?

 

Regards,

 

Bjarne Anker

Maritech Systems AS

Norway

  1. DataWindow
  2. PowerBuilder (Appeon)
ORA-12154
Oracle Procedure Call with Array Parameters
Responses (5)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Sunday, 30 June 2019 19:24 PM UTC
  2. PowerBuilder
  3. # 1

Another thing which comes to mind is:

Instead of duplicating the data before doing the export, work directly on the origin datawindow:

1) dw_origin.SetRedraw(false)

2) delete all invisible columns you don't want to export using Modify() and "destroy" syntax:

.Modify( &
"destroy ")
//Example: dw_origin.Modify("destroy column salary")
//OR
// dw_origin.Modify("destroy salary")

3) export dw_origin to excel

4) dw_origin.reset()

5) dw_origin.retrieve(..)

6) dw_origin.setredraw(true)

 

Just wondering if anyone has any thoughts if we could do something "nifty" here, using our brandnew C# Web Api's?

regards,

MiguelL

Comment
mike S
  1. mike S
  2. Monday, 1 July 2019 13:10 PM UTC
@miguel, that is a good idea, but if they want excel export to match exactly what is displayed then it won't work for grid datawindows where the user moved the columns around (or if they were moved at design time). The copy data approach also allows the users to extract any dw compute fields so the user get a pretty accurate representation in excel of the report/datawindow.



Users wanting to run huge reports for extraction into excel is a fairly common request, and IMO one of the few reasons to compile into 64 bit. Other than the c# approach, a 64 bit pb exe could be used just for doing these sorts of extractions either as a process server or called from an IIS web service.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Monday, 1 July 2019 13:36 PM UTC
Good points, to be honest, we use dw2xls.pbl from "Desta", still a great product and worth it's price.
  1. Helpful
There are no comments made yet.
Georgios Papageorgiou
Georgios Papageorgiou Accepted Answer Pending Moderation
  1. Saturday, 8 December 2018 08:59 AM UTC
  2. PowerBuilder
  3. # 2

Hi,

Did you try the editbin.exe with option

LARGEADDRESSAWARE ?

We had plenty of success using this modification to the .exe

Regards

Georgios

Comment
Shenn Sellers
  1. Shenn Sellers
  2. Monday, 10 December 2018 22:44 PM UTC
If you don't have access to Visual Studio, you can use this application recommended by Bruce Armstrong to make the 32bit app able to use 4 GB of memory.



https://www.brucearmstrong.org/2013/03/nice-tool-for-increasing-memory-for-32.html
  1. Helpful
There are no comments made yet.
Bjarne Anker
Bjarne Anker Accepted Answer Pending Moderation
  1. Friday, 7 December 2018 08:15 AM UTC
  2. PowerBuilder
  3. # 3

Hi.

 

I tried sharedata and it still crashes, but with a "out of memory" error.

My computer has 20 GB of memory, and pb170.exe uses around 2 during this functioncall.

 

This is no big issue, so I've instructed the customer to break the report i half to reduce the amount of data.

They are OK with that.

 

However, I will definitely try to build a 64-bit EXE and test it.

 

Regards,

 

Bjarne

Comment
David Peace (Powersoft)
  1. David Peace (Powersoft)
  2. Friday, 7 December 2018 16:10 PM UTC
As a 32-bit application it will only address 2-3GB of ram. Chris' Rows to disk it a good suggestion.

Clearly you are pushing the limits of this approach.



David
  1. Helpful
There are no comments made yet.
Brad Mettee
Brad Mettee Accepted Answer Pending Moderation
  1. Thursday, 6 December 2018 14:54 PM UTC
  2. PowerBuilder
  3. # 4

Why not share the data between the two instead of copying the rows?

dwc_original.ShareData(dwc_visible_only)

That way you don't duplicate data, and don't need to create a loop to copy 100k rows at a time (to keep from crashing).

Comment
Marco Meoni
  1. Marco Meoni
  2. Thursday, 6 December 2018 16:51 PM UTC
Sharedata does not apply here.

It needs same columns between 2 DW/DS.

But Bjarne wants to drop those ones that are set invisible because they are not meant to be exported to Excel.

Best,

.m

  1. Helpful
Brad Mettee
  1. Brad Mettee
  2. Thursday, 6 December 2018 20:01 PM UTC
Good point about differing column lists.



How does the data assign/copy handle those missing columns, and could it be part of the problem?
  1. Helpful
There are no comments made yet.
Marco Meoni
Marco Meoni Accepted Answer Pending Moderation
  1. Thursday, 6 December 2018 14:22 PM UTC
  2. PowerBuilder
  3. # 5

Hi Bjarne,

limitations may come from the actual computer.

The fact that you can transfer 290k but not 330k is an indicator that you may be running out of memory.

Did you look at task manager -> memory usage while copying columns?

If you (roughly) multiply [330k rows * #bytes taken by the columns' size] you may easily allocate some GBs, (x 2, since you have 2 DWs) 

What' are PB version and computer specs? 

If memory is the issue, an additional test, if you are running 32 bit EXE, would be to compile the app in 64bit mode.

Best,

.m

 

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 6 December 2018 15:41 PM UTC
Hi Bjarne,

I think that Marco may have "hit the nail on the head" with this analysis. a 64Bit App EXE could be the answer.



The only other suggestion I have is to try the "Rows to Disk" feature of the DW and see if that alleviates some memory from the process.

Regards ... Chris
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.