EA16.1 (1628) DB RetroEngineering gives an error

[Typia]

Hi guys,
when I try to make a retro engineering for an ODBC based connection, when comes the moment to import tables into the packages I have this error



Moreover, there a few bugs in this interface, for example when I tick a schema it brings me all the tables from all schemas.
is there a support team reachable for those kind of issues ?

Many thanks

[Geert Bellekens]

You probably want to delete the constraint operation that it is trying to create, and then try again.

You can send a bug report to Sparx support: https://sparxsystems.com/support/forms/bug_report.html

Geert

[Modesto Vega]

What type of database are you trying to reverse engineer (SQL Server, PostgreSQL)?

Does Sparx EA reverse engineer anything before getting to that point?

Is it giving you any indications of whether it is failing to read the constraint of failing to write its representation to the model?

[Typia]

Thanks a lot for your replies

You probably want to delete the constraint operation that it is trying to create, and then try again.

You can send a bug report to Sparx support: https://sparxsystems.com/support/forms/bug_report.html

Geert

Hi Geert
Maybe I didn't get your point but I'd rather not touch to the data structure I try to retromodel.
Regarding the bugs I come across there's a lot (mainly on interface)

What type of database are you trying to reverse engineer (SQL Server, PostgreSQL)?

Does Sparx EA reverse engineer anything before getting to that point?

Is it giving you any indications of whether it is failing to read the constraint of failing to write its representation to the model?

Hi Modesto

It's failing to write in the model. Everything is ok until it tries to add the tables to the model. Seems like there's a unique constraint in the model (we use qea), I tried on EAP which gives me the same kind of error but in French.
I'm not a DB Admin but seems like the EA DB structure can't handle the way our database is designed.
EA points to a solution which is to redesign the index of t_operationparams to allow duplicate values but don't know if it's impacting.

here are the screens

[Modesto Vega]

t_operationparams has a a primary key/unique constraint on OperationID and Name.

Name is the name of the column involved in the operation, it is worth checking if for some weird reason there are constraints with the same column included twice.

Also, are you reverse engineering from scratch or refreshing a model? If refreshing a model, there are is an option on the reverse engineering screen to update the existing model. 

[Geert Bellekens]

Thanks a lot for your replies

You probably want to delete the constraint operation that it is trying to create, and then try again.

You can send a bug report to Sparx support: https://sparxsystems.com/support/forms/bug_report.html

Geert

Hi Geert
Maybe I didn't get your point but I'd rather not touch to the data structure I try to retromodel.
Regarding the bugs I come across there's a lot (mainly on interface)

I meant deleting the constraint in your model (assuming you are reverse engineering over an existing model)
If not then I would check the constraint in the database as Modesta Vega suggested.
There might be something weird going on why you get the error on this particular constraint.

Geert

[Typia]

Thanks a lot.

Also, are you reverse engineering from scratch or refreshing a model? If refreshing a model, there are is an option on the reverse engineering screen to update the existing model. 

I meant deleting the constraint in your model (assuming you are reverse engineering over an existing model)
If not then I would check the constraint in the database as Modesta Vega suggested.
There might be something weird going on why you get the error on this particular constraint.

Geert

This is a import from scratch.
I also tried an import with only tables list (no FK, no PK, no Index) and it's ok.
Once I add PK, FK or Index it fails.
As said before, i'm just supporting the retro and can't mess with the data structure as it is.
I'm gonna submit a ticket to support.
Many thanks.

[Modesto Vega]

Have you tried importing everything except for foreign keys? You might even be able to exclude just the offending FK.

I have seen that error before and I am trying to find out if I have any notes on what cause it and how it got fixed.

[Typia]

Have you tried importing everything except for foreign keys? You might even be able to exclude just the offending FK.

I have seen that error before and I am trying to find out if I have any notes on what cause it and how it got fixed.

As long as I'm trying to import either FK / PK / Constraints it blocks.

Seems like EA itself doesn't allow duplicate in its own structure.
Weird thing is that I managed to do the exact same retro 3 years ago and don't remember having suffered a lot like this.

I tried the retro within qea, eap and SQL based repo.
I have different formulations for the error message but still point the same thing regarding an which can't be duplicated in operationparams

[Geert Bellekens]

I'm pretty sure there is something unusual with the one contraint it is trying to import.

Can you try to delete the constraint and then see what happens?

You an also report this as a bug, but that will not solve your problem today.

Geert

[Paolo F Cantoni]

By now, I would have confirmed that the problem exists in v17.0 or v17.1.

Just a thought,
Paolo

(Experience has shown that to get any traction on a defect, it must be present in the latest version)

[Typia]

By now, I would have confirmed that the problem exists in v17.0 or v17.1.

Just a thought,
Paolo

(Experience has shown that to get any traction on a defect, it must be present in the latest version)

Thanks,
I'm still progessing on that.
Problem still exists on 17.1

Screenshots i sent were with DB2 Odbc Driver v10.5
When I try with Driver v 11.5 I have this error message. Is there any way to have a more verbose message ? Obviously this is ok while testing the connection in ODBC panel



Many thanks