v16.1 - Reset Auto Increment Columns dialog - still available?

[Paolo F Cantoni]

Six years ago, there was a set of options to reset EA's internal surrogate keys via the Reset Auto Increment Columns dialog.  See:https://sparxsystems.com/forums/smf/index.php/topic,35967.msg232097.html#msg232097

Is this still available?  We couldn't find it even using the Find Command... widget.  Searching the Help also "draws a blank".

Some of our intersector (Instance) IDs are approaching eight digits, and resetting these might be a good idea.  Is there any reason we shouldn't (assuming it's still available)?
If it's not available, may we know why it was removed?

Paolo

[Geert Bellekens]

Looks like they have a new way of resetting ID's:

https://sparxsystems.com/enterprise_architect_user_guide/16.1/the_model_repository/reset_table_auto_increment_or_.html

Geert

[Paolo F Cantoni]

It looks like they have a new way of resetting IDs:

https://sparxsystems.com/enterprise_architect_user_guide/16.1/the_model_repository/reset_table_auto_increment_or_.html

Geert

No, that's not Resetting IDs; the IDs are reset as a by-product of the TOTAL project transport process.  That option has always been available (and I guess, not surprisingly, only used as a LAST RESORT).  Also, in this process, ALL IDs are reset.  You can't selectively manage IDs as possible with the Reset Auto Increment Columns dialog.

My question regarding the previous dialog - the in-situ reset of IDs - still stands,

Paolo

[Geert Bellekens]

I can't find anything about it in the release notes, but I'm pretty sure that's what they replaced the existing functionality with.

Evidence: the same help page for version 15.2 refers to the, now missing, menu option:
https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_repositories/reset_table_auto_increment_or_.html

Geert

[Paolo F Cantoni]

I can't find anything about it in the release notes, but I'm pretty sure that's what they replaced the existing functionality with.

Evidence: the same help page for version 15.2 refers to the, now missing, menu option:
https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_repositories/reset_table_auto_increment_or_.html

Geert

Thanks, Geert!

I didn't realise it was still there in v15.2 I expected it would have been removed earlier.  I have a v15.2 version I can use for this.

To my original question, there hasn't been any issue with actually running it, has there?

Paolo

[Geert Bellekens]

To my original question, there hasn't been any issue with actually running it, has there?

Not to my knowledge, but I've never used that option myself on a production database.

Geert

[qwerty]

Those are stored in a table with a simple syntax so you could fix them with a regex.

q.

[Paolo F Cantoni]

Those are stored in a table with a simple syntax so you could fix them with a regex.

q.

Paolo

[Geert Bellekens]

Those are stored in a table with a simple syntax so you could fix them with a regex.

q.

Think you got things mixed up. Paolo is talking about the primary keys in the database (like t_object.Object_ID)
I guess you are talking about the auto-number added to a name when creating new elements.

Geert

[qwerty]

Ah, yes. The auto-increment for primary keys is stored in a system table. AFAIK...

q.

[Paolo F Cantoni]

Looks like they have a new way of resetting ID's:

https://sparxsystems.com/enterprise_architect_user_guide/16.1/the_model_repository/reset_table_auto_increment_or_.html

Geert

So, I decided to give this a try  (actually as a mechanism to transfer projects - rather than Reset IDs - recall my post about SQL Server - SQL Server Project Transfer taking 8x longer!).

Findings:
Project Transfer using regular mechanism SQL Server to MSAccess .eapx = ~15 mins
Project Transfer using regular mechanism SQL Server to SQL Server  = ~120 mins

Full Project Export to native = ~30mins ^[1]
Full Project Import from native = ~60-90 mins ^[1]

Differences are that regular Project Transfer preserves the IDS - important for the uses we make of these "clones" but not insurmountable.
Of MUCH MORE CONCERN is that the import ended up with Project Integrity errors - Two packages, one a branch with tens of subordinate packages, ended up being orphaned - in addition to classifier/type mismatches!

Trying some further testing.
It also lost contact with the Project Template Package during the import.  We had to reset it manually.

Paolo

^[1] Unfortunately, timings are not available in the logging windows for the Export/Import, so these values are only guesstimates - particularly for the import.  I have previously told Sparx that "logs" of necessity need timing information!  There's a reason Star Trek officers give a stardate BEFORE they give the log information!

[Paolo F Cantoni]

Has anybody else tried this option (Full Project Transfer via Native XML) with a significantly complex repository?
Have you experienced any issues (such as the above - they're reproducible, by the way; we created a new export and import and the same thing happened)?

Not sure how to report this, as it would require the supply of our entire IP in the full repository.

Perhaps, if Sparx might indicate why, out of over 2500 packages, these two might have been orphaned.   That is, under what circumstances can an imported package lose its parent?  We could investigate on our end.

Thoughts?
Paolo