Tap Forms – Organizer Database App for Mac, iPhone, and iPad › Forums › Using Tap Forms › Add Record Details – Table Control Not Working
Tagged: Add record details, Table Controls
- This topic has 5 replies, 3 voices, and was last updated 2 years, 11 months ago by Sam Moffatt.
-
AuthorPosts
-
January 4, 2022 at 5:21 PM #46221
Chris MedeirosParticipantI have one Table that will not bring up a new (blank) record using the +> table control. The table is a ‘Link to Form’ (Join) field.
Instead of a new blank record, it displays the first record in the table.
For more background, I included the following attachments:
1 = Field information
2 = The table control I’m clicking on
3 = The expected result
4 = The actual result (If I click on the + (in example 4) to add a record, I get the expected result)Any ideas what could be going on?
Attachments:
You must be logged in to view attached files.January 5, 2022 at 2:57 AM #46227
Sam MoffattParticipantIt might still be creating the blank record but when it loads in the list view that record is excluded because a blank record likely doesn’t meet your JOIN criteria because it’s
Lot #
field isn’t set. When you’re in the list of linked records, the new record button works because TF hasn’t recalculated the record list yet, it is just inserting the newly created record into the view. Though when this happens if a recalculation happens, that record will disappear from the list if it doesn’t satisfy the JOIN field criteria.Ideally if you want to use TF to create the records then the JOIN type really isn’t a good fit as you have to manually ensure the correct value is set. JOIN is great for piecing together externally linked data though. One other workaround I personally use is a script that creates linked records with the correct values set for the link to work properly (important when using calc fields to JOIN on composite keys).
January 5, 2022 at 3:10 AM #46228
BrendanKeymasterAh ya, that’s probably what’s happening. I’ll have to dig into this. Tap Forms should be setting the Join field value for you based on the joined value from the parent record. That’s what it does when you add directly into the inline table.
January 5, 2022 at 2:16 PM #46229
Chris MedeirosParticipantBrenden & Sam,
Thank you. When it comes to deductive, logical thinking, you two ARE the ‘sharpest tools in the shed’!
Sam, yes I found all the ‘blank’ records in the Six Week Cure Log form.
Brendan, uh, yeah, TF was doing exactly what you designed it to do. However, I had designated the Lot # field as a Calculation field. Thus TF was unable to set the Join field value and like Sam mentioned, TF couldn’t display the new blank record with the expected criteria.
By simply changing the Lot # field type from Calculation to Text, all is well again.
Thanks again.
January 5, 2022 at 4:36 PM #46230
BrendanKeymasterAh ok! I guess I hadn’t considered the join field being a Calculation field. Although it should just be a copy of the value from the parent, so I would think that it should still have worked. But I haven’t yet had a chance to look into that code.
January 6, 2022 at 2:55 PM #46245
Sam MoffattParticipantI think you’d need to set the value of the fields referenced by the calculation field because otherwise a recalc will reset the field value anyway. I wonder if there is some sort of data race between setting the value and then the record creation triggering the calc/script fields to be run as well. That would work ok for calculation fields for the composite key use case but I can see if someone joined on a script field that might be a little more challenging as well.
Would it make sense to block the UI if someone uses a calculation or script field in a JOIN?
-
AuthorPosts
You must be logged in to reply to this topic.