You launched a search on an unstored (and unstorable) field. Given the time it took, on a table with much more than 100k records.
N.B.: Remember that you can disable a field (Layout mode - inspector - data tab - field entry section - Find mode - uncheck) from being searched. Few people use this option, many more use the other one (Browse mode - uncheck) but it's worth remembering that it exists.
I should add that this is an extremely complex solution that I just inherited from another developer, so I didn't have a hand in creating any of it.
So in other words, telling me to not do a thing that FileMaker allows but can't handle isn't a useful answer. The point here is that FileMaker should be able to gracefully escape from any process without tying up the client for 52 minutes. You tell it to stop, it should just stop, right?
As developers – and for users too – we're going to come across all manner of solutions, some good, some bad, most mediocre. The platform should be able to manage basic functionality. So I cancel a search, it should just cancel, don't you agree?
A rifle allows you to point it to your head and press the trigger, but it's a good idea not to do it. You're asking for a head detector which will stop the action...
Filemaker gives you power, and leaves the control of it in your developer hands. Make good use of it. If you tell the server to go to the north pole and report when it arrived, it will head for it. Blindly.
If you launch a snowball but require it to stop from reaching its goal whenever you click a stop button, that snowball will reach its target days later, if it has to communicate with you every millisecond and see if you changed your idea and are issuing a stop command.
This could (and does) happen to users .....
Chime in if you've seen it, or if you can provide any insights or ideas.
I have had this happen and yes it is an annoyance, but its normally caused by a silly mistake I have made during development, in the same way I can create a script which goes:
Allow user abort: Off
set variable [$var ; 1 ]
If it happens to end users, then it should be classified as an issue with the solution, rather than with FileMaker.
Your analogies have no validity in this situation. Of course you can program a loop into a script and FileMaker will blindly follow it. FileMaker has in fact taken into consideration things like this, by allowing abort in certain situations, and allowing a developer to launch the Script Debugger to halt a script that has run awry. In fact, FM Inc. has even built in a way to stop a runaway recursive script.
Of course you can't recall the snowball – but is a search like a snowball to FileMaker client? Is it really as impossible to halt that search, the way it is to change the trajectory of a snowball? FileMaker can't "beam aboard and stop it," to make a geek reference.
Because that's what your analogy is saying. FileMaker client loses complete control of a search once it's launched. Are you really apologizing for FileMaker allowing a basic function to run for 52 minutes after the user has requested that be cancelled? And for the record, I don't think the system even cancels in this situation – it completes its task, but discards the result and puts you back where you were. If that's the case, then why is there a Cancel button at all?
If it happens to end users, then it should be classified as an issue with the solution developer, rather than with FileMaker.
The (end) user is always right.
I don't think the system even cancels in this situation – it completes its task, but discards the result and puts you back where you were. Then why is there a Cancel button at all?
That is a fair point though, one I have wondered myself in the past.
Edit: not enough snipping of the quote...
Filemaker will respond with results within a second if you search on a indexed field across 100'000'000 records.
if you do a search on unindexed fields, it's your fault. As it is your fault doing an ExecuteSQL on a set of records with uncommitted records. You just have to know the risks and code around them.
Example: We have invoices with line items and a field summing them up. Unstored.
Accounting wants to search for unpaid invoices with total > 100. How do you solve it ?
(Keep in mind that as you issue your search, 47 people add line items to invoices).
OMG, I just did further investigation, and this wasn't even a search on an unstored or stored record. It was a Go To Related Record that spawned the search, my cancellation, and the delay. So all this talk about it being a bad solution, you shouldn't do this or that (all valid, and always good to be repeated) – is moot.
This may have been a stall in the network (it's a remote solution), but this is happening on completely sound development practices. Not an issue with the solution at all.
Okay – so what this is really about is the ineffective cancel button. Network hesitation is a factor of life; can the FM client really not detect that and obey the cancel command within a reasonable amount of time?
None of which I did. So, to extend your argument (and your desire to forgive FileMaker and make it my fault), it's my fault for navigating to a related record, and trying to cancel when it was taking too long? It's my fault that I clicked a button which was labelled to suggest it would perform a specific function ("Cancel") and it didn't do that (cancel)?
Try telling that to a client.
See additional info at the end of this thread...
That is a fair point though, one I have wondered myself in the past.
Thanks! And this is my point in the thread – not to debate development practices (which turned out to be a red herring anyway), but to question those things we've wondered about and just "live with," rather than getting them fixed. Cheers!
The issue is still likely something wrong within the Solution itself.
One which springs to mind is attempting to show fields / related data from an incorrect table occurrence on the destination layout, causing FileMaker to have an extremely hard time resolving the data.. depending on how its all setup of course
Just to clarify that with an example:
Layout 1, based off table occurrence for "Clients"
Layout 1 also contains a portal based of the table occurrence "Clients_Transactions"
Within the portal, fields may be pointing directly to "Transactions" rather than "Clients_Transactions"
I have done this myself more than once and it has had the same effect.
But, I would still expect Cancel to work, perhaps similar to how you can cancel 'summarising fields' and it simply display invalid results or ?.
I hope a FM expert like cache cleaner TSGal will chime in. A GTRR (based upon a global) might still require to evaluate n keys to determine the outcome.
Not having that kind of problem in our solutions (which is different from not having had them in development) is what matters to me, the rest is academic.