Leaderboard


Popular Content

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

  1. 2 likes
    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. 1 like
    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.
  3. 1 like
    Hi Ward, I tried this and got the same responses. It is possible to create a modified version of that module that will accept a user-agent as a parameter, so you can pose as whatever browser you'd like. Please send me a direct email if you'd like an estimate for that.
This leaderboard is set to Los Angeles/GMT-08:00