Jump to content

ehwalker

Members
  • Posts

    56
  • Joined

  • Last visited

Profile Information

  • Title
    Wildlife Research
  • Industry
    Wildlife Conservation

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ehwalker's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Yes, it is the chronology that is important. For example, to calculate how long an animal has been in captivity, would need subtract the capture date from the subsequent release date. If I have a single table, then this sorted relationship would allow me to find the date of the next release by sorting the relationship and taking the first related value? In regards to design and this overarching question: I have three main child tables of Animals: captures, releases, and holdings. I have join tables sitting between each of these and Animals as each 'capture', 'release' or 'holding' record can involve multiple animals. Considering your suggestion I'm thinking that I leave the main child tables as they are currently, but use a single table for the joins between each. This seems to solve my original question because I can perform these calculations within that single table? And it seems to address several other issues (e.g. creating a clear 'history' of what happened to each animal over the course of its life). Am I on the right track here? Thanks so much for taking the time to address this. So this relationship would be valid even though it's based on an unstored calculation? I hadn't considered calculating the primary key of the other record... very useful! Hmm, how does this lookup from the list of ids in the parent record work? I don't quite understand yet.
  2. Thanks comment. Hmm, yes after considering your thoughts I think I have created separate tables where it would be better to have only had a single table.... it'll be a lot to rework this, but would also solve several other issues I've been having. Thanks for the thoughts. Hmm, yes there are meaningful connections between these child records.... what would your suggested approach be to create these relationships?
  3. Thanks comment, I suspected this might have been the case. Thanks for the feedback. I wanted to have the values stored so that they could be used in relationships to records in other child tables of a given animal. So, using this number to relate the first exam of an animal with the first 'capture' of an animal, or the first 'release' of an animal. From the 'Animals' table there are several child tables and sometimes I need these child records to be related to one another... I thought that numbering them somehow would make this simple, but perhaps it's best to think of a different approach?
  4. Hi, I have a parent table "Animals" and a child "Exams". I would like to chronologically number each Exam for a given animal based on Exams::date (i.e. first exam = 1, second = 2, etc.) and I need this number as a STORED value. Additionally, as exams are added, I need this number to update across all child records for that animal in case an exam is added 'between' two existing records (eg. Exam 1 = 1Jan21, Exam 2 = 31Jan21.... new exam added as 20Jan21, so would need the previously labelled Exam 2 to become Exam 3, etc.). I can do this with calculation field no problem with a self join relationship from Exams... but I do need the value stored. I can update an individual Exam # with a trigger field referenced in the autoenter calculation, but this doesn't update the number for the other Exam records for a given animal. Is there a robust way to accomplish this? Thanks.
  5. Ah... well, I'm working on importing very messy data from excel and to do this had setup the relationship using a "name" field in both the main database table ("Farms) and a temp. table imported from excel. In this temp table, I wanted to filter out all the records that had parent "farm" records already in the main database (based on these matching names) so that I could see which records within the excel table did not have related "farm" records so that I could create them based of data in the excel table. Does this make sense?
  6. Yes, okay thanks. I first ran into this issue when trying to use the "*" operator and the omit option to find records that did not have a related child record by using this operator within the related primarykey field (UUIDnumber) from the child table. I guess then there would be no way to do this then without changing the validation options?
  7. Hi Comment, thanks for the quick reply. Sure. I have a numeric field "Exam#" that has validation set as follows: Then, within a table view layout - I'd like use the available find operators for the find (e.g. * or # ) When trying to run the find, I get the error that the find value fails the validation and says a numeric value only can be used. If I check "allow user to override..." in the field options, I can override the validation fail and the find works as expected. Thanks for your assistance, please let me know if further clarification is necessary. Perhaps I've made some simple mistake somewhere, but I don't think I've experienced this issue in the past...
  8. Hi, I'd like to search in a field with validation set to 'numeric only' using the available find operators (e.g. match empty "=" or, zero or more characters "*") but the find is being prevented by the validation. Is there anyway of getting around this without removing field validation? I realise you can set it to allow overide, but would like to avoid that as well. Is this a recent change to FMP? I'm not sure I've run into this issue before in the past. Thanks.
  9. Ah, well that's certainly an easier solution that's quite obvious now that I think about it 🤣. Thanks for the help, really appreciate it!
  10. Thanks! As I have two table occurrences of DRUG.ADMINISTRATION (one to EXAMS and another to ANAESTHESIA), does this calculation work? It would have to be set to evaluate based from one of those occurrences, yes?
  11. Thanks Comment! Very simple, but my concern there is with data export. When exporting, would one then need to export records from each table occurrence individually to ensure that the DATE field is included in the export? This is why I was trying to populate the DATE field with the actual date rather than just showing the date through the relationship... as I thought it would cause issues with data export?
  12. I have a table DRUG.ADMINISTRATION with 2 table occurrences relating to the tables EXAMS, and ANAESTHESIA, both of which I'm considering as parents as DRUG.ADMINISTRATION records need to be created from each of these tables via a portal on their layouts. Within DRUG.ADMINISTRATION there is a field DATE which should capture the DATE of the parent. Currently, I have two table occurrences of DRUG.ADMINISTRATION; one setup with a relationship to EXAMS via DATE and EXAM.UUID and one setup with a relationship to ANAESTHESIA via DATE and ANAESTHESIA.UUID. This works fine when creating records, but if the DATE field is modified in the parent table DATE is not updated in the child table and the relationship is broken. I need this DATE field to update automatically if the DATE field is modified in the parent table. I had thought to try an auto-enter calculation/lookup or calculation field to capture this date, but because I have the two occurrences of DRUG.ADMINISTRATION there's no way (that I know of) to set this calculation to evaluate in the context of the appropriate table occurrence. Any solutions to this? Perhaps this setup is not best practice as I'm struggling to find a solution (not requiring scripts), so any advice is welcome! Thanks.
  13. Thanks bcooney for the advice, I'll have a look at this option! Hadn't thought about backups, so having the external file seems a really good solution. Will still need to figure out how to make it work with my layouts so that the appropriate identifiers will populate whenever a photo is added. Thanks!
  14. I'm looking for advice regarding strategies for storing photos/scans within my database. Currently, I'm of the mindset that I would prefer to have a single 'container table' that is used throughout the database where needed. This table would have a few identifiers, which autofill based on where (as in from which layout, or where on the layout) the container is populated. Then, there would be a single layout where all photos/scans could be browsed/filtered/etc based upon those identifiers. First question, is this design good practice or should I reconsider my approach? Please note that for my purposes a container is not always necessary for every record (i.e. some records will have photos attached to them, and many others will not), and some records will need multiple containers (a record can have more than one photo attached to it). Second, in the case this is good practice, are there any examples available on how to best implement it? I really appreciate your time, please let me know if further clarification of my question is necessary.
×
×
  • Create New...

Important Information

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