07 Dec 1997

& Other PESTs*

What's Here

We have thrown away our old bug reports from V4 and V5 which used to be on this page. PowerDesigner has so many old bugs fixed and and new bugs added that we can't keep track.

* PESTs, as you may know, are Poor Execution Showing Through - aka "undocumented features", "unintended consequences", etc. These are typically things which Sybase will not acknowledge as broken but which consistently cause confusion and frustration among users.

Although PowerDesigner provides the best looking data models we've ever seen, and in spite of its superior list of features in every category, this is a frustrating and disappointing product to use. It is buggy! Not just Microsoft buggy; PowerDesigner is disgustingly sloppy in design and coding quality. We have used it extensively for five years, at times to the exclusion of other tools. We love the creative flexibility and speed of work. Yet we cannot reliably and repeatably generate a complex physical model from a conceptual.

Don't Blame AIS!

Our purpose is to share among users of PowerDesigner (ex PowerDesigner) information about critical bugs and quirks which have been noticed so that we don't all need to duplicate the often painful process of discovery.

See also

PowerDesigner Users' Resources

PowerDesigner Review

DataArchitect

Merge, Fold, Unify Foreign Keys

The terms Merge, Fold, and Unify appear nowhere in PowerDesigner help in the context of foreign keys. Yet these are three names for a common and classic function: the collapsing of two (or more) foreign key columns into one so that they reference the same parent key instance.

Take a look at this grossly simplified CDM. The important aspects are the symmetrical dependent relationships from Airline to its children and the many-to-many between the children.

This causes a dual inheritance of the key of Airline into the resulting association table in the PDM.

Notice that I have renamed the two Airline FKs to make their inheritance more evident.
Now the question is: do I want to merge (or fold or unify) the columns Airline_Of_Pilot with Airline_Of_Flight so that only one value is stored and thus United Airlines only allows its own pilots to work its flights? If that is the business rule and the desired solution, then here's how to do it.

Now comes the scary part. Delete the selected column with the Delete button. Because this is a foreign key column, PowerDesigner will invoke this dialog:

Don't make the mistake of choosing No because the column will be deleted and there is no Undo other than to abandon your PDM without saving. Even if you regenerate the PDM from the CDM, this column will never reappear because your Delete action is stored in the PDM and played back when you regenerate.

If you choose Yes (which you should), then you will see this:

You must choose the column into which you intend to merge the one which you are deleting. Choose wisely, for there is again no Undo.

After you OK out of the several levels of windows, this is how the diagram looks:

Now both references from the child table include the term Airline = Airline_Of_Pilot. One Foreign key column in the child table maintains referential integrity to two parent keys.

Of course I could rename the FK column to something more appropriate, but that's beside the point.

This is what is variously known as merging or folding or unifying foreign keys. Many products do it better: ER/Studio and ERwin use the IDEF1X standard dialog approach. Silverrun uses drag-and-drop on the diagram. System Architect has another approach. Only PowerDesigner makes this so hard that even Sybase doesn't know how to do it.

"Add" from a List

PowerDesigner, at V6.0, is in the midst of converting from one Add presentation to another. The original format below allows clicking anywhere on the desired line to select that instance.

This new format, which appears in some, but not all Add lists, operates quite like Microsoft Excel in that it requires you to click in the leftmost column of gray buttons to select a line for adding.

Copy/Paste ~ Duplicate ~ Synonym

Copy is not a method for moving or representing any object in a PowerDesigner model to another location. In a nutshell, don't ever Copy / Paste within a model!

Duplicate is similar to Copy / Paste. The difference is that Duplicate will only create new entities and identifying attributes (and their underlying data items), but not all attributes / data items and no domains. This may have some usefulness if you create an entity like this and want to Duplicate it into a dozen lookups, then change each entity name and identifier name. But I don't recommend that method. There are better ways to propagate a set of shared attributes (think inheritance).

A PowerDesigner Synonym is a very simple and powerful concept: another picture of the same object within the same diagram. Each picture is always identical in content because they are pictures of the same thing. You can draw relationships to any Synonym and move them to another Synonym of the same entity with absolutely no effect on the semantics of the relationship. And if you delete all Synonyms, all relationships instantly reconnect to the remaining symbol for that entity. Nifty and useful.

Check Parameters

• There is no datatype validation for min-max or list of values
• The list of values is not checked against the min-max range
• Unit, Format, Lowercase, Uppercase don't do anything

Generate Physical Model

What do the radio button choices mean? Why do I say "sometimes" pops up? Let's investigate.

First, as Peter Jessup pointed out to me, you will only get this dialog if MetaWorks is installed. In PowerDesigner V5. a limited version of MetaWorks used to be included with each modeling module (i.e., ProcessAnalyst, DataArchtitect, AppModeler). Apparently that is no longer true; now you must purchase MetaWorks separately for each licensed seat. So if you don't have MetaWorks, skip the rest of this section.

This simple dialog box hides the complex and messy issue of renumbered object IDs which is discussed below under MetaWorks. Rather than rearchitect the entire product, Sybase has injected this (apparently) undocumented workaround. The intent is to prompt you to consolidate your CDM into MetaWorks before generating a PDM if the CDM contains new objects. That's the meaning of the upper, default radio button. This only matters if you intend to use MetaWorks with this model.

The logic is that every time you add a new object, it must acquire a stable, permanent Object ID (OID) from the global MetaWorks repository before you generate a PDM. Thus your PDM will contain the correct, permanent reference in each Source Object ID (SOID) to the CDM source objects. This may make more sense if you have read the section below on renumbered OIDs. Then again, it may not.

Are you confused yet? Well, if not, read on.

Since everything in PowerDesigner is an object and gets a unique OID, if you add so much as one attribute to your CDM and then Generate Physical Model, this dialog ought to prompt consistently. But it doesn't. Our observation (in several class settings with many students) is that you may or may not receive this dialog before generating a PDM - seemingly always for entities and relationships; sometimes for attributes (which create underlying data items) and other objects.

Furthermore, if you repeatedly consolidate and then generate a PDM, you may easily end up in the situation with multiple PDMs open at the same time - the prior one and the current. This is a very old bug which can cause great dismay if you get confused and start modifying the wrong (obsolete) PDM. Now which one do you save?

Generate Physical Model from a Submodel

Here is a snippet of our standard classroom model showing the entities Flight and Flight Segment inheriting identifiers through the hierarchy.

Below is the result generated into a physical model:




Now we'll make a CDM submodel with just two entities:

- and then generate just the submodel into a PDM:



We may not expect the result:



Notice that the column Airline_Code has disappeared as a <pk,fk> in both Flight and Flight_Segment. Furthermore, Flight_Type is also missing as <fk> in the Flight table.

In other words, PowerDesigner only generated from the CDM exactly what was included in the submodel - WYSIWYG - and relationships not shown are ignored. Is this what you want? Be warned.

Trigger Options and Trigger Generation

All this relates to the obscure radio button settings on the Options tab of the PDM menu Database / Generate Database (also now found on a separate menu item at Database / Generation Options and again as an Options tab under Database / Generate Triggers and Procedures).

These "Options" are actually persistent preferences. They effect the way your trigger editor window works. If an Option is set for Declarative, then the associated trigger type will not be marked to Generate in the trigger window. Thus you are forced to make the trigger User defined. But if you set the Option to Trigger, then you will see the associated triggers marked in the trigger editor as on for generation. Weird!

See also Triggers

All Models

Protect Symbols

But it is not security. anyone can execute Arrange / Unprotect Symbols to remove protection from every protected symbol in the model.

Arrange / Disposition / Arrange Connectors

Arrange / Disposition / Arrange Connectors will center the end points (i.e. "attach points") and remove any bend points or elbows in the body of the relationship. This will cause multiple relationships (or other connector lines) between the same pair of objects to be stacked - with no visual clue. Relationships are often "lost" this way. They're actually just hidden one behind another. This command is equivalent to using the tool bar icons for vertical or horizontal centering on a set of connecting lines (e.g., relationships).

Arrange / Disposition / Arrange Attach Points will only center the end points. If you have used the non-automatic elbow line style (i.e. allowing straight diagonal lines) and you have placed any intermediate bend points, then multiple lines connecting the same objects will be neatly centered but will not collapse on top of each other. This command has no tool bar shortcut icon.

Format Line Style: Setting the Line Style for Relationships & References

The bottom choice (highlighted) forces lines to follow horizontal and vertical pathways, with rounded elbows or bend points at corners. When you move such a line it will find a new horizontal and vertical position automatically. This is the installed default.

The next choice up from the bottom is the same except that line corners are square instead of rounded.

The lightning bolt on the Format / Line Style sub-menu is the choice which gives you complete control. It does not insert any automatic elbows into relationships, references, and lines. This setting allows you to place lines at any diagonal. You can also insert and remove bend points manually with Control+Click and position them anywhere.

Now here's the troublesome part: If you have any line type objects selected, these commands set the properties of the selected set. If you have nothing selected, then your choice sets your preference for the creation of all new line type objects. Isn't that obvious?

Creating & Using Report Templates

Who wants to tackle this one? Mike? Tom? Barbara?

MetaWorks

Object ID Renumbering

So far, so good; nothing wrong with that.

In order to allow PowerDesigner to repeatedly generate a new PDM on top of the old and preserve physical specifications made in the PDM, the program maintains a link between the CDM object and the PDM object (if any) which is generated from it. This is called the Source Object ID or SOID. The SOID is a foreign key in a PDM object which holds the OID of the CDM object from which the PDM object came.

Still with me? No problem yet...

When a CDM is consolidated into MetaWorks, the OIDs assigned in a model may no longer be unique. After all, every CDM numbers its new objects with the same logic and MetaWorks exists to hold any number of models. So a strong probability exists that the original OID will no longer be unique throughout MetaWorks.

Fortunately, the designers of PowerDesigner understood this issue. Unfortunately, they built a lousy solution. Rather than assigning each MetaWorks object a new and separate key for use only within the MetaWorks context, PowerDesigner renumbers every new object consolidated from a CDM. It changes the OID (the primary key) and relinks all foreign key references. Wow! What a lot of hard work to build a broken solution.

Now here's the real problem: When you extract your CDM from MetaWorks (or if you allow it to do so automatically when you consolidate), your CDM OIDs no longer match your PDM SOIDs. The result is that any changes or refinements made in the PDM are lost when you regenerate the PDM. PowerDesigner can't find a new SOID to match the old SOID so it discards the old object, and your work with it.

Is this clear now? I thought not. But it's not your fault or mine.

The net result is a simple ritual: Always consolidate (and extract) before you generate.

Of course this blows away the smooth, dynamic rhythm of model in the CDM, preview and refine in the PDM, and them go back for more modeling in the CDM. This is one of half a dozen reasons why we call MetaWorks - "MetaDon'tWork".

Want more?

If this sort of solid product usage knowledge is vital to your organization's productivity, you might like to contact us about a custom, on-site training program for PowerDesigner and enterprise systems modeling.

Copyright © 1997 Applied Information Science