FeatureLayer setDefinitionExpression & Internet Explorer

SteveCole · ‎09-28-2015

This strikes me as odd but I guess it really shouldn't since this is Internet Explorer..

Anyways, I have a simple page that loads two feature layers that have two date fields (a beginning and ending date for events). When I add the layers to my map, I attempt to apply a defintion expression based on those date fields:

var today = new Date();
var theDefExp = "endDate > date '" + today.toLocaleDateString() + "'";
theLayer.setDefinitionExpression(theDefExp);

This works fine in Chrome and Firefox but, under Internet Explorer 11 (and using any "previous" document modes), this throws 400 errors when it actually attempts to display features. In the ArcGIS Server logs, here's the real error:

An invalid where clause or definition expression has been requested: "endDate > date '‎9‎/‎28‎/‎2015'"

So why does this cause heartburn for IE but not Chrome/Firefox? More importantly, what do I need to change to make it IE friendly?

Thanks!

Steve

SteveCole · ‎03-14-2016

Just got off the phone with ESRI after submitting a possible bug request about this. After a lengthy call, we finally determined that the issue was not with ESRI's software. The problem lies with my use of the Date.toLocaleDateString() function.

For whatever reason, the encoding must be different or something. The final solution was a little less elegant but it now works within IE:

    var currentTime = new Date();
    var month = currentTime.getMonth() + 1;
    var day = currentTime.getDate();
    var year = currentTime.getFullYear();
    var theCurDate = month + "/" + day + "/" + year;
    
    var theDefExp = "endDate >= date '" + theCurDate + "'";
    theLayer.setDefinitionExpression(theDefExp);

View solution in original post

TracySchloss · ‎09-28-2015

Because it's IE - isn't that answer enough?

I've sometimes had luck switching the use of single quote ' vs double quote " in my where clauses. Maybe that will make IE happier.

var theDefExp = 'endDate > date "' + today.toLocaleDateString() + '"';

SteveCole · ‎09-28-2015

Sadly, no. I'm also trying the actual Epoch numbers but that isn't working either:

"endDate > date 1443476100"

TracySchloss · ‎09-28-2015

I figured that was too easy, but the position of those quotes can be a deal break. Are you sure it's lower case d on 'date'? Case is the sort of thing that other browsers ignore, but IE chokes on.

SteveCole · ‎09-28-2015

no- capital D did not make it work. Also- using a double quote makes Chrome/Firefox not work.

SteveCole · ‎09-28-2015

One thing I will add is that I do notice a subtle difference in the request that is sent on.

Chrome:

http://<server>/rest/services/transportation/constructionClosures/MapServer/0/query?f=json&where=endDate%20%3E%3D%20date%20%279%2F28%2F2015%27&returnGeometry=true&...

Internet Explorer:

http://<server>/rest/services/transportation/constructionClosures/MapServer/0/query?f=json&where=endDate%20%3E%3D%20date%20'%E2%80%8E9%E2%80%8E%2F%E2%80%8E28%E2%80%8E%2F%E2%80%8E2015'&returnGeometry=true&...

Internet Explorer is retaining the single quotes for the specifed date but Chrome seems to be removing it.

TracySchloss · ‎09-29-2015

If you copy the Chrome request and run it in IE, do you get a response then?

I use where clauses a lot, but unfortunately I don't have any experiences specifically with date fields.

SteveCole · ‎09-30-2015

That was a good suggestions. Pasting the Chrome request into IE yields successful results but pasting the IE request into Chrome returns the 400 error. IE is doing something to the request that is getting passed on.

TracySchloss · ‎09-30-2015

That's a tough thing to track down, nothing but generic kinds of words to do a search on. I wonder if there is anything in the IE settings that is effecting it. Could there be anything in the AGS forums related to the request itself that talks about the differences between browsers?

SteveCole · ‎09-30-2015

Yeah, I debated whether to post this question here or in the AGS forum. I think I'll try a post over there as well. Maybe someone actually from ESRI would chime in. Thanks for the suggestions, though!