Latest Contributions by NanaDei

Hi Simon, We are reviewing this case in-house and a support case will be created shortly to reference your Esri UK case number. Further review of the behavior will be handled through the support case. Thanks Nana ... View more

Hi Simon, Can you please log an Esri support incident for a review of the encountered performance behavior? In addition to answers to Vince's inquiry, please include a trace file and the PostgreSQL configuration parameters. Please let me know the case number when you receive it from the support team. Thanks Nana ... View more

The error is being encountered as the created "spatial table" is not a geodatabase object and such tables are not directly editable within ArcMap. The current "spatial table" resides in a database which is not a geodatabase. Such "spatial tables" are termed as "query layers". You can find information about using query layers from this blog. At ArcGIS 10.2 and above, query layers are editable using a feature enabled map service. ArcGIS Server is needed to create a feature service using the query layers. This link sheds light on authoring feature services and it has information on using a 'geodatabase' or 'database'. The following link also has a tutorial on how to perform web editing using data from a 'database'. From the initial problem description, one can also leverage ArcGIS Online to create a feature service. Information about creating a hosted feature service can be obtained from here. Please let us know if the above information was helpful in reaching your goal. Thanks ... View more

There are 2 bugs mentioned in knowledge-base article 42335. NIM099594 - Oracle errors, ORA-29877, ORA-20085 and ORA-06512 are encountered when attempting to make object schema changes, spatial index changes, add Global IDs, register data as versioned (Register as Versioned tool), or create a raster dataset in ArcCatalog after upgrading certain ArcSDE 10.0 Oracle geodatabases. The following error messages may be returned: "ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine ORA-20085: Insert Spatial Reference SRID 4326 does not match SDE.GDB_ITEMS.SHAPE registered Spatial Reference SRID 0 ORA-06512: in "SDE.ST_DOMAIN_METHODS", line 2000 ORA-06512: in "SDE.ST_DOMAIN_METHODS", line 2372" NIM095988 - When editing data that has been upgraded from ArcSDE 9.3 to ArcSDE 10.1, the following error is returned: "ORA-20085: Insert Spatial Reference SRID 2274 does not match dataowner.A833.SHAPE registered Spatial Reference SRID 3" A general patch is being tested and is expected to be released soon for NIM099594 on ArcGIS 10.2.2, 10.2.1 and 10.1sp1+QIP. A fix for NIM095988 is already available in 10.1sp1+QIP and 10.2.2. However, the patch for NIM099594 on ArcGIS 10.2.1 will also include the fix for NIM095988. ... View more

Thanks to mhassoun. The behavior was related to working on ArcSDE 9.3 geodatabase feature classes in SQL Server 2005. Please review the following link for SQL Server versions supported at ArcGIS 10.2. ====== http://resources.arcgis.com/en/help/system-requirements/10.2/#/Microsoft_SQL_Server_Database_Requirements/015100000070000000/ Thanks ... View more

Hi CCStormwater, Can you please contact Esri Tech Support for further review on this behavior? Thanks ... View more

Hi Luke, The behavior seems to be related to SQL Server 2012 native client and we are actively reviewing this issue. The SQL Server 2008R2 native client is forward compatible and it can be used with the SQL Server 2012 gdb as a workaround for this replication sync behavior while we review the issue. Testing on our end indicated that the sync succeeds only with SQL Server 2008R2 native client installed on the client machine. The sync fails under these conditions: - SQL Server 2012 native client installed on a client machine - both clients (SQL Server 2012 native client & SQL Server 2008R2 native client) are installed on the same client machine From your post you mentioned that "We had an issue connecting to sql server 2012 databases using the sql native client other than using the sql native client 2012...identical release version as the database." What is the build of the sql server instance? eg. SQL Server 11.0.2100 Is it likely you'll be able to test from a test machine having only SQL Server 2008R2 native client installed? You can also log a support incident for further review if the connection issue persists with only the SQL Server 2008R2 native client installed. Thanks ... View more

Hi Chuck, Is this user is part of a database role or windows group on the SQL instance? Is the issue only  specific to this windows user? Database users and other windows users work successfully? CONNECT privilege is granted on databases to the public database role by default. Hence, you can grant the "db_datareader" database role to the user as a minimum. Thanks ... View more

🙂 - I was checking whether the parcel data being replicated was a 'parcel fabric', as replicating parcel fabrics is not supported pre-10.1. Since the replica creation succeeded at version 10.0, I don't think a parcel fabric was involved. Thanks for the information. ... View more

Since you've been able to create the replica, this suggests that all feature classes/tables in the parent geodatabase has GlobalIDs and they are registered as versioned. Layers that are not versioned and/or do not have Globalids are not included in the replica. I also wanted to check if the data being replicated is a Cadastral (Parcel) Fabric and which version of ArcGIS Desktop version (10.0 or 10.1) is being used to create the replica. Thanks ... View more

At ArcGIS 10.1, one can change field names for tables/feature classes in a 10.1 geodatabase.  Field names must still conform to geodatabase field name guidelines and  fields in a 9.3.x or prior release geodatabase cannot be renamed.  Other changes to fields are not currently supported at 10.1 and the remaining listed requests will be re-evaluated as separate ideas post 10.1 for inclusion in a future release.  Hence, this idea will be modified to the 'Change field order' request. ... View more

Hi Tom, The feature datasets are owned by 'dbo' due to the fact that the user who created the datasets is/was part of the 'sysadmin' role. The 'dbo' user concept is explained in the following Microsoft documentation. For ArcSDE geodatabases, the owner of the dataset is the only user who can create/import feature classes into the dataset. The last statement from the following link can be reviewed. Granting users "CREATE TABLE" and "CREATE PROCEDURE" permissions will allow users to create data in the geodatabase and in feature datasets that they own. Users who own data in an ArcSDE geodatabase must also have the same name as their default schema. The following link can be reviewed for this information. In your instance, it may be appropriate to have a single database user, eg. 'gisadmin' owning all data(feature datasets, feature classes, etc) in the geodatabase so that all users are not added to the 'sysadmin' role. Thanks. ... View more

Thanks for your response. The following link discusses unregistering data as versioned. Step 1 can be skipped if sde.DEFAULT or dbo.DEFAULT is the ONLY version in the geodatabase. Complete step 1 if child versions exist in the geodatabase. The following geoprocessing tools can be used for the 'compress' and 'unregister as versioned' operation. -- Data Management Tools > Database > Compress -- Data Management Tools > Versions > Unregister as Versioned The following link also sheds light on registering and unregistering data as versioned. Please let us know if the above information helps in your case. Thanks ... View more

The feature dataset must be unversioned first, prior to removing it from the topology. This behavior has been enhanced in the upcoming release of ArcGIS 10.1, where feature classes from a versioned topology can be removed when the ArcSDE geodatabase is version 10.0 or higher. Thanks ... View more

Is 'DBO.Parcels' participating in the 'Cadaster_Toplogy'? If it is participating in the topology, the 'Delete' option will be grayed out. Thanks ... View more