Restructure App Hierarchy with Data In Place
I have a bit of a structural issue in my app I need to fix. We developed a CRM / Purchasing system with tables as follows:
Opportunities: To Track the sales potential of a new client opport...
Forum Discussion
Hey Ivan,
I feel your pain!
Thankfully QB offers some pretty nice tools that you may be aware, but are worth mentioning:
With these tools, we need to basically go through each impacted field. One convention is to prefix fields that you'll be deprecating with a lowercase letter "z" instead of deleting them. But be careful as renaming fields could potentially break other processes such as Pipelines or API calls (typically not the latter when referenced by FID). For example, if you had a "Name" field that would become "zName" to indicate you have assessed the field and it's no longer necessary. This is nice when sorting fields by too (to shuffle them to the bottom of the list).
Or you can try to kinda hijack lookup fields instead of deprecating them, by changing their name the value they point too. But I typically wouldn't use this "sleight of hand" technique in larger refactors (such as this one) and instead I'd try to keep the old system in place until the new system is build in parallel.
Then, once you tested everything you can delete the older relationships and "z" fields.
Also, worth mentioning is Quickbase keeps backups of your app that you can request if necessary. But you can also copy an app with its data if you want to create a playground to test the new architecture first. There is also Sandbox functionality too!
Also, you could potentially leverage Access Permissions to disable viewing, adding, and editing of records in the older tables before deletion to make sure there are no issues.
Anyway, there is no simple answer. Just plan it out and then methodically flag and eliminate the older fields and relationships. You've got this ;)
------------------------------
Brian
------------------------------
I feel your pain!
Thankfully QB offers some pretty nice tools that you may be aware, but are worth mentioning:
- In App Management you can Show Relationship Diagram, I'd make sure to tidy and study.
- In a given Relationship, you can see the fields involved on both sides (the Parent Summaries and the Child Lookups and foreign key)
- On a given field you can see the Usage and Dependencies
- The Usage provides links in which you can repeat the process to again view Usage and Dependencies.
- The Dependencies provide a field ID, which you can manually key into the URL to more quickly navigate (since they are not linked)
With these tools, we need to basically go through each impacted field. One convention is to prefix fields that you'll be deprecating with a lowercase letter "z" instead of deleting them. But be careful as renaming fields could potentially break other processes such as Pipelines or API calls (typically not the latter when referenced by FID). For example, if you had a "Name" field that would become "zName" to indicate you have assessed the field and it's no longer necessary. This is nice when sorting fields by too (to shuffle them to the bottom of the list).
Or you can try to kinda hijack lookup fields instead of deprecating them, by changing their name the value they point too. But I typically wouldn't use this "sleight of hand" technique in larger refactors (such as this one) and instead I'd try to keep the old system in place until the new system is build in parallel.
Then, once you tested everything you can delete the older relationships and "z" fields.
Also, worth mentioning is Quickbase keeps backups of your app that you can request if necessary. But you can also copy an app with its data if you want to create a playground to test the new architecture first. There is also Sandbox functionality too!
Also, you could potentially leverage Access Permissions to disable viewing, adding, and editing of records in the older tables before deletion to make sure there are no issues.
Anyway, there is no simple answer. Just plan it out and then methodically flag and eliminate the older fields and relationships. You've got this ;)
------------------------------
Brian
------------------------------
Thanks everyone, appreciate this and will be reading through it, digesting, and preparing myself mentally lol
That being said correct me if I am wrong but the usage does not connect to pipelines. I dont think I have any pipelines that might be affected but anyway to monitor that or I just need to manually go through them and see?
------------------------------
Ivan Weiss
------------------------------
That being said correct me if I am wrong but the usage does not connect to pipelines. I dont think I have any pipelines that might be affected but anyway to monitor that or I just need to manually go through them and see?
------------------------------
Ivan Weiss
------------------------------
- You can check if any pipelines touch the app by going to the app settings and then to Connection Central under the Advanced Features.
This will only tell you if any touch the app though. For any details you would have to check the actual pipelines.
I keep these details in an app for easy reference.
------------------------------
Dwight Munson
------------------------------
