Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on May 28, 2018, 02:55:51 pm
-
One of our users is trying to reverse engineer an Oracle DB.
We're usually a SQL Server shop, so I haven't done one of these for ages. Using b1351, he seems to be doing all the right things on the Import from ODBC dialog. Are there any "gotchas", "secret sauces" that we should be using?
The result is that after asking it to reverse engineer everything, for the tables, we get the table objects, no features or relationships - just empty boxes...
TIA,
Paolo
-
Done a couple of oracle databases and never been able to get the relationships either. Fortunately the primary keys and foreign keys where named consistently that i wrote a script to create the relationships. Not ideal but i ended up with the desired result.
-
Are you using legacy reverse engineering? Have you tried Database Builder?
-
Make sure the ODBC driver is the Oracle driver and not the "Microsoft ODBC for Oracle" driver.
-
Are you using legacy reverse engineering? Have you tried Database Builder?
Yes (I think so), I'll give it a go!
Paolo
[EDIT: I tried it, but it seems to me that the import DB Schema is the SAME dialog as the non-Database Builder route. I tried an SQL Server DB (as my user isn't in yet) and both routes worked fine.]
-
Make sure the ODBC driver is the Oracle driver and not the "Microsoft ODBC for Oracle" driver.
Will do, when I get in to work.
I should get both the columns AND the FK relationship, yes?
Paolo
-
Make sure the ODBC driver is the Oracle driver and not the "Microsoft ODBC for Oracle" driver.
Will do, when I get in to work.
I should get both the columns AND the FK relationship, yes?
Paolo
It's been a few years since I reverse engineered an Oracle DB but I remember getting everything.
-
A combination of V14 and the DB Builder (we were using the Oracle ODBC drive - 11.0.2.1) did it.
We imported 2355 tables, 159 views etc... However, we got a Resources Exceeded message and thought it might have damaged the FK Constraint import. But it seems that this product hasn't got any FK Constraints!
Paolo
-
But it seems that this product hasn't got any FK Constraints!
Who in his right mind would design a database without FK constraints! :o
Ohh, um, ... nevermind... :-X
Geert
-
I'm not an Oracle expert but any RDBMS should spit out the schema DDL code as a text file on request. Then just run the DDL in EA to recreate the schema as a physical data model?
-
Why do it the simple way if you can go through a variety of ODBC and native drivers instead?
q.
-
I'm not an Oracle expert but any RDBMS should spit out the schema DDL code as a text file on request. Then just run the DDL in EA to recreate the schema as a physical data model?
Interesting I didn't know you could run DDL in EA to recreate the schema. I've search the help and can't find anything on that particular feature. Care to share a reference on how to access it?
-
Why do it the simple way if you can go through a variety of ODBC and native drivers instead?
q.
Probably because the help tells you to use ODBC drivers. Haven't found out how to run DDL in EA yet though. Still searching in the online help for that feature.
https://www.sparxsystems.com/downloads/resources/booklets/uml_code_engineering.pdf (https://www.sparxsystems.com/downloads/resources/booklets/uml_code_engineering.pdf)
-
EA can't reverse engineer a DB schema from a sql file.
-
Yes, I know that EA can't RE a DDL. Unfortunately there's no emphasis for irony/sarcasm in texts.
q.
-
We discussed that in the past.
The advantage of using ODBC is that it gets you a standardized interface for any database (given the ODBC driver is implemented correctly).
So in this case EA doesn't have to worry about the actual database type, as long as it conforms to the ODBC standard it can be imported.
Now in theory that should also work for importing DDL,'s since SQL is in fact an ANSI standard.
Unfortunately that doesn't work in the real world as each database vendor has invented his own SQL dialect.
So if EA was to implement such a feature it should cater for each and every different SQL dialect out there.
I too would like a DDL import feature, but I can understand why Sparx choose the ODBC option. I would probably do the same if I was in their shoes.
Geert
PS. For a client who needed to RE a DB2 database from the mainframe we have build our own DDL parser to correct the part that was imported via ODBC
-
Yes, I know that EA can't RE a DDL. Unfortunately there's no emphasis for irony/sarcasm in texts.
q.
I didn't know that! Not even the higher cost versions? Don't open source tools like MySQLWorkbench do that already? Me sees a feature request lurking somewhere......
-
EA can' parse DDL. Since it internally seems to have a SQL parser (the SQL you send from EA to a DB are mangled in the one or other way) there should be ways to get EA eating a DDL. However, times for seeing feature requests being implemented are no longer in the range of a couple of weeks.
q.
-
EA can' parse DDL. Since it internally seems to have a SQL parser (the SQL you send from EA to a DB are mangled in the one or other way) there should be ways to get EA eating a DDL. However, times for seeing feature requests being implemented are no longer in the range of a couple of weeks.
I think that this sort of functionality would be best community produced. Sparx should be responsible for the parser and documentation about it and the community could craft for the particular database technology.
-
Yes qwerty, I understood your sarcasm. Unfortunately, not everyone in the thread seemed to realise.
-
Doh :-[
q.
-
Yes, I know that EA can't RE a DDL. Unfortunately there's no emphasis for irony/sarcasm in texts.
q.
Mmmh really? No smiley or emojicon then for sarcasm :o
-
Actually I can't interpret any of them as "sarcastic intention". :o is shocked (as you can also read from the hovered note).
q.