Latest Contributions by BrianFausel

Awesome, looking forward to it! ... View more

Hi @ShengdiZhang I checked the single letter search again and it looks like it works as you describe in Experience Builder and not in Web AppBuilder. Because we are moving forward with all ExB apps that fix will be good for us. Also, in the cases of the old WAB apps our users have the workaround of not including the direction and then the search still works for them. Thanks, Brian   ... View more

It is possible to upgrade enterprise and file geodatabases, though it would be to whatever Enterprise equivalent that Pro 3.3 is (looks like Enterprise 11.3). I would think a geodatabase created in 11.x will not work in ArcMap. If the geodatabase was not upgraded, I have had issues opening layers in ArcMap if you set up newer Pro-related functionality (attribute rules, for instance). Once you remove the advanced functionality then the layer works in ArcMap again. ... View more

I recently asked the Esri AI Chatbot (in Support app) about the single-character string search problem. It's answer was that the search "doesn't recognize incomplete or single characters as valid search terms." Not sure where the AI sources that but it was an interesting response. ... View more

I recently asked the Esri AI Chatbot (in Support app) about the single-character string search problem. It's answer was that the search "doesn't recognize incomplete or single characters as valid search terms." Not sure where the AI sources that but it was an interesting response. ... View more

I have seen this same searching issue with single characters in a text field. I'll be curious to see if this is confirmed to be a bug. In my case it happens across all Esri apps I use (Web App, Experience, Instant) and the searching layer is hosted in ArcGIS Online. I can't say if the problem also happens with an Enterprise-sourced layer. There are only 2 workarounds I know of. Unfortunately I don't think either of these will work for you: 1) Tell the users to include other parts of the intended search result. In your case I don't think that will work given your lot strings. In my case the problem is a direction letter abbreviation in between address number and street (entering "3805 s casper" does NOT produce results, "3805 casper" does). So I have been able to live with the issue for now... 2) The problem seems to be created when you set up a full text index on the AGOL hosted feature layer. I have found that if you delete the full text index, now the search will work assuming the user enters the exact string. They will even be prompted with the candidate suggestions. This might work for you with the lot field. However, by eliminating the index you loose the enhanced searching. Also, when you configure a new search in the Esri apps (ExB, Instant) a new full text index will be created automatically by AGOL when one does not exist on the layer field. ... View more

I have seen this issue from time-to-time as well and would also be interested to see if there are any explanations or workarounds. I haven't had a chance to try to pinpoint why it happens because it is sporadic. I'd say 80% of the time I can create the indexes without issues. In my case it happens on an AGOL-hosted feature layer with approximately 15,000 points. I've seen it when creating attribute and full text Indexes for text fields of 100-255 characters. The "creating index" occasionally runs for a long time, sometimes even over night. Sometimes it eventually does finish. Other times it doesn't but then I am able to overwrite the AGOL-hosted feature layer with an update from Pro (which automatically deletes indexes) and then the "create index" works fine on the updated layer. ... View more

I too wish there was more info or a video about the attribute and full text indexes created on ArcGIS Online hosted feature services. With the recent February 2024 AGOL update (and/or possibly the Oct 2023 one) there seems to have been a change to how they are created if you don't manually create them. I can confirm the #2 question from Patrick is a YES: "When a feature layer is overwritten, do you need to re-create the index because the data has changed?" I found that if I use ArcGIS Pro to overwrite a hosted feature service in AGOL the indexes will be gone. And this will change how the end-user searching works in your apps. You will want to re-index all of the attributes used in searches.  Interestingly it also seems that attribute indexes are created automatically when you set up searches in the AGOL web map (Settings --> Enable Search) or in Experience Builder search widget. I think the ExB part was added in the Feb 2024 update in relation to a searching bug fix in that app because I don't recall seeing that happen before the update. The indexes are created if they don't already exist on the feature service, and are given a title that indicate their source (example "exb-{app id}-widget..."). If you manually create the indexes on the hosted feature service then they are not created during the app configuration. This 2022 blog post kind of hints at some of this. There is also some useful info in this developers doc. The Experience Builder search widget doc also has some info about the "breaking change" of full text indexes added last fall. ... View more

Hi @ShengdiZhang  I completed some testing and can confirm that the searching with hosted feature service indexes now appears to be consistent across Web AppBuilder (WAB) and Experience Builder (ExB). In other words I think the index searching bug in ExB has been fixed. However, I do still have some remaining questions about how the searching handles single-letter words. I have noticed that if you include a 1-letter word the search candidate list will often not include the right result. Following the examples above and searching on this test ExB app: "3805 casper" works (which is good and the preferred way for users to search). "3805 s casper" does NOT work...for some reason the "s" seems to throw it off even though you can see the candidate after you type "3805". Similarly the test ExB app has searching set up for owner names. If you type a name with single middle initial it does not work but will work if you type first and last name. Try common name "smith" to see some middle initial examples. This single-letter word search issue appears to be consistent across ExB, WAB, Instant Apps, etc. For me it is not a deal-breaker but I am curious to know if there is any explanation for it. Thanks!   ... View more

Hi Shengdi, thanks for reaching out. I can confirm that the recent AGOL update changed the way the searching worked. But I have not had a chance to fully test it yet. Will post an update here when I have a chance to look at it. ... View more

One thing to check if you haven't already is to make sure the layer IDs in the Pro publishing document are consistent. In the Map Properties - General there is a setting to "Allow assignment of unique numeric IDs for sharing web layers". With that checked on you can now manually control the IDs for each of the layers in their General Properties. Look for the "Layer ID" setting. When published the IDs you set for the layers in Pro will appear to the right of the layer name in REST: If you don't control this setting the layers will be ID-ed automatically by Pro. I would think each GP output would result in a different ID number. I've overwritten many services and generally if you keep the layer IDs consistent they will work. Though I haven't done a ton of this with the dashboards so perhaps there is something odd with them. In my experience an overwrite does not change the Service Item ID used within AGOL. As mentioned schema changes are another story! ... View more

This sounds like a similar issue I had with attribute and text indexes with a hosted feature service and Experience Builder hosted on AGOL. My searching details can be seen in this thread. In summary it came down to a bug in Experience Builder as I did not have similar issues in Web AppBuilder. It was logged as ENH-000163068 if you want to refer to it. • Synopsis: Experience Builder Search Widget does not honor the Feature layer's Full Text Field Indexes • Status: In Review   ... View more

I have confirmed with Esri Support that this appears to be a bug in Experience Builder. It was logged as ENH-000163068 if you want to refer to it. • Synopsis: Experience Builder Search Widget does not honor the Feature layer's Full Text Field Indexes • Status: In Review Below is a summary of what I saw while searching for variations of an address string in a text attribute in Experience Builder (ExB) and Web AppBuilder (WAB). In my case the apps and data are all hosted in ArcGIS Online. I haven't done any testing with anything coming from Enterprise. The example address I am searching is stored in the text attribute as "3805 s casper dr" (address number, direction abbreviation, street name, suffix abbreviation). "3805" (left-side start of the string) returns a proper candidate list in all ExB and WAB apps. "casper" (street name in middle of string) returns an appropriate candidate list in WAB (with layer index) and ExB (with layer index). The recent AGOL update causes this search to return NO results in ExB (no index on layer). "3805 s" (direction included) returns partial results in WAB (with index) - 2 of 4 (?), NO results in ExB (with index) and all available candidates in ExB (no index). "3805 casper" (direction left out) returns correct result in WAB (with index) and NO results in ExB (with index) or ExB (no index). I have only tested address-like text strings but would guess there might be a problem with other types of text. In my case the workaround will be to eliminate all text indexes on the feature service. This at least allows my users to enter "3805 s casper" to get results they have been used to seeing.   ... View more

I have opened a support ticket. In the meantime I tested the searching in the web map JSAPI search as you suggested. I saw the same results you did where the index search appears to work. Interestingly I also tested it in a WebAppBuilder app that also worked the same as the web map. A side-question I have is about the candidate list that appears if a user enters the direction "s" when using the web map JSAPI search. In this example if I just type "3805" I see 4 candidates (which is correct):   If I type "3805 s" then I only see 2 candidates and note that they are ones with words that start with "s" later in the string: And finally if I type "3805 casper" it finds the correct one. This is actually the ideal behavior and what I would expect from a full text index. But I am still curious why "3805 s" does not show 4 candidates. ... View more

Thanks Russ. I'll investigate the Map Viewer search you mentioned and will definitely contact support to either create a ticket or see if there is one already. Will post any updates I find. ... View more