Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


rwoods last won the day on July 13 2019

rwoods had the most liked content!

Community Reputation

29 Excellent

1 Follower

About rwoods

  • Rank
  • Birthday 07/09/1973

Profile Information

  • Title
  • Gender
  • Location
    Nottingham, UK

Contact Methods

  • Website URL

FileMaker Experience

  • Skill Level
  • FM Application

Platform Environment

  • OS Platform
  • OS Version
    OS X 10.14 Mojave

FileMaker Partner

  • Certification
  • Membership
    FileMaker Business Alliance
    FIleMaker Platinum Member

Recent Profile Visitors

4,509 profile views
  1. Hi John Filemaker stores times as seconds from the programmers point of view, so you can just add a number of seconds and FM will do the arithmetic correctly. 3 hours = 10,800 seconds So 10:00AM + 10800 = 1:00PM newTimeField = oldTimeField + 10800
  2. Hello Relationships need indexable (or global) fields on both sides of the relationship, so the problem will be that c.OrderStatus is not indexed. And you can't index it, because it is a non-stored calculation, probably because it references fields from a relationship itself. You need to make c.OrderStatus a stored field. Do this by either :- 1) Making it an Auto-Enter calculation (rather than a calculated field) as this can be indexed. FileMaker will not update this Auto-Enter calc automatically whenever the related fields it references change their value, so you will need some sort of trigger in there to force it to update. 2) Maintain the value of c.OrderStatus in your scripts (or layout/field Script Triggers), don't have it be calculated at all. It is a pain that you can't make relationships be based on unstored calculations, but I suppose it is for performance reasons. Relationships need to work fast, and unstored calcs can be very slow.
  3. You can also tell if your fields are within your portal by using the 'Objects' pane on the left hand side of the FM17/18 screen in layout mode. Single-click the portal in the layout to select your portal, then look at the Objects pane. There will be a disclosure triangle to the left of the portal's entry, and if you click that you will see which fields and other objects are within the portal (they will be indented). If they are not within the portal, then they will not show within it. I have found that cut->click inside portal->paste sometimes convinces FM to paste them within the portal. Or just drag them out, drop them, count to ten potatoes, then drag them back in might do it. I believe it is the top-left pixel of the field that needs to be inside the boundary of the portal for it to be considered to be 'inside' it. The bottom-right of your portal does not matter, it can be way outside. The Objects pane is 100% accurate though...
  4. Hi Dominic You could rewrite your code as follows. Assuming the pattern you have established so far carries on into the future, it will save you having to edit this calc in the future Case ( //First case is true if date is prior to 1st April in its specific year Month ( Date of Referral to Regulatory Body ) < 4 ; Year ( Date of Referral to Regulatory Body ) - 2011 ; //Second case is true if date is on or after 1st April in its specific year Year ( Date of Referral to Regulatory Body ) - 2010 )
  5. OK, in that case... 1) Enter find mode 2) Select First Aid Level 2 3) Hit return (you will now have those that have First Aid Level 2) 4) Enter find mode 4) Choose Car at level 3 5) Choose 'Constrain Found Set' (this performs the second find only on the results from the first find) This may be awkward for inexperienced users, so you could create a script that steps users through this. I don't agree that you cannot concatenate two fields Table2::Skill & Table2::Skill Level would give FirstAid2, Car3 etc and you may need to do this. But I may be missing something...
  6. You have to add a second find request. So if you are in table 1... 1) Enter find mode 2) Select First Aid Level 2 3) Add a 'New Find Request' (Cmd-N or Ctrl-N depending on platform) 4) Choose Car at level 3 5) Hit 'Return' One thing you need to be aware of, is that FileMaker does funny things when searching in portals. If you select First Aid in one field in the portal, and Level 2 in another field in the same portal on the same find request, FileMaker may think you are trying to find one or the other (OR) rather than both (AND). You may have to create a single field in Table 2, which concatenates the two pieces of information, and then search on that new field in the two find requests, to get what you are looking for.
  7. I feel a join table coming on!
  8. Hello Not sure if you have tested this at all, but my understanding is that so long as those file references in your other files are not called (i.e. you are not a on a layout that shows data from them, and not calling scripts that use them), then FileMaker will not attempt to open them. Therefore, so long as you set the global variables before you first make a reference to the files, FileMaker will not attempt to open invalid file paths.
  9. So you are saying that 'delete child records' is independent of the layout that you are on at the time? So that delete fires if *any* relationship between TO's based on those tables has the 'delete child records' option set, regardless of which layout you are on at the time?
  10. Presumably bcooney meant that both the parent and child TO's are repeated, and set to delete via the relationship, and therefore only when you are on a layout based on those new TO's does the cascading delete occur. Provides a way to perform that function for the developer, without risking it happening inadvertently from the main TO's used in the solution. Maybe?
  11. Hello again Last time you said you were entering subdomain.domain.com and the record with server.subdomain.domain.com was not being found. I explained that before. Today you are searching for server.subdomain.domain.com (which FileMaker thinks is just one word) and it is finding it, because it exactly matches the word stored in your record.
  12. Hi John I think the issue is that you are using a value list in a situation in which it was never really intended to be used. It seems like you are only setting these records up once (since you don't want any duplication), so why have a value list? A value list is used to guide users so that they only choose valid selections when filling in a field, but your users won't be setting up records using that list perhaps? You are probably only setting up one new record each year. Why not just type in the year when you setup a new record? I can't think of any easy way to do what you originally asked, it would be a whole lot of effort for no big benefit.
  13. Hello You are only entering one word, the dots don't appear to FileMaker as word separators. Quick Find doesn't support wildcards, so you cannot type *subdomain.domain.com for example, which is a shame. This article explains that the only operator you can use is the "" "" operator https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fperforming-a-quick-find.html%23wwconnect_header So quick find probably won't help you here. You could create an auto-enter calculation field (text) and substitute '.' for ' ' from your other field, and then add that to the layout and make it available for Quick Find, but that is a bit of a cludge.
  14. Hi qasalla Some thing in Filemaker are very easy, and some are more complicated! Relationships allow you to show portals. If you want EVERY study type to appear for EVERY participant, then the relationship that you use would have to be a 'cartesian join', that is one that succeeds in every case. You do this with the 'X' symbol when defining the relationship, and you should just use the Primary key in both tables, with the cartesian join, to create that relationship. Then you will see every study type for every participant. However this isn't very useful. If you have a field in the 'study' table that is 'Eligible_BOOLEAN', where the intention is that you somehow set that if a participant is eligible for that study type, then it will be the same for EVERY participant. This is probably not what you want. To solve this you have to setup a JOIN table, that is a table that has a record for each time a participant is involved in some way with a study type. The join table has two foreign keys, one relating to a participant, and one to a study type. You then need to find a way to add a record in that join table each time you want to store some information about that participant in relation to that study type. I've enclosed a little example, which I hope starts you on the right path. You pick the study type from the popup menu in the 'Participants' layout, and it will add a JOIN table record for that study type for that participant. You can manually select if they are 'Eligible' although you may have a different way of working that out. As a clue, it uses a Script Trigger on the popup menu, to run a script, which adds the JOIN TABLE record. Have a poke around it and see if that helps at all? Example.fmp12
  15. Hi Greg It would be helpful if you could post your database on the forum. It will be something to do with the setup of your relationships probably, in that it is generating entries in the TYPE table when you are choosing the type in the cards table. If you post the DB then I'm sure I could give you the answer quickly! (or someone else might beat me to it)
  • Create New...

Important Information

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