Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


rivet last won the day on July 18 2016

rivet had the most liked content!

Community Reputation

39 Excellent

About rivet

  • Rank
    < = >

Profile Information

  • Gender
    Not Telling
  1. Most of my medium to heavy scripts are now performed on server. To give the users some feedback while they wait, I wanted a method that was simple and subtle. In this example I ; added a popover button with '+' icon set the feedback message in the popover title bar formatted, sized and positioned the popover added a OnObjectEnter script tigger to the popover in the script I add a PSoS step with Wait for completion set to 'On' last step of script is Close Popover
  2. normalization key question

    Yes thanks, for showing that video and introducing the party model to me, definitely some good take-aways in it. I am partly there with two main tables company and profile, which have their related; vendor, client, agency, contact, artist tables etc. But to go full 'party model', I will be curious to see how he pulls it off in FM. Yes denormalize at the invoice. Yes Docket is same as project. The verdict is out on the advantages but if I did do it, I would have a server-side script bursts the json into a table for printing. The quote system is already like that. Whenever the user edits a quote, a server-side script creates 300 records/template rows and populates the quoted items in about 3 sec, its not that bad. So I was only toying with the idea of not having all those un-awarded, never to be reported, line items, weigh down the system. thanks again.
  3. normalization key question

    If I am still on track with you; I have a table occurrence quote_agency ( quote::id_agency = partner::id AND quote_one = partner::type_agency ) so when the client does a search in field quote_agency::company, it will only return partner records that are agencies. (NOTE I forgot to mention the partner fields in initial post; type_agency, type_production, type_billto ) What if the company that was invoiced in 2015 has a name change in 2017, What name should show on the 2015 invoice after the change? yes just finished video thanks, and saw that ignore Interesting I have be debating about storing all quote line items as json until the quote is awarded, at which point I would burst into line items. Am I thinking old school on this one? There can be multiple invoices and quotes on a single project, what binds them, just a docket#? thanks again.
  4. normalization key question

    Thanks for reply, I will have a look at the video. I do have a role table for unlimited team members ; director, producer, writer etc. But in this case for searches etc I think the fix foreign key is best an still flexible if another partner type does come into play. company name field is for historical reasons. If the company name changes at some point in time, I need to have an accurate history on past invoices etc. yes just a single contact and a single email contact field, similar reason as the company field. Also it can be used as an open field that allows any name typed in, with no relationship to any table. yes a quote can have revisions docket. to clarify; an approved quote will open a new docket in the docket table.
  5. I am building a new system ground up. There are three section ; - quote - docket - invoice In each section there are three relationships going to the table partner ; - production (company) - agency - bill to table : partner fields: id, id_company, company, address, phone, contact, email quote turns into a docket and docket will then have related quotes and invoices. Once the partners are established in the initial quote, they are unlikely to change in all three section for the duration of the project. Regarding keys, this is what I am thinking and I am just looking for a 'brain check'; My thought is I want to maintain/relate the initial three partner records across all section unless there needs to be a deviation. In each section I will have three child keys for partner::id: - id_production - id_agency - id_billto By having a child key for each; - I can place the fields on layout without a portal - searches will target exact partnership type - I believe it will allow for easier modification/deviation of a partners record Thoughts, pitfalls?
  6. Help, for some reason I can't get this to work when MacOS region is set to Canada.
  7. for those using lauchbar's wonderful snippet feature, here are all the functions for the BaseElement plugin BaseElements_snipits.zip
  8. Hi Brendan, I recently ran into the same issue. I typically use ExecuteSQL function to get my data for charting. There are some limitations of this function but with some help I was able to bend the data into shape. Have a look: https://community.filemaker.com/thread/166294. Hope that helps
  9. Here is the update that allows clearing of the field. RIVET rapid time entry_v2.zip
  10. 3 Panel Slider

    updated file: admin / <blank>
  11. A while back I wanted to see if I could emulate the UI of Reeder3. While not very practical, there is a bit of an illusion that is kind of interesting. The sample has two layouts. The one you see in the gif and another with actual data. Enjoy RIVET 3 panel slider.zip
  12. Hard Gradation

    Good point, I forgot to mention it was the popover content that I am filling with the 'hard gradation'. Previously I would add an object/shape that was just a bit smaller then the popover but that would give me a slight border. The shape had to be smaller because if it was the exact size the scroll bars would activate. With this technique I no longer required an object and I get a very nice edge-to-edge color fill. I have updated the image, and will post a sample.
  13. Here is a trick I use on popovers, since its difficult to place an object edge to edge on them without activating the scroll bars. select the object set fill to gradation pull the left and right gradation handles tight towards each other
  14. I am starting a new DB and pondering the schema. In a past project I had various company types that required their own section but I had a parent table called company which would hold basically the company name. so: company: company_name, id - agency: [ separate table, agency details ] - client: [ separate table, client details ] - vendor: [ separate table, vendor details ] I also did the same for contacts: profile: first_name, last_name, id - contact: [ separate table, contact details ] - talent: [ separate table, talent details ] The new project has similar requirements and I am wondering if I should normalize it further and merge company into profile. A major benefit is searching a single table and having it return all contact and company but I am wondering if this is straying form best practice or if you can foresee any downside.

Important Information

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