I have a case that I have spent over a year developing a Sign Inventory application. There has been several stumbling blocks along the way with ESRI limitations of functionality from no Android version of Collector, subtypes groups not working in services, could not use Feature to Feature relationship class relationships, etc. I have another problem that I believe is not going to be an isolated function to me. This problem is taking related records from the relationship class and moving them to another parent feature. My example: I have a pole Feature class (used as the spatial location) for the pole structure. The Pole has a 1:N relationship with table "Sign" records related to the Pole. If the Pole is run over or damaged by a storm, etc. the pole is retired and a new pole is put it in the ground and has an "active" status. There can be up to six signs on one pole (most I have seen). If the signs are still in great shape, then they are physically removed from the old pole and bolted or riveted to the new pole. I can not find any possible way to for them to keep these signs and just move the relationship to a new parent feature. Retiring and adding them all back in is not a logical methodology. Those poles are not retired, they are still in use, but on a different pole. I have created the relationship based on GlobalIDs based on ESRI's strongly suggested method. This goes beyond Collector, but it definitely should reside in remote field collection apps as the field is where everything happens. I have spent well over a year of my life developing this solution (much of it was data quality, hence trying to simplify the field collection methodology and may be the first to include EVERY sign style in the MUTCD specifications (except for Interstate-related signs as our City does not maintain anything on those highways.) Please help, Brett
... View more
In the case of a relational database server failure, ESRI recommends that we restore geodatabases from backups on new server, make all new connection strings to new database Instance (machine name), fix every database connection error in every map and/or ArcGIS Pro project that is connected to an Enterprise database (SQLServer/Oracle, etc.), republish every service on your Enterprise ArcGIS Servers and potentially check/fix all maps and their popups. This process, to me, sounds like potentially a ton of work to get your Enterprise back up and running again. I proposed that there is, potentially, another solution that cuts the work down to a few hours at best. Our servers are virtual on VMware. This approach still would work with stand alone physical machines used as database servers as well. I propose that it is possible to create a server with the same machine name for your Enterprise database server (and for this document, we'll just use SQL Server as an example), leave it off your Domain. Add OS and any typical software and install SQL Server, taking the machine name as the Instance (in effect having the new server with the same name and Instance as your existing server), Then the magic...Take old server off the Domain and add the newly created one to your Domain and restore all geodatabases from their backups Verify user accounts are still there or authorize the same user accounts set up on old server, and in theory, everything is back up and running at that point. All of your old connections should now still work, including Services and Maps. I could not get confirmation form Tech support that this approach works as they have apparently never had anyone with a failing DB Server to confirm this method, so I thought I would ask the Community if this seems to be a way around this type of disaster recovery without all of the work. Please let me know if anyone else has had a failing DB Server and tried another method.
... View more