>>>I was suggesting a rough calculation that would find matches within a square area rather than a circle. 1 degree of latitude is approximately 111kms (not miles - I was wrong above) so places within 20km North or South would be within +/- 20/111 degrees of the the target latitude. Longitude is cruder. At 50 degrees N it's about 70km so 20km East or West would be +- 20/70. But using that formula for somewhere in, say, Florida would include places up to about 28Km either side. So I was suggesting using this method to get a first selection (which might include some places outside the target distance) and then to make the more accurate calculation using just those results.
>>>
>>>But if you're getting acceptable performance doing the full calculation straightaway there's not much point.........
>>>
>>>Also the best solution is going to depend on your data. For example if you have a lot of records per zip code it will make more sense to calculate zip codes within the target distance then look for records with that zip code. Conversely, if your records don't include that many zip codes there's no point in doing the calculation for zip codes that don't exist in the data......
>>
>>The goal here is to rely on a table with a list of latitudes and longitudes. So, we cannot rely on a city table. So, using a pre-generated tables with all the pre-calculations cannot apply. The main table can have multiple entries per street. So, the approach from the blog of George Mastros is working so far.
>
>Sorry, what's the George Mastros blog ?
>
>I just need to adjust it for km and to avoid those stored procedures.

http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/sql-server-zipcode-latitude-longitude-pr (and check comments and also another link at the very top).