Overview

During the compilation process, PowerServer Toolkit (installed at C:\Program Files (x86)\Appeon\PowerBuilder [version]\Pstools by default) converts static DataWindows and embedded SQLs to PowerServer C# models (.cs files) and deploys them to the PowerServer C# solution > "AppModels" project > [appname] > "ESql" and "Models" sub-folders respectively.

PowerServer C# models share similar concepts with Entity Framework (EF) Core models, but they are specifically designed to serve as the backend counterparts to PowerBuilder DataWindows and embedded SQLs. Each PowerBuilder DataWindow in the original PowerBuilder application has a corresponding C# models in PowerServer. The C# models define how data is structured at the server-side and PowerServer uses these models to interact with the database, and the DataWindows at the client are responsible for displaying the data and handling the user interface.

To ensure that C# models can be generated successfully and correctly, please be aware of the following:

  • The database schema information is essential for generating C# models.

    The IDE must be able to access all relevant tables and execute the stored procedure (if necessary) to generate the correct models. Therefore,

    • When you create the database connection cache in the PowerServer project painter, it is very important the login name and password you provide has full access rights to the database.

    • If your application connects with multiple databases, for example, dw_1 connects with an Oracle database and dw_2 connects with a SQL Server database, you will have to configure two separate caches, one for each database type.

      The IDE will attempt to connect using the cache in sequence until it finds the correct table that maps to each DataWindow. When generating the model for dw_1, the compiler first uses the configured Oracle cache. It successfully locates the table in the Oracle database based on the DataWindow definition and generates the model accordingly. When generating the model for dw_2, the compiler initially uses the Oracle cache as well. However, since the corresponding table cannot be found in Oracle, it automatically switches to the configured SQL Server cache. There, it locates the table schema and successfully generates the model.

      If none of the caches succeed (for example, if a DataWindow references a table that does not exist in any of the configured databases), the parsing error will be displayed in the IDE > Output window.

    • The C# model generated for each DataWindow is specific to only one database type. If a single DataWindow is designed to work with multiple database types (e.g., Oracle and SQL Server), you should configure separate PowerServer projects for each database type, so that the corresponding PowerServer Web APIs work with that particular database type. For more details, refer to Supporting multiple database types.

    Why schema information is required?

    The .NET Core data provider enforces strict validation rules on the data type and length, therefore, the IDE has to read information about tables, columns, constraints, and indexes from the actual database in order to generate the C# models correctly.

    If the data source of a DataWindow is a stored procedure, the IDE executes the SQL statement (Select statement or stored procedure) with default parameters in the database, to get the schema information. (However, please note that executing stored procedures with a null retrieval argument in an ASE database may cause performance issue or table locks.)

  • The C# models can be converted from the PBL file, but not from the PBD file.

    Database-related constructs found in the PBD file (such as certain embedded SQL statements) can NOT be converted into C# models, because the PBD file is the compiled version of the PBL file, and does not contain the source code and metadata required for generating C# models. For more, refer to PBD.

Dynamic DataWindows and SQLs

Both dynamic DataWindows and dynamic SQLs are sent to PowerServer at runtime.

  • For 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.

  • Similarly, SQL statements that are dynamically generated from SetSQLSelect, QueryMode, QuerySort, SetFullState, SetChanges, or PSR will be sent from the client to PowerServer and handled by PowerServer dynamically.