Forum Discussion
ArchiveUser
10 years agoQrew Captain
Wow, 2 years old and 3 years since a QuickBase reply; perhaps there are other threads but this one still comes up quick in searches and remains an issue. The QB reply seems to indicate a "why don't you just do it our way" response yet there would appear to be many different reasons to want this functionality.
I also need different tables for different years. Yes we could load this all into one table and differentiate with reports but when you have multiple reports, executive summaries and so forth the need to switch between them causes added complexity versus clicking on a table and seeing what you expect to find. Simply needing to dictate the additional differentiation by stipulating the year when adding entries while dealing with multiple teams and participants invite far too much potential for error; inexcusable when dealing with millions of dollars in capital. As simple as it may sound, in a turnover period between years this could easily cause trouble. This is not to mention staffing changes or adding new or evolving metrics that were not tracked in previous iterations.
As for the reports themselves; while again being able to switch them to a different calendar year that is not ideal for all the above reasons so wanting them truly separate with the one table solution would require rebuilding all these reports. Do yourselves a favor and do your own quick google search and count how many articles advise to copy the entire app then move the table, then rebuild a bunch of things that do not go with it. Why is this still an issue?
Regards,
Scott
I also need different tables for different years. Yes we could load this all into one table and differentiate with reports but when you have multiple reports, executive summaries and so forth the need to switch between them causes added complexity versus clicking on a table and seeing what you expect to find. Simply needing to dictate the additional differentiation by stipulating the year when adding entries while dealing with multiple teams and participants invite far too much potential for error; inexcusable when dealing with millions of dollars in capital. As simple as it may sound, in a turnover period between years this could easily cause trouble. This is not to mention staffing changes or adding new or evolving metrics that were not tracked in previous iterations.
As for the reports themselves; while again being able to switch them to a different calendar year that is not ideal for all the above reasons so wanting them truly separate with the one table solution would require rebuilding all these reports. Do yourselves a favor and do your own quick google search and count how many articles advise to copy the entire app then move the table, then rebuild a bunch of things that do not go with it. Why is this still an issue?
Regards,
Scott