Form within a form

You have three choices.

1. Create a child table to hold auxiliary information, but then be fully aware that it will get very difficult to have a Project Report which will show data from these fields or filtered on data from these fields.  So it is not likely that this is the best solution.

2. Have a separate Section on the form for the new fields.

3. Have a separate form and then the users will need to use button to see that form or to edit on that form.

#2 is the best approach, I feel especially knowing that the 2017 road map shows us having tabbed forms in the late Fall.

Thanks Mark. Do you not sometimes get concerned at having too many fields in a table?  Coming from MS Access mindset, I am quite frugal when making my table too big.    

I prefer the button approach over having a lot of sections on a form. Now sections are collapsible by default (only if you check the box) so that helps. The user just has to open each section if they want to see it.

I have over 700 fields in one table. It's not good but we are waiting to redesign soon :) 

QuickBase has no field limit and on the new platform (Mercury) it's based on Oracle which has a limit of 1,000 fields.  As Ann says, I also have apps which have close to 1,000 fields.

I come from a 20+ year MSAccess mindset, and I can tell you that QuickBase tables don't seem to care about numbers of fields, so I embrace that fully because QB makes it so easy to do it that way. I have one table that's the hub of our application (Clients) that has about 1000 fields. I have other tables with hundreds of fields. I don't see any performance issues with this.

The only thing you have to watch out for is the 500 MB single table maximum database size, but lots of fields usually don't blow that - it's lots of records with a field or two that is multi-line text and has lots of text in it. Our Internet Webform Response Leads table qualifies for that, and I'm constantly having to beat it back using Data Collaborative's excellent inflate/deflate utility which archives multi-line text field text into a linked file attachment. But I never worry about adding more fields to an existing table if that's the right approach to represent our business logic using proper computer science normalization rules. What gets me to 1000 fields in my client table is the gazillions of summary fields from dozens of other tables that are related to the client table.

Don't make it harder than it has to be. Add those new fields in the existing table. Use tabbed/buttoned sections in the single form, and just make sure your field names are somewhat consistent and organized so you don't drive yourself crazy.

The only time (so far) that I have had issues with slowness is Large (and I mean large) formula fields and a table that has about 200000 records in it with a lot of those large formula fields in it.

Thanks. Keeping track of each field's purpose could be a major issue when go back to review after a long time. Wish there was an option to write description but not field tips. 

I agree. I inherited my app about a year and half ago so I had to figure out what each field does. I am still trying to understand them all.