Additional Tips and Tricks
At this stage, the application has been successfully compiled, packaged, and deployed to an end-user workstation. However, that's rarely where the story ends. There will be a need for continual redeployments as the application evolves and changes over time. This section introduces some additional points to consider for reducing the workload of supporting the deployed application.
Building Version Information into the Executable
A very critical stage in the deployment process is ensuring that the client application and the relational database model are at a consistent patch level. For example, a user who inadvertently ran version 2.1 of the client executable against a database that had been patched to version 3 might encounter significant errors, or even cause data corruption.
One technique for preventing this situation is to place version information into both the executable and the database. At application startup, these separate values can be compared, and if the versions are not compatible, the application can shut down or initiate a patch process.
Storing the version and build information in the database is relatively straightforward. Compiling this same information into the executable relies on the fact that PowerBuilder resolves variable declarations that include value assignments at compile time. Add the instance variable declarations shown in Listing 3.5 to a globally available object, such as the PFC AppManager, and the application will be able to know the exact date and time of the compile, along with other custom build information.
Listing 3. 5 Instance Variable Declarations for Build Information
date lcd_build = Today() time lctm_build = Now() ulong lul_temp string ls_key = "HKEY_CURRENT_USER\Software\Sybase\PowerBuilder\" + & "myApplication" integer li_dummy1 = RegistryGet ( ls_key, "Build", ReguLong!, lul_temp ) integer li_dummy2 = RegistrySet ( ls_key, "Build", ReguLong!, lul_temp + 1 ) ulong lul_build = lul_temp
This technique requires that the specified registry key exist on the machine doing the compile. The integer value found in the "Build" key will be automatically incremented, just by performing the compile. Other than creating the key the first time, no other manual steps are required.
A database table could be created that stored similar information, and the application startup process could validate the settings against each other and determine an appropriate course of action should they differ.
Deploying Applications from the Database
This tip comes from Berndt Hamboeck, a frequent contributor to the PowerBuilder Developer's Journal, where this tip was recently published. It addresses the actual deployment of client-side files to the user's workstation by actually storing the zipped deployment files directly in the database itself. Because many enterprise-class databases now support binary large object (BLOB) datatypes, it's possible to place large binaries such as a .ZIP file right into the database.
When the application detects that an upgrade is available, it performs a database query to retrieve the zipped deployment files onto the workstation, and then unzips them and performs the install. This can be a very powerful solution for PB application deployment, especially when combined with the previous tip on detecting version inconsistencies.
The PBDJ article can be found by contacting Sys-Con Publishing, at http://www.sys-con.c. The source code for this solution is also available on the accompanying CD.