Forum Discussion
_anomDiebolt_
8 years agoQrew Elite
I think you should probably follow Mark's advice of using two tables - especially as you indicate you are new to the product. But I just want to point out that using script you can easily implement exactly what you want without any additional tables or relationships. Moreover, a script solution will not hit arbitrary limitations as your description of the problem is refined or additional requirements come into view. For example, although you literally asked for a "count" - and that is what I implemented - but you might actually want a summary of the information and perhaps a drill down link to explore related records. All of this would be possible with script in just a few lines of code.
But again I just want to point out the superiority of using script!
Here is my quick demo (it took me only 5 minutes to put together):
View any record and [Count] will display the total number of records with the same [Name].
Count Similar Records ~ List All
https://haversineconsulting.quickbase.com/db/bncw958tt?a=td
Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=618
But again I just want to point out the superiority of using script!
Here is my quick demo (it took me only 5 minutes to put together):
View any record and [Count] will display the total number of records with the same [Name].
Count Similar Records ~ List All
https://haversineconsulting.quickbase.com/db/bncw958tt?a=td
Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=618
_anomDiebolt_
8 years agoQrew Elite
As I said I think you would be better off to initially pursuing a native solution as Mark suggested and then move on to scripting solutions as your experience and requirements grow. I often answer questions just accepting the conditions a user describe assuming there is good reason for their approach to the problem. Using script is so powerful that it can pretty much absorb any scenario or assumptions a user makes.
However, in your case I think you need to use some type of parent/child relationship and I question if merely displaying the number of "double entries" is a totally adequate solution. Don't you need to further identify what the double entries are and drill down into that data? So if I were you I would further engage with Mark to further develop your requirements and proceed to a native solution first.
Once you do that I would further proceed to learning how to use script with QuickBase. Once you learn how powerful using script with QuickBase is you will have an epiphany and exclaim "What was I thinking - script is much better than native."
In the [Notes] field in every record of the Pastie Database there is an hyperlink pointing to this pastie which describes how to setup the IOL Technique:
Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=294
However, in your case I think you need to use some type of parent/child relationship and I question if merely displaying the number of "double entries" is a totally adequate solution. Don't you need to further identify what the double entries are and drill down into that data? So if I were you I would further engage with Mark to further develop your requirements and proceed to a native solution first.
Once you do that I would further proceed to learning how to use script with QuickBase. Once you learn how powerful using script with QuickBase is you will have an epiphany and exclaim "What was I thinking - script is much better than native."
In the [Notes] field in every record of the Pastie Database there is an hyperlink pointing to this pastie which describes how to setup the IOL Technique:
Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=294