I have a flex 3.5 app that has been working for a great number of years. I wrote it from the ground up not basing it on the sample flex viewer.

I had some server problems yesterday and took the downtime as an opportunity to upgrade everything from 10.4.1 to 10.5. For some reason my definition queries on map services on the 10.5 server no longer work. I do not know if this is by design or a configuration that I can change.

All the services draw unless I use a definition query on them. The query I am using works in the service layer query URL (10.5) so I am really at a loss for why it will not work in the flex application.

I pointed the Flex application towards a development 10.4.1 server and all the definitions work as they have in the past. There is not any code to troubleshoot, the only difference between a functional application and an non-functional one is the version of ArcGIS Server.

Can anyone help?


There is a patch available for server - ArcGIS Server 10.5 Layer Definition Query Patch http://support.esri.com/download/7489

This patch provides a fix for layer definition queries to ArcGIS Server 10.5 map services including certain requests made from the ArcGIS Online and Portal for ArcGIS map viewer and custom JavaScript/Flex applications.

  • Thank you so much Bjorn. I will check into it as soon as I get back to my desk... Monday – Segrest Apr 27 '17 at 17:10
  • 1
    It works! I will buy you a beer next time I am in California. Thanks again – Segrest May 1 '17 at 15:20

If you're talking about layerDefs 'simple syntax', as Esri refers to it as, this is no longer a REST-supported feature...use the JSON representation.

This is an example of the deprecated simple syntax (0 and 5 refer to layer ids):

0:POP2000 > 1000000;5:AREA > 100000

...and this is the equivalent JSON representation:

{"0":"POP2000 > 1000000","5":"AREA > 100000"}

I can't test this without access to a Flex app (or how yours is set up), but I think you'd need to edit the mxml for LayerDefinitions (or where you've set up your layerDefinitions). For example, Esri posts this sample (I am posting only the relevant portion), and I think if the way definitions are set up in this SQL fashion is determined faulty (I am not sure how this is passed to the REST request), you'd have to replace the STATE_FIPS = '49' as in the case below with JSON:

<esri:ArcGISDynamicMapServiceLayer id="censusLayer" name="Census"

        <!--Utah is FIPS = '49'-->
        <esri:LayerDefinition layerId="0" definition="STATE_FIPS = '49'"/>
        <esri:LayerDefinition layerId="1" definition="STATE_FIPS = '49'"/>
        <esri:LayerDefinition layerId="2" definition="STATE_FIPS = '49'"/>
        <esri:LayerDefinition layerId="3" definition="STATE_FIPS = '49'"/>


Since the Flex api is no longer actively supported, you will likely have to create a workaround such as manually forming the REST URL to include the 10.5 expected parameter format.

UPDATE: Apparently the problem manifests itself with the JavaScript API as well, see https://geonet.esri.com/thread/188421-imageparameterslayerdefs-does-not-work-with-105. The fix for the API (ver 3.20) is not expected until the next release, presumably next month.

Meanwhile, user dnc has posted (1/14/2017) a programming workaround (slightly condensed to remove console logging):

dynamicMapServiceLayer.on('update-start',function(evt) {
  if(evt.target._params.layerDefs.charAt(0) !='{') {
    //if not json syntax, convert
    evt.target._params.layerDefs = evt.target._params.layerDefs.split(':').join(':"').split(';').join('",') + '"';
    evt.target._params.layerDefs = '{' + evt.target._params.layerDefs + '}';

Along with this snippet, dnc states: "Just replace dynamicMapServiceLayer with your variable name. Place this code right after creating your layer."

Of course, this is JavaScript code, so just in case you're unfamiliar with reading this code, it is essentially an 'intercept' of what is passed as a REST param of layerDefs to 'fix' the code that no longer works with 10.5 -- the same type function you'll need with Flex. To explain this code snippet in a little more detail, this is what takes place:

  1. Test the current def for the presence of '{' in the first character position (index 0). If this character does not exist, then the syntax is invalid; proceed with the character replacement to fix the query, items 2 and 3 below. Otherwise, the syntax is assumed valid and the current def is left as-is.
  2. The character replacement is done in 2 lines, the 1st line serving to add the double quotes and change the semicolon to a comma in order to convert to the proper JSON syntax...
  3. ...and the character replacement in the 2nd line is really just adding the opening '{' and closing '}' brackets. (This could all be done in a single line, but I suppose this was done in 2 lines for improved readability.) Thus the 'punctuation' of the string has been changed from id0:def0;id1:def1;id2:def2... to {"id0":"def0","id1":"def1","id2":"def2"...}

This same type of fix to intercept and replace text in your Flex app should be relatively easy (perhaps easier than rolling back your ArcGIS Server instance to an earlier version).

  • This is a bug, BUG-000102051, and although the report says it affects the JavaScript API, it's a problem for any app that doesn't properly pass the layerDef params to ArcGIS Server REST API. See: support.esri.com/bugs/nimbus/QlVHLTAwMDEwMjA1MQ== – T. Wayne Whitley Feb 19 '17 at 0:08
  • I tried the modifications you suggested... unfortunately it references esri:LayerDefinition which is not present in the version of flex I am running. Thanks for your suggestion though. I will keep tinkering with it till I get it to work (if possible). I think the JSON bit will be the key... maybe by the time I get it sorted ESRI will have fixed BUG-000102051 Thanks to you both – Segrest Feb 21 '17 at 16:14
  • so this intentional change to 10.5 broke everyone's definitions, glad it was more than just me. – Segrest Feb 21 '17 at 16:28
  • Unfortunately, as I read the bug report, the planned bug fix is is to change the JS API to deliver to REST the JSON formatted string...meaning you will still have a problem with Flex. That is why I suggested you find a way to develop a similar patch for your app as that above developed albeit temporarily for JS. I am not versed at all with the Flex API but know at some point a REST request is sent which you will have to intercept and reformat. – T. Wayne Whitley Feb 21 '17 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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