Jump to content

LaRetta

Members
  • Content count

    10,930
  • Joined

  • Last visited

  • Days Won

    144

LaRetta last won the day on January 16

LaRetta had the most liked content!

Community Reputation

492 Excellent

6 Followers

About LaRetta

  • Rank
    Lifelong FM Student

Profile Information

  • Title
    Developer
  • Industry
    Software
  • Gender
    Not Telling
  • Location
    Everywhere

FileMaker Experience

  • Skill Level
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    El Capitan
  1. SQL SLOW

    Considering OneStop's request, an unstored calculation which needs to compare every record in the same table using DISTINCT, particularly if any record is open, would be a resource nightmare as I suspect he discovered. But why not simply create a script which uses that same single ExecuteSQL() step after making sure the record isn't open? Via script is the only way I ever use *ExecuteSQL(). Ah well, I shouldn't have stepped in since I didn't take the time to read the entire discussionl. Thank you for clarifying, Olger! * and yes, there are always exceptions such as a smaller or single-record tables.
  2. SQL SLOW

    The point is that creating a calculation field using ExecuteSQL() is not recommended.
  3. SQL SLOW

    Hi Barbara! As I explained, I really haven't followed this thread and was simply making an observation about Tom's mention of ExecuteSQL() in a calculation and Josh's mention of using a looping script. Depending upon the need, I thought PSOS was a good mention here. Nice to see you!
  4. SQL SLOW

    You took the words right out of my mouth, Tom. Unfortunately, I hadn't had the time to follow this thread as I'd liked. Wim explains it very well below, link here https://community.filemaker.com/thread/149215?start=0&tstart=0 (although the entire thread is well worth the study). OneStop, you're lucky to have such great assistance. This is why I still ask questions here as well. :-) My apology for not reading the entire thread so I'll only suggest that using Perform Script on Server is lightening fast if you can use it. I'm still blown away at the speed differences. Agnes, you've been quite helpful and respectful throughout. This forum is lucky to have you assisting.
  5. Move characters

    Not quite. OneStop, you'll need to search for *-
  6. Hi Steve, There would be no reason to make this stored data unless the User needs the ability to change that date. Making it a stored calculation is better option. :-)
  7. We would need to see your file. We can't give a solution with no information on how you are structured. Did you search here for scanner scripts as I suggested?
  8. I am not available right now and it looks like you have lots of good help. Also, I simply have never used a scanner so I would hesitate in assisting with the scan portion. I only have one suggestion for you at this point: do not rush this decision. Be sure this step gets you closer to a structurally-solid solution. Changing a structure later on (once it has business data) is much more difficult than designing it properly in the first place. Really, I again suggest you create a record with the scan. You can search here on FMForums; I know there have been many examples presented on scanning and creating records. Hang in there. FileMaker is fairly easy to learn but it still is not simple; particularly an inventory process.
  9. I see Dan responded about searching but I had created this sample file showing how you can add or decrease values in any number field using Show Custom Dialog[]. So once you've found your desired record, the user action of selecting it will pop up a dialog. However, it usually works better to use RECORDS to add or decrease a field's value because that will allow a history of the changes. If you simply change a field, you will never know when it was changed, who changed it or its prior value. You would completely lose your audit/history trail and if a mistake happens, you'll never know how to switch it back. Using a related table showing an 'adjustment record', or even adding a record in the same table might be better approach (we have no reference of the purpose so it is difficult to provide more definitive answer on where the adjustment record should be created). If you wish to explain the purpose of this action, we could help you pin it down further. I hope between Dan and I, we've helped you move forward on your request. :-) AdjustAmount.fmp12
  10. Change hover style on fields in read mode

    Hi Tamanna, welcome to FMForums! You haven't indicated your FM version or OS. Please complete your profile since it can make a difference in what we recommend. Please see attached (you must be signed in to download it). You can select your portal (in layout mode). From Inspector, select the third tab (styles). Pop open popover of portal to show portal row. Pop open the next popup and change to 'hover' and change the fill to yellow or your color choice. I realize this isn't changing the FONT but won't this work instead? test.fmp12
  11. 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.
  12. 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.
  13. 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. :-)
  14. 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.
  15. 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
×

Important Information

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