Forum Discussion
QuickBaseCoachD
6 years agoQrew Captain
Yes, you got it. I would agree that it will save some micro seconds to only update records which need to be updated so I agree with the filter (it also helps with sort of self documenting what the saved table to table import is doing, as it will be less obvious 2-5 years into the future when you or someone else is trying to remember what that saved table to table import is doing).
Yes, since it's only 36 fields, then I would set like 35 to Do Not Update so just update that one field, just to make it even more obvious what the import is doing.
Yes, since it's only 36 fields, then I would set like 35 to Do Not Update so just update that one field, just to make it even more obvious what the import is doing.
TateForgey
5 years agoQrew Assistant Captain
What is the best practice if it is a connected table? You can't schedule table to table imports because it is connected.
This should be its own thread since I have run into this problem before, but I'll ask here since it is the same kind of problem. I have a connected table (People) with a relationship to another table (Tests) and a summary field that shows me earliest test date. Easy. Reporting requirements cause me to create a Days table with a "Date" as the key to display those earliest test dates and I create a relationship with the People table using the reference key of the earliest test date. Quick Base allows this, and this works, and everyone is happy right up until it doesn't work because those relationships based on a summary field can be wonky. (reports show "0" even when clicking on that "0" show multiple records in the drilldown report.). So, I think, "Well, I guess I need to take that summary value and put it in a hard-coded date field to base that relationship on." However, I have tried multiple automations that I just can't get to reliably fire and fill this out since the "change" is based on that summary field changing.
So, what is best practice here? I'm back to the relationship based on the summary field now and hoping it doesn't flake out. Is there a way to make that more stable or at least know when it might get weird? If not, what is the best way to populate this date field from the summary date field?
------------------------------
Tate Forgey
------------------------------
This should be its own thread since I have run into this problem before, but I'll ask here since it is the same kind of problem. I have a connected table (People) with a relationship to another table (Tests) and a summary field that shows me earliest test date. Easy. Reporting requirements cause me to create a Days table with a "Date" as the key to display those earliest test dates and I create a relationship with the People table using the reference key of the earliest test date. Quick Base allows this, and this works, and everyone is happy right up until it doesn't work because those relationships based on a summary field can be wonky. (reports show "0" even when clicking on that "0" show multiple records in the drilldown report.). So, I think, "Well, I guess I need to take that summary value and put it in a hard-coded date field to base that relationship on." However, I have tried multiple automations that I just can't get to reliably fire and fill this out since the "change" is based on that summary field changing.
So, what is best practice here? I'm back to the relationship based on the summary field now and hoping it doesn't flake out. Is there a way to make that more stable or at least know when it might get weird? If not, what is the best way to populate this date field from the summary date field?
------------------------------
Tate Forgey
------------------------------
- MarkShnier__You5 years ago
Qrew Legend
Can you fire the Automation based on change in the details table that is being summarized?
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------- TateForgey5 years agoQrew Assistant CaptainI did think about that and took a shot at that but couldn't get it to go. I'll check my logic again because the automation could just have been bad. I'll admit I went into it thinking what I was doing might not have "time" to work.
I looked up the earliest test date summary field down to the test record and created an automation triggered by a record being added to the test table with an action to write the test date to the earliest test date "hard-coded" date field on the person if it was earlier as filtered. There is a person ID in the test I used to filter to the ID of the person in the action.
I'll take another shot at that since it does sound like the logical thing to do. Maybe there is a way I can get it to fire.
------------------------------
Tate Forgey
------------------------------