EA13 crashing when saving diagrams

[marke]

Hi,

I have been running a project for some time using EA1309 on a MySQL server. I have started getting duplicate entry messages when I save a number of diagrams:

Microsoft OLE DB Provider  for ODBC Drivers [-21472179001]

[MySQL][ODBC 5.3(w) Driver][mysqld-5 5.9]Duplicate entry'2147483647' for key 'PRIMARY'

and then EA crashes with a "Runtime Error!".

I have run a Project Integrity Check and it reports no errors. I have disabled all add-ins which made no difference.

I'm a bit of db newbie but I tried searching for 2147483647 in phpmyadmin but found only 1 match inside table t_diagramlinks. 2147483647 appeared as an Instance_ID on a diagram. I was able to trace down the diagram. I deleted it  in EA and the 2147483647 just appeared as an Instance_ID on the next diagram (in phymyadmin). At this point I decided I was out of my depth.

I'd really appreciate any tips on how to diagnose this further and, ideally, how to fix it. Restoring to a backup would be a last resort (although we do nightly backups) as a number of people have been working on the project for a few days since the problem appeared. I think I know the root package below which the problem manifests so I guess another option would be to xmi export that/delete it/xmi import it to clean things up. I'd lose a few baselines but that wouldn't be the end of the world.

Mark

[qwerty]

This sounds like you should contact Sparx support directly to help you out. ICR a similar issue being posted here recently.

q.

[marke]

Thanks q. I have contacted Sparx directly too but hit-and-miss as to when/whether I get response, on past experience, so thought I'd try my luck here. I did search in here but couldn't find anything directly relevant. There was a posting where the cause was an add-in hence my trying that out.

Mark

[qwerty]

From what I read you have done anything one could/should do in such cases. Now it's Sparx' part. Usually they are quite responsive when it comes to this kind of issues. Check your spam folder and/or ping them once again.

q.

[Simon M]

I would try the Reset IDs command.

Below is the link to the 12.1 documentation for the command. I hope it's the same for 11.

http://sparxsystems.com/enterprise_architect_user_guide/12.1/the_model_repository/reset_table_auto_increment_or_.html

[marke]

Hi Simon,

That did the trick. Thank you very much.

Would there be any harm in running a Project Integity Check + Fix and a Reset Ids nightly after the backup?

Regards,

Mark

[qwerty]

Project Integrity Check is essential (I think) at least on a weekly basis. Unfortunately you are forced to do that manually. I don't think that resetting ID should be done regularly. Especially since it requires MySQL to be restarted afterwards.

q.

[Simon M]

A data integrity check is useful to run frequently.

Reset ids is much less so. It only really becomes a problem when the auto-increment fields reach the upper limit on the data type used. That mainly becomes an issue for models doing a lot of xmi imports to update packages. If anything I'd open the dialog once in a while to check what the highest entries for any of the tables are.

[marke]

On one project the Project Integrity repair seemed to delete all of the root package's baselines. The log of errors did not mention baseline and the _recovered_ package was empty.

Is that an expected behaviour? The help for Project Integrity doesn't mention baselines.

I baselined the root package on another project, ran Project Integrity repair and it didn't delete the baseline.

[qwerty]

I'm keen to know what the integrity check really does. Up to now (it's been there all time IIRC) it's been a puff of white smoke to clean things up. But the wizards will likely not enlighten their apprentices.

q.