Latest Contributions by NatCarter

If you do a Join between the Feature Class and the Attachement table to identify which features have attachments or not the resultant layer will not expose the attachments when using the Identify tool.  This means we can symbolize them as needed but we loose the functionality of retrieving the one or many attachments since a join is a one-to-one and attachments are a one-to-many relationship. Xander has a good process to identify those features that have attachments and make note of it in a new field in the feature class but this is a job that needs to be run after every edit or built into a users workflow. An on the fly way to accomplish the symbology we are after without extra fields and jobs to calculate those fields is to leverage the layer's definition query.  ESRI's documentation refers to this as a Subquery when you build a definition query for a layer that has to do with data from another feature class or table.  Try using this syntax to complete the SQL statement in the Definition Query property of your layer to filter its records based on the presence or absence of attachments.  In this example Global ID in the Feature Class is used as the foreign key in the Attachment Table. Feature with Attachments = GLOBALID IN (SELECT REL_GLOBALID FROM <your attachment table>) Feature without Attachments = GLOBALID NOT IN (SELECT REL_GLOBALID FROM <your attachment table>) ... View more

We figured out that our issue was a result of the way the Query Widget sends the request to the service it's tied to. The Query Widget first goes after the count of the returned features of the request and then goes after a full feature set by listing all Attribute Fields noted in the service for the Query's "Out Fields" parameter vs leaving it empty. Going after all the Fields listed by the service for the Feature Layer being queried failed the request as the service's JSON was not up to date with backend data changes. Once we re-published the service with the update feature attributes the Query Widget was able to process the request correctly. Although our service definition needed to be refreshed we never assumed that the WAB Query Widget was going after specific fields in our feature layers without us defining them. Maybe a "*" or leaving the Out Fields empty by default would be a better implementation unless its explicitly defined in the Widget's paramaters. Thanks for the follow up. ... View more

Andrew, We are also experiencing the same issue although we are hitting our ArcGIS Server v10.41 services from the WAB applications hosted by AGOL.  Our query widget was working fine until the ArcGIS.com outage earlier this week and now that its come back on line and then updated (March release) our query widgets are returning "Query Failed" although querying the service through its REST endpoint with the same where clause is just fine. Checking the network traffic in debug mode in the browser shows that the query request is returning a valid and correct response of the ObjectID assigned to the result of the query so it must be the code in the updated widget??? I tried adding a brand new query widget from the WAB seeing if my previous widget didn't update correctly but the new one added 3/3/17 doesn't work either. - Object ID field is defined - There are no joins to the feature layer in our service - The behavior is consistent across browsers - We are querying against an integer field type  Thanks for the help in modifying the configs in the widget to get it to work or just keeping us in the loop on this bug. Nat Carter GIS Coordinator Montana DEQ ... View more

Thanks, that was it.  Another solution is to switch out the data sources for the service to an FGDB and there are not any query request errors or limitations other that the MaxRecordReturn of the service itself. Thanks for the quick help. ... View more

Do you have a public service we can use to reproduce this? Please see the attached document for service URLs, example SQL, & mapping service properties. ... View more

As the ESRI documentation of using one SDEHOME and creating unique dbinit.sde files for each instance only works for initial creation, and not one the service is restarted, one solution is to create a separate SDEHOME for each instance. 1. Create a named folder on your C drive for each instance; maybe even the same name as the instance to help keep track of everything.  In my case I created 3 new folders C:\DEQGPRD, C:\DEQGPUB, C:\DEQGFLD for my 3 instances. 2. Go to the current installation of ArcSDE and copy and paste the entire thing into each folder. 3. Update the service and dbinit files within each new "home" to reference just the one service they will manage. 4. Be sure to update the windows\sys32\drivers\etc\service file with any changes to the service names. 5.  Do not run the ArcSDE Post Installation wizard but instead use the sdeservice commands to set up the services for each separate SDEHOME.  See http://help.arcgis.com/en/geodatabase/10.0/admin_cmds/Support_files/serveradmin/sdeservice.htm#xregister for help with the sdeservice command parameters. When I restarted the services manually or the rebooted the server all SDE services remained in tact the way they were set up. ... View more

Hi all all the questions above are now solved. I have created 4 ODBs and SDE services using this method exactly: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Using_multiple_geodatabases_in_Oracle The 4 DBs are now populated with data. Normally they work fine. This is until I restart the PC. And I started getting an 'bad user' error message when tried to connect to either SDE service from catalog. I noticed the following: I have copies of the dbinit.sde file: the original dbinit.sde dbinit_chevdb.sde dbinit_enidb.sde dbinit_geology.sde each of them is pointing to a different ODB. My default DB is callled orclsde and this is what must be set in the the original dbinit.sde. But now it has changed to the database that is pointed to by dbinit_geology.sde. This made all SDE services useless. If I delete all SDE service and recreate them again using postinstall's last step 'create SDE service'  they all work fine until next restart. Using only the last step in the post install DOESNT use customized dbinit.sde. It uses the DB name though. Any ideas why it does this? How can I have stable 4 instances of SDE. I have run into the same issues when connecting via SDE services to my 3 databases.  Followed same protocol and instructions as you and ended up with same results as you.  Any updates on how to keep the SDE Services in tact after restart??? It looks like after a restart all SDE Services look for the entry in the default "dbinit.sde" file and ignore the custom ones defined when they are initially created.  If you manually change the Oracle_SID entry in the dbinit.sde file to the right SID before starting the cooresponding SDE service...the SDE Service performs correctly like it did when you initially created it using the custom dbinit file for each SDE Service. Do I need to write my own batch job that runs at start up to control this or is there an ESRI fix?? ... View more