Forum Discussion

AndrewNelson's avatar
AndrewNelson
Qrew Cadet
4 years ago

Relationship/Summary Restrictions on Date fields

I am working on building out a system where our foremen can "schedule" certain equipment to be used for specific days.  For simplicity's sake, they do not need to check out a specific piece of equipment, but rather just reserve one of a TYPE of equipment for that date.  Part of this system is that I need a way to alert the user when they request a piece of equipment that has already been reserved too many times for that particular date.

My intended structure was something like this: a table called "Equipment Reservations" with the following fields:

Date - the date the equipment is reserved for
Equipment Type - A multiple-choice Text field that lets the user select what type of equipment is being reserved
Equipment Count - this is a formula-numeric field that returns how many pieces are available based on the Equipment Type field.  Essentially just a case() statement and a list of quantities for each option in Equipment Type

Basically, I need a way to count up how many Equipment Reservations there are that have the same Date and the same Equipment Type, and if it is more than a certain value, either a) trigger a checkbox field on the reservation to highlight the request as invalid, or b) just halt the request and not allow it to be submitted at all.  

In the past, I've solved this problem in a somewhat roundabout way.  I created a table called "Calendar Date" and just pre-populated it with a record for every date for the next 20 years.  I use the short date text as the unique identifier and then created a relationship between the Equipment Reservations table and the Calendar Date table, using a formula-text field that simply contains "toText([Date])" as the reference field.  Then I could set up Summary Fields for each Equipment Type that would count the number of Equipment Reservations related to that Calendar Date with the same Equipment Type.  However, now when I go to set that up, it no longer works - Quickbase will not allow me to create ANY summary fields on this relationship because the reference field is a toText([Date]).

What is the point of this restriction?  Why was it implemented?  Is there other any way to count the number of "siblings" that share more than one field in common?



------------------------------
Andrew Andrew
------------------------------

8 Replies

  • Is that date field a lookup field?

    ------------------------------
    Mark Shnier (YQC)
    Quick Base Solution Provider
    Your Quick Base Coach
    http://QuickBaseCoach.com
    mark.shnier@gmail.com
    ------------------------------
    • AndrewNelson's avatar
      AndrewNelson
      Qrew Cadet
      No, [Date] is a normal Date field, and [Date ID] (the reference field for the relationship) is just a Formula-Text field containing toText([Date]).  It appears that because I have used a derivative of a date field as the reference field, QuickBase simply won't allow me to create ANY summary fields on the relationship. 

      I have done this in the past, and from what I can tell it is still working where it was already implemented.  But even when I try to add another summary field to THAT relationship I get this message:

      We are sorry -- at this time, you cannot create a summary field using a relationship where the reference field is this type of formula field. Please visit our limits page (https://XXXXX.quickbase.com/db/main?act=dohelp&page=quickbase_limits) or contact Care for more information.


      ------------------------------
      Andrew Nelson
      ------------------------------
      • MarkShnier__You's avatar
        MarkShnier__You
        Qrew Champion
        I just did a test  relationship and it sees to work for me.  Key field of the Parent was a text field and on the child side my formula was a totext([date field type])

        ------------------------------
        Mark Shnier (YQC)
        Quick Base Solution Provider
        Your Quick Base Coach
        http://QuickBaseCoach.com
        mark.shnier@gmail.com
        ------------------------------