You should not mix External and Internal Objects under the same Object Type
Posted by Matti Kyllönen (M-Files) on 13 March 2019 02:33 PM
A metadata card of an object shows an ID number in the upper left corner. This ID is called "Display ID" and changes depending on where the object originates.
Display ID shows the object's IDs in the order shown below (if the object has any of these):
More information about this can be found from the user guide: https://www.m-files.com/user-guide/latest/eng/faq_why_are_there_objects_with_the_same_id_in_the_vault.html
If an object has been configured to be of an external object type, which means that objects are read from an external database (e.g. SQL), the object's Display ID in the metadata card will show the External ID that is given in the external database.
M-Files vault, however, always gives every object an unique Internal ID. The scripts and e.g. setting metadata in external file source's case with XML file uses the internal IDs when referencing objects or value list items.
2 The problem with mixing external and internal objects
The problem in mixing external and internal objects is that they may show different types of IDs in the metadata card and this can lead to a confusion situation.
If you have configured external object type, for example with SQL, you then have objects created automatically to M-Files and they have external IDs (e.g. CH1, CH2). The objects in M-Files also have Internal IDs (e.g. 1 and 2) but only the External IDs are visible in the metadata card. In this case it is possible to see the actual Internal ID, but it requires a bit of manual work. Please see more information from: https://support.m-files.com/index.php?/Knowledgebase/Article/View/114/7/displaying-an-external-objects-internal-id.
If you later disable the external connection and create new objects manually, the new object will show the internal ID in the metadata card, but the older ones show the automatically created External ID.
The conclusion is that if you need to reference the objects later with scripts be careful to use Internal IDs.
3 Problem with External Value lists' case
M-Files value lists can also be connected to an external database. The value list items will also get External IDs in that case.
They will also have their Internal IDs the same way as the object types have, but the internal IDs are more difficult to figure out.
The IDs that are visible in the M-Files Admin are compared to the Display ID in the object types side.
If you need to find out a value list item's Internal ID, you will have to make a replication package where the value list values are included, and check the ID from there manually:
Within the package, you can see the internal ID as shown: