Jump to content
  • Our picks

  • Topics

  • Blog Entries

    • By David Jondreau in Wing Forward Solutions
      In the blogs and forums I favor, there’s a buzz over the past few years about “intermittent fasting”.  The idea is that not eating all the time is healthy. As far as physical and emotional health benefits, the pop science seems intriguing and it meets my common sense filters, so why not try it?
      There’s a few different versions. 16/8 is popular. That’s where you only eat in the same 8 hour window each day. Say, from 10 AM to 6 PM. That’s sounds helpful, something I would call “time-restricted eating” more than fasting. I can do that unintentionally depending on how my day rolls out. I want to fast though.
      There’s “24 hours:. Pretty self-explanatory, where you don’t eat after dinner one day until dinner the next. There’s 5:2 where you eat a small number of calories, 500 or so, two non-consecutive days a week. All fine.
      For me though, I’m trying full fasting. That’s no food from when I go to bed on Day 1, until when I get up in the morning on Day 3. A 36 hour fast. Two nights. That will give me the chance to feel hungry and give my digestive system a break. And I’m doing that every six days.
      I like the idea of doing it weekly, but doing it the same day, like every Tuesday or every Sunday doesn’t seem sustainable. No Sunday brunch ever? No way. A birthday dinner on Tuesday means a cheat day? Nah. I’d rather be consistent. Every six days means the day of the week changes each time.
      I put “FAST” as an all-day event in my Google Calendar, set it to repeat every six days, and follow along. It’s been three weeks so far, and it’s going great.

      View the full article
    • By David Jondreau in Wing Forward Solutions
      At DevCon 2018, Molly Connolly led a session on data cleaning. During that session, there was a question of how to import data without updating the Modification timestamp. The goal is to display when a user last modified a record, not the developer.
      Two methods* of doing that were mentioned but there is another, more robust, answer.
      It’s simple and flexible: create an additional field that references the Modification Timestamp field and set a variable flag when you don’t want to update it.
      Let’s call the default modification timestamp field “ModificationTimestamp”. Then the new timestamp field should be an auto-enter calc with the calculation of:
      If ( $autoEnterOff ; Self ; ModificationTimestamp )
      Then, at the start of the the Import script, set $autoEnterOff to True.
      Some benefits?
      It’s simple You never have to modify field definitions after the initial set up You never have to modify scripts after the initial set up It’s local to the current session. Other users won’t be affected. You can use this in other scripts, such as a scheduled server script that performs a nightly update. You can use a global variables $$autoEnterOff instead or in addition to script variables and perform developer hand-edits. *There were two other options discussed during the session.
      One to actually turn off the auto-enter option before the import and then turn it on again afterwards. I would strongly recommend against getting into changing a field definition on a live file. Plus user modifications that happen while you’re importing won’t be logged.
      The second way is to change the Import[] options to not use auto-enter options. That can be complicated by wanting some auto-enter options to fire, especially when adding new records (for primary key options).
      I can also imagine a more complicated scheme that involves multiple imports, or exporting timestamps and importing, etc. But why bother? The above method is simple with no drawbacks except an additional field.
      Additionally, you can display the user account that wasn’t a developer who last modified a field by changing the ModifiedBy field. Uncheck the auto-enter AccountName option and change the field to an auto-enter with a calculation of: If ( $autoEnterOff ; Self ; ModifiedBy ) where ModifiedBy is the default auto-enter “Modification Account Name”.
      Sample File

      View the full article
    • By Kevin Frank in FileMaker Hacks
      This a quick followup to last month’s part 2, because today I want to to dig a little deeper into JSONSetElement and take a closer look at the first argument: As I wrote last time… Part of what makes JSONSetElement so powerful is that it can be used both to create new entries, and to […]

      View the full article
    • By dbservices in DB Services Blog
      The latest and greatest version of FM Quickstart is now live! FM Quickstart is a free FileMaker CRM that’s fully customizable and works out-of-the-box with 8 main modules. Check out the article for a free download!

      FM Quickstart 17
      Joseph Yeager
    • By FileMaker Magazine in FileMaker Magazine
      While FileMaker's calculation engine is super powerful for managing all kinds of unique calculations, the one thing it lacks is a feature for running a repetitive function across a range of data. This is certainly possible within the Scripting engine with the use of the ever wonderful Loop script step.
      However, as stated, there's no way to really process a range of data using just a function. Unless... you create your own or use one which has already been created.
      As it happens, there is just such a function which has long been one of the most powerful custom functions of all possible FileMaker custom functions. It was created over a decade ago and is still, too this day, one of the most powerful custom functions you could ever learn to use. The function is called CustomList and it's a must-know function for any FileMaker developer.
      Click the title or link to this article to view the video.

      View the full article

Important Information

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