Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About bcolburn

  • Rank

Recent Profile Visitors

2,645 profile views
  1. Hello all. I am trying to copy data from portal records into another related table (both share the same parent record as below) in order to populate binary fields for data analysis from a more flexible portal-based records structure.   Analysis_Variables l------------l Patients l------------l Patient_Autopsy ------< Patient_Infarcts  A patient will only ever have one record in the Analysis_Variables or Patient_Autopsy tables (that is created when necessary), but an autopsy can have multiple infarcts (entered via a portal "Infarcts" on a layout displaying records from Patient_Autopsy).  In Analysis_Variables, I have created fields for binary data input that have this shared naming structure: "Analysis_Variables::Autopsy_Infarct#_Trait". For each infarct #, there are 5 traits of interest (field names are specific for these in my database, just simplified here for ease of generalizability). My script currently looks like this:  Go to Object ["Infarcts"] Go to Portal Row [select; First] Set Error Capture [On] Set Variable [$row; Value:1] Loop   Exit Loop If [isEmpty(pk.InfarctID)]   Set Variable [$Trait; Value: Patient_Infarcts::Trait]     etc. (repeat for all record traits of interest)   New Window [Name:"Infarcts"]   Go to Object ["Variables"]   Go to Portal Row [select; First]   Set Field By Name ["Analysis_Variables::Autopsy_Infarct" & $row & "_Trait" ; $Trait]   Set Variable [$Trait ; ""]   Close Window   Set Variable [$Row ; Value: $Row + 1] End Loop  When I get to the "Set Field By Name" step, I get Error 415 back ("Related Record Required"). I have a few ideas as to why, but I'm wondering if someone can help me fix my script and/or propose a more elegant solution. I've attached a doctored screenshot of my database to help clarify what I'm doing and how everything is layed out. The main record it was taken from is from Patient_Autopsy.  Thanks so much!    Â
  2. Hello All, I was just informed my predecessor at work created a huge and hugely important database that would help me out a lot if I could access. Unfortunately, he quit and was the only one that had access to the database, since it was his personal project at work. It's hosted on a shared server and our server administrators can't access the file either. I looked at old posts on here with similar threads and none of the ideas posted worked (e.g. id:Admin, pw:blank). Does anyone have any ideas for how to get back into this file? There are four or five files like this I'd like to access and I've seen FM password recover programs available, but am wary to download and try without feedback/review first. Thanks for your help! Ben
  3. All great feedback. Thanks for your help, everyone!
  4. No response = unclear? If you need any clarification or just want me to start a new thread, let me know.
  5. Hello again. So all of these solutions were helpful, but I am now wondering how to apply them to several different link tables at once. I have multiple link tables that function this way (prescriptions, diagnoses, etc.) and all of them need a count as described here. In Laretta's solution, she retrieved a list of patient IDs from the link table and used a relationship filter to exclude them from a second TO of patients, thereby creating a portal of patients without records in that particular table. However, it seems this solution requires referencing the specific patient ID foreign key in a link table to work, thus requiring a unique calculation field like LaRetta's for each link table of interest. Is it possible to somehow create a field that can recognize the link table I'm interested in and reference that particular foreign key when necessary? For example, when I enter the layout for a diagnosis or condition. I thought about using a temporary variable to detect which foreign key to count based on the active layout, but that would still require a pretty long case() function, which usually means I'm doing something wrong. I also want to make sure that however I solve this, a count can be exported at any time, even if I am not on the layout. That is to say, I want to be able to get a snapshot of all counts at once and not have to scroll through every single diagnosis record and transcribe a count once the field recognizes the layout/record. Does this make sense? What is the best way to operationalize this idea?
  6. I can't find a way to do this. I found a great example file with a complex script that I would like to recreate without doing it step by step. any ideas?
  7. I understand. Is there an equally convenient trick for getting percentages on each of these levels without referencing the specific demographic characteristics in a unique field? I may have found my own answer: a summary field in each sub-summary part like this? FractionofTotal (g.Count_PatientID) when sorted by (g.Select_DemographicCriteria)
  8. I have a global field where you select the demographic characteristic (e.g. sex, race) you want to evaluate, chart, and display in a portal that is filtered by relationship to the interactive global field. I was planning on placing the count field in a copy of that portal only as big as the field itself in order to create an interactive count. If I placed this construct in each of the sub-summaries and added a script so that when I select a demographic, it also sorts the records by that demographic, I would then be able to further dissect the initial interactive count, no? So if I select "sex", the script sorts records by sex and the sub-summary report for sex is displayed with the portal count field dissecting portal records by male and female? If this is true, I would need a separate sub-summary for each demographic trait, no? If I am sorting by multiple characteristics (e.g. demographics as well as assigned study case type) is there a way to put a sub-summary in a sub-summary?
  9. I hate you. And also love you. Thanks. I am sometimes reticent to try every solution offered since not every one works out, but your point is well taken. Thanks However, I do have a question. If I am on a layout of Patients and want to create a portal for viewing Patient records, how can I do that? Create a second TO and relate the two pk's?
  10. I'm confused. If I use a layout and show records from Patients, there will be 2,000 (or however many records I have in that table) records in the report layout too. If it's the same table, it doesn't matter if it's a different layout, I thought. It should still have the same number of records. And I am including all of the records... that's my question. I'm trying to summarize demographic information for ALL records on file. Is it possible to see an example file?
  11. Right. But if I create a separate layout for my report that draws from the patients table, won't it have to create just as many records as I have Patients, all showing identical data? I was under the impression that this was not the most parsimonious solution and that somehow I should be able to summarize the database in a layout that only needs 1 record, since it only has one unique data set to display? I realize that just because I have 2,000 Patients doesn't mean I have to show all of those records at once, but it seems strange that I should display my data in a way that requires more than one record. This was where I initially got the idea for the Cartesian join with a table that only has a single record and is joined to the Patients pk.
  12. Sorry - I just wanna check in on this. I realize it won't be populating a graph visually for every record, but if I display database summary data on the patient layout, it will still have to populate that information every time I swich patients, no? I was kind of thinking of a completely separate layout that I could go to only when necessary in order to prevent calculations/filtering/etc from slowing down the load time per page. I only need access to the summary information once a week, but I use the patient layouts multiple times daily. Isn't putting the summary data on that layout just unnecessarily burdening the system?
  13. Gotcha. The first bit was what I needed to know. The global fields are indeed designed to be used for relationships. Also, I just meant placing it in the portal row for each record - I know how the global field will work. Thanks for your help!
  14. I think I understand your logic, but if I were to place database-wide analyses on the patient data layout, wouldn't I be generating an identical set of graphs/charts/etc. on each of my ump-teen records? My new fields would be global fields to determine graph/chart output based on user interactivity. For example, pick the demographics of interest, pick the case types of interest, etc. and pop out a chart via the method I linked to above). Other than that, I was planning on adding a global count field for each record to create interactive counts for the portals I create (to show how many records are populating the graphs/charts users select for). To summarize. You use global fields to set parameters and a chart displays the data while a portal shows and summarizes the matching records. I was also planning on creating one or two additional portals for administrative purposes, but those would only require a global search and global count field each to work as I would like.
  15. I have a main table (Patients) with many records that I want to represent and quantify data from in an analysis layout using interactive charts (method here: http://filemakertoday.com/filemaker-resources/filemaker-techniques-examples/item/216-creating-dynamic-summary-charts-filemaker-11) What is the best way to do this? I was planning on creating a new table (Study_Analysis) and using a Cartesian join between the two primary keys. Is this appropriate? This seems like a simple question, but my only other idea was to add my new fields to Patients and display those records on the analysis layout, which might mean running calculations on all Patient records when I enter the layout (I think...?). Can anyone offer some guidance?
  • Create New...

Important Information

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