Leaderboard


Popular Content

Showing most liked content on 09/17/2015 in all areas

  1. You need to have an ID for each patient record and each visit record created must be related by that same ID (patient::id = visit::patient_id). To script your buttons to create a new related visit record you would need to set a variable to the patient ID, freeze the window, go to the visit layout, create a new record, set the patient_id field to the variable and return to original layout. Why are you limiting the system to only track up to nine visits? I think a better solution would be to have visits displayed in a portal and just use one button to add a visit - an unlimited amount of visits. You can then edit the visit record within the portal or use a pop-over.
    2 likes
  2. Dave and Steve: you're right! I made a simple example file to demonstrate this. WindowTest.fmp12.zip
    1 like
  3. Bruce, I'm confident what I said in my first post is accurate but I should clarify, the found set of the TO of the *current layout* stays the same when opening a new window. However all layouts based on other TOs revert. Keep in mind, in terms of maintaining found sets, FileMaker doesn't actually care about the layout, but rather the TO (not base table) of the layout. Here's a 1 minute video of what I'm talking about: https://youtu.be/fES-BcJCizE Steve's experience is a direct result of this behavior.
    1 like
  4. It sounds like the field where you are making the selections is in the Collections table, instead of being in the Requests table, where it belongs. Indeed, that would seem like a more flexible solution - see if the attached helps: Collection 2.fp7
    1 like
  5. The biggest misconception here is that you think the relationship graph is an ERD. It is not. So this statement, based on your graph: Is not possible. Each relationship on the graph is bi-directional so not all relationships can be one-to-many in all directions. Each object on the graph does not represent a table, but a table occurrence. Before you get to deep into other thinking, read up on this notion and the various graph management approaches. This is a good place to start: http://www.nightwingenterprises.com/Resources/approaches_to_graph_modeling_en.pdf Anchor/Buoy is an easy one to grasp and will get you where you want to be quickly: http://www.kevinfrank.com/anchor-buoy.html, but keep an open mind for the other approaches. As to your problem, context is everything. You will need a layout that is based on the TechnicalInspections table occurrence. If the relationships are set up correctly you can get data from that context you will be able to see the related data. Whether you actually need to bring some of that data over into the inspections table has nothing to do with relational design, but is a business logic question: if you want each inspection to reflect the state of the craft and its ownership at the time of the inspection then you should not use the most actual related data since ownership may change over time. In that case you will need to grab and store the point-in-time data. What you probably need is to find a tutor/mentor in your area, someone who can sit with you for an hour or two and walk you through the basics. You can start that search here: http://developer.filemaker.com/search/ If you have not already done so, purchase the FileMaker Training Series (http://www.filemaker.com/learning/training/fts.html - only $50 or so) and go through the exercises. Don't skip any because while you know relational design based on Access, you need to learn the basics of how it is implemented in FM. If you skip it you'll keep getting blocked on conceptual things.
    1 like