Sounds like a known issue and yes, it's been around for a while.
Anyone know if it's still an issue in 13 or 14?
For More Information see: Find with Complex Relationship Triggers error message and fails
This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip
Looked in bugs database ... thanks! The closest I could find was BugID 343 and linked to this article "Find with Complex Relationship Triggers error message and fails". This is the exact article that you sited above. This is not a 100% match ... notably, this problem doesn't throw an error ... just returns nothing.
Are there any tools that let you see the inner workings of FM ... specifically, something like in SQL Server, there is a query plan diagram ... and you can see how it plans attacking the query?
I appear to have duplicate reports in the KBL and both reference the same report thread.
Take a look at this report: Finds on calculation fields computing values from global field based relationship fail
This is from Report #204. Note that "calculation fields computing values from global field" would be an unstored calculation field.
Desperately need some more info: Is this issue solved? If so, in what version?
We came across this issue one or two month ago - with a large FM solution that was created from scratch but has very old data (imported from an older multi-file FM solution). First, we were really afraid that the file was damaged but couldn't find nothing... The solution is running almost for a year - it was working fine for the first reportings (where those 'finds' are used)..
Fortunately, the reports that were affected were 'looping reports', so we could just add a line in one of the loops and the 'find' became obsolete. Investigations took quite some time, tough..
We're about to migrate to 14 (will wait some time...) - so, could one kind soul tell me if that issue is solved?
@markus: we have some work arounds for this (but no permanent solution) ...
1. Server Reboot.
2. Create a new index, on that table (or a table in that table occurrence graph), or drop an index and recreate. We just found this work around a couple of days ago.
BTW: I've also started yanking these find criteria from looping scripts as well, and just checking the value of the unstored calc in the loop itself.
Hope this helps; I feel your pain.
we also realized that after a server-reboot, the 'find' will show the results - for a while. At the moment, we're fine with our method - but the customer is running about 10 different and separate solutions - with about the same reporting meccanos.. I'll have to check for those 'finds' everywhere.
Here, after the 'find', the scripts are looping through the found set and marking records - so, I can use that loop for deselecting non-wanted records - makes the original find no longer necessary
Thank you for your posts.
We are currently tracking another issue which sounds similar:
In essence, a find on an unstored calculation may stop working in a hosted file, where the calculation field is based upon an aggregate function of a related table. If the aggregate function is based on the current table, it works.
Your description in the original posting "Steps to reproduce" appears to confirm the other link.
I have attached your post to the original report. When more information becomes available, I will post again.