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

Resolved Data windows when switching from PB2019 to R2

  1. Issue
0
Votes
Undo
  1. Rudolf Fürst
    Rudolf Fürst
  2. PowerBuilder
  3. Monday, 20 July 2020 13:27 PM UTC
Hello,

We work with a report system that can be adapted and expanded independently of the program for the individual customer installations. For this purpose, the individual views are saved in the database as PSR files. Typical for these installations are 70-250 views per installation. The process was developed under PB 6.5 and is constantly being updated. Problems occurred when switching from PB2019 to PB2019R2. The program sporadically crashes without errors. A view is displayed several times without errors and then the crash occurs.

Changing and saving the views manually solved this problem. It is a big problem for us to convert all installations to PB2019R2. Is there a tool with which we can batch convert the data windows?
 
Thanks
Attachments (1)
Dws.png Dws.png
Datawindow where clause: Key and Updatable Columns...
tree-view control node's check box is not selected...
Responses (4)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 20 July 2020 16:29 PM UTC
  2. PowerBuilder
  3. # 1

Hi Rudolf;

  The PSR file is the DW object source plus all the datum for the DWO's buffers in a proprietary file format. Since the PSR contains the DW source, the PSR's are thus PowerBuilder and InfoMaker version dependent. Mixing and matching PSR versions is like "drinking and driving" .. not a good outcome. BTW: Its been this way since PowerSoft created the PSR feature.

Regards ...Chris

 

Comment
Rudolf Fürst
  1. Rudolf Fürst
  2. Wednesday, 22 July 2020 13:38 PM UTC
Hi Chris,

We have been using the process since PB6.5. When converting to 9,10.5,12.5.2017 and 2019, these errors have not been corrected.

In the latest build 2328, many DWs are alternative versions e.g. 10.5 in the PBLs. We liked the Ribbon Bar well, we switched to R2 early. Could it be that the switch from 19 to 19R2 is part of this problem because version 19 is displayed in the edit source in both?

regards Rudi

  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 23 July 2020 14:27 PM UTC
Hi Rudi;

The value "Release=19" would be in the DWO source for both PB 2019 and 2019R2. However, it could be a slight change to the DWO syntax in R2 for PDF Generation or trying to use older DWO's source in 2019/2019R2 where the source relates to a deprecated feature. It's hard to tell.

Regards ... Chris
  1. Helpful
There are no comments made yet.
mike S
mike S Accepted Answer Pending Moderation
  1. Monday, 20 July 2020 17:17 PM UTC
  2. PowerBuilder
  3. # 2

is your attached sample actually a datawindow syntax of a PSR that blew up and then was fixed by saving it in R2?

it could just be the PSR format that is the problem.  i have seen issues with PSRs if the datawindow has global user functions in it.  

 

Storing datawindow syntax in the database/files then loading them at runtime is very typical process - and fundamentally the same as loading it from a PBD.  It does not matter if the datawindow version is from an earlier version of powerbuilder (ie version 11 of datawindow running with PB2019).  Even the PB migration process doesn't do anything with old datawindow versions.

As long as the datawindow version is the same or prior version of powerbuilder, then you should be good. 

if the 'fix' requires the datawindow(s) to be rebuilt to the current version of pb, then that is a bug in PB.

 

However, PSR files are not used nearly as often.   at one time sybase was planning on killing off the psr.

 

 

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Monday, 20 July 2020 17:41 PM UTC
Hi Mike;

The blow up your describe is probably due to a known bug in the DW Control and DS where an Update() or Print() command will have the PBVM fire all the DWO's Expressions and computed columns again (for no reason). There is a ticket in the Support System about this. Of course, if a CC or expression calls a GF, then that would compound the situation. Hence the next possible GPF when printing.

Regards ... Chris
  1. Helpful
mike S
  1. mike S
  2. Monday, 20 July 2020 17:54 PM UTC
what you describe could be the OP's problem....



in my case, i think it occurred on display of a PSR when the function does not exist in the PSR viewer and/or possibly the called function was an older version of PB. problem was in old versions of PB, i don't remember if it is also in appeon versions.



  1. Helpful
There are no comments made yet.
Ken Guo @Appeon
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 21 July 2020 09:09 AM UTC
  2. PowerBuilder
  3. # 3

Hi Rudolf，

 

If your application works well in PB 2019 but not in PB 2019 R2, that should be a regression bug.

However, we can’t reproduce it locally, could you please provide a reproducible case for us for further analysis?

If yes, please open a ticket in our support ticketing system (https://www.appeon.com/standardsupport/newbug) along with the test case. Thanks in advance.

 

 

Regards,

Ken

 

Comment
Rudolf Fürst
  1. Rudolf Fürst
  2. Tuesday, 21 July 2020 15:14 PM UTC
hi Ken,



Sorry, I cannot provide a reproducible case for further analysis. The error occurs sporadically. Many DB tables have been hit. Creating a reproducible example would only be possible with a section of customer data (at least 30 tables). I estimate the effort for this on days.



Rudi
  1. Helpful
Ken Guo @Appeon
  1. Ken Guo @Appeon
  2. Wednesday, 22 July 2020 01:21 AM UTC
Hi Rudi，



Can you reproduce the issue if you use a test case with two newly created testing tables?



Regards,

Ken

  1. Helpful
There are no comments made yet.
Rudolf Fürst
Rudolf Fürst Accepted Answer Pending Moderation
  1. Thursday, 23 July 2020 13:25 PM UTC
  2. PowerBuilder
  3. # 4

Hi Ken,

Unfortunately, I am not able to create a small test example. We did not observe this error in the beta phase. We carried out the changeover and delivered it to the customer. About 50 employees work with this program at the customer' office. Some employees work without any problems others had a lot of crashes per day. Viewing the views always works for 5 to 10 times without any problem. We have been able to recreate a situation where the error occurred.  In the trace we realized that the program always crashes at the destructor of the view. We changed the View to fix the problem. Unfortunately, we have a lot of views. Attached an example.

Regards Rudi

Attachments (1)
nest_artkhead_01.zip
Comment
mike S
  1. mike S
  2. Thursday, 23 July 2020 14:18 PM UTC
are you saying your users open up the psr and just look at the data that is stored there (not retrieving it again or printing it from the database?)



if so, have you considered just deploying a stand alone PSR viewer to see if that makes any difference?



Are you able to say that the amount of data in these PSRs is pretty big? As in so big that if the memory isn't properly released it could cause PB to crash? or is it more the complexity of the PSR's setup (lots of expressions?)
  1. Helpful
Rudolf Fürst
  1. Rudolf Fürst
  2. Thursday, 23 July 2020 15:00 PM UTC
Hi Mike,



the problem is not related to the size of the data. Happens with one line, sometimes with 5000 lines.

Our PB development uses these procedures, the same program - different views (disign and number)



Regards Rudi



  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.