Instant Search Indexes on nightly updating data
Nearly of the data that we use in our webmaps gets refreshed nightly by automated processes. The feature class schemas rarely change, but essentially all of the data is wiped out, then the newest data is inserted
If we have a service that has an Instant Search Index on it, and the data is refreshed nightly, how does this impact the index? It appears not to be a problem but I am wondering if anyone knows more about this, as I'm sure other organizations have a similar set-up.
Thanks-
Allen
-
I've had issues with the index for our parcel data, so much that I've just turned it off completely. Essentially, how it has worked for our organization is that when the new data is updated bi-monthly the index recreates completely (takes about 3-4 days), during which time my users are unable to search by any parcel number, address, owner name...
There may be a quick fix, but I haven't come across it.
0 -
Interesting Craig -
I'm not sure what is going on behind the scenes here, but our index, built on a huge service with data that is updated nightly, seems to be unaffected by the nightly data refresh process. Obviously it won't catch any new data, but the process does not seem to break the index and instant search capability.
This is our first week of working with this, so the situation may change when the index rebuilds itself.
0 -
We have problems replacing entire datasets that are involved in instant searches. When I replace it then search for an address, that address starts to auto-suggest, but the result is a different address. I guess the instant search is indexed based on the objectid of the feature class. So if I replace the dataset the objectid for an addresses may not be the same as the one in the index.
I try to keep the index matched by republishing the service, deleting the index using the trash can icon, and re-creating the index. This doesn't work and it is difficult to tell what is going on with the index. What sense am I supposed to make of it when the search index says it is at 100% but there is a pause button next to it? It isn't a huge dataset and the index doesn't take long to recreate but I can't really tell when it is done or even started re-creating.
Anyone know of a procedure to make sure the index and the data match? Is there a plan to make it easier to use frequently updated data? What about being more flexible about what fields are used as the index key? We have a unique id that would be much less error-prone but I can't use it for the index.
Regards,
David0 -
I am having the same exact problem as David. I replace my parcel layer every two weeks and when users do a search they often get results on the wrong side of town with the wrong APN and address.
Deleting the index with the trash can icon seems to have zero effect and just seems to make the problem worse in that I can no longer turn instant search off entirely. It acts like its indexing but never finishes and then prevents me from turning instant search off.
On another post someone found a workaround that I have adopted as well.
1. Stop GAS2 in Server Manager
2. Delete the 'data' folder ( for me found here: C:\Program Files\Latitude Geographics\Geocortex Application Services 2 )
3. Restart GAS2, this recreates the 'data' folder and all related subfolders
4. Rebuild the index as normal in GE Manager
Not perfect by any stretch but at least allows me to have instant search enabled and be confident that the users are going to get their intended results.
0 -
Does anyone know where the data folder is for 4.3?
0 -
I got the answer. To delete instant search data on 4.3, you need to delete the following directories:
DistributeDB and Search
Located at:
C:\Program Files\Latitude Geographics\Geocortex Core\Data
YOu will first need to stop the Geocortex Core service.
Now the indexes are built MUCH faster in 4.3, so it might be possible to create a nightly routine to delete the instant search data and set them to reindex...
0
Please sign in to leave a comment.
Comments
6 comments