Forum Discussion

MarkShnier__You's avatar
MarkShnier__You
Icon for Qrew Legend rankQrew Legend
5 years ago

Re: How to Create a Legit 'Save & Keep Working' using the code page alternative?

Do you find hat you are unable to create children in Grid Edit on the form when the parent is not yet saved.  That should normally work.  ie is it necessary to do the Save and Keep working step.

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

3 Replies

  • BradLemke's avatar
    BradLemke
    Qrew Assistant Captain
    5 years ago
    In short: yes it's necessary, but for a variety of reasons.

    I found that using an embedded grid-edit on a record form was inconsistent at times if the record ID didn't exist yet, though that was when I was initially developing the workflow a couple years ago.  However in addition to the grid-edit child records, I also have a separate child table where they need to interact with an actual form.  Initially, they did this through a url link to open it in a new window, but I ended up figuring out how to iframe embed this child's form onto the parent record (another 'unsanctioned' thing I need to figure out an alternative for - but we'll do that some other time).

    I have several other workflows that can be optimized using this specific 'save and keep working' use-case as the initial function and then do other stuff (like redirecting to an exact form for this new record, but kinda hard to do without knowing the RID ahead of time).

    ------------------------------
    Brad Lemke
    ------------------------------
    • QuickBaseJunkie's avatar
      QuickBaseJunkie
      Icon for Qrew Legend rankQrew Legend
      5 years ago
      How about replacing the step 1 GenAddRecord button with a call to a code page that creates a new record then displays the new record for step 2?

      This way it starts out as a saved record and you don't need step 3.

      There is some risk of the record being abandon without data, but it might be better because you have the rid for any subsequent actions right at the beginning.

      ------------------------------
      Sharon Faust (QuickBaseJunkie.com)
      Founder, Quick Base Junkie
      https://quickbasejunkie.com
      ------------------------------
      • BradLemke's avatar
        BradLemke
        Qrew Assistant Captain
        5 years ago
        Api_addrecord also isn't an option for a variety of reasons:
        1. Several fields are intrinsically *required*, none of which can safely have a default value set for them.
        2. The system is a 'point-of-sale', and so we could have multiple orders pre-abandoned per week (per user), and we don't allow deletion of records due to traceability concerns. 
          • Pre-abandonment is typically due to lack of required information from the customer or salesman (ex. purchase order#) and we can't expect every single data-entry member to memorize which accounts require what info before anything can be shipped/sold.  Many don't require anything special/unusual, but the ones that do require it will flat-out refuse to pay an invoice without it. 

        I'm sure there's a hundred different ways to do what we do, many of which might even be better/faster/more efficient.  What I'm *REALLY* trying to do here is figure out how to make this work this way, because the solution to this (if bulletproof) will open the doors to several other process optimizations that I've been shelving.

        ------------------------------
        Brad Lemke
        ------------------------------