There is a pesky little issue that is fixed in a October 28, 2008 hotfix for MOSS that I want to call out and explain. The problem can be vexing and difficult to diagnose, and the KB article text may be a bit too vague for you to recognize that it applies to you, so I'm going to explain it in a little more detail.
The particular problem/fix of interest is described in the KB article as follows:
- When you search for more than 9 digits but less than 40 digits, you may not receive the expected search results.
Here's what was really going on under the hood on this one:
Prior to this hotfix, the MOSS 2007 crawler would recognize numbers as numbers and so rather then indexing them as strings it would index them as number data types. This worked well for small numbers, but for very large numbers (those consisting of more than 9 digits) the data type conversion resulted in them being converted to exponential notation before being added to the index and therefore lose precision. For example 3,000,000,000 will convert to “3E9” and then you won’t get a hit on “3000000000” nor on “3,000,000,000”. There were a few other things going on to make matters worse.
First, because only a few digits of percision were retained (I'm personally not sure of exactly what the old level of precision was - so don't ask me :) ) 3,000,000,100 and 3,000,000,200 would both convert to the "3E9" value.
Second, there is logic in the crawler that will treat a space character positioned between consecutive groups of 3 digits as if it were a thousands seperator (which is typically a comma or a period, depending on your locale). So, from the perspective of the crawler 3,000,000,000 = 3 000 000 000 = 3.000.000.000.
All the above went out the window when there were more than 40 digits in a row because the data type conversion would fail and things would fall back to indexing the string.
Adding it all up (pun intended) it could be pretty frustrating to understand why queries don't bring back the results you expected.
So now you know the whole story.