Create a new table in the .eap file

[tonySparx]

Hi all,

I need to store my rules addin in the .eap file. Is it possible create a new customized table (through SQLQuery method or in another way) where I can store this information and subsequently I can query it?

Other suggestion I've not seen?

Thanks

Antonio

[Geert Bellekens]

Antonio,

The EAP file is a standard MS Access file so you should be able to create a new table using the correct MS Access version, or an SQL connection.

The Repository.SQLQuery doesn't really allow updates, so you could get an error when trying to pass DDL to that method. (although it might be executed correctly as well, who knows...)

But; while technically possible I wouldn't advise you modify the existing database structure of EA. Why don't you create a new database for you own needs, that sits next to the (standard) EA database?

There are way to query cross-database you know.

Geert

[Paolo F Cantoni]

As Geert suggests, the most effective (and clean) mechanism is to use a side-on MS Access database that uses linked table technology to access the EA DB (which could be in either an .EAP file or a server repository).

We do this all the time and it works well...

HTH,
Paolo

[tonySparx]

Thanks to all!!  This is just what I was looking!!

As Geert suggests, the most effective (and clean) mechanism is to use a side-on MS Access database that uses linked table technology to access the EA DB (which could be in either an .EAP file or a server repository).
HTH,
Paolo

So, if I understand correctly (I'm a newbie in DB management) after EA project loading my addin can(through ADO API):

1)create a new MS Access DB (myDatabase.mdb file), with my application-specific tables which I will fill with some data .
2) Create linked tables to EA DB.
3) Read and write "myDatabase" that will contains EA data (linked tables) and addin data ("my" tables).

Is that correct?

Thanks all again!!  

Antonio

[Geert Bellekens]

Yes, should all be possible.
Whether you want to spend energy to dynamically create the database and linked tables is another question.
Depends on how much of those databases you need of course.
If you only need it a few it would probably be faster to create them manually.

Geert

[tonySparx]

Yes, should all be possible.
Whether you want to spend energy to dynamically create the database and linked tables is another question.
Depends on how much of those databases you need of course.
If you only need it a few it would probably be faster to create them manually.

Geert

Thanks a lot Geert!  

[Jason Goetz]

I have a couple follow-up questions as this pertains to me as this question pertains to me as well.

1. Is there any reason you would need to link any tables to the EA database? If I simply need to persist data specific to my EA Add-In, can I just create a database?

2. How would I ensure that multiple users working in a version controlled environment are able to share this data along with their EAP data? Is there any way to ensure this data is checked in along with any modified modules?

Maybe these questions are one and the same. I haven't quite wrapped my brain around version control / concurrency in EA.

Thanks,

Jason

[Paolo F Cantoni]

I have a couple follow-up questions as this pertains to me as this question pertains to me as well.

1. Is there any reason you would need to link any tables to the EA database? If I simply need to persist data specific to my EA Add-In, can I just create a database?

2. How would I ensure that multiple users working in a version controlled environment are able to share this data along with their EAP data? Is there any way to ensure this data is checked in along with any modified modules?

Maybe these questions are one and the same. I haven't quite wrapped my brain around version control / concurrency in EA.

Thanks,

Jason

Hi Jason,
Not quite sure what you're asking with point 1.   There are all sorts of reasons, depending upon your requirements why you might want to supplement the data in the EAP with additional data.  However, if all you want to is persist data and handle the referential integrity yourself...

As to point 2, I don't think you should be placing the .EAP in a VCS.  So consequently, you should be placing the XMI exports therein.  Therefore, you should export the data in the second DB as XML and persist that.

In our case, we often use the supplementary tables for transient data and so don't need to place it in VCS.

HTH,
Paolo

[fwoolz]

All,

Just to add my thoughts and observations:

1. I have successfully added tables and queries not only to Access databases linked to the tables in an EAP file but also to database repositories (including Access 2007). EA seems to blissfully ignore the extra objects even though they are directly in the database used by EA.
2. Some tables in EA can be "hacked" to accept entries that EA will ignore but your application could use. For example, the t_document table can hold arbitrary text and binary data linked to elements PROVIDED THAT you set the DocType field for your added row to a value not used by EA. I'm not sure of all of the values EA uses, but they include ModelDocument (for linked RTF docs), DiagramHelper, SSDOCSTYLE, SSMODELDOCSTYLE, and SSBackup. I've tried this with EAP files and other repositories and it seems to cause no grief to EA - it accesses the table data it knows about just fine while ignoring the additional, "hacked" data. I'm currently messing around with an add-in that would do something like this to allow multiple "attachments" to elements of various types in addition to the Linked Document provided by EA. The only problem I can see with this approach is if Sparx decides to change the way they use the affected tables or if name collisions arise due to added features.
3. If you want your app to work completely within the EA universe as defined by Sparx, extra stuff can be associated with elements by adding the appropriate objects to EA, linking these objects to the element of interest, and then adding the extra stuff to the linked objects. For example, the 255 character length limitation for tagged values can be overcome without sacrificing the tag Notes field by creating a class with attributes having the tag names (and types!) desired, creating an instance of the class (an object) linked to the element of interest, then setting the Run State of each attribute to the desired value for each tag. Since the RunState field in t_object is a Memo field, arbitrarily long values can be assigned. (In fact, the RunState field is already a "hacked" field since Sparx packs multiple name-value pairs in the one field using a delimited string.) Similarly, multiple linked documents can be associated with an element by linking several Artifact objects to an element, then assigning a linked document to each Artifact.

Fred W

[Geert Bellekens]

Fred,

I think there are a couple more reasons why not to mess with the EA database directly such as:

• Deployment of your tools for a new project (e.g. different EA database) is going to be a bit more difficult
• Features such as Project transfer will probably not work anymore
• Changing database type (e.g. from eap file to dbms) is going to be difficult (because of the 'Project transfer')
• Upgrading to a new version of EA will always be monitored closely to find out if the upgrade process doesn't ruin the "hacked" database parts; and you have to test whether the new version still has no issues with the changed/added database parts

So sure you can hack away in the EA database itself, but unless there is a really good reason I would not advise it.

Geert

PS. Nice badge you have there  

[fwoolz]

Geert,

Those are good points and valid concerns. But the concept of "user data" is embraced in a number of applications and domains; why not in EA as well? I'm thinking of things like the "Tag" property in .NET Windows forms objects. The missing piece here, I think, is a commitment from Sparx to support, within limits, "user data" of the type we're discussing. In this way, tables like t_document could be opened up to custom apps wishing to store related custom information provided that they follow certain rules agreed to with or set down by Sparx. In exchange for users following the rules, Sparx could commit to providing proper transfer, replication, etc. of conforming user data.

BTW, that badge in your signature is pretty cool too. 8-)