>George,
>SNIP
>>
>>I'm well aware of the premise of this thread. The answer is still the same: Fragmented files are not, and cannot be more efficient than those that are not for the reason I stated. If you want to know the exact reasons why, then post back.
>
>I just completed some testing on this today, and though I'm still thinking through all the results, it is pretty clear that your statement above is not ALWAYS true.
>
>Have a look at thread #737567 for (limited) details.
>
>cheers, and Happy New Year

Jim,

As programmers we are compelled always to examine the worst case scenario. With any fragmented file the worst case is the drive's maximum seek time per cluster read. In reality, however, we know that this isn't the case, but still the best we can hope for would be the average seek time per cluster read.

With an unfragmented file, however, the worst possible case would be that the each cluster read would result in the average seek time. In this case, the reality is probably closer to the minimum seek time.

While it may be true that it may not always be the case that an unfragmented file results in faster retrieval, the instances where it does not are exceptions, and not the rules. As programmers, we design against rules.

In regards to SQL Server, it's really an apples and oranges comparison, since SQL Server by-passes the NT/2000/XP file handling and deals directly with the drive.