Good suggestion Francisco.  I'm probably going to spend more time turning my application into a "cloud" app before I request any changes, though...because I'm not sure such a change would be beneficial.  In my current project I am seeing times when I would want to see c# model datatypes be Int32? and others when a double? is perfectly appropriate. 

It does appear the "Build & Deploy PowerServer Project" process needs refining.  I just debugged another issue that arose from that process and found that the c# model for a DataWindow whose SQL is a stored procedure wanting 16 arguments was not generated correctly...the "DwProcedure" definition in the model was missing a parameter even though it was defined below.  I've attached an image in case I didn't describe it clearly.

Anyway, I will press on because nothing I've found has been a show-stopper.

Hi Chris,

When PowerServer converts DataWindows to C# Models, it follows the principles below:

1. When the data source of the DataWIndow is a stored procedure when converting to C# Model, it determines the column types by checking the result after running the stored procedure with default parameters. If it fails to run the stored procedure, it will be then converted according to the column types in DataWindow. For example, "Number" will be converted to C# "Double" in the model.
2. When the data source of the DataWindow is Select SQL when converting to C# Model, the data types of the columns will be obtained from the database table. If it fails to query the database, it will not generate the corresponding C# Model in AppModels. An error will be shown on the error tab of the PowerServer Deployment window.

So for the issue where a number in DataWindow is translated into double in C# model, we recommend that you check the following:

1. Confirm whether the database is connected correctly and whether the DB user has sufficient permission to access related stored procedures and tables when PowerServer generates models during deployment.
2. Check the relevant stored procedures, and see whether the resultset structures are different depending on the input. If the same stored procedure returns resultsets with different columns or different column data types, it will cause a mismatch error. PowerServer doesn't support this case.

About the mapping of the SQLServer database data type in C# Model, you can refer to the link below

https://docs.appeon.com/ps2022/SQL_server_data_type_mappings.html

For the issue "the c# model for a DataWindow whose SQL is a stored procedure wanting 14 arguments was not generated correctly", we suggest that you submit another ticket separately and provide a small test case that can reproduce the issue (including procedure syntax, table syntax, test data) for us to reproduce and analyze the issue. Thank you!

Regards,

David

Posting an update on this...both issues I mention in this thread have been reviewed by Appeon Support and they tell me the functionality will likely be fixed in PowerServer 2022 R2 BETA.

The main issue that led me to post this question is a bug and I will need to wait until PowerServer 2022 R2 BETA to see improvements.  The detailed reason for the behavior is...

This issue is because there is a parameter in the stored procedure; In the DataWIndow the parameter is a fixed value. 
PowerServer parsed this parameter name incorrectly, failing in executing the stored procedure and thus was unable to get the resultset. 
As a result, the C# model was generated by mapping the data types in the DataWindow, which led to the error.

For the issue I mentioned regarding the c# model missing a parameter...it appears the way the datawindow was parsed during the generation process produced the issue.  There are both a "chassis" and "chassis2" datawindow argument defined but "chassis2" wasn't being passed to the appropriate stored procedure parameter, instead "chassis" was being passed to 2 different stored procedure parameters when executing the stored procedure.  Appeon's detailed reason is...

The cause of this problem is due to the @chassis2 = :chassis in the Stored Procedure Data Source of DataWindow

Thank you to everyone who responded tp this question...I really appreciate the help!

Hi Chris,

The DataWindows use stored procedures as DataSource? Or plain tables?

Regards,
Francisco

Thanks for the explanations. 

It is not realistic for me to modify the many stored procedures as there are other non-PowerBuilder applications that may use them.  I did attempt to replace every instance of "double" with "Int32" and that improved some areas but broke others...like where the "Number" DataWindow datatype is for a column in the database that is a "Float"...so, I guess even if SnapDevelop had the setting I wondered about, it would create problems in a different way if I used it.

Sounds like the primary solution for me is to keep notes on which DB columns are found to be mapped incorrectly and fix those specific issues in their respective c# models.