Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


LaRetta last won the day on October 21

LaRetta had the most liked content!

Community Reputation

488 Excellent


About LaRetta

  • Rank
    Lifelong FM Student

Profile Information

  • Title
  • Industry
  • Gender
    Not Telling
  • Location

FileMaker Experience

  • Skill Level
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
  • OS Version
    El Capitan
  1. Help with relationships

    One more thing I've noticed ... Your Services and Rent History tables do not appear to have a unique ID. You really should have one in every table. If you ever lost your data or had to restore, you would use this unique ID to update/correct or replace the records. It's more than just used for a relational key. Without knowing your business quite a bit more, I am only guessing here but I would consider the RentalHistory more the 'contract period'. If rent can change over time, the rental agreement on the monthly charge would be in Rental History ... charge THIS Tenant THIS much for THIS property for this timeframe. Your Invoices should be related to this RentalHistory table as: 'this invoice is charged to this tenant during this rental agreement for this property. I guess that was two things, LOL.
  2. Help with relationships

    That is fine. And, as you have it, one Tenant can be 'paying' for, or be responsible for, one or multiple Property Listings. I would suggest that what you consider 'Rent History' should actually be a join table between Property and Tenant. Join Property_IDFK from Property to RentHistory. Then join Tenant_IDFK over to Tenant. This allows more flexibility, such as a Tenant leaving then coming back and it allows one Tenant to be responsible for multiple Properties etc.
  3. Help with relationships

    Hi Karina, welcome to FMForums! Your relationships look correct but let's walk through it. Please indicate if any of the following are incorrect: One Tenant can have multiple Property Listings. One Property Listing can NOT have more than one Tenant. One Tenant can have multiple Invoices. One Property Listing can have multiple Services against it. One Service can NOT apply to multiple Property Listings at a time. Does that fit for you? As for the Rent History, that would probably depend upon the answers to 1 and 2. Also, it isn't needed for this specific question but it helps if you complete your profile. It would help to know your self-rating so we know whether to go into specific detail with our answers or whether you'll be familiar with various terms etc. And for many questions, it helps to know your OS and FM versions. :-)
  4. Value List sort by related field

    I was wrong. From perspective of TIMESHEET, a relationship between two stored values (employee) and TIMESHEET::date ≥ gDateFilter WORKS (global calculation). It only identifies the first related child record but I wouldn't have thought the relationship valid at all. I just assumed and changed the relationship and it worked but it wasn't necessary! Maybe I'm getting rusty! ;-) Courtney, I just changed value list in your Example to 'sort by second field (your unstored calculation) and it works as you wish (I think). Did you have something different in your real file than this Example file? Also please note that, although I was aware of some types of value lists working even with the "This value list will not work because it cannot be indexed." message ... I did not expect it to work in this situation. I double-smacked myself! Anyway, let us know if you still need help with it and thanks for opening my eyes a bit. I sense Comment's influence here.
  5. Value List sort by related field

    Hi Courtney, Try it now. Notice that I corrected your graph. Your perspective was TIMESHEET but you had the child side set up with the global date. That won't work. I reversed the relationship and reversed your value list. Does this give you what you want? ExampleMOD.fmp12
  6. Non-functional join table

    Hi, a few things to try: Field behavior allows entry in browse mode. The portal is based upon Membership table occurrence. The fields in the portal are from Membership table occurrence. The data types of the IDs are all matching. The layout is based upon either Exercise or Group. Make sure the fields are within the portal. I just noticed ... you have the portal based upon Group. It should be based upon Membership.
  7. It seemed that the requirements were for a generic script which didn't have to hard-code the table occurrence and which would set all records in the found set. A loop would be required since ReplaceFieldContents can't handle a variable table occurrence name, thus using Set Field by Name[].
  8. Select the object which is your button. Right-click to bring up the field options. Select Button Setup. Select Perform Script and find your script in the list and select it. There are a few cautions with your concept which I'll mention briefly: I don't know what you are doing but whether it is clearing month-end values, flagging records, or something else, you will want to include error trapping in case a record is locked and thus can't be modified. You've rated yourself as Beginner so I doubt you are running a standard Developer process such as synchronizing records. I am concerned that your script suggests that you might be 'over-working' your data. You have come to the right place for assistance to help you stay on track so your solution works well. Let us know how it goes! :-)
  9. Ah. Of course. Well this will run by the firing of a script which takes place on the table occurrence they are on so it wouldn't be clearing all tables ... only the table they are on when they wish to clear them. It's a fine distinction, for sure and I think we have it covered!
  10. Hi TeachEd, You'll need a looping script as Lee has indicated. Just use your Set Field By Name [] in place of the Set Field[]. This will allow the script to be flexible across different tables and various table occurrence names.
  11. We don't know if you are working with a sorted set nor whether the record being duplicated is the one 'last visited' or immediately prior so I would suggest, to expand on Tom's suggestion, that you use a script parameter. Create a script named Duplicate record with these steps: Set Variable [ $value ; yourFieldHoldingTheNumber ] Duplicate Record Set Field [ yourFieldReceivingTheNumber ; $value - 1 ] Replace the 'yourField' portions of the above script with your actual field name (you can double-click it to insert it). Then attach this script to a button called Duplicate Record. And welcome to FMForums! :-)
  12. Search until, then

    I wasn't implying you would do anything 'behind her back' ... I was only properly cautioning you. We still need to see the script if you wish to know how it would be changed to meet your request, which still isn't quite clear. :-)
  13. Search until, then

    If the script is searching for EXACT, then it probably begins with == but we can't say for sure without seeing the script. Find the script, print it to PDF or save as PDF and post it here for us. However, I would caution about considering a change without speaking with the developer. There may be good reasons it is finding exact in this instance. Still, we are happy to take a look for you to help you understand it. :-)
  14. Search until, then

    I'm afraid that your response didn't help us solve the issue here. The dash makes no difference - ANY word starting with 'chicago' will have been found. Are you searching a related table? We need more information then to help you because searching would work fine in your examples.
  15. Search until, then

    Hi, FM Help covers it quite well here: Finding records To find in this example ... enter just chicago The dash is a word separator but even without a word separator, searching for chicago will also find chicagoian. What are we missing in understanding your request? If the example wasn't quite right, and you want to find a word which is WITHIN other text, then you can use the wildcard character as: *chicago*

Important Information

By using this site, you agree to our Terms of Use.