SQL Server and EA projects

[aline]

Hello dears,
Isn't possible that my client-users save and work with your projects connected with a SQL Database?

To EA, is applied the database only for save the model (central .eap file)??

Is that so little for a tool with EA??

What I need to know is if anybody work saving your projects AND your model in a database.

regards for all
Aline

[«Midnight»]

Ensure you have the Corporate Edition of EA. You should be able to work with a shared SQL Server (or other DBMS) repository.

Follow the directions in the documentation to do the initial setup.

[aline]

Hi Mid,

So, I already intalled my Corporate version of EA and created an SQL Server to work together EA.

I followed the steps of the documentation...  By the way, I was read all the documentation.. and I don't saw anything that hold on me to solving my doubt.. or better... my problem.

I wait your answer Mid,
And thanks so much.
Aline

[«Midnight»]

Where exactly is the problem occurring Aline?

If you cannot connect to your corporate repository, try this. From the EA main menu choose File | Open Project (or just control-O). At the upper right of the Open Project dialog, check the Connect to Server box; it is very easy to miss this since there's so much stuff lower on the dialog. When you've done that click the ... button to start a set of dialogs that will help you choose or create an OLEDB (or ODBC) data source pointing to your DBMS repository. When you've finished this process you should be connected.

Remember that just creating a database withing SQL server is not enough. You need to run the script Sparx provides (check the corporate resources page) to set up the schema.

You also must initialize your database with some bootstrap data. You do this from within EA. You do not need to have a project open. From the main menu choose Tools | Data Management | Project Transfer and fill in the dialog. This lets you copy a project over to the DBMS. It can be a complete project - which you can then work on via the DBMS repository - or it can be an empty template. [Even an empty project has a lot of reference data that is required by the DBMS.]

A convenient use of the data transfer function is to create an empty project, then load your corporate preferences into it. You can then save this file in a safe place, and only use it as a handy way to ensure a valid starting point for future projects. You can also store a copy of the template in the DBMS, which makes it easy to find and protect.

HTH, David

[aline]

Ok Mid,

In this case I've been work with a master repository with a EABase for example and behind of this I've some others repositories.. each of these storaging only one project. Is that ok to firm up it?

But, in my case, what I desire is make with the all existents projects get stored just in one repository. Is this possible? Or not?

Thanks so!
Aline

[«Midnight»]

I see what you mean now.

What you want is to have all projects available from the same database (or schema if you prefer that term).

What you can do - this is possible from either an EAP file or a DBMS - is to create several 'model' nodes. Each of this is a complete project. You can experiment with this using an EAP file.

Right click the model node in the Project Browser view - make sure the very top node is highlighted. From the context menu choose New Model (root node) and you will get a very simple dialog that just allows you to name the new model node. Once you've entered the name you now will see two models, which is the same as two projects.

There are all kinds of open questions about what multiple models entail. In particular you will want to think through the security aspects. All your developers will have the same access rights to all the models stored together. This could work well if you divide your project inventory along development team lines. However, it could work against you if you put everything in one basket.

It is easy to do this with the automation interface as well. Check the properties of a new package. You might want to experiment a bit - try reading the properties of multiple models you have set up by hand - since some of these look like legacy stuff, and the documentation is a bit vague.

There are also issues with references between models. For the most part EA seems to enforce splits between models. Still, you might run into strange behavior if you do something like replicate an element between models but keep the same GUID throughout. EA might do strange things if you reference the element. This could be a particular problem with the automation interface.

One more caution. You must have at least one model node in a file. As near as I can tell, you can rename the 'default' model that EA creates for you, but you cannot delete it. Just remember this in case your development teams want to remove old stuff, and wonder why one of your model nodes won't disappear on command.

Please let us know how this works for you. It's an area that has produced a fair amount of interest along the way - at least for me.

All the best,
David