• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Program shutting down when dw.retrieve returning too much data

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

Resolved Program shutting down when dw.retrieve returning too much data

  1. Issue
0
Votes
Undo
  1. Anita Headley
    Anita Headley
  2. PowerBuilder
  3. Tuesday, 5 March 2019 00:33 AM UTC

I am using PowerBuilder 2017 R3 Build 1858.  SQLServer 2012 database.

datawindow.Retrieve crashing program when try to retrieve 'too much' data.

I have a report that takes a date range argument.  when I put in a short date range, the report runs fine.  When I try a longer date range, I get this

 

I have been working with Powerbuilder for 20 years and have never had a simple dw.Retrieve do this to me before.

How do I capture the error to keep it from crashing the program?

 

INNO Setup - Uninstaller is in Programs and Featur...
Widow/orphan behaviour in DW reports
Responses (6)
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2019 01:34 AM UTC
  2. PowerBuilder
  3. # 1

Have you run the SQL in MSSMS so you can see how may rows?

Which database interface are you using?

 

Comment
There are no comments made yet.
Anita Headley
Anita Headley Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2019 01:39 AM UTC
  2. PowerBuilder
  3. # 2

returns about 1200 rows for longer date range.  Has no problem returning that many on other datawindow control on same Window.

 

Using ODBC SQLServer Native Client 11.0

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 5 March 2019 19:51 PM UTC
Hi Anita;

Are you saying that the same DWO when run in another DC works OK?

Regards ... Chris
  1. Helpful
Anita Headley
  1. Anita Headley
  2. Tuesday, 5 March 2019 20:18 PM UTC
Yes Chris, that is exactly what is happening. And it works fine in second DC if send a short date range that only returns a few hundred records.
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 5 March 2019 20:48 PM UTC
Sounds like either the 1st DC is corrupt somehow or there is some weird code on a DC's event like: RetrieveStart, RetrieveRow, RetrieveEnd, RowFocusChanged, ItemFocusChanged or even a User Event that is mapped to a low-level MS-Windows message that gets triggered during the retrieval and its PBScript that then fails. Note: Check your ancestor's related event scripts as well.



Another issue could be the DWO itself. If you Edit the DWO's source .. does the 1st line read - "release 17;" ?



  1. Helpful
There are no comments made yet.
Olan Knight
Olan Knight Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2019 03:51 AM UTC
  2. PowerBuilder
  3. # 3

1200 rows should be no problem at all to handle.

1) Check the disk space on your platform
2) As Roland said, actually run the SQL of the DWO in either the ISQL Painter or some other interface to see what is actually being returned.
3) Put the RETRIEVE command in a TRY/CATCH block
4) Try another database if that's an option for you.


Good Luck,

Olan

Comment
There are no comments made yet.
Anita Headley
Anita Headley Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2019 18:33 PM UTC
  2. PowerBuilder
  3. # 4

free disk space is 260GB

SQL returns 1282 records

I put the Retrieve in a TRY-CATCH

    TRY
    rowcnt = dwc_export.Retrieve(g_user.user_id)
   CATCH (runtimeerror er)
    MessageBox("Runtime Error", er.GetMessage())
   END TRY

It still crashed the program rather than catching the error.  Is my syntax correct?  I've never used TRY-CATCH with a datawindow control retrieval.

 

Another database is not an option - client has SQLServer 2012 and is not even willing to upgrade to newer version because of other applications.

 

I have two datawindow controls (dw_1, dwc_export) on this window (w_reports).  The first one (dw_1) uses a datawindow that has dw_rpt_valid_permit_list as an embedded sub-report.  The second (dwc_export) just has dw_rpt_valid_permit_list as the dataobject.  The first datawindow control retrieves the data with no problem, even with larger date range.  The second datawindow control crashes the program when the retrieval is called.

Comment
There are no comments made yet.
Anita Headley
Anita Headley Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2019 20:15 PM UTC
  2. PowerBuilder
  3. # 5

Yes Chris.  exactly what is happening.

Comment
There are no comments made yet.
Anita Headley
Anita Headley Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2019 22:05 PM UTC
  2. PowerBuilder
  3. # 6

Well, I solved it by copying the datawindow to a new name and having the second datawindow control use the new datawindow.  I don't know why this solved the problem, but I am now able to run multi-year date ranges without crashing the program.

 

In answer to Chris' suggestions:

The first datawindow control is based on u_dw from PFC.  It has no custom event coding.

The second datawindow control is based on datawindow. It also has no custom event coding.

The source of the DWO does start with "release 17"

Comment
Load more comments
Anita Headley
  1. Anita Headley
  2. Tuesday, 5 March 2019 22:25 PM UTC
both dwo are in the same pbl. I am now using both copies. The original dwo retrieves just fine in the first datawindow control (based on u_dw). I understand that all PFC objects have lots of ancestor code, but I had not added any additional code and the PFC based datawindow control was working just fine. It was the pure PowerBuilder datawindow control based on datawindow object that was having a problem.



I have just been migrating the PFC forward along with the application which was originally built in PowerBuilder 6. This bug just turned up when changing the back-end database from Access to SQLServer. This is also a relatively new report and may not have been tried with a multi-year date range before. This application has over 100 canned reports.



Where would I get the latest version of PFC? (For use in any new applications).
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Tuesday, 5 March 2019 23:26 PM UTC
PFC was made open-source by Sybase many years ago. The latest open-source repository for PFC is here: https://github.com/OpenSourcePFCLibraries

  1. Helpful
Anita Headley
  1. Anita Headley
  2. Wednesday, 6 March 2019 00:33 AM UTC
Thank you

  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.