Wim Decorte

From the menu: File > File Options > the "open" tab

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.

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.

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.

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.

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.

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.

Story of our lives When you run the code locally are you touching that same FMS?

Both should work, they use different protocols. How do you try to access the file through FM Go?

Yes, but no wildcards AFAIK

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

Same deal, the connection license is included. Your users can connect with FMP, FM Go and WebDirect. But you only get 5 connections total, so if one user connects with all 3 of those then you only have 2 left.

If you use FM Cloud then your licensing will the new "FileMaker Licensing for Teams" and your license will include the FileMaker Pro licenses. So you get them with the server. You can download the installers from the FM Cloud admin console. Note that those FMP clients can not be used standalone, they can only be used to connect to the server. If you open a local database without connecting to the client the user wil get a prompt after 15 minutes that they need to connect.

Can you expand a bit on what the code is doing? Is this PHP code on the Wordpress side trying to talk to FMS on the PHP API there? Or the XML API? Or the new REST API? Also note that Windows 10 (Home or otherwise) is NOT a supported platform for FMS and you can expect issues. People that have tried seem to struggle particularly in the web publishing areas.

All of it can be automated, that's be beauty of integration. The user does not need to be familiar with mail merges or knowing how to output from Word to PDF. It really can be a simple as a button in FM, data flows to Word without any user interaction. Chances are that you'll need some non-FM OS-level scripting to make it happen but: - it's not scary - it's very rewarding - you may get a more optimal solution than trying to force FM to do something that is may not be terribly good at