Rebuilding address locators

[MikeAdams]

I am using ArcGIS 9.3.1.  I created several address locators, but when I attempt to rebuild any of them, ArcCatalog tells me "You cannot rebuild this address locator.  The address locator was created using a release of ArcGIS previous to ArcGIS 9.2.  Please create a new address locator."  All of these address locators were made using ArcGIS 9.3.1.

[AnthonySchaffer]

So you are creating a locator within an SDE geodatatbase?  I would suggest you not do that, but rather keep it in it's own directory.  No problem to access or point to data in the SDE database, but it's much better practice not to store a locator as an object of any flavor of geodatabase; SDE, file, or personal.  You've already made a case supporting this, right?

Why is it not good practice to place an address locator within a geodatabase?  I have never seen such recommendations in any product literature.   And creating an address locators is one of the options available when right-clicking on a geodatabases connection in ArcCatalog.

[BradNiemand]

Anthony,

There is really no benefit with storing a locator in a geodatabase because a locator is all inclusive (it is a snapshot of the data). Also, the database overhead with storing it there has no benefits and will also cause a significant performance slowdown.

Brad

[AnthonySchaffer]

Anthony,

There is really no benefit with storing a locator in a geodatabase because a locator is all inclusive (it is a snapshot of the data). Also, the database overhead with storing it there has no benefits and will also cause a significant performance slowdown.

Brad

Brad,

If that's the case, then again, where is this documented?  It is not in the ArcGIS Help regarding address locators.  Also, why then the right-click option to create one in the geodatabase?  Do you see the inconsistency here:  your answer implies that ESRI software is condoning a practice that ESRI Support recommends against. 

You state that doing this will cause a "significant performance slowdown".... based on what?   Database access can be as fast or faster than simple file access.  Databases do not exist only to store dynamic data; storing relatively static database (i.e. snapshot) in a database is very common.

I can think of several benefits to storing a locator in a geodatabase:

a) it will be backed up along with the source data
b) one less data store to register with ArcGIS server (including security credentials)
c) security of the locator data is controlled through the database, rather than separate file level security, so one less thing to manage/debug

[BradNiemand]

Anthony,

You can think of a locator as a database in itself.  It contains data records and indexes that are all within the locator (.lox file).  When storing it in a GDB, the .lox file is stored as a blob in the database with a field in another database table that links to that blob.  So essentially you have a database that is stored in another database.  As you can see, there is really no use for that locator to be in the database because it is already optimized with indexes and therefor it doesn't need to use the benefits of a database, it's own indexes.

Now to address your other comments which are valid:
a) it will be backed up along with the source data
    - This can be useful but is it worth the performance hit?
b) one less data store to register with ArcGIS server (including security credentials)
    - You are correct but this is a one time thing
c) security of the locator data is controlled through the database, rather than separate file level security, so one less thing to manage/debug
    - Once again you are correct.  The security can be managed at the database level as opposed to having to manage it at the OS level as well.

Let me also state that there is no restriction, at this time, to storing locators in GDBs but we just suggest, for performance reasons, not to do it.

Hopefully I have clarified some of your concerns but feel free to respond with any others.

Brad

[BradNiemand]

I forgot to answer one of your questions:

We don't have any official documentation on this as of right now but we will definately add it for the next release.  Here are some forum posts that suggest the same thing.

http://forums.arcgis.com/threads/92913-slow-geocoding-on-locator-stored-in-sde

http://forums.esri.com/thread.asp?c=93&f=1113&t=269905

Brad

[KimOllivier]

Maybe we get lulled into placing the output in the same database when the message "All sources must be in the same database" pops up? It does make a tidier workspace to put it with the sources. The locator is 3 files not just one, but in ArcCatalog you only see one entry. But I am now straightened up to place them in a plain old folder.

Also note in the fine print that you need the locator in a folder to use multiple threads. Since we all have multicore processors why would we not use them all to get better performance, especially on large datasets?

[JanelleLuppen]

"I have received the same message about the locator having been created from an earlier version, even though I created it last week in 10.1. Also, it was not created inside a geodatabase, just in a regular directory, and no SDE was involved at all."

[AnthonySchaffer]

Well, I took the advice and now store address locators on a local drive on the ArcGIS server, rather than in a database. 

However, I am getting the same error that "You cannot rebuild this address locator.   The address locator was created using a release of ArcGIS previous to ArcGIS 9.2.   Please create a new address locator."

My address locator was created using ArcGIS 10.1 SP1, which hopefully is not "previous to ArcGIS 9.2".   I had to create it from scratch to place it outside of the SDE database.   Once created, the locator works fine; it participates in a composite locator that in turn is used by our published geocode service.  

I have a nightly python script that rebuilds all of the contributing address locators (yes, it first stops the geocode service before running the rebuild).   The first locator rebuilds fine; the second fails in the script and again when I try it manually in ArcCatalog (thus the message above).    I don't know whether the rebuild attempt causes corruption - or how, since it uses the standard Python arcpy.RebuildAddressLocator_geocoding(locator) function.  

Update:  I noticed that the when this happens, the feature class that the locator is based on was empty (a bug in a separate script that refreshes it).   The feature class did exist in SDE, but had no records/features.   Apparently attempting to rebuild a locator against an empty source dataset will corrupt the locator and the only solution is to delete then recreate it from scratch.   To the ESRI folks, it would be preferable for the RebuildAddressLocator_geocoding function to return an error or perhaps a warning in this situation rather than the current result; has this been fixed in 10.2?

[MatthewBaker2]

I'm having the same issue with 10.1 SP1.

I started the thread linked to above about slow performance of locators in SDE, so following the answers to that thread, built all my locators in a simple folder, and have been having great results for some time.

However, suddenly yesterday all our locators are corrupt with the error mentioned in the posts above and subject of this thread.

There seems to be no reason why this is happening...?

-m

[KatieBrander]

I tried for months to get an automated python process going to update address locators similar to the method you described. If you haven't yet discovered, the bug that corrupts address locators when attempting to rebuild an empty table still exists in ArcGIS 10.2.2. Furthermore, even when there is data in the source table, I found that using the arcpy function to rebuild the address locator would inevitably corrupt them sooner or later! In the end we decided it was safest to do a manual rebuild in ArcCatalog - but even this fails sometimes with an error message simply stating "Can't rebuild address locator". Sadly, it seems the only reliable method is to manually delete and re-create address locators every time.