Regeneration of objects (recompiling the binary portion of the objects, including reinitialization of pointers to other objects) is key to making sure that PowerBuilder behaves properly. However, the sequence in which objects are regenerated is also critical. When encountering problems, regeneration of individuals objects should be avoided. To be the absolute safest, only the standard Full Rebuild should be used (Library Painter / Design / Full Rebuild or the Target context menu in the System Tree). In fact, it has been observed that there have been cases where multiple consecutive regenerations may be beneficial. The logic to this is somewhat elusive, but it’s hard to argue with success.
Occasionally, source gets loaded into a PBL (typically on a failed import), but is dissociated from a library entry. In these cases, PowerBuilder will pick up on these objects and use them, even though you can’t see them. The way to ensure you don’t have any of these problems, and to get rid of them if you do, is to optimize all your PBLs.
The real purpose of optimization is to defragment the space allocation of objects PBL, similar to the defragmenting files on a disk drive, and to reduce the size of a PBL if there is unused space in it. However, this is extraneous to the troubleshooting purpose of optimization.
There are times when duplicate objects (same object name and type, different PBLs along the library path) are there by design, but most times they are there by accident, and cause problems. Problems will arise when different developers use different library paths, and PowerBuilder picks up different versions of the object on each workstation (PowerBuilder picks up the first version it finds in the library path).
You can identify this problem in PowerBuilder by doing a Full Rebuild with the Information messages option checked. When you do, duplicate objects will show up with messages like:
pbl_name.pbl(object_name).1: Information C0146: The identifier 'object_name' conflicts with an existing global variable with this name. The new definition of 'object_name' will take precedence and the prior value will be ignored until this version of 'object_name' goes out of scope
However, this will only identify one of the two duplicate objects. PBL Peeper’s Object page will let you identify both sides of the duplicates quickly (through the View / Show... / Duplicates).
The key to isolation of a problem is being able to reproduce it. Sometimes this is painfully simple. Others it is painfully difficult. However, unless you can at least describe on a minute, technical level what is happening when the application or PowerBuilder blows up, you’re not likely to get too much more than sympathy from anyone else. Reproduction may be dependent on a single user’s unique interaction style with the application (e.g. constantly switching back and forth between yours and other applications). Reproduction may be dependent on identifying influencing environmental factors, like system resource availability (Symantec’s Norton Utilities provides a tool called System Doctor that is excellent for identifying environmental problems like this).
After you’ve identified a means of reproducing the problem with your application, it may be beneficial to create an isolated reproduction of this problem. The first thing this does is allow an opportunity to validate your hypothesis on what is causing the problem. The second thing this does is allow someone else to view this problem outside of the context of your environment. If you eventually get to the stage of reporting this to Sybase, they won’t want to receive 250MB of code and 7G of database. They’ll want to receive as small a sample as possible.