Latest Contributions by AllanBenvin_yyc

Thanks for this post. We have a similar issue with Oracle. For various reasons I won't get in to our data is defined as a custom 3TM WGS84 114 but the coordinates are actually NAD83 3TM 114. This issue is not noticed internally as all our data matches. It is only when we share externally that we see the issue. We need to correct the spatial reference of all our data but retain the current correct coordinates. A re-project is not valid as it would move the data so the DefineProjection tool looks promising at first. However, in testing I have found that it only partially changes the spatial reference of a layer. It seems to update the layer definition in the GDB_ITEMS table but the SRID in the registration tables and on the features still have the old SRID.  I have found that doing a DefineProjection and then a subsequent copy/paste will correct the SRID on the registration tables as well as on the features. Unfortunately, doing a copy/paste on our 4000+ datasets which include complex data types, versioning, archiving, topology, relationship classes and networks would create a total mess. It turns out I came up with the same method as the original poster here, but in my case my testing was done with Oracle. We also have SQL Server but Oracle hosts our most complex data sets. The attached document details my testing, processes and the various registration values, but I'll include a bit of info in the text here. As mentioned, the DefineProjection tool only updates the layer definition in GDB_ITEMS but the SRID remains the same. The process below shows proposed method on how to update the SRID without altering geometry for data in Oracle SDE. Manual update using SQL   This fixes the registration and the geometry without having to alter archiving, versioning, relations classes etc. Proposed Process: 1) DefineProjection to define as WKID 3776 2) Delete spatial indexes 3) Update SRID on features to same geometry but change the SRID UPDATE AB_CAL3TM_CHANGE SET SHAPE = SDE.ST_GEOMFROMWKB(SDE.ST_ASBINARY(SHAPE) , 3776); 4) Update the ST_GEOMETRY_COLUMNS to the correct SRID update SDE.ST_GEOMETRY_COLUMNS SET SRID = 3776 WHERE TABLE_NAME = 'AB_CAL3TM_CHANGE'; Update SDE.LAYERS to a SRID that has the same SR as well as M, Z tolerance etc, see section below named  Gettting Layer SRID in document. UPDATE SDE.LAYERS SET SRID = 86 WHERE TABLE_NAME = ' AB_CAL3TM_CHANGE’; --(this is the srid of a valid nad83 layer) So far I have only tested this process on a few layers but the results have been good. The one question I have is how do I know which SRID to use for the SDE.LAYERS  table? In my testing I have been reading the SDE.LAYERS table to find a record with the desired spatial reference and matching xyzm values. If there is no matching record my next course of action would be to create a layer that has my desired properties via ArcPy and then find the LAYERS.SRID value from that.  If this process proves valid I would script it to handle versioning, archiving, fabric etc. See the attached document for the full process and please let me know your thoughts or suggestions on this process. ... View more

Yes, it is ridiculous that we cannot copy/paste values into this field. Typing long URL and GUID values in here is impossible as it automatically adds double quotes. When you delete one of the extra quotes it removes your whole string.  How hard is it just to have the ability to enter text like a normal person? It seems the box is trying to introduce logic to "help" but it makes it impossible.   PS: Also the font makes it hard to distinguish between l1 0O ... View more

I second the comment by JS_ESRI. I do a similar thing where I want to restrict editing of certain records in a table to specific users.  In my case I have two validation tables: 1) a superuser table for the support team names 2) an maintuser (editor) table. If the current user is in the superuser table they can edit any record. If the user is in the maintuser table and the current record corresponds to their currently selected record, then the edit is allowed to proceed. Code is below for reference. (Don't judge too harshly) var curUser = GetUser($featureSet).username var loadTab = $feature.LOAD_INSTANCE+"."+$feature.LOAD_OBJECT_OWNER+"."+$feature.LOAD_OBJECT_NAME //check if user is in the superuser tab //Parse curUser to strip out @coc and convert to uppercase var idx = Find("@",curUser) if (idx > -1){ curUser = Split(curUser,"@")[0]; } //Check if user in superuse table var superTab = FeatureSetByName($datastore,'GBS_UTIL.COC_METADATA.METADATA_SUPERUSERS', ['*'], false); var superSQL = "UPPER(USERNAME) = UPPER('" + curUser + "')"; //run the query var foundRecs = Filter(superTab, superSQL); var superCount = Count(foundRecs); //If user is in superuser table then return tru and allow edit, no need to go further if (superCount > 0) { //return {"errorMessage":"Current was in SuperUserTable:"+curUser+ " count is:"+superCount} return true } //If not in SuperUser table then check privs. //check if curUser is in an editor: var maintTab = FeatureSetByName($datastore,"GBS_UTIL.COC_METADATA.METADATA_EDITORS_V", ["*"], false); var maintSQL = " LOAD_OBJECT_FULLNAME = '"+loadTab+"' "+ "AND "+ "(PORTAL_USER = '"+curUser+"' "+ "OR DB_USERNAME = '"+curUser+"' "+ "OR DB_ALIAS = '"+curUser+"' "+ ")" //run the query var foundMaintRecs = Filter(maintTab, maintSQL); var maintCount = Count(foundMaintRecs); //If user is in superuser table then continue and allow edit if (maintCount == 0) { return {"errorMessage":"Current user does not have maint privs on the table. \n "+curUser+" has no privs on "+loadTab+ "maintCount "+maintCount} } //If you get to here without a prior return then return true to allow editing return true ... View more

I have a bug in for performance degradation between Pro 2.9 and 3.x.  - BUG-000161441 Operations such as arcpy.Describe or arcpy.Exists are 25 times slower. I used these to test as they are very simple and discrete and widely used in scripts and likely in Pro itself.  ... View more

What would be useful is a tool to re-create the index on the globalid correctly for the state of the data. I find the preserveGlobalIDs setting to be key to certain operations like append but depending on the version of ArcGIS that you used when you created the GlobalID column the indexes may not qualify for this setting to work and may cause more problems. The article here describes the indexes for GlobalID on base, A, D, and archive tables depending if your data is versioned, archived etc. FAQ: How Have Unique Indexes on Geodatabase-Managed Global IDs Changed? (esri.com) We have thousands of datasets created over the years and the indexes are in all sorts of different states. Fixing these up based on the rules in the link is pretty much a nightmare.   ... View more

Same thing for me, using Pro 3.1.1. Delete a featureclass with 100 records takes over a minute. Rename also takes a long time.  I did some performance testing on some thing and found that  basic operations like arcpy.Exists or arcpy.Describe are 3 to 25 times slower than a similar machine when going against and enterprise GDB (Oracle in my case). Example results for arcpy.Describe were: Pro 2.9:   0.1seconds Pro3.1:  4.02 seconds I have submitted this to ESRI and it is logged as a bug BUG-000161441  I'm not sure if the cause is the same but it seems to be very widespread. If these basic tasks are so much slower I'm sure the cumulative effects are even worse. ... View more

So I am more confused than ever now. I created an aprx in 3.1.1 with a point layer and a stand-alone table. I added a relate in Pro between the two and published it both as a map service and as a feature service by reference to our portal. There were no warnings as I think there were with older versions of Pro.  In portal, using the Classic Map viewer I can do an identify a point and the "Show Related Records" link at the bottom will then open the related records quite nicely. If I use the new map viewer there is not "Show Related Records" link in the popup. Perhaps this will come with time. In short it appears that publishing a relate on a feature service now works better than before despite the article that says this functionality will be removed. ( 24040: In-memory relates are not supported—ArcGIS Pro | Documentation. It also does seem to work with a feature service but in my particular case I am not editing. Being able to edit associated records could be done via Survey123 if a custom app was built. I would really like to see this functionality remain and be added to the new map viewer.   PS: In my case both the point layer and table are in the same database. I'm not sure if this makes a difference.   ... View more

I would also like this too. Otherwise I will have to concatenate values in the table to make unique values. I tried adding another clause but the fields available are both from the same table. Specifically the fields are limted to the Action Data table. So it seems there is no supported way to link on multiple columns. ... View more

Allow for the display of related data in ArcGIS Enterprise Portal without using relationship classes I would like to second this idea. From our perspective, we have a large environment with over 900 datasets in our read-only geodatabase that are published as services to our Enterprise portal as referenced services. The data can be joined/related in a myriad of ways. We are trying to create viewing apps that have one to many relationships between things that will show in a popup window.  There is an ESRI post about this that says in memory relates are not supported for web feature layers. 24040: In-memory relates are not supported—ArcGIS Pro | Documentation The article suggests using database relationship classes to get this functionality but this recommendation is not practical. Relationship classes are made for editing data. They enforce behaviour such as setting parent field values to null when records are deleted. Relationship classes also add additional resource requirements to the database in terms of memory and dependencies. Adding relationship classes to a read-only database to meet all possible data relationships is really not practical. It would result in hundreds of relationship classes and would make the database unmanageable. Data and schema updates would be a nightmare.  I would imagine that this is likely why in-memory relates were created in the first place. They give the user the ability to relate two datasets for read-only purposes using tools such as Identify without having to make structural changes to the database. As we move our hundreds of users to Enterprise Portal with targeted apps we lack the ability to have a simple relate between two objects without having to modify the structure of our database. To me this seems like a huge lack in functionality as we move users to portal-based applications. There may be technical reasons as to why in-memory relates are not supported in feature services but as an alternative maybe functionality can be added to allow for relates or joins between services to be made at the portal level in an application or a map that would offer the same functionality for related records that has existed in ArcMap for over 20 years. Thanks. ... View more

Any luck on doing this? ... View more

Make sure that the account the job is running under has a named user account with AGOL or if it is a service account then configure your batch server as a Concurrent Use license. This will eliminate the licensing issues on the batch server. ... View more