Jump to content

NLR

Members
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    1

NLR last won the day on November 9 2015

NLR had the most liked content!

Community Reputation

4 Neutral

About NLR

  • Rank
    member

Profile Information

  • Gender
    Male
  • Location
    Donvale, Victoria Australia
  • Interests
    Gliding, Flying, Radio-control hobbies

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    17

Platform Environment

  • OS Platform
    Mac
  • OS Version
    Sierra

FileMaker Partner

  • Certification
    9

Recent Profile Visitors

6,026 profile views
  1. There's a quirk in the way Filemaker finds duplicates when there's a constrain involved. I know your pain. In the past I spent many hours trying to understand why and finally saw the answer. If you remove the index from the field where duplicates are being found, it should solve the problem. I came to the conclusion that Filemaker internally takes advantage of indexing (if it exists) when it searches for duplicates, and the duplicates it comes up with are always across the ENTIRE Table. Unfortunately found sets are ignored! However if there's no index, Filemaker will properly const
  2. I'm assuming the field you refer to is defined as a text field. The test below is based on this. A test for a TEXT field's contents being purely numeric is: GetAsNumber ( Field) = Field An example: If a text field contains the value: 1+4 GetAsNumber (1+4) = 14 returns false, therefore the value '1+4' would be excluded for you. On the other hand, GetAsNumber (18) = 18 returns true, therefore the value '18' would be accepted. But if your field is defined as a number field, a more stringent test needs to be used such as: GetAsNumber ( Field) = Field and Length
  3. The summary approach isn't the only way. I also like a looping method like one shown earlier by someone else. I must admit I found it difficult to grasp what your intentions are, however on a few more read-throughs of your various letters I think I get the idea... Anyway, I've put together a script which runs a loop. And within this loop there's a "Find" which gets records for each Client for the 63 day range you decribed (ie. going back 9 weeks from "today"). Then a second smaller loop within, which counts up each occasion a Pickup is done by that person. So for each person, we k
  4. Try this: To use a sub-summary value, consider the GetSummary function
  5. Take a look at my revision. I basically just redefined the field MISSED PICKUP QUANTITY••• I've left comments within the definition explaining that because this field needs to calculate when the other field it relies on is empty, you must remove the tick which says "Do not evaluate if referenced field is empty" Also I changed the definition to read: If ( IsEmpty (PICKUP QUANTITY) ; -1; 1 ) Other than that I adjusted your script a little. Because you have defined that summary field, there's actually no need to run the bulk of your script because once it's sorted, the result y
  6. There's a number function called Int (number) which strips off any decimal portion leaving just the integer part. In your example, Int ( 100.4 ) = 100
  7. It's not that hard. There's no need to close the file. Filemaker Pro has a command: "Save a Copy as" which saves a copy of the current file. It's a script step too. There are a few options when saving, such as Saving a compacted copy (slightly compressed), and saving a "Clone" (without records). It has been possible for many versions of Filemaker Pro. https://fmhelp.filemaker.com/help/16/fmp/en/index.html#page/FMP_Help/save-a-copy-as.html It's purpose is for Backing up. The command is available for single user Filemaker Pro (and Advanced) and to Filemaker when acting as the ho
  8. There are one or two ways I've done this type of thing. The sample I've just made doesn't use a script. A relationship and three fields are used: theYear: A number. An auto entered calculation = Year(Get(CurrentDate) Relationship: Based on theYear=theYear. I named it BaseTable_SameYear IncidentNo: A number. An auto enter calculation which replaces existing value. Evaluate always = Last ( BaseTable_SameYear::IncidentNo )+1 YearlyIncidentNo: A calculation of type text = theYear & " - " & IncidentNo It's important when defining IncidentNo, to evaluat
  9. Given the name of a script, you can use the Design functions to work out where its name appears in the List of scripts and knowing that, deduce its scriptID - because it appears at the same level in a List of all your script IDs. Or use this calculation: Let ( [ WantedScriptName = "MyScriptName" ; // <-- the name of your script goes here AllScriptNames = ScriptNames ( "" ) ; AllScriptIDs = ScriptIDs ( "" ) ; PositionOfScript = Position ( ¶ & AllScriptNames & ¶ ; ¶ & WantedScriptName & ¶ ; 1 ; 1 ) ; Nth_Item_In_List = ValueCount (Left(AllScriptNames ;
  10. It's probably a better idea to use a related table instead of a repeating field. It really depends on how far you might want to extend things later... Kept simple, repeating fields are OK for this type of thing, however you might find yourself hitting limitations later. Anyway, here's a method which gives sequential Item numbers which skip any empty entries... Description is your Description 'Text' field Repetition is an additional repeating Calculation field of type 'Number' defined as: If ( not IsEmpty ( Description ) ; Get(CalculationRe
  11. Regarding XML versus MER, I think either would do. I used to think of XML as safer because of its delimiters. Then again I've just now done some practice exports and re-imports back into Filemaker. So far I haven't been able to trip up the MER format. It seems to handle carriage returns, double quotes, tabs, and other characters just fine, and for ease of reading the raw file (if for no other reason), I'd now use that. On checking FM Help I see that the character separating fields varies according to language, if that's a consideration. Regarding the use of FM12 versus FM14 for import
  12. I sympathise. I can see your problem and imagine the pain and frustration at not having a clear way to get user's data out of the old and into the new. I have had quite a lot of experience in providing updaters. As I see it you have the worst possible situation in trying to jump two hurdles. First the conversion from an fp7 file format to the new fmp12, and the second being that a Runtime application is absolutely restricted to only "knowing" its own bound files with that internal binding code. Each case on its own presents challenges but both together... (a really tough one). I k
  13. I've used a method similar to this in the past for creating Name badges for people attending meetings, where the purpose is to make a person's name as large as possible to read at some distance. (People with short names like Tom have an advantage). I've reworked some of what I remembered into a demo (see attachment)... There are two versions. Because of a difference in behaviour between fp7 and fmp12 files, it was found that doing a conversion of the fp7 file was problematic. I therefore revised the script, and the fmp12 version (as provided here) now works correctly. In
  14. I watched your video and that helped a lot. Following from that, I was able to make a small file to cement my ideas, and I think it miht be what you are after.. Basically I used your Tables with minor changes. I defined a new Employees field: "NextAppointment" which calculates the maximum date from all visits by that particular person (as per your BloodTests Table). Then, in your Dashboard table where you currently have a portal displaying BloodTests, I chnged that portal to show Employees. And with those employee records you can see the "NextAppointment" field. I'm sure there
×
×
  • Create New...

Important Information

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