ForeignKey Relationships & DDL Reverse Enginee

[ola_strandberg]

I have been told that these problems will be fixed in build 654. The support guys have been really responsive.

Will post again when I'm happy ;-)

/Ola

[ola_strandberg]

OK, so build 654 is here...

I have not reverted to 651 again, which is as good a sign as any.

Most of the problems that I have experienced have been solved. The problem that remains is that if the tables have been moved into packages and you reverse engineer a new table into the model, the foreign key association is still not picked up. If all tables reside in the same package as the diagram all seems to work.

There is also an issue of some diagram elements being orphaned in this process (Tools | Data Management | Data Integrity)

I have sent proper scripts to reproduce to Sparx Support about both issues.

/Ola

[CJ]

G'day Ola,

Thanks for the info.

How do you handle the problem with tables moved into packages?

We've left all reverse-engineered tables in an "Import" package, and create, in another package, a diagram for each group of tables that fit a view of the data model.

[ola_strandberg]

Hi Jason,
that's exactly what we have done. The tables are all in the same package together with a diagram called "All Tables", which we use for reverse engineering.

We then, like you, have separate packages with diagrams of related functionality.

I haven't received any comment from Sparx regarding placing tables in packages, i.e. if this is intended to work or not.

I am a little miffed here: I received an e-mail response to my initial bug report saying that it would be fixed in 652/653. 653 contained the new bugs with lost realization links for which a fix was promised in 654. However, reading the release notes for 652/653/654 I can't find an official statement that they have been fixed. Does this mean that they are not officially fixed? Or, are these problems included in "Fixed problem with..."-like statements?  

Sparx: Any chance of providing finer granularity release notes? E.g. assign bugs an id (and communicate this id to the reporter) and then referring to the id in the notes.

Regards,
Ola