Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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:

Layers:
    Some-LayerA (0)
    ...
    Some-LayerE (4)

Tables:
    databaseName.SchemaName.TableName (5)

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

Fields:
    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.

share|improve this question
    
Is this a one-to-one or one-to-many join? –  mwalker Jul 25 '13 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 '13 at 18:40
1  
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 '13 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 '13 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. –  blord-castillo Jul 31 '13 at 15:51
show 3 more comments

2 Answers

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.

share|improve this answer
    
No duplicate fields, all of the fields (apart from objectid) are strings, dates, and doubles –  MichaelM Jul 26 '13 at 18:43
add comment
up vote 0 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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