FM Server :13.0v5, Win Server 2008R2

Clients on LAN: Win 7, Mac 10.10, FMP 13.05, FMPA 13.0v5

 

Some, but not all, of my finds unexpectedly stop working, but the problem is always resolved by restarting the FMS.

 

Three different tables affected that I have noticed so far, but only one or two of the finds in those tables. Changing to a different layout for the same TO makes no difference. If I use a scripted button, right click constrain found set, manually enter find mode and enter find criteria...different ways of attempting the same find just stop working. Other finds on that layout, that TO work fine. Sometimes the sort order of the found set changes, but the set is not constrained or a new found set does not appear. There is no error message, except if it is just a straight find and it gives me "No records match the find criteria...." even though that is clearly wrong.

 

I first noticed the  problem back with FMS12, but it was rare - every 6 months or so, therefore didn't bother about it.

When first moved to FMS13 still a rare problem, still fixed with a FMS reboot.

But just this year it has become more frequent and now requires a restart every day.

An older version of my file running on a FMS12 also has the problem, but still only occassionally.

 

As a test I changed the scripted button to PSOS and...

"The operation could not be completed because the target is not part of a related table"

But the field is in the layout's TO?

 

Any suggestions??

 

Any of the fields you search on unstored calculations?

 

the PSoS thing may be a red herring - PSoS also runs the file's OnOpen script, perhaps there is a find there that is out of context because of a script step that is not supported server-side?

Yes actually, I see some unstored calcs in there?

 

Are they the problem?

Opening script will take it to a different layout with the wrong TO

Any of the fields you search on unstored calculations?

 

the PSoS thing may be a red herring - PSoS also runs the file's OnOpen script, perhaps there is a find there that is out of context because of a script step that is not supported server-side?

Can you explain what the problem is with unstored calcs, and any suggestion about how to fix it?

The issue with unstored calcs is that FM has to calculate their value across the whole table before it can begin the search.  Which may take a long time depending on the # of records you have and that may push your script schedule past its allotted time.

Ah ok, thanks Wim

 

Is there anything I can do about that?

The obvious, right: avoid unstored calculations where you can on large data sets.  Find ways in your scripted workflow to set the data statically...  Sorry for the generic answer but I can't give you more detail without knowing the design of your solution and what you store in those unstored calculations.

Thanks Wim. I was hoping you would say something like change settings or upgrade the server, ... but I really should learn this lesson about unstored calcs.

 

 

So for example, one of the offenders is a table of invoices, with an unstored calc field "Amount Owing"

(Invoices::TotalLineItems - Invoices::SumPaymentsApplied + CreditNotesOnInvoices::Amount Paid)

 

And the search is Constrain Found Set "Amount Owing ≤0"

 

Where would I start to work around this?

Sure, you could upgrade the server, but that is just pushing out the problem.  That would be like trying to make a car that is stuck in first gear go faster by shedding weight instead of fixing the transmission.

 

Your example would need fixing at the root:

- the total for in invoice is set by script when you add/remove a line item or update quantities or product

- applying payments is a transactional process that updates the invoice's "due" amount - that field then becomes a static number field

 

Don't try to calculate things over and over where there is a distinct process that updates those numbers and you can calculate it once and be done with it.

Thanks Wim, I see what you mean. I will have quite a few to fix.