Forum Academy Marketplace Showcase Pricing Features

Creating 'amendments' of existing data but still storing the original values to go back to - version control of data

I’m going to try and implement the suggestion on preventing copying projects with the same name by adding the constraints you’ve mentioned in your post.

If I don’t add any search and just point to my dropdown’s value (which has the project name), it will still pick up and duplicate all the versions with the same name (assuming there are multiple amendments already put through). This is actually what I already have in place at the moment. So adding the above constraints and adding in :last time will be key.

Yep, I’ve built out this repeating group today. Needs more work to make it fully functional however which I’ll revisit.

Good idea on the dropdown re the type of revision. I may implement this instead of having the text there a bit later on.

Yes and I highly recommend storing the actual trial under the amendment, not the trial name. Performance would be better when searching and just overall easier to deal with

Think about if a trial is renamed and you didn’t have any steps to rename all the amendments too, it would immediately break the link between them

Yeah, I think I see where you’re coming form. As I’ve linked the amendments table via the trial name you’re saying that I should store the amendment data in the amendments table and have all other datatypes pull amendment-related data from this central table than have me save this data separately in each of the datatypes’ table and the amendment table.

I think I’ve got my amendment creation ‘engine’ working now.

I’ll be taking a look into that now especially as I’ve got all the right datatypes set up already.

I wonder whether I have done this data-saving mentioned above correctly.

Current working set-up:

  • There is a central db where all tables are linked to. This is done by having as many fields in the central db as there are other tables each with their datatypes as the central db all linked via the trial short name, and vice versa, so there is a link both ways. So the central db saves the short name, and all tables pull from it. (All this is working fine across the app).

New version management table introduced now:

  • On this amendment page I have created another table (called version management, formerly amendments). Just like any other table in the app this is modelled in the same arrangement as above. It has its short name field linking to the central db and then central db linking back to the version management each with the datatypes of the opposite db saved to create the relationship.

Now, when I go into the app tab and open up the record of one of the sub-tables I am testing this on, I don’t see the small ‘change search field’ under the field to indicate the link. I feel I need to be linking directly with the VM table above to make this work?

This is my workflow at the moment:

Do I need to link directly from my sub-table to the VM table, or can I go through the central table to the VM table, where this link already exists - and still have fields in my sub-tables populate based on data stored in the VM table (which is the objective here)?

Okay now you’ve lost me a little bit… I forgot you had more subtypes so its more complicated

What’s not working now with your new setup?
So you have a central table type, then your subtypes, and you added a version datatype now? Your sub types should have a field for their relevant Version, then your Version type should have the field for the Central data type. So your sub type has a link all the way back to it’s central trial (I think that’s what you’re calling it?)

Or want to change your editor access to view and DM me the link?

And yea maybe do two way links. Your version type has a field for each subtype, and your sub types have a field for it’s version. I think that should make it easier in the future just make sure you fill those fields in when the things are created

Yeah I’ve got lots more subtypes. I’m testing this amendment out on one of the subtypes which I will then copy for the others and make as part of the same workflow.

Example of simplified database structure is:

Central DB

  • Trial name (Main)
  • Trial name (Subtype1 DB)
  • Trial name (version management DB)
  • Trial name (Version Management DB)
  • Version
  • Date
  • All other fields

Subtype1 DB

  • Trial name (Central DB)
    - Trial name (version management DB)
  • Version
  • Date
  • All other fields

Version Management DB

  • Trial name (Central DB)
    - Trial name (Subtype1 DB)
  • Version
  • Date
  • All other fields

In Italics is what I can implement to have a direct link between the subtype(s) and the version management DB to pull the version and dates.

So, the aim here is when a user creates an amendment, this is saved in the version management DB first and foremost, and new entries are created for the subtypes which then pull the saved version, date etc data from the version management subtype corresponding to the correct trial name.

I will DM you the link.

Also just a quick tip you can add emojis to your datatype names to categorize them and make it easier to read.
I took a look but there’s so many fields I’m not sure, you’ll have to just try what you’re thinking.