problem with the ID (repeated in several objects)

[Anonymous]

Hi good morning all.

Can 2 objects have the same ID?.

I have come to understand in a conversation that in the same project 2 or more objects that are imported into a central model can have the same ID, is that possible? I am working with the id as the primary key in my projects and if the ID can be repeated my structure would fall.

Thanks so much.

[jeremytammik]

The duplication that you mention can occur momentarily, as long as the two separate elements live in two separate versions of the project.

As soon as they are merged in the central model, the duplication is resolved.

If your add-in might be active in both of the separate versions of the project at the same instant, you might be better off using the unique id instead.

The element id is safe to use within each individual Revit RVT file, isolated from all other RVT files.

Cheers,

Jeremy

[RPTHOMAS108]

I’d be interested to know what happens to the UIDs when you remake the central file (either discard or keep worksets) i.e. when you detach from central and save over the central file. We occasionally have to do this to reduce the file size or perform audit.

I did recently store some UIDs for columns outside of a file but when I went to find those same UIDs a couple of weeks later only about 60% were found. I know things change in two weeks but I was also storing the XYZ positions and found more matches that way (using a distance tolerance).

When you look at the UID the majority of it is related to workset or central file and only the last few characters are unique. So, when asset tagging using these it would not be nice for the guy trying to find the microwave when 1000 sinks share the same prefix as the microwave.

If you want a unique reference how about a date time Long related to when the element was born? You could even offset from a more recent time and not even have to use a Long. Also if you know when an element was born you can partly track how changes have occurred over time.

[jeremytammik]

Thank you for this important input.

I would not expect the unique id of an element to change in the way you describe unless it was heavily edited, so heavily that it is replaced by a different newly generated element.

If you can provide a reproducible case for such behaviour I can pass that on to the development team.

I totally agree with your suggestion to generate your own id instead in a manner that makes sense to you and can be controlled as needed.

The timestamp makes total sense, and so does the location.

Here is my discussion of a similar topic back in 2012:

http://thebuildingcoder.typepad.com/blog/2012/03/great-ocean-road-and-creating-your-own-key.html#2

Cf. also my approach to using named guid storage for project identification:

http://thebuildingcoder.typepad.com/blog/2016/04/named-guid-storage-for-project-identification.html

You could do the same for any other element as well, of course.

The GUID id has no intrinsic meaning; the location and timestamp based one does.

Which one is better depends on the detailed use case and personal preference.

 

Cheers,

Jeremy