Our app is a scale calibration app, sometimes in the field we have to add a new scale to a customers database.
For some unknown reason yesterday we noticed that when we added a new scale to the database, it would save it without a unique identifier, even though we have the ID field set to be one.
If I duplicated the item, which is basically an Add Row button with the same fields as the previously created scale, again with the ID as a unique identifier, it would work sometimes, but other times not… it seems around a 50% success rate.
Is there any reason why this would be happening? Data connection was solid so I cant blame that.
Just to be sure: you’re using the Row ID as a unique identifier, correct?
Could you provide a quick recording of what you’re doing? That might help in solving your issue faster.
Unfortunately I’m not… The Row ID came a lot later and I realise my mistake now, this was using an imported table from another app i’d previously used, and so I tried to keep everything the same way I had imported it, which was using a seperate ID column, which is referenced throughout several tables.
I then introduced Row ID, but because its referenced everywhere else I am now stuck in between. The only way I can do this is by creating a unique ID in the old ID column.
You would have to update the ID in every child row to point to the correct parent row and vice versa. There is a little more to it than just adding a Row ID columns and changing your relations. You still ultimately need the values to match for the relation to work.
Still doable, but I think it’s a little more involved. I would add all of the row ID columns first since that won’t affect anything. Then create relations or use existing relations where needed using your unique ID, and create a lookup to return the Row ID associated with the that Unique ID. Then it’s a matter of overwriting the stored unique ID with the associated RowID everywhere.
Another option is to run it a little more parallel. Keep your existing set up, but add a new column in the child rows to store the parent RowID along with already storing the parent UniqueID. Once you have updated that new column by copyong the correct parent RowID to all of your child rows, and you have your actions and workflows setup to update the new ID column with new rows, then you can start pdating old relations to use the RowID values instead of UniqueID values
Again, at the end of the day a relation still needs a matching value to work, so a parent RowID still needs to be stored in a basic column in a child row (or vice versa). You can duplicate your app and data to be safe, but if you do the parallel method, then you should be pretty safe as you will not be touching anything important until you have confirmed that the new relations all work properly. Once you have confirmed that, you can update the old relations.
@Jeff_Hager is right. Apologies, I made it seem a bit too easy. I’d recently done something similar, but indeed, you first need to make sure they know what to look for.
For safety purposes, I would go for Jeffs advice here: