Creating new record in Table - step by step help please (newbie)

[St3v1e]

Hi,

while looking around online for some information regarding building my first FMP 18 database, I came across an excellent idea to add comments in a tab, which I'd love to reproduce in a  simple Contacts DB. Unfortunately after nearly a week of trying (spare time), I've decided to ask for a little help as I'm getting confused about functionality & also how to set this up correctly.

Rather than describing the whole setup, I've attached the file.

The problem is as follows:

• In the Comments layout, when the "Comments" tab is chosen, you'll see a "New Comment" button.
• The idea works nicely - ie: I click the "New Comment" button and a new comment area appears.
• Problem is, when a "New Comment" is added, the record count also increases.
• I end up having 1 contact name, and 10 records - the remaining 9 are blank "contacts"

I suspect I'm not understanding the relationships or layouts to do this correctly, but any help or guidance will be very much appreciated.

Hope all the above makes sense.

Many thanks in advance.

Note Buyers Database (Rolodex) Updates copy.fmp12

[AHunter3]

The layout that your file opens to, called "Comments", shows records from the Comments table.  Visually, it appears to be a duplicate of the layout called "ContactNames", which shows records from the ContactNames table. 

There is a tab on those layouts (both versions) labeled "Comments".  

Your SCRIPT looks like it was constructed with the notion that you would start off on the "Comments" version of the layout, since it copies the value of Comments::PrimaryKey and not the value of ContactNames::PrimaryKey, but it would make a lot more sense if it started off on the "ContactNames" version of that layout and copied ContactNames::PrimaryKey into a variable instead.

Either way, it next goes to the layout "Comments" (which is redundant becuase that's where you already are) and in step #6 it makes a New Record, which explains why you're getting a new record each time you run this.

In Step #9, your script is told to set the field Comments::Comment to a value, but you haven't told it what to set it to, and you don't want your script setting Comments::Comment to a value anyhow, that's the field you would be manually filling in!  

Then you have your script going back to the "Comments" layout, which, once again, is where you already are.

 

So essentially everything is wrong.  

 

a) Start off on the other layout, the one called "ContactNames"

b) Change your $Variable name to $ContactNamePk (this isn't necessary but it will make more sense to you if you do)

c) The value to set it to is not Comments::PrimaryKey but instead ContactNames::PrimaryKey

d) Now it makes sense to go to Comments (because now it's not the layout you're starting from!)

e) New Record makes sense because you're creating a new comment for the ContactName, unlike how it was when you were starting off in Comments to begin with

f) In step 9, the field to set is Comments::fk_Comments, not Comments::Comment

g) And the value to set it to, which you haven't specified at all in your script, is $ContactNamePk, the variable you created in Step 2

 

 

 

[AHunter3]

I should also add:  the notion of multiple related comments to each ContactName really only makes sense if your "Comments" tab on your ContactName layout is set up as a portal, so that you see comment 1, comment 2, comment 3, etc all on one screen, with a scroll bar in case you have 37 comments or something for one of the ContactsNames.

[St3v1e]

Hi again, Man, trying to juggle this with other work is so time consuming, but I'm enjoying the FMP work much more than my other tasks.

Thanks so much for the info, and all makes sense. I found a video on YouTube which basically explains the procedure you kindly set out above. I also found another video which shows how to create the same scenario using built-in functions in FMP (ie: using a portal & an Add-On table). Either will work nicely - however, as you noticed, the DB is a mess, and so I'm starting from scratch using my newly acquired knowledge and will follow your instructions above.

Is there a way (using either method) to have the most recent Comment at the top instead of being added to the bottom?

Thanks

[AHunter3]

If you're viewing it in a portal, a portal can be sorted — in layout mode, when you select the portal, it's one of the options.

 

Natively, viewing records in a table, whether on their own layout or through a plain-vanilla portal, newest records go to the bottom (or to the far right, using the record slider "book" icon), so "newest on top" is always going to be an override setting that you have to apply in some fashion.  (There are other ways to do it besides sorting the portal; as you'll discover there are almost always multiple ways of doing anything in FileMaker)

[St3v1e]

Many thanks, I've "Sorted" the portal records via the creation timestamp, and now each time I click outside of the new Note field (box) they sort with newest at the top. 

Not that it's really a big issue, but when I click outside of the box, a new blank note is created . ..  but still at the bottom (see screenshot), which is a bit of a pain, as I have to drag the slider down to the bottom each time to find the empty note, so I can enter new note info.

Is it possible for the new note to be created at the top each time - maybe via scripting etc.?

[AHunter3]

Not really, no; at best you could create the illusion of a blank record at the top.  Frankly, at your stage of learning the platform, I strongly advise you to make friends with the native behaviors of FileMaker; at some later point if you want to delve into work-arounds that change the experience of using it to something more to your liking, you may opt to do so.  But the native methods are (of course) easier and more straightforward to learn.  New recs are at the bottom of portals.

What you may indeed wish to do is put a button within your portal that goes to the last (bottom) portal row when you click it.  That lets you bypass the scroll bar experience.

EDITED LATER TO ADD:  The blank row at the bottom isn't a record.  It's a potential record.  When you type into the Note field at the bottom, a new related record, in the related table that the portal is aimed at, springs into existence to hold whatever you just typed.  Until you type something in (and click out of the portal or otherwise commit), the record doesn't actually exist.  This is more obvious if you create a brand-new Contact record and go to the place where you would create notes— you have the blank line waiting but you very obviously don't already have any related Notes records for this Contact that you just created!  But FileMaker gives you a place to type a note anyway, and when you do, a new record springs into existence (with the foreign key in place to connect it).  That's why it would be awkward and difficult to design a portal with the blank at the top.  Claris Corporation themselves could do it if they so chose (making that an option) but a workaround that we mere mortals who do our developing in FileMaker as opposed to on FileMaker, we're best off working with what Claris designed for us.

[St3v1e]

Thats a great answer - I'll look into the button situation immediately.

Thanks also for the detailed explanation of how all this occurs - I do believe you're correct in suggesting I wait until I have a better understanding before delving into work-arounds. At this stage, it's purely functionality I'm trying to achieve, and a few bits and pieces like this aren't going to affect that.

As always, I very much appreciate your valuable guidance.