Using the unique hidden IDs in workbench import

Get Help
1

Hi.
Some users would like to use the Locality ID (the hidden value) instead of the Locality name when importing collection objects with the workbench, to make sure that, when the locality already exists in the database, no spurious new locality records are created because of a small, unintentional difference in any of the fields (e.g. a mistake in the name or an extra point).

I included the LocalityID field in a test workbench import:

error_workbech_localityid_2
error_workbech_localityid_21185Ă—57 9.98 KB

and entered a valid LocalityID in the field, but the validation gives this error:

error_workbech_localityid
error_workbech_localityid898Ă—341 26.1 KB

Would it be possible to use these hidden IDs in the workbench?

We could assign a “custom” ID to each locality, but it seems rather unnecessary work when the system is already creating unique IDs for the localities.

Cheers,
Soraya

2

Hi Soraya,

I’ve been making use of the GUID when mapping datasets, as we were having the same issue of localities and agents not matching. I had initially looked at using the ID for these fields, but switched to the GUID when I found it couldn’t be mapped.

Robyn

3

Hi Robyn @rdrinkwater,

Thanks a lot for the tip! It’s very useful. I never think of the GUIDs because they are not user friendly, but we will have to use them.

It would be good if someone could explain why the locality GUID can be used in the workbench to map to an existing locality but not the locality ID.

Cheers,
Soraya

4

Hi @sorosoro and @rdrinkwater,

You can check the “Reveal Hidden Form Fields” at the bottom of the page to map hidden fields. They will appear at the bottom of the field list in gray.

Reveal Hidden Form Fields
Reveal Hidden Form Fields1312Ă—1368 62.7 KB

The same goes for mapping hidden fields in the Query Builder!

5

Thanks @bronwynscc, but that’s not the problem. The thing is that including the LocalityID as a field in the workbench gives an error (see screenshot in my first post), but using the locality GUID works.

Maybe the LocalityID field is not in the insert statement or something like that?

We can use the GUID, it’s not a big deal, but it’s user-unfriendly.

Cheers,
Soraya

6

My apologies, I didn’t realize I missed the mark on what was needed!

The ID field for each table is unique in that they are fully system-generated/maintained and not currently available in schema config. I found a feature request on GitHub ( #4288 ) to allow unhiding ID fields in the schema for this same purpose of reducing unintended duplication when importing via WorkBench. I left a comment relaying that you both also request that this feature be implemented in a future release.

Let me know if you have further questions or if there are more details or context you’d like the development team to be aware of and I’ll add it to GitHub :grin:

Best,

Bronwyn

7

No worries! Great you found that GitHub ticket, good to know.
Thanks!
Soraya

1 Like