Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Finds not working - esp large sets, constrain, omit finds


This topic is 3546 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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

 

Posted

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?

Posted

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

  • 2 weeks later...
Posted

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?

Posted

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.

Posted

Ah ok, thanks Wim

 

Is there anything I can do about that?

Posted

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.

Posted

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?

Posted

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.

Posted

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

This topic is 3546 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.