The first and simplest and perhaps not productive idea would be to open its Edit:Preferences and click on the Memory tab and set the cache to 512 for 15, 256 for 14 or whatever the max is. This often produces a boos in speed but perhaps not what you are looking for.
The answer may be in the statement: The files in the solution (there are 64) were developed pre FM version 7, and the logic in the script works but is antiquated in design.
I have seen in the past where my favorite software on a Mac stopped development yet it kept working for new OS after new OS but I could see degradation. And then one OS upgrade it just quit as it couldn't deal with the changes.
Now the second thing you can do is simple and has produced significant improvement when using 15 and it begins to bog down on my laptop. Do a Save Copy As and use the compression choice. Quite all computers. Rename your file File OLD.fmp12. Rename the copy to the original file's name and place it in the same folder. Now open it with the offending computer and see if it works faster.
So much for theorizing. What you need is a copy of FIleMaker Advanced and to step through each line of code in the script in question. FileMaker 14 and now 15 seems to pause and freeze a lot even with a new file and new scripts and so the problem may be with a bug in FileMaker rather than your scripts or both...
Some developer may have a few year long task rewriting your files for you...
Check that computer's hard drive for issues.
FileMaker clients create and maintain a number of encrypted temp files on the client machine. If drive issues such as very limited free space or some bad sectors exist, this could greatly limit the client's ability to exploit temp files in order to get faster performance and that in turn can slow down that one client machine.
I have seen this happen, where a machine had a bad network cable
Are you sure the Latency is the same for each machine ?
It would also pay to run Recover on the files, and check the Recover Log for "Problems". You never know
Is everyone Windows 10 ?
> one computer (out of 8) that takes almost a minute to run a find script. Seven other computers push the button, results appear in 1/2 second
Re: "Just the one button/script on this one computer is slow."
Why don't you post the offending script? I'm sure someone will be able to spot possible fixes if you do.
I've experienced this same scenario in an office from a dying hard drive.
Check any user specific settings. Can you log-in to your solution on that computer as another user?
Thanks for all the replies, everyone. I address each below:
First off, this issue is closed with the client. He will buy another computer rather than pay to have it worked on by a tech or by any paid developer. It's cheaper that way (his opinion). I am convinced it is the computer or it's software configuration itself, as the script runs fine on a similar machine running Win 10. I posted this because I have never seen this type of problem (where only one script is involved) in my years of tech support and FileMaker development (I've been doing this since 1989).
Second, I neglected to mention in my first post that I recovered all 64 files, and none of them had any problems. There were other system wide performance issues (now solved) that mandated recovering the files.
gofmp: I can't try that now, no access to the computer. I did run the script on my Mac with script debugger. While the style was old, making the script longer than necessary, it functions properly when stepped through (as well as when it is at full speed on the other systems).
philmodjunk: Good thought. I did not have the tools to do a decent check on the hard drive. Usually, though, a bad hard drive displays problems with other programs and the OS, and this system was stable.
gdurniak: Good thought. I suspect the network card or it's driver may be an issue, but generally speaking, that would affect other internet and network calls. Can't check that now, though.
keywords: Another good idea, but I don't have access to share it now.
CarlSchwartz: I successfully logged on as admin and the results were the same.
Thanks, everyone. I'll let the client know of the discussions here. He can then make his own choice.
Other applications are often not as "drive/tempfile dependent" as FileMaker and thus might not be as noticeably affected by such an issue as FileMaker. First thing that I'd check is how much free space is on that drive. If it's very limited, that might be the whole issue right there.
I'd also do a re-install of FileMaker--can't hurt, might help.
And please note that recovered files are not necessarily "repaired files". Usually they are, but recover doesn't catch every problem and can't fix every problem that you might have with a given file. Replacing with undamaged back up copies, if at all possible is the better option.
Thanks for the advice. I won't be going back there for this issue, however. The client computer had FM 14, then a clean install of FM 15 - probably would have addressed the corrupt file issue.
A full hard drive (or mostly full) is a decent possibility. I will ask the client to look at that.
Solution found by client! He found a program named Blue Stack (it allows android apps to play on a Windows machine) installed without permission by a previous employee in September. Once removed, the script runs great.
This is an unusual solution – I would have ever guessed. Generally speaking, software conflicts cause more problems than one tiny thing like this.
Thanks everyone for your suggestions!