Latest Contributions by WilliamCraft

You wouldn't necessarily need to rebuild indexes to be able to see data in the feature class.  I'm not sure what the issue could be that you're having.  What method are you using to "push" the edited features into the table?  Are you using an ArcMap edit session, the Simple Data Loader in ArcCatalog, or some other tool?    To connect to your database in ArcCatalog though, look under "Database Connections" and double click Add Spatial Database Connection. ... View more

When you make the edits, are you performing them in a child version of SDE.DEFAULT?  If so, those need to be reconciled and posted to SDE.DEFAULT before you compress in order to see them in the base table. ... View more

Please do not blindly unregister your replicas or delete those replica versions especially if you have functional replicas. If you are having trouble with one replica there is no need to unregister all replicas. Your best bet is to contact Support Services. They would be able to troubleshoot with you. Regards Cheryl Donna, a point of clarification that I'll make based on Cheryl's remarks.  The way your original post is written suggests that you have one and only one replica that is registered with the geodatabase.  Therefore, it was my intention that the instructions I provided to initially troubleshoot the issue involved cleaning out the replica and its related sync send verion(s) that may not be working properly.  I was hoping to get you back to a good starting point so that you could try again to create and register your replica.  I don't believe you have other replicas registered besides the one you described, so I don't think you would be "blindly unregistering" replicas that are otherwise working correctly but I could be wrong.  Let me know when you have more information to report once you have walked through the steps I described.  Of course, you could also open a support ticket but that is certainly your decision.  Good luck. ... View more

I could be wrong, but this feels like it could be related to a limitation in the number of concurrent connections to the database based on the level of ArcGIS Server you are running.  You mentioned that you are running Workgroup, which to my knowledge allows only for 10 concurrent users.  Despite using SQL Server Standard rather than SQL Server Express (which is typically used with Workgroup), I think you are still limited by the Esri software in terms of the number of connections at one given time.  Is it possible that your services, upon spinning up SOC instances per user requests, could be using up your available connections which causes the behavior you describe?  The article below on page 3 discusses the capacity limitations for ArcGIS Server levels.  I know it is for 10.2, but I think if you dig hard enough you'll find something similar for 10.1 SP1.  http://www.esri.com/library/brochures/pdfs/arcgis-server-functionality-matrix.pdf See if you can log into your database to see how many connections are being made to the geodatabase by Esri-related clients such as ArcGIS Desktop, Flex GIS applications, Python scripts, etc.  This might tell you if you've hit some sort of maximum limit. ... View more

My suggestion is that you utilize the Export / Import Configuration tool for ArcGIS Server 10.2 using the Administrator Directory.  That URL is generally something like http://gisservername:6080/arcgis/admin/login.  This tool allows you to backup and restore your site configuration whenever you need to rebuild a server.  I do think taking a backup of the configuration store and the server directories would be a good idea in case there are specific files that need to be recovered after importing the configuration.  However, I believe the configuration site export file should contain all of your service definitions and registered data stores.  If you are using a multi-server site by chance, make sure you re-install the software on all of the ArcGIS Server machines and join them together as a site before re-importing your configuration. ... View more

The T5_Inserts feature class from the delta geodatabase will contain whatever changes were made to the parent geodatabase since the last sychronization and acknowledgement transpired between the parent and child (replica).  Modifying the feature class in the delta geodatabase will probably lead to a plethora of problems with respect to applying the changes to the child correctly and to keeping the two geodatabases in sync as a whole.  I would not recommend editing the delta geodatabase. If you want to fix this issue, I would suggest going back to the source feature classes within the parent and fixing the data at its origin.  You mentioned that features were accidentally copied into another feature class.  It should therefore be possible to start an edit session on the parent geodatabase and copy the features back to the appropriate feature class (or delete them entirely depending on what you had intended).  From there, you would generate another delta geodatabase, import it to the child, and then acknowledge it.  In other words, get the data issues fixed on the parent and then proceed with the synchronization process. ... View more

Ian, does the user account that is running the ArcGIS Server service on your server have read/write permissions on the ArcGIS Server directories and configuration store?  I am assuming that your ArcGIS Server site consists of a single machine only.  If there are multiple machines in the site, then the account running the service on each should have exactly the same name and password.  Furthermore, a domain account is something I would recommend for the service run-as account. ... View more

It sounds like you might need to register the data store (i.e., your Oracle or SQL Server data connection or your file GDB) with ArcGIS Server before publishing.  If the data store(s) referenced by the layers in your map document / service definition are not registered with ArcGIS Server, I believe the default behavior is for a copy of the data to be made and placed locally on the ArcGIS Server machine.  To prevent this, check out the following link: http://resources.arcgis.com/en/help/main/10.1/index.html#//01540000060n000000 To register your data stores, check out this link: http://resources.arcgis.com/en/help/main/10.1/index.html#//015400000504000000 ... View more

If you are only updating one field (the subtype field) of a particular table, then something like this would be all you need: UPDATE DBO.SDE.TABLE1 SET SUBTYPE = 1 WHERE SUBTYPE = 2; Running this statement in SQL Server Studio Manager as a user with write privileges on that table (or the 'sa' account) would change the values for the SUBTYPE field but no other fields.  Let's say that you'd like to change all values that are currently '2' to become values of '1'.  The statement above would accomplish this.  If your table is versioned, ensure that you have compressed to state 0 before doing something like this on the base table (i.e., DBO.SDE.TABLE1). ... View more

The replica log within the database is the SDE.GDB_REPLICALOG table.  This is the case for 10.1 and for just about all previous versions of ArcSDE.  Interpreting any of the numeric values in the ERRORCODE field can be painful and must be done with online searches.  There are a few random Esri-published articles about specific error and HRESULT codes but they are incomplete and difficult to understand at times.  A better (but not always great) way of seeing the messages associated with any replication error codes from the log is to use the "View Log" feature found within the Manage Replicas dialog box in ArcCatalog.  This can be accessed by right clicking the geodatabase connection and picking Distributed Geodatabase from the menu.  Once you find your replica of interest in the list, right click the replica entry to see a sub-menu with the View Log feature I mentioned before.  In summary, you might find something like "-2018348485" in the ERRORCODE field of the SDE.GDB_REPLICALOG table but in the View Log dialog box you might see something like "CANNOT LOAD LOW PRECISION OBJECT WITH HIGH PRECISION DATA".  This is just an example, but I think it makes the point that you'll get a bit better error reporting in ArcCatalog than directly querying the SDE.GDB_REPLICALOG  table. ... View more

Is this data in SQL Server or Oracle by chance?  Your best bet might be to run a SQL statement against the table to update the attribute values for the subtype field without affecting the other fields.  If you do this on a versioned feature class, make sure there are no records in the corresponding A and D tables before executing your SQL against the base table.  In other words, go to state 0 before mass applying a SQL attribute update. ... View more

I think his suggestion might be to ensure that the user you are connecting with in ArcCatalog has been assigned to something like the db_datareader role within the database.  Technically, a user account can exist and connect but have no permissions to see any records.  So, you have a user login set up at the SQL Server instance level and there should be a corresponding user created within the database for that particular login.  In SQL Server Studio Manager, if you can log in as an administrator or the 'sa' account then you can expand the database properties to see the Security section.  Under the user in question, right click to see the properties and then ensure that it has been assigned to at least one role. ... View more

Is it possible that your tables are registered as versioned within ArcSDE?  If so, which transactional version are you connecting to with the ArcSDE connection file from ArcCatalog?  I'm wondering if all of your records might exist in a different version that hasn't yet been reconciled and posted.  For example, you might be connecting to SDE.DEFAULT to view the data in ArcCatalog but perhaps you've inserted your records into a child version called SDE.DEFAULT_CHILD.  As another test if this turns out to not be the issue, can you log into SQL Server Studio Manager and see the records that way?  If you cannot, then your tables might be empty to begin with. ... View more

That could certainly be the reason for the error, yes.  But, let me know if either of the two suggestions I mentioned prevents the error from occurring.  To re-cap, one suggestion was splitting versioned and unversioned feature classes into two map documents.  The other suggestion was using two ArcSDE connection files (one for versioned and another for unversioned) to path your layers in the map document and seeing if opening an edit session lets you pick one. ... View more

Open the map document (i.e., MXD) for this particular map service and check to see if the layer referenced in the error messages shows a red exclamation mark.  If so, then you have a broken data source that needs to be repaired for the map service to stop throwing errors.   It looks like the underlying data source for that layer in the map document might be the SY_DES_CLEANSING.Mech_Gritting_CWays_Pri1 table within Oracle.  Which user are you using in your ArcSDE connection file for the map document's layer connections?  Does that user have permission to see the base table AND the A, D, S and F tables for that particular object class?  If the user does have the right permissions on all 5 tables and/or you are connecting as the schema owner (i.e., SY_DES_CLEANSING), then I'd be curious to know if you are using Oracle Spatial (i.e., SDO geometry) based on the error content.  I have heard of a number of issues with successfully getting layers to register with ArcSDE.  I know there are many other individuals on these forums with much more Oracle Spatial knowledge than myself.  🙂 ... View more