Latest Contributions by ChrisBeaudette

Thanks Ted, good advice!  An index should have existed on that table already, but didn't. Some interesting results this morning: - Before adding the index, querying the layer took ~3.7s in the browser (it was unusually fast this morning for some reason) - Added a unique, clustered index on Addresses.LocationAddressId (used in the WHERE clause):  query took 43s. Completely counter-intuitive! Restarted the GIS service:  4.6 minutes Even less intuitive! While I was at it, I added a non-unique, non-clustered index to Addresses.LocationPointId (used in the JOIN) and a unique, non-clustered index on Locations.LocationPointId (also used in the JOIN).  (Note that there was already a clustered index on OJBECTID in the Locations table, so I was forced to create a non-clustered index).   Result (after restarting the map service):  4.5m  Time spent in DB on "exec sp_cursorexecute ..." (the business end of the query with 554K reads): 381 ms For the balance of the duration of the request, the database is executing "exec sp_cursorfetch" commands twice per second, e.g. "exec sp_cursorfetch 180150129,2,1,100", until the response is returned to the browser, at which point the "exec sp_cursorfetch" commands cease. If I remove all indexes and restart the map service, a single request still took 4.5m.  This is a development environment and I'm the only one hitting both the GIS server and the database.  A SQL Profile trace confirms this. Note that my tests consist of panning a map service with a single query layer in it using the JS API in a Web browser. I suspect yours and my situations are different for environmental reasons unknown.  Wish I could get this to work in a reliable manner, but it looks like my only option is to downgrade to AGS v10.3x. ... View more

Got it.  My expectations have been correspondingly lowered.  (Again) ... View more

Thanks for the reply Drew. We actually already tried using the SQL from the spatial view in our query layer -- that's the code included in my post above.  Before we did that, our query layer was (effectively) a simple 'SELECT * FROM OUR_SPATIAL_VIEW', and OUR_SPATIAL_VIEW had the SQL code above.  Pulling the SQL into the query layer seemed to help at first, but subsequently performed poorly for us.  The performance stats noted above were using the "full" SQL in our query layer. Would love to hear from Esri on this. ... View more

We are running into a very similar situation with ArcGIS Server v10.4.1: published map services in v10.4.1 with a query layer are extremely slow so as to be unusable, whereas the same MXD published to a v10.3.1 AGS instance -- using the same data layers in the same SDE instance (v10.2.2 on SQL Server 2014) -- perform as expected. When using the AGS JS API to browse the map services (pan, zoom, etc), each containing the same, single query layer, the following browse times are observed in Chrome Dev tools and SQL Server Profiler: - v10.4.1: o time for round trip in browser: 4m 36s o duration of time in database query: 349ms o number of database reads: 559,555 - v10.3.1: o time for round trip in browser: 3.2s o duration of time in database query: 2.02s o number of database reads: 830,292 Ignoring the differences (by a factor of 6) for the duration of the database query (since the db times are a small fraction of the total time w/ v10.4.1), it's pretty obvious that the bulk of the time of the request to v10.4.1 is spent in the AGS tier. At the time of the request, CPU and memory on the GIS server were not under strain and were not variable. In other map services that had multiple layers, when one of them was a query layer, the map services were equally slow, as were ALL map services on the v10.4.1 instance at the time the map service with the query layer was running. When the query layer was removed from the map service, performance returned to normal. The query itself references tables all within the same database and runs in 4s in SSMS for all features: SELECT Addresses.[LocationAddressID] , Addresses.[HouseNumberStreetNameFull] , Addresses.[ParcelID] , Locations.LocationPointID , Locations.Shape FROM [GIS].[Addresses_All] Addresses INNER JOIN [GIS].[LOCATIONPOINT] Locations ON Locations.LocationPointID = Addresses.LocationPointID WHERE Addresses.[LocationAddressID] IN (SELECT MIN(LocationAddressID) FROM [GIS].[Addresses_All] GROUP BY LocationPointID) The noted bug (BUG-000097186) refers only to ArcGIS Desktop -- not ArcGIS Server. ESRI: Is this also a known issue with ArcGIS Server? This should be simple to reproduce -- have you been able to do so? Other than downgrading to v10.3, what are my options? ... View more

I was having the same issue.  My scenario: - ArcGIS Server 10.4.1 (without the noted patch applied), running as an arcgis user that is a domain account - SQL Server 2014 - MXD with a single layer that references the geodatabase with a domain account - The arcgis domain account was added to the geodatabase using ArcCatalog:  Administration > Add User - Publishing a simple map service, i.e. no feature service, KML, etc. I got the following error in ArcMap: 001487 : Failed to update the published service with the server-side data location. Please see the server's log for more details and the following 3 errors in the AGS logs, all with a 'Source' of System/PublishingTools.GPServer: 1)  Failed swizzling the service 2)  Failed to create the service.: Updating the server connection string for layer DB_NAME.SCHEMA_NAME.LAYER_NAME failed. Attempted connection string was SERVER=SQL_SVR_HOST_NAME;INSTANCE="DSID=deba8037-3eb1-48c8-ae85-5af6cab4ac1b";DBCLIENT=sqlserver;DB_CONNECTION_PROPERTIES=SQL_SVR_INSTANCE_NAME;DATABASE=DB_NAME;VERSION=sde.DEFAULT;AUTHENTICATION_MODE=OSA. Table name is DB_NAME.SCHEMA_NAME.LAYER_NAME. Please verify the data exists on the server. 3)  Error executing tool. PublishServiceDefinition Job ID: j5fc1408de51349e3b665bab437ddd069 : ERROR 001487: Failed to update the published service with the server-side data location. Please see the server's log for more details. ERROR 001369: Failed to create the service. Failed to execute (Publish Service Definition). I was able to publish to other geodatabases in the same instance.  I did a SQL Profiler trace on the failed publish and found the following error: The EXECUTE permission was denied on the object 'SDE_get_primary_oid', database 'DB_NAME', schema 'sde'. When I compared the SQL Server permissions on that stored procedure, I found that the 'public' db role had no permissions at all in the database where the publish was failing, and 'execute' permissions in the DB where it was succeeding.   Perms on sde.SDE_get_primary_oid in database where publish was failing: Perms on sde.SDE_get_primary_oid in database where publish was succeeding: A cursory glance at other stored procedures in the sde schema showed that the SQL 'public' role had execute permissions on all of them, even in the database where the publish was failing.  For some reason, the required permissions were not granted to SDE_get_primary_oid only.  This was unexpected since in both databases I added the same domain user account using the Create Database User tool. The solution was simply to add execute permissions for the SQL 'public' role on the sde.SDE_get_primary_oid stored procedure.  And, of course, to swizzle my bad self. ... View more

RE "in 10 the main scope from multiple instance is support more than one type of authentication or user/role store":  this is exactly what we need to achieve.  Is this no longer possible as of v10.1? ... View more

Kurt: I'm curious about this as well since we are just getting started with the SDK.  What features are you interested in that have not yet been implemented? ... View more

One additional very important note regarding the onclick event handler for the FeatureLayer:  change this:      $(".titleButton.arrow").on("click", function(evt) to this:      $(".titleButton.arrow").one("click", function(evt) (Note the "one" instead of "on" for the event handler attachment).  If "on" is used then a listener is added each time you click the arrow button and the handler is executed n+1 times each time you click it.  Using "one" executes the handler at most once per element per event type. ... View more

I know this post has been around a while, but I recently had the exact same requirements and was able to do it as follows... These can be implemented using a combination of the on click event handler of the FeatureLayer that has the popup associated with it, and some overridding css. Note that I'm also using jQuery and jQuery Mobile.  There may be a cleaner way to do this, but this worked for me: For #2, "override the behavior of the showContent button ( > ), so that it calls my own function", you would add an onclick event handler to your FeatureLayer as follows:      var fl = new FeatureLayer(...);      fl.on("click", function () {                     $(".titleButton.arrow").on("click", function(evt) {   // this is the selector for the circled arrow div                         //evt.preventDefault();  <-- Note that this has no effect, hence the comment                         $(".esriMobileInfoView.esriMobilePopupInfoView").css("display", "none"); // hide the default contents of the attribute info div that takes up 100% of the viewport                         alert("hi there"); // put your custom code here                     });       }); Note that hiding the contents of the default div that contains the feature's attribute info must be done on the onclick event for the feature layer -- adding this to your css will NOT work, even if you use "!important":      .esriMobileInfoView .esriMobilePopupInfoView {           display: none;      } This has the effect of hiding the default behavior while implementing your new behavior.  For #1, "suppress the display of the feature count", I found that this takes a combination of adding another jQuery selector to the onclick event handler for the feature layer:      $(".titleButton.prev").parent().css("display", "none"); This has the effect of selecting the parent element of the left "previous" arrow in the feature count area, whether it is hidden (in the case of a single element) or not. The parent of the "previous" arrow contains all 3 elements of the feature count area -- the "previous" arrow, the feature count, and the "next" arrow -- so by hiding it (the parent) you effectively hide the entire contents of the feature count div area. Note that none of these work when put into css (as well as other css parent selectors):      .titleButton .prev > div {           display: none;      } which is why I put it in the onclick event handler of the FeatureLayer. For completeness, this is the entire event handler for the FeatureLayer:           fl.on("click", function () {                     fl.setInfoTemplate(new PopupTemplate({ ... }));  // I'm also setting my InfoTemplate here                     $(".titleButton.prev").parent().css("display", "none"); // hide feature count area                     $(".titleButton.arrow").on("click", function(evt) {                         $(".esriMobileInfoView.esriMobilePopupInfoView").css("display", "none"); // hide default attribute popup                         alert("hi there"); // add custom onclick handler code                     });                 }); Some additional css is also required (this could also have been handled in the event viewer, but I prefer it in the css wherever possible):      .esriPopupMobile .titlePane .title {           margin-top: 9px !important;  /* I found that the !important is required here */      } Note that this will move the title of the Popup down 6 more pixels from the already-set 3 pixel margin. This is necessary since the feature count area is removed and so the title must be re-aligned vertically. ... View more

FeatureLayer is inherited from GraphicsLayer. From the help information Doh!  Should've caught that.  Thanks for answering so quickly. ... View more

Agreed ... View more