Laura_Thacker
Qrew Commander
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Help connecting Table to Table Relationships
Ok, I think you might be overcomplicating your design. Your [related site] field in your Risks table can be passed down into your milestones table via the [related risk] relationship in milestones; so your "siteid# and any other lookup-information can easily be displayed and reported on from milestones. You state that the Site Risk Register is a join table housing all the Risks and Milestones relating to a site in a single table. But, by definition; every Risk having multiple milestones means that each Milestone is a "join" record of a Risk and Milestone for a Site. Therefore; if you display ALL the milestones for a single Site; you get all the Risks automatically as a groupable-value. You can then embed a Report Link field-type on your Sites table that lists all the Milestones and group that report by the Risk (parent). If your Site Risk Register is supposed to be a list of "all risks" and "all milestones"; then you can build that fourth table and have a Pipeline create the join-table records there for all of them; but I would question the purpose of this "Site Risk Register" as it relates to Sites and what you would do with that extra table?Re: Need help deciding between two db setups
Between your two options; you would need option 2 because you need to assign multiple faculty members to a Thesis for reading. There's also a (better) 3rd option. Assigning child-records of Faculty to a Thesis will provide better reporting in the long term; particularly if your Thesis Faculty need to have fields they fill in regarding the Thesis (yes they've read it, yes they have comments or feedback, yes it needs review etc.). When you have multiple-persons who are responsible for entering data relating to a single-entry; storing all of that in a single record gets hard to report in a standard table-style report. Leveraging the power of the Quickbase relationship with summary fields and lookups; you can do reporting from both the Thesis, Thesis Faculty and Faculty tables! I recommend this one.Re: Formula for form fields
Actually you could do either; since these are lookup fields. FORM RULE with HIDE/SHOW solution: Your rule will look like this: When [Table 3 Field 1] = "value 1" then show [table 3 field 1] hide [table 2 field 1] hide [table 2 field 2] This logic means that when the table 3 field 1 SHOULD be visible; then it will be and under all other conditions it will be hidden. Conversely by adding the hide table 2 field 1 and 2; you're saying that when table 3 field 1 SHOULD be visible, then the other 2 fields should not be visible. So when table 3 field 1 is not visible the other table 2 field 1 and 2 WILL be visible. FORMULA: If( [table 3 field 1] = "value 1", [table 3 field 1], [table 2 field 1] & " " & [table 2 field 2]) (this assumes your table 2 field 1 and 2 should be displayed "together" in a single field. Also, this formula will "persist" across the entire table which would include reports, forms, formulas and emails etc. So this might be a better solution that one simple form rule that only exists in that one state. Using this formula in this way you can turn off reporting for the 3 lookup fields and rely only on this one formula.
Groups
Mobile Qrew
For your mobile based use cases, there's no better space to discuss Quickbase mobile than in the Mobile Qrew.Pipelines Qrew
A Qrew dedicated to sharing all things Pipelines.Realm Admin Qrew
Where Realm Admins help other Realm Admins Realm Admin.Women's Qrew
For builders who identify as women to connect and learn from each other.
