Features List of PowerBuilder .NET Packages 1.0.x
This document introduces the new features along with the provision of PowerBuilder .NET packages 1.0.x.
PowerBuilder .NET Packages in NuGet
The following PowerBuilder .NET packages are available for download from NuGet.org:
- Creating projects that runs on .NET Core/.NET Standard
- Using PowerBuilder.Data.AspNetCore objects for .NET Core, and using PowerBuilder.Data objects for .NET Core or .NET Framework
Microsoft SQL Server
Supported versions: 2016 or 2017
Supported versions: 12c or 18c
Supported versions: 11.3, 10.1, or 9.6
ODBC connection to SQL Anywhere (64-bit only)
Supported versions: 16 (22.214.171.1243 or later) or 17
Objects and their APIs
These are the key objects provided in PowerBuilder .NET packages:
.NET DataStore is a .NET implementation of the PowerScript DataStore, which is compatible with the .NET Core and is developed with the PowerBuilder IDE. It brings the heart of PowerBuilder to C# development and with fast performance.
ModelStore objects are created through simply specifying the attributes in the model. You can then use ModelStore for common data operations such as data caching, filtering, sorting, status tracking, data traversing, and statistical analysis.
For more information about PowerBuilder .NET packages, see PowerBuilder .NET API Reference.
Because .NET DataStore and ModelStore explicitly and/or implicitly use SnapObjects DataContext's transaction APIs to manage transactions, using transactions in .NET DataStore and ModelStore has dependencies on the following SnapObjects packages:
For more information about SnapObjects.NET APIs, see SnapObjects .NET API Reference.
Transactions in .NET DataStore and ModelStore can be either explicit or implicit:
- An explicit transaction is one that you explicitly create by using context.BeginTransaction()
- An implicit transaction inherently includes all the CUD operations on the model until a commit method (SaveChanges in SqlModelMapper, or Execute/ExecuteProcedure in SqlExecutor) is executed.
Simple, minimal coding
Simple to code advanced functionality, and data access is in models to minimize maintenance efforts.
.NET objects are used as query criteria in a type-safe manner, and testing APIs are provided to verify SQL.
Relationships are defined while coding (not pre-defined) and are only persistent for a particular query.
There is little overhead compared to ADO.NET, and queries, updates, and actions are executed in bulk.