1. Kristin Sisk
  2. PowerBuilder
  3. Wednesday, 14 February 2024 16:13 PM UTC

Is it possible to dynamically change the datawindow syntax for a nested report in the group header datawindow? 

I have a header and footer on a nested report.  I want to be able to assign the datawindow syntax to the nested report at runtime.  I am storing the datawindow syntax in the database.  Approaches I have attempted so far were not successful.

Previously this was achieved by adding the custom datawindow objects to a library.  The library was dynamically added to the library list through "AddToLibraryList".  With our move to PowerServer deployments we need to replace this approach.

Thank you

Who is viewing this page
Kristin Sisk Accepted Answer Pending Moderation
  1. Wednesday, 14 February 2024 16:39 PM UTC
  2. PowerBuilder
  3. # 1

Thank you for your quick reply. 

Is there any way around it by having a "dummy" datawindow and then changing the datawindow syntax at runtime?  We successfully tested doing so with a datawindow but I have not been able to do so with a nested report. Since we allowed users in the past to customize report headers and footers we are looking for a way to not remove support for that functionality.  Most of the customization is around the formatting.  Thank you again.

Comment
  1. Chris Pollach @Appeon
  2. Wednesday, 14 February 2024 19:32 PM UTC
Hi Kristin ;

One way that I can think of (I have not tested this approach BTW) would be (my best guess here) ...

1) Create a new PBL that has all the child DWO's in it that "could be used", so that the PS Compiler builds all the proper related C# stuff.

2) At App runtime, use the SetLibraryList() command to remove the child DWO PBD used in the step #1 compile.

3) Use the LibraryCreate() command to create an empty PBL

=> I would also use the FileExists() and FileDelete() commands to blow away any previous PBL instance.

3) Use the AddToLibraryList() command to add the PBL to the App's library list for the PB Loader

=> That should now condition the PB Loader as to where to find the "latest" child DWOs.

4) Grab the DWO source you need from the DBMS and use the LibraryImport() command to create any DWO's you need in the new PBL "on the fly".

=> As long as they have the same Class Name & SQL as in Step #1, that should be OK. - but they can then have their own look & feel (ie: text, labels, column positions, headers, footers, expressions, etc). As long at the expected result set is the same, then that should not matter..

5) Now have your PS App run the Nested Parent DWO's as normal.. The PB Loader should now find the corresponding child DWOs in the new PBL where the dynamic child DWOs were just created. They "should" execute OK DML wise via their Web API call & return the JSON result sets (Parent & children) from the Web API call (as expected from Step#1). Then the PS App on the client machine should then render the JSON result sets GUI wise.



In theory (just off the top of my head), I "think" that this should work. Food for thought.

Regards .. Chris



  1. Helpful 2
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 14 February 2024 16:20 PM UTC
  2. PowerBuilder
  3. # 2

Hi Kristin ;

  You cannot use this approach with PowerServer based Applications. That is because the PS Project that executes on the "Build & Deploy" phase must see all the DWO's in order to create A) the corresponding DW.NET and B) C# Restful Web API for each DWO it encounters, during that part of the PS deployment. If the PS project does not see every DWO in your PB App's source then these C# items will be missing and the PS App will fail at runtime on the PS Server Web API call. 

PS:  DataWindows that are dynamically created using SyntaxFromSQL, when the SQL SELECT statement is sent from the client to the PowerServer, PowerServer will get the schema of tables and columns from the database and then PowerBuilder Runtime will generate the DataWindow source code using the schema information.

HTH

Regards ... Chris

Comment
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.