Show X amount of fields in a form

Ricardo - I would really recommend against this approach and suggest utilizing a Child table for the text entries. Setting up your application in this manner is often a recipe for disaster as it will have far-reaching implications that may not become apparent until much further down the line when it will become extremely difficult to resolve. Not only will this impact any reporting that you may want to do, but eventually can cause serious concerns with respect to performance and overall application design.

Hi Blake. I can't agree more with your recommendation. Here is a follow up question. So the child table would also hold 100 fields (say 100 is the top amount) to which the user will use any amount they want. For example: Parent record is created, then they will add 89 values into the child table. The form will display 100 fields and the user populates 89 of them. In other scenario, the user only needs to populate 5 fields or even 1. So, the user would need to scroll up and scroll down to find the only field that needs to be populated. Just on the top of my head as an issue, the user may erroneously populate the wrong field.
Is there a way to create new fields automatically when user enters certain value in a field or and easier way to display only those fields of interest? I can think of a lot of dynamic form rules and would work. However, the amount of those fields in the child table will increase proportionally in time so keep up with the rules may end up cumbersome

Can you provide a bit of context? What is the purpose of these fields / forms?

Blake,
Here is an example.
A project has billables for each month. Each billable has Deliverables.
So, the table that has the billables has N amounts of deliverables. Instead of creating, say, 100, I was thinking if a drop down menu with numbers from 1 to 100 that when a user selects 89, it will create 89 fields.
At the begining I was thinking of creating 100 fields of deliverables in a child table. But then, I can only get summary fields from the child into the parent. That's one set back. Then, dynamic rule of show/hide would be large.
That's one scenario. The second scenario, say that we have 100 fields and each field is for each month starting to day and with 100 fields the last month would be something like in 8 years and 4 months in the future. Say 50% of deliverables are consistent and is month by month, one next to another, aligned. But some deliverables are separated, one in April, next in July, next in August, next in December. It is easy to just create 100 date fields, but then, again, it would be 100. If user can select, I need 17 fields to enter the deliverable dates, and forms shows 17 fields to be entered, it would be A BIG time saver, just imagine this case for over 600 projects and you'll get the picture of the time saved.

Not to diminish the prior advice, it is possible to do using script BECAUSE EVERYTHING IS POSSIBLE WITH SCRIPT AND I CAN THINK OF ANY REASON NOT TO USE SCRIPT EVERYWHERE.

Show N Fields
https://haversineconsulting.quickbase.com/db/bk7ep82tz?a=nwr

Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=519

Hey! That's pretty neat and awesome. It comes very close to what I need. Now I just need to understand the code and adjust to my needs. A billion + 1 thanks Dan!

Note that this is not a complete solution. You can't use the same code in view mode because there are no id's or name's to grab onto to select the row the field is in. Also you probably want to give meaningful values to the labels or some how incorporate dates in the display. The real point of my post is to demonstrate everything is possible with script.

I understand. I knew it will have to be a script to do this but I don't know how. Using regular QB functions won't work so script is a must.
I haven't coded for a while, since 2003, but I hope it is just like riding a bicycle, you just at some point remember.

>Ricardo Tsai, Lions Tamer, commented on your answer to the question:
It is about as difficult as taming lions so you are good to go.

Ricardo - Dan's suggestion of using script will definitely get you setup in the way that you're suggesting. I would still caution against it, however, unless you're going to use additional script to automatically generate child records based on those fields. If you're using multiple fields on a table to identify date-based information, such as Billables / Deliverables, think about this - how are you going to report on these numbers in the future? How, for instance, would you easily produce a report that shows the Total Billables to Date? What if you wanted to know the Average Billable for June? If you utilize QuickBase as what amounts to a glorified spreadsheet, you are not using it to it's fullest extent and can get practically the same functionality from something like Google Sheets or similar services. What you're proposing may be a time saver in the short term, but it will very probably end up unusable.