Latest Contributions by NanaDei

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

The 'Show of Type' is a filter that can be set to display the desired data type. Both 'Delete Rows' and 'Delete Features' tools have "All filters listed." and "Feature classes". [ATTACH=CONFIG]11811[/ATTACH]       [ATTACH=CONFIG]11812[/ATTACH] The "Feature Classes" filter option may have been selected when using the 'Delete Rows' tool. [ATTACH=CONFIG]11813[/ATTACH] Thanks ... View more

Hi Scott, From the screenshots, it seems the feature class was updated from 1464 to 1539 features. Can you post a screenshot of the geoprocessing output window after running the 'Delete Rows' tool? The Delete Features or Delete Rows tool should achieve the same goal. Data Management Tools > Features > Delete Features Data Management Tools > Table > Delete Rows Thanks ... View more

Since the default for replicating standalone tables is 'schema_only' the following workaround can be used with the 'Create Replica' tool. >>Create a model using the 'Make Table View' and the 'Create Replica' tools. > Pass the standalone table to the 'Make Table View' tool and set a filter in the expression. eg. Objectid>=1 can be used if the entire table is being replicated. > Pass the output of the 'Make Table View' to the 'Create Replica' tool and define the various parameters. ... View more