Applications may end with no notification, or it may produce a Fatal Error or Dr. Watson message. In both cases, they don’t manage to complete the SystemError event, making diagnosis difficult. In fact, the information from Windows logging tools like Dr. Watson is seldom useful. The key piece of information you need is what the last line of PowerScript that was executed before the application terminated. Most times, this is the piece of information that leads to identifying the problem.
The first tendency would be to use the debugger to identify this. Unfortunately, by its nature, the debugger is intrusive, introducing events into the flow that wouldn’t normally occur (e.g. LoseFocus every time the debugger gets focus). The debugger may or may not be successful in identifying the problem.
The tool needed is best if it’s nonintrusive. The tool that PowerBuilder supplies is the PBDEBUG trace. For each line of PowerScript that is executed, a trace file is opened, the reference to the line is recorded, and the trace file is closed. Because of this constant closing of the file after every line, when the application blows up, you’re assured that the last line of PowerScript executed is recorded as the last line in the trace file. However, the big downside of the PBDEBUG trace is that the constant opening and closing of a file, performance expensive operations, slows execution of the application significantly.
The experienced PowerBuilder developer may think that a profiling trace may do the job better, since it has almost no performance impact on the application that is running. However, one problem with profiling traces is that, if the file is not closed correctly, PowerBuilder cannot read the trace. Therefore, profiling traces are not suitable for this task.
PBDEBUG tracing can be turned on:
- in the System Options dialog in PB7 or greater
- in the PB.INI file in PB6 or earlier (see the ReadMe.txt)
- with a /PBDEBUG command line parameter for any PowerBuilder generated executable
When generating a PBDEBUG trace file out of the PowerBuilder IDE, it is pretty straightforward to control where the trace file is written to. When generating from the PowerBuilder generated executable, the location of the trace file is not controllable, and is always placed in the same directory as the executable. Because of the performance hit of constantly opening and closing the file, you want to do everything possible to have the trace file generated on as fast of a hard drive as possible.
The generated trace file is a text file, primarily listing script names and line numbers. Assuming you have a text editor that can read as big a file as your trace becomes (traces easily reach triple digits in megabytes) without crashing your system, in theory that’s all you need. However, PBL Peeper’s trace viewer can add to your trace viewing by minimizing the memory requirement for reading big trace files, viewing source beside your trace, identifying context more easily, and making searching more simple. To quickly move to the last line in the trace, use the View / Last menu or toolbar item.
For better or worse, all Windows applications work in a highly interdependent environment. If there’s a bug in software your application is using, it could show up as a crash in your application. The information from the crash may or may not directly point to the supporting software. Among the elements you need to make sure are up to date and working:
- database drivers or database client software
- printer drivers
- display drivers
Often, when running low on memory resources, both Windows and Windows applications will fail in ways that don’t make the problem obvious. What’s worse, typically your application will crash in what appears to be random places, that actually just correspond to the points where resources have run so low that the application will fail. Both your application and other applications can cause a memory or resource shortage that can cause your application to crash. There are many monitors that will warn you when resources are running low, both from Microsoft and from third parties. For years, I’ve been a big fan of permanently running Norton System Doctor, part of Norton Utilities from Symantec, and it’s avoided a lot of problems for me. If you’ve got an NT variation (NT4, W2K, XP), you should be able to use PerfMon.
One resource that often runs out, particularly in Win9x operating systems, is Graphic Device Interface resources, or GDI. No matter how much memory is installed in the system, Windows maintains a fixed size heap for GDI and User Resources. The more controls and windows that get instantiated, the more GDI handles that get used. The exception is the DataWindow: no matter how many controls you put on the DataWindow, it will only use two handles.
Termination can be frustrating, as it is hard to troubleshoot and often happens at a time when delays cause tension. Other suggestions throughout the Troubleshooting Guide are applicable in this situation, especially things like optimization, regeneration and checking PowerBuilder configuration. The following are some things to try.
Watch the microhelp line for clues. Sometimes the last message will indicate the last object it was trying to regenerate. The problem may lie with this object, or sometimes with an object that it references. Eliminating this or referenced objects may be able to provide a successful build. While this in itself is probably not useful, it narrows the scope of your problem significantly.
Rebuild the PBLs. Sometimes it’s just easier to create PBLs from scratch and start over again, if the problem turns out to be something corrupted in the PBL. However, this isn’t easy to do with the PowerBuilder IDE, since it’s hard to import objects that have references to other objects that may not be imported yet. Sybase has an ORCA algorithm that is supposed to handle this, and PBL Peeper implements this algorithm, but for the last couple of versions of PowerBuilder I’ve found there are problems with this algorithm, and have had problems implementing it. PowerBuilder 9 and forward have ORCAScript, which has a command to build PBLs from scratch, scc refresh target, intended to support SCC, but I’m told that it will work outside of the context of SCC. The method I have used (quite extensively in PowerBuilder 6, when I’d get problems like these on quite a regular basis) is the bootstrap functionality of PowerGen. It provides a quite reliable method for rebuilding PBLs which I have found to be much less memory intensive than the methods provided by PowerBuilder.
Build with alternative tools. Another tool to build with is no guaratee of success, since all methods are calling the same ORCA function calls that Sybase provides. However, success can be had this way. Working within the PowerBuilder package, PowerBuilder 9 and forward have ORCAScript. There are always third party tools that come and go that provide build functionality, but the one that has been around the longest and has worked well for me consistently is PowerGen.
Another issue that has often cropped up since PowerBuilder 7 is a problem with painter layouts. These layouts are stored in the registry. If a layout is corrupted when stored, then PowerBuilder will fall over itself when trying to open up that painter and tries to restore the layout. To have PowerBuilder revert back to “factory settings” for the layouts, delete the appropriate entry under HKEY_CURRENT_USER\Software\Sybase\PowerBuilder\x.0\Layout\Default, where x is the PowerBuilder version number.