Forum Discussion

JamesTrory's avatar
JamesTrory
Qrew Assistant Captain
6 years ago

Key field question

For each record in one of my tables I want to generate a "Job #", a unique 4-digit number starting from 1000. I want this to be the key field.

I have a formula field called [Job #] with this formula:
[Record ID#]+1000

This works fine. It's the key field part that I'm stuck on.

A key field also by default has to be a required field. The Record ID is not created until after a form is saved. So the problem is that I can't save a new record because [Job #] is required as the key field, but can't be created until after the Record ID is also created, which means saving the form first.

I hope that makes sense. Basically I'm prevented from being able to create new records. I can't figure out a way to have [Job #] to be the key field AND be a unique number for every record without using [Record ID#].

17 Replies

  • JamesTrory's avatar
    JamesTrory
    Qrew Assistant Captain
    Yeah it's definitely complicated.

    I'm writing an app for the production team at the photo studio I work at. Every shoot that they have to organize needs a unique 4-digit code that allows them to easily identify a shoot, which is [Job #].

    [RefID] represents each SKU that they will shoot on a job, so one [Job #] can have many [RefID].

    I have a table called 'Sets' where they will create a new job that includes pertinent information about that shoot, like the date, the location, what brand of clothing will be shot, etc. When they save the new job it creates [Job #] from the Record ID. There are anywhere from 4-8 jobs per day so there are a lot of jobs to keep track of.

    Several days later (maybe even weeks later), in another table called 'Sent to Studio', they will add the [RefID] SKU's. There could be hundreds. These are the SKU's of the garments that will be shot on a job. Next to those SKU's I want them to also be able to add the [Job #] from the jobs they created earlier in the week so that we can see which [RefID] were on which [Job #]. I don't see a way around having to do this in bulk.

    I've been trying to work out how to do this without [Job #] being the key field in 'Sets' but it doesn't work. The issue is that if [Job #] is the key field, [Job #] is now required. But [Job #] can't be created until after the Record ID has been created, which won't get created until the set is saved. This results in the user not being able to create and save a new set, because [Job #] isn't created yet but is also required for saving a new set. It's like a vicious circle.

    Where it gets more complicated is that I have another app already built called Shot Tracker. It's been in use for over 2 years. This is tracking the images of the SKU's after the shoots have happened.

    The jobs in this app also use a [Job #] to identify a shoot but that # is being created in another software entirely. I want to ditch that software and transition the job # generation to the new app I'm building in Quickbase. Then I can relate the new app to the current Shot Tracker app with [Job #] being the key field across multiple tables so that we can see what's happening on each of these jobs, from set to SKU to actual images.

    But I think that requires me to work out how to make [Job #] the key field in several tables, possibly in more than one app. Otherwise this spider's web I'm creating won't work.

    ::phew::
    • QuickBaseCoachD's avatar
      QuickBaseCoachD
      Qrew Captain
      I think that I would need to be on a GTM screen sharing session to sort this out with you.  I'm still not understanding why you cannot just create the set record in advance of the shoot and let the auto created [Record ID#] be used for the Job# on the Set record.

      QuickBaseCoach.com
    • JamesTrory's avatar
      JamesTrory
      Qrew Assistant Captain
      Yeah I understand what you're saying.

      I have to speak with the production team about this. I think the problem for them if I create an app that used Record ID as the job # is that there would definitely be an overlap in the production teams' current invoicing and tracking records with older jobs from several years ago.

      My idea was that if I can start the app off by generating Job # to continue on from the current number sequence then it would be easier for the team to transition to the new QB app. I can only do this by taking Record ID and adding whatever number the production team is on, so if they're on job # 1900 when they first start using the app I would put in a [Job #] formula, "[Record ID#]+1900" or whatever worked to continue the sequence.

      It could be however that we could start from scratch, in which case this would all be a lot easier. But I'm not sure that's going to be possible.
    • QuickBaseCoachD's avatar
      QuickBaseCoachD
      Qrew Captain
      I really think you are making this needlessly complicated.

      We are where we were.

      I suggest that you should just Import (from excel) and Delete 2,000 Set records into the app and roll the number wheel ahead so it won't conflict with the past numbering system.

      Then just use the [Record ID#] as the Job number  and as the as the Key field.  If you like you can rename the [Record ID#] to be called [Job #]
       
      Plain vanilla solution.