Identifying Change in a Model

[statro]

I'm an admin on a shared EA model (20-50 users) and would like to hear from anyone if they have identified a relatively painless way to track changes to the model?  e.g. how you track changes from either the object level, or the package level, or the view level, or the root node level, or even the project level.  Our database is somewhat large (500MB+) and using subversion or the clearcase approach for tracking change is cumbersome when trying to compare an ever evolving project.

[dbax]

I don't know which version of EA you have but as of version 7.0 the EA incorporates very nice audit features that may satisfy your needs. I am also an EA administrator (30-40 users) and I have been using it ever since version 7.0 came out. So far I had no problems and I've used it several times to "correct" the mistakes made on several model artifacts.

You should check it out but be warned that once you upgrade to EA 7.0 and turn on the audit feature on the server-based repository you cannot revert back to the older one.

[statro]

I've been skeptical to upgrade to 7.0 from 6.5 due to some large compatibility issues we saw when we upgraded from 5.x to 6.0.  Have you seen any issues that would lead you to question the backwards compatibility with users who still may be using the 6.5 application?  I believe we'll upgrade, but probably not for a few months until we can get some more thorough testing done.

With that said, any experience w/ 6.5 or do you believe that 7.0 is really the solution I need?

[Martin Terreni]

I upgraded without any particular problem, though there was a problem with pictures being resized when moving from 813 to 815.

[bmioch]

Thanks for the positive feedback regarding Auditing dbax.

Your last statement is not 100% true. Auditing does upgrade your model so that older versions cannot open it.

However, for the time being, when you turn Auditing off it gives you the option to roll the Database version number back. This rollback option will eventually be removed, but it is there for the mean time.

[statro]

Thank you each of you for your feedback, it definitely helps and will most likely result in me upgrading as opposed to just staying on 6.5.  

In the interim (and due to extenuating circumstances beyond my control) I must ensure that this database stays synchronized with another database being build under 6.5 - no direct connection, manual synch.  The latter of the two databases will not have the option to upgrade to 7.x for several more months and I'm still trying to find a way to identify change in the 6.5 project without having to do complete database synchs and just use package level XMI imports and exports.

Any other thoughts on how to determine which packages w/in a view may have had changes in a specific time range?

thanks again for the positive responses.

[«Midnight»]

Hi Scott,

Perhaps this will work, at least in the meantime.

EA is pretty good about letting you extend a DBMS back end by adding stored procedures, triggers and the like. Perhaps you can add a date field - as an additional field in a table, or in a custom table you design for this purpose - and use triggers to detect and record changes. You'll have to do a bit of work, but it might get you over the hump.

David

[dbax]

bmioch,

You are right, if you turn off the auditing then you can rollback the database version. I haven't mentioned that since I personally had no issues with upgrading from 6.5 to 7.0 and had no reasons to go back to previous version of DBMS whatsoever. Nonetheless, this is a very important statement and I thank you for mentioning it.