1. Jeff Gibson
  2. PowerServer
  3. Wednesday, 7 August 2024 17:14 PM UTC

I'm working with a migration over to PowerServer 2022 R3.  The previous version they were running in was PB 2017 R3.

This datawindow in question was working just fine in the old version of PowerServer.

This datawindow has two visible columns.  One column is a code column. Column name is option_code. The second column is that same option_code column that is used to place a drop down datawindow in. That dddw shows a value based on what that code is.

When we run the application in PB Classic, it works just fine.

However, when we run it in PowerServer, nothing retrieves. 

We are successfully setting the transaction object. However, it just returns zero rows.

I'm wondering if something might be causing an issue with the use of a column more than once.

Or if the name of the column in the dddw matching the column name in the main datawindow could cause a problem.

Any thoughts would be appreciated.

David Xiong @Appeon Accepted Answer Pending Moderation
  1. Thursday, 8 August 2024 03:29 AM UTC
  2. PowerServer
  3. # 1

Hi Jeff,

 

I suggest you submit this issue to our ticket system (at https://www.appeon.com/standardsupport) and upload a small test case that can reproduce the problem (including table SQL, test data, etc.) to help us reproduce and analyze it.

 

Regards, 

David

Comment
  1. Jeff Gibson
  2. Thursday, 8 August 2024 16:40 PM UTC
I will see if we can do that David. I'm uncertain if they have any restrictions on their data. But we will check.
  1. Helpful
There are no comments made yet.
Jeff Gibson Accepted Answer Pending Moderation
  1. Wednesday, 7 August 2024 21:35 PM UTC
  2. PowerServer
  3. # 2

New Information,

We attempted to rename the datawindow control from dw_standard to dw_specs. Made all the appropriate changes to the code to match that. Rebuilt the PowerServer project. Still did not retrieve the datawindow.  Reminder that it does work on the Client Server PB Classic side of things.

We went ahead and moved the datawindow that was at the bottom into the datawindow control that is having the issue.

That datawindow DID retrieve in the control. So, it's not a naming convention issue with the datawindow control.

We are going to swap the datawindow object that is problematic to another datawindow control to see if it possibly retrieves there.

Until that point, I'm attaching the exported datawindow object to see if you can see anything that might cause the datawindow object to not work correctly in a PowerServer environment

Attachments (1)
Comment
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Wednesday, 7 August 2024 21:06 PM UTC
  2. PowerServer
  3. # 3

what database? sql server or oracle?

triple check the retrieval arguments and their datatypes.  I assume you have a retrieval argument and are not just getting back all of them?

you may need to look at the c# code and compare the datatypes.  

are you using any 'weird' datatypes like: bit, time, datetime2 etc?

 

any errors in the log on the powerserver webapi server?  (event log if windows server)

Comment
  1. Jeff Gibson
  2. Wednesday, 7 August 2024 22:12 PM UTC
Database - SQL Server 2022

Both arguments are string. So absolutely nothing weird on the argument front.

The problem I have is another developer is handling this build, so I don't have immediate access to the C# code.



We're going to check the log file.
  1. Helpful
  1. mike S
  2. Thursday, 8 August 2024 16:56 PM UTC
what is the datatypes as per the table in sql server



my guess is there is a datatype mismatch



  1. Helpful
  1. mike S
  2. Thursday, 8 August 2024 17:01 PM UTC
Also is see:

LEFT JOIN

which looks weird. i always use left outer join. had to look that up to see if it is valid.

maybe the c# doesn't like that?

  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 7 August 2024 20:37 PM UTC
  2. PowerServer
  3. # 4

Are all DWs in the app failing to retrieve data or just a specific one?

Comment
  1. Jeff Gibson
  2. Wednesday, 7 August 2024 20:43 PM UTC
Is just this specific one Armeen. All the other datawindows on this user object that is incorporated within the second tabpage are retrieving like they should. All datawindow settransobject calls are successful. CreateOnDemand is Off., (See my additional comment to Mike S)



It's absolutely bizarre. I've never ran into this in the past with other conversions.



And for the record. This datawindow retrieves just fine under the PowerServer environment under PowerBuilder 2017 R3.
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Wednesday, 7 August 2024 20:05 PM UTC
  2. PowerServer
  3. # 5

"when we run it in PowerServer, nothing retrieves."  - the datawindow won't retrieve, or the dddw won't retrieve?  i assume you mean the dddw?  

is the dddw retriveal set to auto retrieve, or are you retrieving in code?

 

option_code - Did you only include the column once in the sql, and then have that column twice on the datawindow display? the field name is different for each, correct?  

 

my first thought is something is wrong with the dddw datawindow sql.   

----------------------------------

also, make sure you updated the dlls etc in PS 2023 - update the cloud app launcher and the dlls.  its a separate process than the application deploy. its under tools and listed as "powerclient" even though its powerserver.

 

Comment
  1. Jeff Gibson
  2. Wednesday, 7 August 2024 20:38 PM UTC
We migrated everything from PB 2017 R3 up to PB 2022 R3. Build 3356.



So now I have some additional info. We threw the datawindow that used a dddw away and built a new datawindow that did a join to the secondary table. So now the datawindow is just two columns coming from two separate tables. There are no column names that match.



The retrieve on the PowerServer side still brings back zero rows. We even added a command button that sets the transaction object again against the datawindow and fires the retrieve. (In case it was a timing issue on the construction of the window).



This datawindow just won't retrieve in the new environment.



The name of the datawindow control is dw_standard. The datawindow object name is d_purchase_body_selection.



Now my next thought is, are we possibly dealing with a keyword that is stepping on something over on the C# side of things.



Any thoughts would be appreciated. I'm even considering just renaming the dw control to see if that might clear this up.
  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.