Self-taught user, long-time forum lurker here. I am working with my GIS database manager to set up data entry forms, and while we have a common field name of Accession Number to key the database, she was seeking a second for secure redundancy. She has a specific field name already in use in her database that she would like to use, which is not in Specify.
To the best of my knowledge, it would be particularly challenging to create a new field name within Specify (as opposed to editing a field title), correct? Has anyone set up a common field key between Specify and another internal institutional database that didn’t require the other database to use Specify field names? (Which is the obvious solution; I am trying to not put all of the the onerous on her and learn a little in the process.)
Thanks for reaching out! While others in the community may have more advice to offer, I did want to mention that we do not support adding additional fields to the data model. To maintain consistency between all Specify installations, we encourage all users to change the field caption for an existing field instead!
Would using a field like text1 on the Accession table as a second identifier work in your use case? In the Specify 7.9.3 update we also introduced uniqueness rules configuration so you can have the field be unique at a given level (collection, discipline, division, etc).
Depending on your workflow, you can have the other database interact with and treat text1 (or any required fields) as a dedicated field for your purposes.
I’d be interested to hear from the community as well on what advice/experience they have with interactions like the one you are looking to configure!
When I read your post my first impression is that it was essentially akin to the problems with maintaining a fork. Of course with an SQL database that you control you could add or remove fields as you please, however the issue you would face is staying in sync with the larger community. The Specify developers work against the official schema, and all their feature development and processes are dependent on that, and they may introduce updates or changes to business logic, front end behaviour, or even the schema itself that would then be incompatible with the additional field you have created in your version.
Usually, in my experience, organizations that go down that path end up being upgrade-hesistent, because they are less confident that the update coming down the pipeline will be compatible with their setup. I am not sure the specifics of your deployment, whether it uses containers etc, but at the very least you would be incurring additional complexity.
As the Specify staff mentioned, there are user-definable fields within the database schema that could be used for this purpose, with the additional configuration only done by the GIS database manager on their end. We have used these fields extensively, and as long as they are well documented (i.e. don’t just leave it named text1 and have tables that explain to users what each of the custom fields have been used for) our experience is that they work as expected of any other field you would want in the database.
Thanks for the feedback. Your responses confirm my understanding. We’ll probably ultimately end up using a third platform to align the fields for documentation purposes.