Wim Decorte

IIRC that is on purpose. It is too easy to do domain spoofing if you use EA for full access accounts so it needs an internal FM account with full access to confirm changes in the manage security area.

Your backup strategy needs to be set based on the answers to these two questions: - how much data are you willing to lose? This determines your 'restore points', how many backups you need to make - how much down-time are you willing to incur? This determines your 'restore time', your procedure for how quickly you need to be able to restore the files The answers also determine obviously how much effort and money you'll need to invest in making this so. Incremental backups are as close to 'transactional' backups as we have in FM. In FM they are called "progressive backups" and they keep 2 backup sets only. Progressive backups are meant to be part of the overall backup strategy, and not to be the only backup used (mainly because it offers that limited number of restore points).

my guys

We differ on that point. Plenty of people are already proficient in parsing JSON. Heck, most of guys are and some of them presented on it at Devcon. And I would probably direct people towards learning JSON parsing over XSLT any place where the two formats are available as outputs. That would obviously just be a generalization, the task at hand and the skills at hand would dictate what we use in what scenario. We try to have all the tools in our tool belt.

What specifically would you want to be convinced of? Perhaps I can point you to some demos. 'Easier' is often and largely a matter of proficiency. Joost indicated that he is proficient at XSLT so importing from XML is a good fit. For many others it is not. Few things are as fast as importing but we do have to consider the whole mechanics. If 'insert from URL' can give you the JSON and you can parse it right there from a variable instead of having to output something like XML to disk and potentially also output the XSLT to disk before importing then perhaps just parsing the JSON could be faster. Just highlighting options.

Or json if you are using FM16 and that is an available format. Parsing json is fast and easy and probably easier to pick up than XSLT if you are not already proficient in xslt.

But it's still a valid approach. Not everyone is good at writing an XSLT to import the XML; some prefer to use the FM text parsing functions to get through the XML. I've done both, depending on the complexity of the XML document.

That's the basic mechanism: export field contents to a known location (you set that, variable or otherwise), import from that same known location.

Can you define the "this"? That would help us out knowing what you need to achieve. For most deployments you don't need anything as fancy as reverse proxies. You'd need those if you want to hide the actual resource or have multiple inside your LAN that you need to route to, those kinds of things.

Did you have it working before 16 and it just now fails? Why the reverse proxy? Perhaps there is another way to achieve the same thing and work around the problem?

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.

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.

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 - ...

Cross-post from FM Community: https://community.filemaker.com/thread/177497

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