Thank you for your post.
Unfortunately, I cannot duplicate the problem, and I know that doesn't help you. Do you have a file you can send me that shows the problem? I would like to see it. I have sent you a private message (top of this screen - right side - X Messages) with instructions where to send the file.
I've done a lot of 5.5 to 10 conversions so I'm guessing my experiences could be very similar to yours. I haven't seen any issues with summary fields which could just be that I haven't tripped over this one yet!
One possible suggestion comes to mind: With files that have been in use for extended periods of time, sometimes hidden damage to the file creeps in that isn't immediately apparent. I have seen apparently healthy files demonstrate unexpected behavior after I converted them. In my case, I was able to trace it back to hidden damage in the original, unconverted file. (My boss--who was then my client, insisted on using recovered files instead of calling me in to replace with original clones :smileysad: )
If you haven't already done so, test a recovered copy of the file and see if the trouble persists. You could also save a clone and import your data into the clone and see if the problem goes away.
I want to give an closure to this post.
After discussed this issue with an engineer in FM. I realized this was a bug in FM9. The issue has been fixed in V10.
Here's the cause of the problem. The field that I used for the summary field is a text field. It's some type of ID. The records that were not counted (skip) by the summary field had a specific pattern like ###E#### ( some number characters then followed by a letter "E" then followed by more number characters. When the number after "E" happen to be =>800, the record would not be counted.
Knowing what the problem was, I selected a different field to be used in my summary calculation.