User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

One of the new features in PowerBuilder 2017 R2 is support for PostgreSQL.  We're going to take a look at using this new (to PowerBuilder) database.

Installing PostgreSQL and ODBC driver

PostgreSQL is an open source database licensed under the PostgreSQL license, similar to the MIT license.  Downloads for the Windows operating system are available from here.  PowerBuilder uses ODBC to access PostgreSQL, so you'll need to get an ODBC driver as well.  The one from PostgreSQL is available here, although there are third party ODBC drivers as well.  When I was testing out this new feature I used the BookTown sample database from O'Reilly Media.

Creating an ODBC database profile

After importing the booktown data using pgAdmin (the admin tool for PostgreSQL), I defined the a system ODBC profile for the database as follows:

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

The stand alone compiler was first introduced in PowerBuilder 2017.  It's primarily of interest for shops who perform routine (perhaps daily) builds of their PowerBuilder based applications, usually in order to perform manual and/or automated testing in order to capture bugs as soon as possible after they are introduced into the code base.

While you could perform command line compiles using the PowerBuilder IDE (and still can) it does require an additional license for the IDE, and it has a few drawbacks (e.g., stopping and displaying a messagebox nobody can see on some error rather than exiting with an error code).

One issue with the initial version of the command line compiler introduced in PowerBuilder 2017 is that it didn't support every option available in the PowerBuilder project painter.  Therefore, if there was some particular feature that use used in the project painter (e.g., generating an external manifest or no manifest at all) it wasn't possible to use the stand alone compiler and get the results you needed.

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

PowerBuilder's initial support for version control systems required drivers for specific vendors (e.g., PVCS) and often for specific versions of that vendor's products.  It was not unusual to find that you needed to wait to upgrade your source control product until PowerBuilder released an updated driver for it.  And if your source control provider wasn't supported by PowerBuilder you were simply out of luck.

 

 

That changed with PowerBuilder 6.  With that release, PowerBuilder abandoned the vendor specific drivers in favor of the recently introduced Microsoft Source Code Control Interface (MSSCCI).  Essentially an ODBC for version control, it freed the IDE from vendor lock-in.  Provide the source control provide provides an MSSCCI complaint interface, or there was a 'bridge' product available that could convert MSSCCI calls into the source control providers native API calls, PowerBuilder could use the product.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

In SQL Server it is generally a good idea to use temporary tables, rather than table variables within your stored procedures. Temporary tables perform much better, particularly with large volumes of data, as SQL Server is able to compile statistics on the data in temporary tables. However, if you are calling your stored procedures from a Powerbuilder application,  you may find that the switch to temporary tables has an unwanted side effect. Here is how the unwanted side effect comes around and what to do about it. 

https://www.selecttop.co.uk/440194269
 
https://www.youtube.com/watch?v=7QK-N6dQxNg