Defensive Programming with PowerBuilder
Another « Big Word » – Defensive Programming – where developer are trying to produce code that will resist to various criteria that could make your program bug/hang or crash!
In PowerScript, this is quite easy to avoid bug by:
- Checking User Data Entry validity
- Checking Parameter validity
- Using TRY/CATCH/FINALLY code to handle properly stream/hardware faults
But what about underlying database changes?
Here we can take profit of the SQL Language Column Alias capabilities first and then, if you are using a database that do NOT follow SQL Standards, you can take advantage of the versatility of the Datawindow about the mapping between the DWO column name and DBNAME properties.
Taking Advantage of the Column Alias at data source level:
As any Good PB programmer, you will use a datawindow/datastore to retrieve data in general.
But one thing that we do not usually do is to be “defensive” also with our results sets.
To achieve this, simply add column alias to every column returned by your queries. Use common sense label that match as possible to the vocabulary used in the working context with a sufficient abstract level above the usually used “Table.Column” schema.
For example, when returning “TAX_CODE.VALUE”, set “VAT_PCT” as alias.
From now, your dw column will be called “VAT_PCT” instead of “TAX_CODE_VALUE” or simply “VALUE” if your query does not use a multiple tables FROM clause.
In the dw painter, you can make it either in graphical mode – using the “Computed Column” tab page:
- Deselect all column
- User Column popup menu and type AS <Alias>
- Add a line for each column alias
Or in Syntax mode:
- Add “AS <Alias>” in front of each column of the SELECT clause
Please note that if you create directly the alias from the syntax mode, the “convert to graphic” options will not work. But if you have created them from the graphic mode, you can round trip from Syntax to graphic as you want !?!
Taking advantage of the Datawindow Column Mapping Capabilities
There you will have to work directly on the export (edit source) of the datawindow object and change the each column name directly by its alias:
The result can be verified (for both method) by checking the “Column Definition” View :
Finally, use variables in your code that match data source ‘s aliases.
Now, if the underlying tables used in your existing data sources have to be modified, you will not have to change anything in your existing code!
This is what a call a very “defensive programming” code…