I've been trying to help troubleshoot an issue that is very strange, and I think we've boiled it down to an issue with ArcGIS Server.

We have a map service that shows up in the services directory as:

    Some-LayerA (0)
    Some-LayerE (4)

    databaseName.SchemaName.TableName (5)

And the layer we are querying against looks roughly like this:

    databaseName.SchemaName.LayerName.ObjectID (type: esriFieldTypeOID, alias: OBJECTID)
    databaseName.SchemaName.LayerName.SomeField (type: esriFieldTypeString, alias: SomeField, length: 3)
    databaseName.SchemaName.TableName.ProjectKey (type: esriFieldTypeString, alias: ProjectKey, length: 18)
    databaseName.SchemaName.TableName.Spent To Date ( type: esriFieldTypeDouble , alias: Spent To Date ) 
    ... More joined fields (No duplicate names or aliases, all strings, dates, doubles)

When issuing a query with only a where clause against the joined table, I can do something like this and have it bring results up:

Where: databaseName.SchemaName.TableName.ProjectKey = 'ValidProjectKey'

--> Returns 2 results
-----> databaseName.SchemaName.TableName.ProjectKey: ValidProjectKey

-----> databaseName.SchemaName.TableName.ProjectKey: ValidProjectKey

However, if I add some extra parameters, then I get no results at all:

Where: databaseName.SchemaName.TableName.ProjectKey = 'ValidProjectKey'
Out Fields: *

---> Returns 0 results

Apparently, if specifying the out fields manually, it will give results:

Where: databaseName.SchemaName.TableName.ProjectKey = 'ValidProjectKey'
Out Fields: databaseName.SchemaName.TableName.ProjectKey

---> Returns 2 results
-----> databaseName.SchemaName.TableName.ProjectKey: ValidProjectKey

-----> databaseName.SchemaName.TableName.ProjectKey: ValidProjectKey

But, if I change that second query to go against one of the layer's native (non-joined) fields instead, then it seems to return an appropriate number of results, but with all of the join fields set to null:

Where: databaseName.SchemaName.LayerName.SomeField = 'SomeValue'
Out Fields: *

---> Returns 514 results
------> databaseName.SchemaName.LayerName.ObjectID: 553
------> databaseName.SchemaName.LayerName.SomeField: SomeValidValue
------> databaseName.SchemaName.TableName.ProjectKey: null
------> databaseName.SchemaName.TableName.ProjectManager: null

------> databaseName.SchemaName.LayerName.ObjectID: 1938
------> databaseName.SchemaName.LayerName.SomeField: SomeOtherValidValue
------> databaseName.SchemaName.TableName.ProjectKey: null
------> databaseName.SchemaName.TableName.ProjectManager: null

Any clues why going against the joined table would lead to such different behavior? I don't have much control over the actual query, because it is being issued through geocortex.

  • Is this a one-to-one or one-to-many join?
    – mwalker
    Jul 25, 2013 at 18:13
  • one-to-many join, the first query above is the actual result of the query in terms of records, and the join is based on the ProjectKey field shown
    – MichaelM
    Jul 26, 2013 at 18:40
  • 2
    If you specify ALL the fields manually, do you get results? If you don't, try removing them from the output fields until it starts working.
    – mwalker
    Jul 26, 2013 at 20:08
  • @mwalker Will try when I get back to work on Monday, will also add some more info to the question that I found on the way out the door on Friday. When getting those 514 results, all joined field values are null.
    – MichaelM
    Jul 27, 2013 at 15:06
  • 1
    That might be an additional problem you are not aware of yet. Joins in ArcGIS clients are only 1:1 or M:1, not 1:M. (I think ArcSDE itself can handle 1:M as a join, since it is really just using the underlying database). For clients, this means that only the first joined record is returned, not all, causing less records to be returned on a query against joined fields than should be returned. You should verify that this query is executing correctly as 1:M and not just functioning as 1:1 with additional records dropped. Jul 31, 2013 at 15:51

2 Answers 2


Thanks to the suggestion from mwalker about trying to query each field manually (rather than using *), I think we finally found the issue.

It ends up that I should have looked more closely at the list of fields in the joined table. Out of the 10 fields in the joined table that had compound field names, 5 of them were done in PascalCase, and 5 used spaces. (e.g. "Classified As" instead of "ClassifiedAs" or "Classified_As")

After republishing the table with more consistent naming, all queries seem to be behaving as expected!

So, end result is the behavior seems to be caused by improper field naming.


Are there any fields that have duplicate names in your data? For example, does your joined table have an OBJECTID field as well?

I've also seen problems when a field is of type UUID. Generally, though, we see problems with duplicate field aliases.

If you determine that one of the fields of the featureclass or one of the joined fields is triggering a failure, you should be able to configure that field to not be visible in Essentials Manager (I'm assuming you're using Geocortex Essentials) - then, the viewer will issue queries with a specified list of return fields and you can avoid the problem.

  • No duplicate fields, all of the fields (apart from objectid) are strings, dates, and doubles
    – MichaelM
    Jul 26, 2013 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.