Latest Contributions by AllanBenvin

‎02-23-2017

In our environment we have several databases including a maintenance and a published environment that we replicate data to. Because or maintenance database has feature datasets (edit focused) and our published database has different feature datasets (more consumer focused) we are unable to use geodatabase replication. If data resides in a feature dataset in the source the same feature dataset must exist in the target. Because of this we have been using our own custom replication. In our replication we still want to maintain GlobalIDs in both databases, we do not want them to be recalculated as they are when you append. To maintain the GlobalIDs we have had to add an additional GUID field to our published data that we can map the GlobalID to when we append new records. This works, but it involves extra logic, an extra column and more processing time. I recently stumbled across an environment setting in ArcGIS Pro called PreserveGlobalIDs that can be used during an append operation. This seemed quite useful as it could eliminate all the jiggery pokery we are doing now. I tried it out and there seem to be some limitations that make it pretty much useless. The documented usage notes are below: (from: http://pro.arcgis.com/en/pro-app/tool-reference/environment-settings/preserve-globalids.htm) This is useful for workflows where the Global ID value for the row is required to stay the same when exporting or appending data. For the Append tool, this environment only applies to enterprise geodatabase data and will only work on data that has a Global ID field with a unique index. If the Global ID field does not have a unique index, the tool may fail. To add a unique index to your Global ID field, you can use the Add Attribute Index geoprocessing tool. The problems I have found with this are: 1) Works only in ArcGIS Pro, this is not available in ArcGIS Desktop 10.5. 2) Requires a unique index on the GlobalID column. When you create a layer in ArcGIS Pro or ArcCatalog and add a GlobalID column, the software automatically adds a non-unique index. ArcGIS Desktop does not allow the user to remove the GlobalID index. The GlobalID index is created as non-unique so that versioning can be supported. A manual change to a system generated index is required to use this option. This manual change is in direct violation of rules enforced by other ESRI software. I would like to see the preserveGlobalIDs setting supported in ArcGIS Desktop and to also be supported on GlobalID fields with a non-unique index as is created by the ESRI software.

‎03-13-2015

Why do I need to an outage to add a new layer to an existing feature dataset in ArcSDE? In our published read-only geodatabase, we average about 800 concurrent connections. This database is used 24/7 for internal and external services. If we have a new layer that needs to be added to a feature dataset I can not do this without either: 1) Official Method: Killing all user sessions that may be locking the feature dataset, which is basically all 800 sessions. 2) Backdoor Method: Deleting all records in the SDE.TABLE_LOCKS table referencing the feature dataset. The only practical method is unsupported. We need a way to do simple maintenance operations on a geodatabase without booting off all the users. The same applies to editing domains, adding columns, creating attribute and spatial indexes. If Oracle is not locking the objects then why should ESRI? These are read-only users. They should not care, and definately should not prevent, another layer being added to a feature dataset or a spatial index being built.

‎03-13-2015

Why do I need to an outage to add a new layer to an existing feature dataset in ArcSDE? In our published read-only geodatabase, we average about 800 concurrent connections. This database is used 24/7 for internal and external services. If we have a new layer that needs to be added to a feature dataset I can not do this without either: 1) Official Method: Killing all user sessions that may be locking the feature dataset, which is basically all 800 sessions. 2) Backdoor Method: Deleting all records in the SDE.TABLE_LOCKS table referencing the feature dataset. The only practical method is unsupported. We need a way to do simple maintenance operations on a geodatabase without booting off all the users. The same applies to editing domains, adding columns, creating attribute and spatial indexes. If Oracle is not locking the objects then why should ESRI? These are read-only users. They should not care, and definately should not prevent, another layer being added to a feature dataset or a spatial index being built.

‎01-28-2015

This would really make AGOL more flexible and work for organizations that have their own enterprise GIS.

‎01-28-2015

This would really make AGOL more flexible and work for organizations that have their own enterprise GIS.

‎03-20-2014

When symbolizing by "Unique Values" in ArcMap, if a domain is present on the column the the values in the domain are added. If there is no domain the table is scanned for unique values in the data. *If there is a domain but it is out of sync with the actual data only the domain values are added. The other values are listed as "all other values". We have a large published geodatabase that is replicated from our edit GDB. Although we can repilcate data, syncing domains is much harder due to object locking in ArcSDE. We have a large user base that occassionally catches that something is missing, at which point we either update the domain or drop it from the published GDB. I think it would be useful to have a lilttle radiobutton on the Layer Properties - Symbology tab what would allow a user to specify something like "base on domain" or "scan table for values".

‎03-11-2014

We have several hundred layers being replicated. Currently I am doing the creation of the replicas using ArcObjects, I would like to migrate this to Python but we also need the ability to unregister replicas. Having the ability to create a replica but not delete it in ArcPy is useless. If all the tools are not available then ArcObjects is still the only viable alternative.

‎09-23-2013

Has anyone reached any conclusions about direct connect and Oracle client versions? We are currently using application server connects but will be migrating to direct connects. We don't want to have all the users connections and mxds broken if they get a new Oracle client installed. I have done some basic testing on a vmware image by using a connection file created for with Oracle 11g. I unstalled the 11G client and installed 10G. After doing this the connection file still worked but I'm not sure if there were still some remnants of the 11G client on my machine. I'm not sure if at 10.1 and above if the oracle client in the direct connect string is actually used. I suspect it may be there just for historical formatting reasons. In short I'm reluctant to move 500+ users to direct connects that may break if they get a new Oracle client installed. I would be grateful if anyone has any experience or information on this.

‎09-06-2013

I am getting the same thing with 10.2 when pointing to an Oracle ArcSDE database. Things work great with a file geodatabase but unfortunately it is not just me working in my basement, this is a large multi-user environment.

‎05-10-2013

I have created a search service on 10.1 and can get it to search and index a file geodatabase that I copied to the server. That's great, it means the service is working but I really want to have the service search our published ArcSDE database. I copied a connection file to the server and added it to the connection but nothing happens, it does not index it. Using 10.0 I was able to get a search service working with an SDE connection after a lot of messing about. Since the connection file had a username/pwd saved in it all objects added to ArcMap from the seach came in with the same saved username/pwd from the search service connection file. So I have two questions: 1) Do SDE connections work with 10.1? I can't get it to index an SDE connection even with a saved username/pwd 2) Why (in 10.0 at least) when I have a search service pointing to SDE does it connect with the same credentials on the search service connection file? It should anonymize the connection and allow each user to connect with their own userid. If anyone has any experience with this then please reply. Thanks

‎05-06-2013

Update, I got my script to work. "findAndReplaceWorkspacePaths" does work but only if your new connection file is stored on a UNC path. It won't work if your new anonymous connection file is on your local machine. (Yes I know this makes absolutely no sense.) The other thing I had to do was make the connection parameters different in the anonymous connection file. If the instance and server are the same, nothing will change. I had to append the full domain name to the server to make it different ('server.stuff.here'). This is a pain because if I run the tool again I will have to change the server name back to just 'server'.

‎09-20-2012

We are also trying to replicate from an edit GDB containing layers in various feature datasets to a published GDB with a different structure (different feature datasets). The only way we create a replica in this scenario is to: 1) Create/paste the layer to the published GDB. Must be outside of a a feature dataset. 2) Create a dummy feature dataset in the target named after the source FDS. 3) If there is a relationship class in the source to any other FDS, then create dummy FDS's for those in the target. 4) Create the replica. 5) delete the dummy feature datasets 6) move the target layer into the desired feature dataset. You may be thinking what a huge pain in the a$$. Yes. Yes it is. The problem is even worse in a production system. We can't be moving layers outside of feature datasets and creating dummy feature datasets without an outage of service to the users. The point of the published GDB is to have the highly available data for internal and external map services. The way locking works on feature datasets everything is pretty much guaranteed to be locked all the time. Why should we have to create dummy FDS just to create a replica?

‎09-20-2012

We have the same situation. We only want to publish some of our data not everything. We also want to be able to re-organize the data in the published GDB. We do not necessarily want it to be in the same feature datasets that it was in the source GDB.

‎08-30-2012

I'm doing something similar but I am trying to export annotation. I also want it to be in a consistent projection with my target database so I am importing it into an existing feature dataset. I get different useless results based on the method. Using ArcObjects with Geoprocessor object 1) If I use FeatureClassToGeodatabase_conversion then the data comes out okay but the name of the output layer is always GPL0 or GPL0_x. The resulting annotation will display fine on the map but I need to be able to control the name. 2) If I use FeatureClassToFeatureClass_conversion then I can control the name of the output dataset but my annotation is hosed. The internal columns such as ANNOTATIONCLASSID, TEXTSTRING, FONT etc are all null. The resulting annotation will not display on the map. These above commands seem to correspond operations in ArcCatalog. Using ArcCatalog: 1) If I right click on the target feature dataset and select Import:Feature Class (multiple) then the data comes out okay and it is named the same as the source. The resulting annotation will display fine on the map. It seems like this is doing the same thing as FeatureClassToGeodatabase_conversion in that the data is actually good but the gp object randomly names the result and the ArcCatalog tool forces the name. I'm guessing there is a rename going on here after the process. 2) If I right click on the target feature dataset and select Import:Feature Class (single) then I can control the name of the output dataset but my annotation is hosed. The internal columns such as ANNOTATIONCLASSID, TEXTSTRING, FONT etc are all null. The resulting annotation will not display on the map.

‎05-30-2012

Yes, "findAndReplaceWorkspacePaths" should be able to do what I am asking for but it does not. It can break the connection but it does not repoint it to an anonymous connection. After following the example supplied by David, the username/password connection is removed from the mxd but when the mxd is opened it does not prompt for the uesrname/password as a normal anonymous connection does. Instead the layers just have the red exclamation mark and each layer must be re-pathed manually. I will submit a ticket with support for this but I still believe a tool built in to Catalog that could "anonymize" mxds would be a great help for any organization that has moved beyond shapefiles and file geodatabases.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by AllanBenvin

Preserve GlobalID on Append

Locking in ArcSDE

Locking in ArcSDE

Re: Configurable Proxy Location for Maps in AGOL

Re: Configurable Proxy Location for Maps in AGOL

Symbolize - Add all Values: option to base on domain or scan table

Re: Unregister Replication via Arcpy and ArcToolbox Tool

Re: Minimum Components of Oracle Client to direct connect ArcSDE database

Re: Search Service won't index everything

Search Services and SDE

Re: Remove password from MXD

Re: Replication-Feature dataset-SDE

Re: Remove dependence among feature classes participating in a topolgy when replicating

Re: FeatureClassToGeodatabase creating output with incorrect feature class name

Re: Remove password from MXD

Preserve GlobalID on Append

Re: Unregister Replication via Arcpy and ArcToolbo...

Re: Replication-Feature dataset-SDE

Locking in ArcSDE

Locking in ArcSDE