Latest Contributions by RyanUthoff

‎07-10-2025

I know I commonly have issues like these with SQL EGDB's and not hosted, but maybe other people are actively using that hosted feature service and therefore, Esri can't get a lock? That's my best guess. One thing that you could try is to un-share the hosted feature service with everyone to ensure that no one is actively using it, then try and add the new field. And worst case scenario, possibly restart the ArcGIS Data Store to clear out any orphaned locks or anything like that that could be causing issues.

‎07-08-2025

Ohhh, I see what you're saying. That's not an issue I can replicate in ArcGIS Pro 3.5. The icon sizes are all the same for me. RyanUthoff_0-1751986531327.png

‎07-08-2025

In my testing of this just now, the width of the icon in the task bar is dependent on how long the name of the application is (in your case, "Testing") until it reaches the maximum width. For example, I named my ArcGIS Pro "Testing" and it made the width long enough to display the text "Testing." Then I named another ArcGIS Pro "This is a long name test." You can see from my screenshot that the width of the icon is dynamic based on how long the name of the application is. It also takes into account how much remaining room you have left on your taskbar. So if you already have a lot of other applications opened on your taskbar, then the width might be smaller than if only ArcGIS Pro was opened. RyanUthoff_0-1751984803250.png

‎07-07-2025

I'm not going to say it's not possible or that it won't work, but running some components on-premise and some on the cloud could very much potentially cause you to have severe performance issues with your services. I imagine the latency will be very noticeable. All ArcGIS Enterprise components need to be in the same physical location. Either in the same physical location on-premise, or in the same region/availability zone in the cloud.

‎07-02-2025

Some people have reported that clearing their browser cache and cookies fixes this issue. So that might be something to try. Could be related to this bug too: https://support.esri.com/en-us/bug/the-arcgis-server-default-print-service-returns-the-err-bug-000135413

‎07-02-2025

What exactly is the problem? I created a quick survey with your if statement and it calculated correctly, as long as the text value of your questions match the if statement, then it correctly calculated the user_type_result for me.

‎07-01-2025

Currently, attribute rule constraints that are configured against an EGDB in ArcGIS Pro do not display the error message (if it hits a constraint) in the Portal map viewer. It just displays a generic error message as shown below. While the constraint error message can be found in the ArcGIS Server Manager logs, that just adds overhead to people's workflows by having to open a new tab and querying the server logs to figure out what the constraint error is. And that's assuming they have the knowledge to access Server Manager to begin with (basic users shouldn't even need to use Server Manager at all). When this happens, the end user ends up having to contact an administrator to figure out the issue, which is unnecessarily occupying multiple people's time when the constraint error could just be displayed in the Portal map viewer to begin with. When end users encounter this message, there is no way for them to understand if this is an attribute constraint rule, or if it is a bigger error/problem that needs to be troubleshooted. This turns what should be a simple attribute constraint rule into a time sink that occupies multiple people's time. Attribute constraint rules are pretty powerful, but they don't really do us a lot of good when an end user hits a constraint and they just receive a generic error message that requires further troubleshooting. My idea is that the Portal map viewer actually display the error message configured with the constraint rule in ArcGIS Pro so end users can quickly understand the issue when they encounter a constraint. RyanUthoff_0-1751434672848.png

‎07-01-2025

I tested this in both Pro and Portal using both the classic and new map viewer, plus WAB. Unfortunately, Portal gives a generic error message as opposed to the error message you specify when configuring the constraint, but it still blocks me from uploading any non-jpeg files. And if I remove the constraint, it uploads just fine. Edit: We're using Enterprise 11.2, while it looks like you're using 10.8.1. I'm not sure if that would impact it or not, but according to the constraint settings in Pro when I configured it, it says the minimum version of Enterprise is 10.6, so I would think it would work in 10.8.1. RyanUthoff_0-1751432752425.png RyanUthoff_1-1751433339196.png

‎07-01-2025

I don't think what you are wanting exists. You're not able to customize Portal's banner to add your own URLs. Since you are using or linking to Portal's built-in web map viewer from your own site, you are essentially entering Portal's "ecosystem" and are therefore limited to what you can do that's not already built-in (such as doing anything outside of Portal's "ecosystem"). Since you're trying to do something outside of Portal's "ecosystem", you will most likely need to develop your own web map viewer that you can integrate into your site that can be fully customized to meet your needs. This way, your users would never even need to enter Portal's site to begin with. They would always stay on your site and you wouldn't have to worry about them finding their way back to Portal's site.

‎06-30-2025

It is recommended by Esri here that your EGDB and your ArcGIS clients (Pro, Server, etc.) all be at the same version. With that being said, it isn't a requirement. However, if you're going to mix and match versions, I'd recommend your EGDB be at the lowest version of the various software you're running. So in your case, it would be a 11.4 EGDB since you're running Enterprise 11.4 (even though you're running Pro 3.5). That will ensure that your EGDB is fully supported by all your ArcGIS clients. Generally, I believe an 11.5 EGDB will work with Enterprise 11.5, but any new EGDB functionality released in 11.5 might not be compatible with Enterprise 11.4. But like I said, it's recommended that you keep your EGDB and all ArcGIS clients at the same version.

‎06-30-2025

DynamicMappingHost is referring to services published using the shared instance type. This documentation provides some more information about it. Now regarding your error message, it appears that one of your services is struggling. If it's a heavily used service, it might be better off as a dedicated instance. If not, then there might be some performance issues with it that you will need to resolve. If you're not sure right off which service is causing issues, what you might be able to do is look at the raw log file (the text log file on your server machine) and find that error message. Then, take the RequestID of that error and do a search for it in the entire log file and you might be able to find that original request (along with the actual service name).

‎06-26-2025

Yep, it's a known issue that Esri is investigating. https://status.arcgis.com/

‎06-25-2025

Upgrading to 11.3 is the highest version of ArcGIS Enterprise you will be able to upgrade straight from 10.7.1. What version you upgrade to is going to mainly depend on your organizational requirements. However, I'd recommend upgrading to 11.3 since you'll get an extra year of support as opposed to 11.1. If you do not have any specific reason to upgrade to 11.1, then I'd recommend going straight to 11.3.

‎06-24-2025

I was curious on trying this and I can confirm that the file size restriction works. However, the video is very misleading. It's misleading because: The example code used in the video uses the Shape_Length column of the spatial table which makes no sense. It needs to be using the DATA_SIZE column of the attachment table. The attribute rule needs to be a constraint and not a calculation. While the subtitles of the video state this, the video itself does not click the constraint tab. It shows them creating an attribute rule under the calculation tab. RyanUthoff_0-1750827356854.png Otherwise, I was able to get the restriction based on file size to work. Yes, you can also restrict based on file type just like you do for file size. if ($feature.CONTENT_TYPE == 'image/jpeg') return true; return false; You can either make separate attribute rules for file size and file type, or you can combine it into a single rule like below. return $feature.DATA_SIZE <= 5 && $feature.CONTENT_TYPE == 'image/jpeg';

‎06-23-2025

Yep, the Copy tool is just a tool in ArcGIS Pro. I don't believe FME will be able to preserve the ObjectIDs, at least not in the ObjectID column when you write it to a FGDB. The ObjectID column is still managed by Esri in that case, and not FME. And FME typically can't override Esri. I think the only way to preserve the ObjectID in the actual ObjectID column is to do it completely through Esri using the Copy tool.

Online Status	Offline
Date Last Visited	a week ago

My Ideas

Latest Contributions by RyanUthoff

Re: esriExclusiveSchemaLock Error on Hosted Featre Layer

Re: Icon size in taskbar

Re: Icon size in taskbar

Re: ArcGIS Enterprise Deployment and Server Configurations

Re: Default Print Service not working in Portal for ArcGIS 11.3

Re: If Statement for text type question not working

Portal Map Viewer Should Display Attribute Constraint Rule Error Message Configured from ArcGIS Pro

Re: Limiting the File Size or Type of Attachments

Re: How to return to the Site from the Portal

Re: Upgrading Enterprise Geodatabase

Re: Dynamic Mapping System Configuration (ArcGIS Enterprise 11.4)

Re: ArcGIS Online June 2025 Update Gateway Timeout when trying to login

Re: Looking for recommendations for ArcGIS Server Upgrade Path

Re: Limiting the File Size or Type of Attachments

Re: ArcGIS Online: Cannot set custom ObjectID values when inserting via FME

Re: Order of Operations for Enterprise Upgrade

Re: No "Copy sent data to a new survey" option in ...

Re: ArcGIS Data Store upgrade 11.5 to 12.1 fails

Re: Limit the size of the ArcGIS Data Store

Re: Why Still Require a Security Question After In...