Nor is the purpose of this page to tear down or criticize what we believe
to be an excellent product from a very responsive vendor. Its purpose is
merely to share among users of PowerDesigner information about critical
bugs which have been identified and properly reported to Powersoft so that
we don't need to duplicate the often painful process of discovery.
- Our report #023: Sub-model relationship displays may not update correctly.
If a relationship is changed from dependent to non-dependent (or visa-versa)
in one sub-model, or if one end of a relationship is dragged into another
entity, this relationship may not be displayed with properly updated symbols
in other sub-models. The following picture was captured from an anctual
session with two sub-models visible:
Powersoft
#277192 22 Dec 1995
- Our report #022: When you execute Generate Physical Model from
within a sub-model, you receive the dialog box to choose whether to generate
the one sub-model or the entire model. If you choose to generate only for
the current sub-model, PowerDesigner will not take into account entities
which are related but not included in the sub-model.
I have not found this fact discussed in the manual (page 163-167) or
on-line help. In fact both state that a designer can generate a sub-model
to represent a work area, implying that this will be complete. Therefore
when generating only a sub-model, foreign keys from entities which are
not in the sub-model will not be propagated, even if those foreign keys
are dependent and thus also primary keys. This means that a sub-model
PDM has a high likelihood of being substantially inaccurate.
Powersoft
#277187 22 Dec 1995
- Our report #021: PowerDesigner may discard unsaved changes
on closing a model. Close any model without saving and then answer "Yes"
to the Confirmation dialog "Do you want to save current changes?
". When the file location window ("Choose the Name of the Model
to be Saved") appears, press "Cancel". Rather than
returning you to your unsaved model, PowerDesigner will close the model
without saving. This is contrary to users' expectations and general Windows
standards.
Powersoft
#277184 22 Dec 1995 "This issue has been duplicated and has been
forwarded to Development for further evaluation. "
- Our report #020: If you rename a sub-model (CDM or PDM) in the sub-model
list, the Windows title bar does not change until you open the Dictionary/Define
Model dialog.
- The manual states specifically on page 368 that the CDM entity Index
Threshold will be ignored when using the PDM Rebuild Indexes
option and we confirm this behavior, puzzling though it may be.
However, the Index Threshold seems to also be ignored in Generate
Physical Model from the CDM. Regardless of the values entered for Number,
all FK indexes are created (or not created - see below) without
regard to the threshold.
- Check Parameters: Generating the PDM is inconsistent and erroneous
in inheriting MINIMUM, MAXIMUM, DEFAULT, and UPPERCASE|LOWERCASE values
from CDM attributes' Check Parameters into the PDM columns'
Check Parameters. We have experienced the disapperance of MINIMUM,
MAXIMUM, DEFAULT, and UPPER|LOWER CASE as well as the generation of the
wrong list of values.
Powersoft
#261088: "It is part of the bugs we want to correct for 5.0 "
08 Dec 1995
- Generate PDM does not update the PK index on a table to reflect
changes to the CDM identifier. Create a new CDM with one entity with any
two attributes. Mark the 1st attribute as "identifier". Generate
the PDM (any database). Check the PK index on the resulting table and observe
that it is built correctly over only the 1st column.
Now return to the CDM. Remove the "identifier" check from
the 1st attribute and mark the 2nd attribute as "identifier".
Regenerate the PDM (any database). Check the PK index on the resulting
table. Notice that the 1st column incorrectly remains in the PK index along
with the correct 2nd column.
When identifiers are changed in the CDM, Generate PDM does not remove
from the PDM PK index those columns which had previously been PK. The regenerated
PK index will contain the original PK column(s) plus the new PK column(s).
The PDM Rebuild Indexes option will correct this. Thus we conclude that
the logic used to build indexes differs between the Rebuild Indexes option
and the Generate PDM option.
Powersoft
Assigned tracking #260244 on 24 Nov 1995
- Our report #012: If you add an index manually in the PDM both Rebuild
Indexes and Generate Physical Model will reflect an incomplete
set of PK, FK, and manual indexes.
Generate Physical Model from the CDM will leave the user-created
index intact and in the order of its creation in the list of indexes. However
the PDM Rebuild Indexes option is broken. It will create user defined
indexes first, then PK indexes, and finally some but not all of
the FK indexes.
Powersoft
Assigned tracking #260237 on 24 Nov 1995
- Regenerating a CDM into the PDM will override any data length changes
made in the PDM.
Powersoft
Assigned tracking # 260224 on 24 Nov 1995. Internal Powersoft documents
acknowledge this "feature" without explanation.
- Our report #016: The CDM relationship description does not carry down
to the PDM reference description.
Create any simple CDM with two entities and one relationship. Enter
any text in the relationship Describe window. Generate Physical
Model and observe that there is no text in the PDM Reference/Describe
window. While this may be a "feature" rather than a bug (in that
the designers may not equate "relationship" to "reference")
it is nonetheless inconsistent with the otherwise uniform inheritance of
the Describe text.
Powersoft
Assigned tracking # 262008 on 27 Nov 1995. Internal Powersoft documents
acknowledge this "feature" without explanation.
- Our report #017: The PDM reference gets its name and code from the
lower of the two CDM relationship labels - an apparent total miscode!
Create any simple CDM with two entities and one relationship. Enter
some distinctive text in each of relationship Name, Code,
upper and lower Label fields. Generate Physical Model and
observe that the PDM Reference Name has taken its text from the
lower CDM relationship label.
- Our report #018: After reverse engineering via ODBC, some foreign keys
are incorrectly referenced in their join expressions. In our test, we constructed
a table with a three-column primary key, then joined it with two separate
references into a second table (i.e., flight to airport of departure, airport
of arrival). We generated the database via ODBC into Watcom 4.0c. On reversing,
one FK join expression contained one column and the other contained
five columns! When we did the same steps via SQL scripts, the join
expressions were reversed correctly with three columns each.
#265351 08 Dec 1995
- Our report #019: Trigger Templates option for Current Model
appears not to be working. In the Trigger Templates dialog window
(Dictionary/Triggers and Procedures/Trigger Templates) when I modify a
template with Current Model selected and then OK and save the model,
the Current Model setting appears to be forgotten in that when I
next enter that template it is set to All Models.
- All changes in the PDM must be preserved through subsequent
generations from the CDM! Or else clarify if the design intent is different.
Some examples follow:
Powersoft:
# 227283. There were several issues combined there, so if you can find
out who the customer was, it would be best if we could talk with them.
Comment:
These situations were encountered and recreated by several users.
- If you create a CDM relationship which is optional and later
change it to mandatory or visa versa, the associated PDM properties
of the relationship are incorrectly and inconsistently generated.
These sequences can lead to dangerously obscure referential integrity
and update behavior flaws.
Powersoft:
# 253124: "It is part of the bugs we want to correct for 5.0 "
08 Dec 1995
- Foreign keys become corrupted if you make adjustments to the PDM
reference. If you delete a PDM reference in the Reference Definition
window and then create a new reference from a column other than the original
foreign key, the new FK column is marked FK but the original FK also retains
that mark as well. The manually marked FK is lost on the next generation
of the PDM from the CDM. In fact, the reference will have no expression!
Powersoft:
Same with item 3. It has tracking # 253127.
- In the PDM you can enter any (possibly illegal) scale and precision
for any data type. One can argue that a designor should not change type,
scale, or precision in the PDM but as long as these facilities are present,
the column editor must evaluate and check such entries.
Powersoft:
Item #4 seems to be designed to work that way, to give you flexibility
beyond what may be acceptable by the .def files, etc, at the time. Again,
if you know who had that issue, we'd be glad to discuss it with them.
Comment:
Flexibility to enter a scale for a boolean type or precision for a character
seems excessive.
- An entity marked not to generate will produce an error during
Check or Generate if that entity does not pass the internal tests (e.g.,
missing attributes or identifier). This prevents you from modeling empty
entity concepts as notes for later implementation.
Powersoft:
Item #5, we'll need to test, and is tracking # 253131.
- If you mark an entity in the CDM not to generate, no table is generated
in the PDM. If there is a reference to the entity, then the child table
in the PDM will hold the migrated foreign keys, even though there is no
parent table. The DDL will correctly not treat those migrated columns as
foreign keys. However, the model diagram and the columns list will incorrectly
and inconsistently show the columsn as "FK". This is onconsistent,
confusing, and indicative of multiple data elements holding the "foreign
key" property of a generated column.
Powersoft:
Item #6 is also best discussed. We'll try it out here, with tracking
# 253132.
- In the PDM the SQL editor will sometimes not list any business
rules, even though some have been defined and applied.
Powersoft:
Item #7 seems to function as designed. We'd need more specifics as to
when the business rules are listed or not. "Sometimes" is a bit
too vague. Probably, the times that they are not listed, there's a good
reason for it.
Comment:
This issue arose in a class with 15 students all working with the same
model on the same machine type. Consistently some could access business
rules in the SQL editor and some could not. That is "sometimes".
- In the PowerDesigner Enterprise version, if you delete an attribute,
reconsolidate, and re-extract, the attribute reappears in its original
entity. Thus there appears to be no way to truely delete an attribute.
Powersoft:
# 253134: "It is part of the bugs we want to correct for 5.0 "
08 Dec 1995
- Page breaks are not calculated correctly in reports. This requires
major manual rework of RTF file reports and disrupts programmed report
manipulation (e.g. in MS Word Basic).
Powersoft:
For item #9, we really need more information. We'd be glad to talk with
whoever has this problem.
Comment:
Referred to the reporting party.
- The Rebuild References option must be carefully protected with
a more explanatory confirmation dialog and removed as a first level menu
option. This option is only suitable to use in reverse engineering. This
option is very damaging if executed in an existing, modified PDM since
it discards all modifications to references (e.g., naming, where clause
order, integrity elections) and also removes references to differently
named columns.
Powersoft:
Finally, item #10 is an enhancement. I entered it in as an enhancement,
with tracking # 253135, and have notified Sean Flynn of it.
- Generating a Uniface CIF file from the PDM 4GL option does not export
Check Parameter DEFAULT values.
Powersoft
Assigned tracking #261093 on 26 Nov 1995
- Generating a Uniface CIF file from the PDM 4GL option incorrectly
exports the Number of rows expected in the table. This is sent to the
CIF file as the maximum permitted occurrences.
Powersoft
Assigned tracking #261097on 26 Nov 1995
- Add Title option will continue to add a title to the current
page as often as you exercise it, even when there is already one (or more)
title on the page.
Powersoft
Assigned tracking # 260219 on 24 Nov 1995
- The PDM does not attach "not null" on Sybase Boolean
(bit) columns. According to the Sybase SQL Server Reverence Manual, Volume
1, page 3-39, "Columns of data type bitcannot be NULL and cannot
have indexes on them."
Powersoft
#260231: Will be included in 5.0 if possible and in 5.1 if not
Bugs