Jump to content

Wim Decorte

Members
  • Content count

    5,325
  • Joined

  • Last visited

  • Days Won

    148

Wim Decorte last won the day on August 15

Wim Decorte had the most liked content!

Community Reputation

455 Excellent

4 Followers

About Wim Decorte

  • Rank
    member
  • Birthday 12/17/1968

Profile Information

  • Title
    Sr. Technical Architect
  • Gender
    Male
  • Location
    Toronto

Contact Methods

  • Website URL
    www.soliantconsulting.com

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    10.11
  1. DDR - where to focus?

    That's why I recommended starting with the FMS logs; it keeps good track of the 4 traditional machine bottlenecks: processing power, memory, disk i/o and network i/o. If those stats show strain on any of those then the consideration is: how much strain and is there a possibility of solving it with more horsepower.
  2. DDR - where to focus?

    messy file references: any file reference that has multiple entries, some of which lead nowhere; multiple file reference entries that really point to the same file,.. Portals: understanding how a portal forces FMP and FMS to exchange data is crucial. If you have multiple portals (and worse: of the portals are filtered, sorted or use a sorted relationship) then you have multiple of those interactions going on just to draw the layout. A lot of performance problems I have had to deal with over the years come from too much unneeded data being displayed on screens.
  3. DDR - where to focus?

    Collect info from the user users about what exactly is sluggish, otherwise you may be fixing things that don't need fixing. Also use the FMS stats log and the top call stats log to help put some numbers to it. While you wait for that, try to map out some of the usual suspects: - messy file references - layouts with more than 1 portal on it - sorted relationships - layouts with lots of unstored calcs and/or summary fields on it - ...
  4. Problem when I use OnLayoutKeyStroke.

    Cross-post from FM Community: https://community.filemaker.com/thread/177497
  5. need windows 10 to store filemaker 16 password

    From the menu: File > File Options > the "open" tab
  6. need windows 10 to store filemaker 16 password

    The ability to store the credentials in Windows' Credential Manager is an option set on the FM file. If the developer turned that option off then you can't use it.
  7. Does FQL actually work?

    FQL is executed on the server as a rule. It is executed on the client if that client has an open (locked, uncommitted,...) record in the target table, any table that is part of the SQL query. Only the client's open record state counts. If other users have open records then that does not matter. Obviously their data will not be in the result set since neither server nor the executing client knows about that data yet, it has not been committed yet. When the server executes the FQL, nothing is cached on the client because no actual record data was sent down. If the client executes the query then server sends *ALL THE DATA FOR ALL THE RECORDS* in the target table, and that is cached at the client as much as the client's cache allows. It is that sending of all the data from the server to the client that is responsible for the slowdown. You can actually see this in action by looking at the FMS stats log, the "Network KB Out" counter. If there are not a lot of record in that target table then the penalty is not high, but it is very linear with the record count. In that demo file I linked to earlier I have two tables to test with, one with 100,000 or so records and one with 1.5 million.
  8. File location in Mac OS (iCloud)

    Haven't looked into it specifically but the risk is real. Even if the current implementation is safe and does not touch open files, you'd still be at the mercy of the Apple Engineers changing it without you knowing it.
  9. Exporting from several fields to one filed in Excel

    Via a script: absolutely. What you are describing is often referred to as a 'scratch' table. A table whose data you will export but that is only there to transform the actual data into whatever form you need for exporting. When you are done with the export you can delete the data from the scratch table. There are other ways too, ranging from exporting from each table individually and using OS-level scripting to concatenate the 3 exports into one excel file. Or exporting to FM XML and using an XSLT style-sheet to transform that XML into an XLSX format.
  10. Subscripts

    Didn't say that it was, just how we do it and why. Doesn't matter where the "problem" comes from; our practice makes it safe no matter what someone's expectation is. For any level of developer, one of ours or one of the in-house devs. It's clear and well-understood.
  11. Subscripts

    I'll counter that. One of our standards is to always an explicit "Exit Script" and to explicitly pass an empty string "" when no real value needs to be passed out of the script. The main reason is that the Get(ScriptResult) will remember the last explicit returned result. If you don't use Exit Script in the sub script but expect Get(ScriptResult) to be empty because you didn't pass anything back then you may be surprised to see a value if a previous script did use Exist Script with a return.
  12. Story of our lives When you run the code locally are you touching that same FMS?
  13. Filemaker Go & Webdirect

    Both should work, they use different protocols. How do you try to access the file through FM Go?
  14. Yes, but no wildcards AFAIK
  15. Does FQL actually work?

    My test file from the devcon presentation a few years back can be found here: http://www.soliantconsulting.com/blog/2016/04/bag-goodies-executesql-named-buckets-relationinfo
×

Important Information

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