Implementing Store Locator Solutions

Zip code-based store locators have become an industry standard for companies with multiple locations. If a franchise has over 50 locations, it becomes tiresome for website visitors to sort through unwieldy lists in order to find the closest store to purchase a product.  Companies are also looking for more efficient ways to refer phone inquiries to the closest locations, and zip code based locators are becoming increasingly popular within Interactive Voice Response (IVR) systems.


Programmers are faced with the challenge of providing an easy-to-use, efficient store locator for their clients’ customers.  They also need to address the reality of how to maintain the store locator.  Programmers should ask themselves the following questions when implementing a store locator:


  1. What level of geographic accuracy do I need for my client’s locator?
  2. How often do I need to update the postal data for the locator?
  3. Can I use the same store locator application for a website and an IVR system simultaneously?
  4. Will my store locator perform efficiently on large customer databases?


Electric Vine Inc., who has helped implement  500 store locators with their Bullseye product, gave us the following answers to the 4 questions:


  1. Zip code level geocoding is suitable for most store locator applications.  Address level geocoding is sometimes preferable if the application is particularly mission critical, or if the client has a large database of stores and has the budget for an address level locator.
  2. About 5-6 times a year is ideal for Zip code level data.  Address level data is often maintained for you by the data company assuming they are hosting the data.  (For Bullseye implementations, an option is available to automatically update zip code data as well, in order to cut down on maintenance time).
  3. You can use the same store locator application for both a website and an IVR system.  With Bullseye for .Net, you can have a web site and an IVR system access Bullseye via a web service.  Bullseye maintains one copy of the customer data.
  4. Naturally, this depends upon the design of your locator, the underlying database, and the server configuration.  The Bullseye solution, after 6 years of implementation and optimization, should be seriously considered for any programmer implementing an efficient store locator, for a variety of configurations.


Some sample code using Bullseye follows:


       1.    Using C# in an ASP.Net page, calling Bullseye to return a list of companies that              

               fall within a 10 mile radius:


      //Initialize Data Source

      BullseyeNET.DataSource oDataSource=new BullseyeNET.DataSource();


      string sDSN=GetBullseyeProDSN();











      //Associate datasource with the search

      BullseyeNET.ZipSearch oSearch;

      oSearch=new BullseyeNET.ZipSearch(oDataSource);



      //The zip code to search from.



      //Search ten miles.

      double nRadius = 10.0;


      //Do paging of the results

      oSearch.Options=oSearch.Options | ZipSearch.OPT_PAGING;


      //What page of results we are viewing.

      int nCurrentPage = 1;


      //How many locations to show per page.

      int nPageSize = 5;






      if (!oSearch.Run())


            WriteLine("Error occurred.  " + BullseyeNET.LastError.Description);





      BullseyeNET.ZipSearchResults oResults=oSearch.Results;

      DataSet oDataSet=oResults.DataSet;

      DataTable oTable=oDataSet.Tables[0];


      int nRecords=oTable.Rows.Count;


      //Draw the results if something appeared.

      if (nRecords!=0)


            foreach (DataRow oRow in oTable.Rows)


                  // Here is the location data.

                  // oRow elements Name, Street1, Street2, City,

// State, ZIP are available along

// with DistanceDouble indicating the miles

// from the original ZIP code. 

// oRow[“DistanceDouble”] accesses that, for example.


                  // There are also User Defined fields that can be

                  // populated with text using the

// administrative website and used as the program

                  // sees fit.  This can be, for example, the path to

// a voice recording data file for use by

// an IVR system.

// oRow[“User1”] would hold the first of those,

// for example.





            WriteLine("There were no results within the selected    radius. ");




The Filter property of Bullseye.NET gives enormous flexibility by allowing the user to write part of a SQL WHERE clause into the control itself.  This makes category searches a snap if you know your SQL.  A database with an evbe_Product table listing ID-Product Name pairs along with an evbe_CompanyProduct table listing Company ID-Product ID pairs makes this simple:


If we have a Product ID, say from a dropdown list box the user has available on the ASP.Net web page, we can put it in the filter before running the above search.


oSearch.Filter = "(evbe_Company.ID in (select CompanyID from evbe_CompanyProduct where ProductID = " + nProductID.ToString() + "))";



We received permission for you to download a free demo of Bullseye.NET to test this application.



For information about this .NET store locator application, please call Tom Flynn at 732 868 8463 or visit

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.