• Insertar un breakpoint.- Ejecute la opción de menú principal: Edit/ Insert BreakPoint
  • Requisito: Debes estar en el editor de código (script) .
• Inicializar el depurador. Ejecute la opción de menú principal: Run / Debug nombre de su aplicación
  • Ejecute la opción Debug  / Start nombre de su aplicación
• Ejecutar línea por línea.- F8
• Detener el depurador.-  Debug/Stop
• Ver el contenido de una variable.—Seleccione la variable, dar click derecho y escoger la opción quickwatch
  • Requisito: Debe estar ejecutándose la aplicación en modo de depuración

Truco: Algunas veces tenemos un error en tiempo de ejecución que nos hace que Powerbuilder se cierre, para localizar en donde ocurre esto la opción Depurar en tiempo de ejecución ayuda mucho.

In a previous blog article we looked at the new feature of PowerBuilder 2017 R2 for Subversion source control support. In this blog article we're going to look at a very similar feature, Git source control support.  I'm not going to go through the history of source code support in PowerBuilder again, I'd refer you to that previous blog article for that.  We're going dive straight in to how the Git feature works.

Setting up Git

For this demo, we're going to use Bonobo Git Server.  One reason I like it is because it provide a web based admin console for managing the server, so I don't have to use the Git command line to do that.

Because it's an ASP.Net application, the machine where we're going to install it must have IIS and the .Net Framework 4.6 installed on it.  To install Bonobo Git once you've downloaded it you simply need to:

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.

One of the new features added to PowerBuilder 2017 R2 is support for REST web services.  This feature isn't 100% complete, as additional REST functionality is planned for 2017 R3.  There's still a lot in the R2 release to look at though.

To make things simple for the demo, we're going to use a online REST web service called JSONPlaceHolder..  The service doesn't require creating an account or user authentication.  While the GET (retrieve) methods are fully functional the POST ( insert ), PUT/PATCH ( update ) and DELETE (delete) methods are placeholders.  They return result codes or in the case of POST the id value of the inserted row, but they don't actually modify the data.

Note that while REST web services can return data in any internet mime encodable format, the vast majority of them use JSON  and JSON is the only data format supported by the REST client object in PowerBuilder 2017.

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.

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:

In a previous blog post I ran through a example of how to use the new command line compiler feature of PowerBuilder 2017 to perform continuous integration using Jenkins and a Git repository.  One of the "next steps" I referenced in the close of that post was the creation of a plug-in for Jenkins that would make creating the build steps for the project much simpler.

Well, I've created such a plugin.  Or more specifically what I did was take the existing MSBuild plugin and customize it to create a number of plugins to do PowerBuilder compiles instead.

In this post I'm going to look at how we can use those plugins, plus some additional changes I've made to the project in Jenkins to make better use of the capability of Jenkins and other Jenkin plugins.