Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Lauchlan_Mackinnon on March 29, 2005, 04:08:45 am
-
Hi
I am a newbie evaluating EA.
I would like to import some databases and look at the structure.
Say I have a SQL Server database server MyServer, with a database MyDataBase.
It's a while since I've mucked around with ODBC - is this the only way to access it? Or can I construct some sort of ADO connection string instead? Is there a wizard for it? I'd really just like a good wizard to construct the ADO connection string for me, or let me cut and paste one in myself.
If I *have* to use ODBC, how do I set it up? I can set up an ODBC connection to the server, where should I specify which database?
Also, I often use another database, for Delphi, called NexusDB. How should I connect to NexusDB databases with EA?
Thanks in advance.
Lauchlan Mackinnon
-
Lauchlan,
you can only import DDL from ODBC-ready databases. Setting up ODBC via Windows utilities should be obvious. You define an ODBC data source in system or user environment and point it via the appropriate driver to the desired database. Now you move to EA, select a package, create/open a class diagram inside, right click the package, Code Engineering/Import DDL..., press the ellipsis button, chose the previously defines source and off you go.
-
Lauchlan,
you can only import DDL from ODBC-ready databases. Setting up ODBC via Windows utilities should be obvious. You define an ODBC data source in system or user environment and point it via the appropriate driver to the desired database. Now you move to EA, select a package, create/open a class diagram inside, right click the package, Code Engineering/Import DDL..., press the ellipsis button, chose the previously defines source and off you go.
Apart from telling me that EA's database access is extremely limited (I hope this is going to change in future versions!) this does not tell me much!
For example, "Setting up ODBC via Windows utilities should be obvious. " Microsoft have a lot of technologies and interfaces that should be obvious but aren't. Obviously I can run through the wizard and set up an ODBC connection pointing to the SQL Server server. What is not obvious is how to get it to point to my specific database (within the server) that I want it to import. It won't let me "Attach database filename" - if I give the filename for the database file with or without the extension it rejects it. I can apparently select it as the default database, but I had always thought the "default" should be "Master." This is the point at which I am confused - should I point to my database by "changing" the "default database", or do I do it somewhere else after setting up the ODBC connection, eg somehow configuring which database I want to use when using the ODBC connection to that server in EA?
Lauchlan Mackinnon
-
What is not obvious is how to get it to point to my specific database (within the server) that I want it to import. It won't let me "Attach database filename" - if I give the filename for the database file with or without the extension it rejects it. I can apparently select it as the default database, but I had always thought the "default" should be "Master." This is the point at which I am confused - should I point to my database by "changing" the "default database", or do I do it somewhere else after setting up the ODBC connection, eg somehow configuring which database I want to use when using the ODBC connection to that server in EA?
ok, I just made my database the "default" and it appears to work to the extent that it lists my tables and says it imports them - but then nothing happens in the diagram.
What else would I need to do, to get the diagram populated from the database?
Thx
Lauchlan Mackinnon
-
ODBC is not a Sparx Systems' product, nor is it a Microsoft one, so you are blaming the wrong company really. You may want to read up on ODBC a bit before you start using it.
The options that you can/have to specify when setting up an ODBC connection are driven by the ODBC driver you are using. There is more than one ODBC driver for MS SQL Server (and no, they are not all created by Microsoft) and the ways you specify the default database differ between them. Generally though, if you have the appropriate database privileges, you will be offered list of databases available at the database server instance you are connecting to.
Use the "default" database only if the default database is the one you want to reverse engineer.
Oh, and a "database name" and a "filename" is not the same thing as in the case of MS SQL Server, a database can consist of multiple files, names of which may not have much to do with the name of the database itself.
If you need help with the ODBC or MS SQL Server in general, please let me know.
Hope this helps.
Bruno
Apart from telling me that EA's database access is extremely limited (I hope this is going to change in future versions!) this does not tell me much!
For example, "Setting up ODBC via Windows utilities should be obvious. " Microsoft have a lot of technologies and interfaces that should be obvious but aren't. Obviously I can run through the wizard and set up an ODBC connection pointing to the SQL Server server. What is not obvious is how to get it to point to my specific database (within the server) that I want it to import. It won't let me "Attach database filename" - if I give the filename for the database file with or without the extension it rejects it. I can apparently select it as the default database, but I had always thought the "default" should be "Master." This is the point at which I am confused - should I point to my database by "changing" the "default database", or do I do it somewhere else after setting up the ODBC connection, eg somehow configuring which database I want to use when using the ODBC connection to that server in EA?
Lauchlan Mackinnon
-
Do the tables appear in the Project View?
ok, I just made my database the "default" and it appears to work to the extent that it lists my tables and says it imports them - but then nothing happens in the diagram.
What else would I need to do, to get the diagram populated from the database?
Thx
Lauchlan Mackinnon
-
ODBC is not a Sparx Systems' product, nor is it a Microsoft one, so you are blaming the wrong company really. You may want to read up on ODBC a bit before you start using it.
The options that you can/have to specify when setting up an ODBC connection are driven by the ODBC driver you are using. There is more than one ODBC driver for MS SQL Server (and no, they are not all created by Microsoft) and the ways you specify the default database differ between them. Generally though, if you have the appropriate database privileges, you will be offered list of databases available at the database server instance you are connecting to.
Use the "default" database only if the default database is the one you want to reverse engineer.
Oh, and a "database name" and a "filename" is not the same thing as in the case of MS SQL Server, a database can consist of multiple files, names of which may not have much to do with the name of the database itself.
If you need help with the ODBC or MS SQL Server in general, please let me know.
Hope this helps.
Bruno
Hi Bruno. I do know what ODBC is, and it *is* a MS framework/technology, if not actually a product. For example, picking the first link Google returned, http://www.martinscholl.com/html/databases/odbc_history.html
<<
With the introduction of Open Database Connectivity (ODBC) by Microsoft, a truly portable database API (Applications Programming Interface) became available. ODBC is a function set that provides an interface that is portable to multiple platforms and RDBMSs. A single application can be connected to different database backends with no changes, re-compilation or re-linking required.
>>
And indeed, I have used ODBC extensively in the past, although not for quite some years (I have used ADO or ADO.NET for projects in the last several years).
<<
Use the "default" database only if the default database is the one you want to reverse engineer.
>>
ok. As I posted prior to your post that's what I did and EA *said* it imported the database, but nothing happened on/in the diagram.
<<
Oh, and a "database name" and a "filename" is not the same thing as in the case of MS SQL Server, a database can consist of multiple files, names of which may not have much to do with the name of the database itself.
>>
Well, I tried them both and neither worked.
I generally find MS's technologies to be clunky, poorly documented, and unintuitive. Perhaps this is why I was having issues with ODBC. And in any case I had viewed ODBC as an outadted/outmoded technology. Why not use ADO, if one is going to restrict oneself to MS database connectivity bandwagons?
But in any case, my issue now is not with the ODBC connection. It is with how to get the database table and relation information into the EA diagram. After importing, nothing goes onto the diagram. The log text in the display window tells me everything imported ok, but nothing goes onto the diagram.
-
Do the tables appear in the Project View?
Not that I can see.
Where would they be - under what folder?
I have a package with a diagram under 'Logical View' and I am trying to import into that. I follow the wizard, but after it says imported successfully, nothing happens.
Thx.
Lauchlan Mackinnon
-
I have a package with a diagram under 'Logical View' and I am trying to import into that. I follow the wizard, but after it says imported successfully, nothing happens.
Thx.
Lauchlan Mackinnon
Ah. I figured it out - Mea Culpa!
I looked at the list of tables, and since there were no checkboxes, I had assumed it was going to import them all. It wasn't obvious I had to highlight them. I did select all and now it works fine.
The next questions then are
(i) I am using a 17" monitor, and the diagrams are cluttered, especially compared with the diagrams in SQL Server itself. Can I float the diagram pane out and enlarge it?
(ii) To work with other databases, I have to have an ODBC connection, right? ADO or ADO.NET won't cut it? The reason I ask is that I'd have to pay extra for this with a database I use (NexusDB). It's an add-on extra for systems that use ODBC.
Thanks
Lauchlan Mackinnon
-
Try to do a search (menu Edit > Find) and let's see what comes out.
Not that I can see.
Where would they be - under what folder?
I have a package with a diagram under 'Logical View' and I am trying to import into that. I follow the wizard, but after it says imported successfully, nothing happens.
Thx.
Lauchlan Mackinnon
-
The next questions then are
(i) I am using a 17" monitor, and the diagrams are cluttered, especially compared with the diagrams in SQL Server itself. Can I float the diagram pane out and enlarge it?
(ii) To work with other databases, I have to have an ODBC connection, right? ADO or ADO.NET won't cut it? The reason I ask is that I'd have to pay extra for this with a database I use (NexusDB). It's an add-on extra for systems that use ODBC.
Also,
say I want to remove the tables I just imported. Is there a way to select them all and delete them? EA seems to want me to delete them one at a time, and confirm the deletion of each one. Seems a bit cumbersome - is there a better way?
Lauchlan Mackinnon
-
Oh I know, that actually threw me off the first time, too :-)
I am not quite sure what you mean by floating out the diagram pane (my English still leaves much to be desired, I suppose), but you can zoom in and zoom out on the diagram, as well as auto-layout it (do not expect too much from that though).
As far as NexusDB goes, did you try the NexusDB ODBC Lite? It is free and for purposes of reverse engineering it should be more than enough. It's limitations are in the amount of data it allows you to work with, but that is not relevant for reverse engineering. You can download it from NexusDB site.
Hope this helps!
Bruno
Ah. I figured it out - Mea Culpa!
I looked at the list of tables, and since there were no checkboxes, I had assumed it was going to import them all. It wasn't obvious I had to highlight them. I did select all and now it works fine.
The next questions then are
(i) I am using a 17" monitor, and the diagrams are cluttered, especially compared with the diagrams in SQL Server itself. Can I float the diagram pane out and enlarge it?
(ii) To work with other databases, I have to have an ODBC connection, right? ADO or ADO.NET won't cut it? The reason I ask is that I'd have to pay extra for this with a database I use (NexusDB). It's an add-on extra for systems that use ODBC.
Thanks
Lauchlan Mackinnon
-
A few options here:
1. Delete the package within which your tables reside.
2. Delete the diagram on which you have placed your tables, that makes them "orphans". Go to Edit > Find, check "Find Orphans", select all the results and delete them here.
3. (This should have been the first option, really :-) ): Select all the tables on your diagram and press CTRL + DEL, that deletes all of them from the diagram and the model at the same time.
Hope this helps!
Bruno
Also,
say I want to remove the tables I just imported. Is there a way to select them all and delete them? EA seems to want me to delete them one at a time, and confirm the deletion of each one. Seems a bit cumbersome - is there a better way?
Lauchlan Mackinnon
-
Oh I know, that actually threw me off the first time, too :-)
I am not quite sure what you mean by floating out the diagram pane (my English still leaves much to be desired, I suppose), but you can zoom in and zoom out on the diagram, as well as auto-layout it (do not expect too much from that though).
As far as NexusDB goes, did you try the NexusDB ODBC Lite? It is free and for purposes of reverse engineering it should be more than enough. It's limitations are in the amount of data it allows you to work with, but that is not relevant for reverse engineering. You can download it from NexusDB site.
Hope this helps!
Bruno
Hi Bruno.
By "floating out" I meant grabbing some handle and undocking the pane so it "floated" above the rest of the IDE, and then I would want to maximize that pane window to take the whole screen area. Basically I wanted some way to get the diagram view to (temporarily) take up the entire screen real estate, while I dragged things around.
Thanks for the tip with NexusDB - they brought out quite a few new product versions since I started with them and I guess I wasn't paying attention when they brought out an ODBC Lite version. Sounds like it would meet my needs!
Thanks!
Lauchlan Mackinnon
-
A few options here:
1. Delete the package within which your tables reside.
2. Delete the diagram on which you have placed your tables, that makes them "orphans". Go to Edit > Find, check "Find Orphans", select all the results and delete them here.
3. (This should have been the first option, really :-) ): Select all the tables on your diagram and press CTRL + DEL, that deletes all of them from the diagram and the model at the same time.
Hope this helps!
Bruno
Yep, that did the trick, thanks!
BTW, the couple of requests I had - like putting checkboxes on the list of tables to import; to provide a mechanism from importing from ADO and ADO.NET as well as ODBC, etc - should I log them or lob them to somewhere, or do Sparx monitor this web forum and take prompt and immediate action? <g>
-
Hi Lauchlan,
I see. Well, you can certainly close or hide all the other panes as well as the toolbars, which leaves you for the diagram itself the whole screen minus the title bar... not quite what you want, but as close as it gets!
No problem about NexusDB, as luck would have it I came across the Lite version only yesterday :-)
Happy to help!
Bruno
Hi Bruno.
By "floating out" I meant grabbing some handle and undocking the pane so it "floated" above the rest of the IDE, and then I would want to maximize that pane window to take the whole screen area. Basically I wanted some way to get the diagram view to (temporarily) take up the entire screen real estate, while I dragged things around.
Thanks for the tip with NexusDB - they brought out quite a few new product versions since I started with them and I guess I wasn't paying attention when they brought out an ODBC Lite version. Sounds like it would meet my needs!
Thanks!
Lauchlan Mackinnon
-
You're welcome!
As far as the feature requests go, the best way would probably be going to the Sparx Systems' home page and going to menu Interactive Sparx > Request a Feature.
Sparx (Sparxes?) seem to be reading the forum regularly and frequently answer questions here, but I am not sure if they can keep track of all the requests made here in the forum (just see how this little thread grew in the past half an hour :-) )
Hope this helps!
Bruno
Yep, that did the trick, thanks!
BTW, the couple of requests I had - like putting checkboxes on the list of tables to import; to provide a mechanism from importing from ADO and ADO.NET as well as ODBC, etc - should I log them or lob them to somewhere, or do Sparx monitor this web forum and take prompt and immediate action? <g>
-
"ODBC is based on Call-Level Interface and was defined by the SQL Access Group. Microsoft was one member of the group and was the first company to release a commercial product based on its work (under Microsoft Windows) but ODBC is not a Microsoft standard (as many people believe)."
(http://burks.brighton.ac.uk/burks/foldoc/93/83.htm)
"ADO: Short for ActiveX Data Objects, Microsoft's newest high-level interface for data objects. ADO is designed to eventually replace Data Access Objects (DAO) and Remote Data Objects (RDO). Unlike RDO and DAO, which are designed only for accessing relational databases, ADO is more general and can be used to access all sorts of different types of data, including web pages, spreadsheets, and other types of documents.
Together with OLE DB and ODBC, ADO is one of the main components of Microsoft's Universal Data Access (UDA) specification, which is designed to provide a consistent way of accessing data regardless of how the data are structured."
(http://www.webopedia.com/TERM/A/ADO.html)
"The Microsoft® Open Database Connectivity (ODBC) interface is a C programming language interface that makes it possible for applications to access data from a variety of database management systems (DBMSs). The ODBC interface permits maximum interoperability — an application can access data in diverse DBMSs through a single interface. Furthermore, that application will be independent of any DBMS from which it accesses data."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/dasdkodbcoverview.asp
"ActiveX Data Objects (ADO) provides a high-level programming model that will continue to be enhanced. Although a little less performant than coding to OLE DB or ODBC directly,..."
(http://msdn.microsoft.com/data/DataAccess/mdac/default.aspx?pull=/library/en-us/dnmdac/html/data_mdacroadmap.asp&print=true#mdac%20technologies%20road%20map%20old_topic1)
and from the same page...
"ADOX: ADO Extensions for DDL and Security (ADOX) enables the creation and modification of definitions of a database, a table, an index, or a stored procedure. You can use ADOX with any provider. The Microsoft Jet OLE DB Provider provides full support for ADOX, while the Microsoft SQL OLE DB Provider provides limited support. No major enhancements are planned for ADOX in future MDAC releases;"
"ODBC: The Microsoft Open Database Connectivity (ODBC) interface is a C programming language interface that allows applications to access data from a variety of Database Management Systems (DBMS). Applications using this API are limited to accessing relational data sources only. ODBC will be available on the 64-bit Windows operating system."
Right now I can't see a really compelling reason for Sparx to move away from a stable industrywide interface that directly accesses RDBMS's to a generalised MS specific interface that does not seem to have a clear future.
JM20CW
bruce
-
Right now I can't see a really compelling reason for Sparx to move away from a stable industrywide interface that directly accesses RDBMS's to a generalised MS specific interface that does not seem to have a clear future.
bruce
I don't think I said ADO "instead of" ODBC, but rather ADO "as well as" ODBC. I don't see any compelling reason to drop ODBC support if they already have it.
In any case, the reason is the same reason why people in the industry always move on to the new/next standard - because MS decree it, and if you don't jump to follow, you get left behind. In this case, customers or potential customers like me who haven't used ODBC in years and now use ADO and ADO.NET regularly.
Also, with regard to the other links you posted, in my experience OLEDB is a LOT faster than ODBC, so there's a definite (end-user) gain in supporting that particular data access mechanism.
And my main reason for liking ADO in this context is not unbridled enthusiasm for the ADO framework, it's that it is very easy to configure an ADO connection string with the tools that every software development environment seems to offer. If MS or someone else had made the ODBC wizard a bit more intuitive and better documented I probably wouldn't care overly much.
The connection is being used, after all, to read the database structure once. If it takes a few seconds or a few minutes longer, it's probably not of all that much consequence.
Also, my recollection is MS developed ODBC in conjunction with a bunch of other participants in the software industry but it was always very much MS driving it and shaping the agenda as it suited them. I can't respond to your specific points as they seem to have gone off-screen while I'm writing my reply.
Lauchlan Mackinnon
-
Right now I can't see a really compelling reason for Sparx to move away from a stable industrywide interface that directly accesses RDBMS's to a generalised MS specific interface that does not seem to have a clear future.
Also, I don't think ODBC accesses databases "directly". There are native drivers for Oracle, SQL Server, etc, but IIRC ODBC is not such. ODBC AFAICR accesses the database server through a driver accessed through ODBC. There is a layer between the user and the database server. On the other hand, OLEDB presents a much thinner layer than ODBC, with corresponding speed increases.
Lauchlan Mackinnon
-
IIRC,
ADO-->OLEDB-->nativedriver
ODBC-->native driver
that's all I was saying, that ADO (not OLEDB) has the extra layer.
My experiences actually differ in a few projects. 2 projects where ADO was dumped in favour of ODBC on performance grounds. One Delphi project using a distributed SQLServer 7 and one VS project where we wanted to hold conections to a (reasonably) local db open for considerable time. Other projects ADO or ODBC gave the required performance - alternatives not investigated.
anyway as i said JM20CW
bruce
-
Or
YYURYYUBICURyy4me.
Mike.