>Thanks to everyone who contributed in this amazing thread. I learned a lot of things and I am now building my class.
>
>When I looked at George Mastros's page, I found a lot of interesting information in there. The ability to get those data from several countries and add them into SQL Server is great. But, in overall, as the initial request is based on an already existing table, where several records contain a list of addresses, we will simply have to add a latitude and longitude fields. Then, I will use the Google API to assign the latitude and longitude values for each of them.
>
>Once the table is finalized, we can just use the following to retrieve the records:
>
>

>declare @CenterLat float=47.7795
>declare @CenterLon float=-65.7191
>declare @SearchDistance float=25
>
>select * from Test
> where(latitude between @CenterLat -  @SearchDistance/111.0  and  @CenterLat + @SearchDistance/111.0 ) and
> (longitude between @CenterLon - @SearchDistance/111.0 and  (@CenterLon + @SearchDistance/111.0) )
>

Michel,

This gives results that may be farther away
(1) The longitude (or was it the latitude) varies. ie the distance of one degree depends on where you are
(2) the between clause gives the locations in a rectangle. You need the circle in the rectangle with a radius of SearchDistance since the corners of the rectangle will have a distance that is greater than SearchDistance

You need to apply a final where clause

where ,,,,
and calculatedDistance < = SearchDistance





>Now, this returns the result instantly. But, what is more interesting is that George Mastros's data, as in the example, which I changed for Canada, thus containing 1621 rows, returns also the results instantly.
>
>Basically, with this approach, I am not even using UDF or anything else. This relies only on the latitude and the longitude fields in the table. So, from one specific location, we just decide on many km we would like to have and the related records would be returned.