Hi, Matt,
Thanks for responding. The reason I am trying to use the Excel import is two-fold: first, we're trying to create a streamlined process to reverse-engineer existing databases, and we believe that separating the extraction of metadata from the import process itself (via standardized queries to the data dictionary) will allow us to lower the barriers of participation, rather than having to train everybody on how to use Power-Designer to reverse-engineer their database.
Second, and more importantly, it is our experience that in practice, the built-in DBMS Reverse Engineering mechanism in PowerDesigner is flakey, buggy, and not very reliable. For instance, in Oracle tables that have interval partitions, the process takes much too long, and sometimes fails altogether by attempting to retrieve every single partition instance rather than the metadata to describe the intervals. When this happens, being an all-or-nothing affair, the process needs to be re-started and there is no real way to work around it.
Using the Excel Import extension, we hoped to control precisely the objects to be imported.
All that said, I understand that the Excel import is using purely name matching, but as I described in my previous posts, there seem to be some rather naïve assumptions made on references; namely expecting that the FK is associated specifically with the PK (not AK), and that both parent and child share the same name.
Is there a way to correct this, or am I doing something wrong?
Regards,
- j.