Messages

1

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 10:14:39 pm »

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

2

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 10:06:04 pm »

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

3

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 07:01:30 pm »

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>

4

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 06:57:28 pm »

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

5

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 06:42:06 pm »

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

6

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 06:28:16 pm »

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

7

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 06:19:23 pm »

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

8

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 06:14:44 pm »

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.

9

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 03:49:29 pm »

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

10

General Board / Re: Importing and modelling databases

« on: March 29, 2005, 03:38:48 pm »

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

11

General Board / Importing and modelling databases

« 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