topic Re: Local map service wildcard query not working in Quartz in .NET Maps SDK Questions

Local map service wildcard query not working in Quartz

PaulLivingstone — Thu, 05 Jan 2017 15:23:35 GMT

The wildcard queries in a local map service on a layer or table from an mpk do not seem to be working. If I create a query such at:

some_field like ‘%1%’

…and call the QueryFeaturesAsync method then zero records are always returned.

Has the wildcard character changed in Quartz?

Even if I query the endpoint that is spun up via a web browser then still no records are found.

Oddly, if I use:

some_field like ‘1%’

…(missing the first wildcard character) then records are returned.

Re: Local map service wildcard query not working in Quartz

MichaelBranscomb — Tue, 30 May 2017 00:08:22 GMT

Hi,

The wildcard characters have not changed. I don't yet know why the query is not working in your example, but in ongoing testing with some test data I have found (test data Type includes features with values 'Forest', 'Reservoir', 'Rest Area'):

- LOWER(Type) LIKE '%res%' => returns 6 results

- LOWER(Type) LIKE '%re%' => returns 6 results

- LOWER(Type) LIKE '%r%' => returns 9 results

Note that when creating the ServiceFeatureTable you should use FeatureRequestMode.OnInteractionNoCache to always query the local service. Or alternatively you can use FeatureRequestMode.ManualCache in conjunction with a call to PopulateFromServiceAsync() to fill a client-side cache with the features you want to query. There'll be an initial overhead in filling the local cache, but queries should then be faster. Note that you may need to set a higher LocalFeatureService.MaxRecords value before starting your service, depending on your choice of query to fill the cache.

I've submitted an issue for further investigation because there was one case where i did not see the expected results (when using the OnInteractionNoCache approach).

Cheers

Mike

Re: Local map service wildcard query not working in Quartz

MichaelBranscomb — Wed, 16 Aug 2017 00:56:13 GMT

Hi,

This should be resolved in the v100.1 release (June 2017).

The problem was in the URL decoding within the Local Server web server.

Cheers

Mike