Can you give more detail? Unstored calculations are sometimes unstored due to references to global fields and global fields behave differently on a shared database than a single user database, but can't tell if this is a factor in your case.
Once the corruption gets reintroduced all unstored calculation fields are unable to be searched.
There are no global fields involved. Fields that were able to be searched for years are no longer able too.
The network is mixed XP & 10.5, with everyone just upgraded to FMP10v3 over the last couple of weeks.
Server is OSX.5 server running 10v2
Data can be imported into one file from Excel. I have experienced before that unwanted characters can be introduced either from excel or more routinely from copying and pasting from the web.
Try exporting the data as XML and reimporting into a clean clone.
At least we've ruled out the obvious.
It's possible that damage to a file could hinder filemaker's ability to index the unstored field. (I know it's not permanently indexed, but the first thing Filemaker does when you perform a find on an unstored field is generate a temporary index for it.)
Have you tested a recovered copy of your file to see if it exhibits the same problem?
Exporting/Importing/saving compressed copy will rebuild the index, but if the corruption is to the structure of the file itself, the repair may not hold.
I don't think it is the structure but the data. Having to export data out of 200 tables is not the undertaking that would be fun.
The XML export sounds logically to clean the data, I think that would remove unseen characters.
The first thing I am wondering if this s a known issue, the calculations cannot be searched in certain circumstances. If so what are those circumstances and how do we correct it. This is obviously an unattended result. As I said earlier, I have experienced something similar before,
that result was unseen characters in a text field. If this is such a case, there is really no good way to prevent it. In the past I have used a custom function to clean the text of data being imported or pasted in from the internet.
In this specific problem, the size of the solution does not make most ideas a quick fix.
I am strictly a consultant for this client, since they have a full time FileMaker developer. I will let him do the heavy lifting. So I am trying to assist an resolving this problem.
I don't think it is the structure but the data.
We perform finds on unstored fields all the time on quite large recordsets. The only issue we've encountered is the delay this can incur. Haven't seen any data specific reports here to support that.
I'd take a backup copy of the file(s) in question and set a recover to run on a workstation overnight. Then I'd test the recovered copy the next morning to see if the issue occurs with the recovered copy or not. If it does, then you should replace your file with an undamaged backup and import the current data into it.
Mr Vodka's suggestion could also be run overnight from a backup.
That is an option, and one I have already thought of. I don't think the issue has anything to do with the actual filesize. I have larger system that can find just fine. However, you can't have a recover just run over night, it is a manual process when you are dealing with 50+ files.
Then at the end of a full day, we don't know if it will solve the problem after data is imported into a 100+ tables of the cloned backup files.
Since the resulting behavior offers only generic terms to search on, it is difficult to find anyone else with this issue.
The facts are that finding on unstored calculations does not work, when they once did. The new variables are upgrade to fmp10 from fmp9 and
importing of data. All files pass consistency check, which does not mean there is not corruption, but worth mentioning.
Thanks for the suggestions, but I need something more concrete because of the size of the system.
You have a concrete suggestion it's just not the one you want to accept. :smileysad:
I totally understand that recovering 50 plus files will take a long time. I suggest recovering one file and testing that one file to see if behavior changes. You did mention that there was one file where you suspected the problem occurs. That would be the first one to test in this fashion if I were you. If it turns out the file is damaged, you may have no alternative but to import the data into undamaged clones, but I am not suggesting that until you first test some recovered copies of the file to see if they are "searchable" in the fashion you need.