Incorrect query results when data contains many wide columns

Description

When service data contain very wide columns, such as many columns of type VARCHAR(8000), a SPATIALQUERY may return records successfully, but only for a limited number of such fields. Beyond that number, the Spatial server returns '0' records. This is an incorrect result and is being investigated as a bug.

For example, a query with a valid ‘where’ clause and subfields="#ID# #SHAPE#" returns N records. It will continue to return N records as more columns are added to ‘subfields’. This is an example of the request:

Code:
<ARCXML version="1.1">
<REQUEST>
<GET_FEATURES featurelimit="25" beginrecord="0" outputmode="xml" geometry="false" envelope="true" >
<LAYER id="0" />
<SPATIALQUERY subfields="#ID# #SHAPE# FIELD_1 FIELD_2 WIDEFIELD_3 " where="TEST.TEST.DISTRICT.TEAMS > 2" >
</SPATIALQUERY>
</GET_FEATURES>
</REQUEST>
</ARCXML>

Code:
<ARCXML version=”1.1”>
<RESPONSE>
<FEATURES>
<FEATURECOUNT count=”5” hasmore=”false” />
</FEATURES>
</RESPONSE>
</ARCXML>

Code:
<ARCXML version="1.1">
<REQUEST>
<GET_FEATURES featurelimit="25" beginrecord="0" outputmode="xml" geometry="false" envelope="true" >
<LAYER id="0" />
<SPATIALQUERY subfields="#ID# #SHAPE# FIELD_1 FIELD_2 WIDEFIELD_3 WIDEFIELD_4 WIDEFIELD_5 WIDEFIELD_6" where="TEST.TEST.DISTRICT.TEAMS > 2" >
</SPATIALQUERY>
</GET_FEATURES>
</REQUEST>
</ARCXML>

Code:
<ARCXML version=”1.1”>
<RESPONSE>
<FEATURES>
<FEATURECOUNT count=”0” hasmore=”false” />
</FEATURES>
</RESPONSE>
</ARCXML>

Note:
A SPATIALQUERY with subfields=”” or subfields=”#ALL#" also returns 0 records.

Cause

Although the created tables use columns of extreme width, it is also possible that certain view-creation transactions and other SQL commands (such as 'replace'), may inadvertently cause columns to become the varchar(8000) data type.

Workaround