Latest Contributions by RyanUthoff

‎12-13-2023

I'm just curious, where is ArcGIS Pro lacking for you?

‎12-13-2023

ArcMap has already essentially been deprecated, currently in "Extended" support. According to the life cycle page, new environment certifications ended in February 2022. I'm not sure if new environment certifications extends to SQL Server compatibility, but I would not expect Esri to make ArcMap compatible with a newer version of SQL Server. It's possible ArcMap will "unofficially" support 2022 (in the sense that it might "work"), but it won't be officially supported. https://support.esri.com/en-us/products/arcmap/life-cycle#:~:text=IMPORTANT%20NOTE%3A%20ArcGIS%2010.8.,supported%20until%20March%2001%2C%202026.

‎12-13-2023

We've used floating licenses in the past so I can provide a little insight. The biggest hurdle you will have to jump through is that only one person will be able to use the floating license at a time. That might not be a problem for your company, but any other people who need to use the floating license will have to wait until the first person is done with the license and released it back. You'll also need to make sure those who use floating licenses don't unnecessarily occupy the license, such as accidentally leaving Pro open all day, etc. Other than that, we haven't had any issues with using floating licenses.

‎12-12-2023

There are a couple other things to look into. The first is Experience Builder. Starting in 11.2, Experience Builder supports related tables (even though the map viewer doesn't which doesn't really make sense). So Experience Builder in AGOL might support it too. It's certainly not ideal to take it to another level and create Experience Builder maps when it's not necessary, but it might be a possibility and a workaround. The other thing to look into is using Arcade to display related records. https://www.esri.com/arcgis-blog/products/arcgis-online/mapping/visualizing-data-from-related-records-using-arcade/ I feel like we shouldn't have to go to these great lengths just to get related table access in the New Map Viewer, but those are the only workarounds I know of right off that might work.

‎12-12-2023

Which map viewer are you referring to? The Classic Map Viewer or the New Map Viewer? The Classic Map Viewer still supports related tables, even though they broke critical functionality of it at 10.9.1 (BUG-000152181). First reported over a year ago and still no fix by Esri..... 😞 The New Map Viewer (in Enterprise) does not support related tables yet (which I'm not sure why its missing such basic functionality). The New Map Viewer in AGOL does support related records. So to answer your question, the only workaround is to just not use the New Map Viewer. And then when Esri breaks functionality of the Classic Map Viewer with no bug fix, we just workaround that by changing the data types in our relationship class. We would love to move to the New Map Viewer as well, but without feature parity with the Classic Map Viewer, it's just a non-starter for us.

‎12-12-2023

Thank you for your comment. To my understanding, in order for Pro to not make that field high precision, it MUST be a query layer first, then you will select that table/view from the table of contents within the register GP tool. I am able to reproduce your issue using your workflow. However, it works fine if I create a query layer first and use the query layer in the GP tool and NOT the table/view directly from the SDE connection. In this case, I think it's technically not a bug, but certainly not a good implementation of this new field type. Unfortunately, this design choice has negative implications for us because that means all of our Python scripts that register tables/views has to be reworked to create query layers for everything first......

‎12-12-2023

Yep, we've encountered this as well. Unfortunately, the way these new field types were implemented in 3.2 was a poor design choice and has caused us lots of issues. We have to completely rework our Python scripts to make query layers out of all of our tables/views before registering them, because that's the only way the register with geodatabase tool will honor the new "compatibility mode." See this thread. https://community.esri.com/t5/geodatabase-questions/high-precision-date-field-issue-when-registering/m-p/1359739#M8723

‎12-12-2023

I have not submitted a support ticket yet because I have not been able to reliably reproduce this issue. More often then not, Esri will not make the field high precision. But every once in awhile, it does and that makes it hard to present to Esri as a bug if I can't reliably reproduce it to them. But thank you for posting your issue. I am able to reproduce it specifically with the views like you mentioned. I was previously only testing it with tables which make it hard to reproduce. But I have a question. In the register tool, are you selecting the view directly from your DB connection? Or are you making a query layer first and then selecting the view from the table of contents in the register tool. I CAN reproduce your issue when I am selecting the view directly from the DB. But I can NOT reproduce the issue if I make a query layer first. And that is what Annie said above in a reply to my post. With what I posted above in this comment, it is technically not a bug because it appears to be working by design, but goodness this is a terrible implementation design choice. Having to rework all of our python scripts to make query layers out of all of the views we need to register in order for Esri to not make a field not high precision is just insane and unnecessary.

‎12-11-2023

Yeah, that's what I meant when I said when doing a field calculate.

‎12-11-2023

Removing values from a domain won't modify your data. However, there are two things to consider. 1. You won't be able re-select them again if you ever needed to use their name (at least not with doing a field calculate within Pro). 2. If your Code is different from the Description in your domain (ex: a code of 5 = John Smith), then it will only display the code once you remove the domain (ex: it will only show the code of 5 as the value instead of the person's name). Otherwise, it's safe to remove domains. It won't modify the data itself.

‎12-08-2023

Glad this discussion was helpful for you! You are right that organizations should consider the costs of hosting a desktop solution in the cloud. I'm not sure about MS Azure, but there are a couple options for AWS. One is the AWS Workspace, which is essentially just a virtual PC (make sure it is hosted in the same region as your DBs, otherwise it will be slow (I know from experience)). However, depending on your organizational needs, you could also use a Windows Server EC2 instance (or Azure equivalent) and have your users connect to it instead of providing them with a dedicated workspace. The machine would be shared, but each person would have their own user account to log into it. You might need to pay for more "seats" (how many people that can concurrently RDP into the EC2 instance), but otherwise you just have to pay for the EC2 instance. It could be a more cost effective solution for people who only use Esri periodically instead of providing them with a dedicated workspace.

‎12-08-2023

Does the username have to come from the map? Or can it come from the username of the Survey123 form? If it can come from the form, then you can just add a row to the form with a "username" field type.

‎12-08-2023

Thank you for your reply. After thorough testing of more than 20 DBs, using the Register with Geodatabase GP tool does NOT always register tables as high precision. It is random. Furthermore, per the Esri documentation you provided, it says "these fields may be assigned to the new field types." It does not say that it definitively will get assigned, but that it may be assigned. I find that incredibly frustrating because the documentation itself is stating that it might make a field high precision when registering a table for literally the exact same field type. While I appreciate that Esri does have an option to opt-out of these new field types, I find it frustrating that this documentation is hidden away in some other random documentation and not included in the documentation that actually talks about these new field types. But more importantly, it's frustrating that Pro is not being consistent when registering these tables which could cause a critical failure for us (that we have already encountered), such as not being able to publish feature services on versions prior to 11.2, without an advanced "unsupported" fix or just scrapping the table/DB and trying to register again hoping it doesn't create it as high precision.

‎12-07-2023

Just to update anyone who might come across this issue. I have found a way where you can "un-migrate" or "downgrade" back to a "low precision" date field. In SSMS, navigate to the GDB_ITEMS table. Query it and find the table you need to remove "high precision" from. There is a Definition column in that table that stores the XML of the table. That is where it contains "high precision" information. You can use the following query to remove "high precision": UPDATE [dbo].[GDB_ITEMS] SET Definition.modify('delete (/DETableInfo/GPFieldInfoExs/GPFieldInfoEx/HighPrecision)') WHERE ObjectID = (your table ObjectID) Note that you might need to modify the query if your table has multiple date fields with "high precision." I'm sure this is definitely not the recommended way of doing this, but we don't have much other choice when ArcGIS Pro randomly assigns date fields as "high precision" when registering tables with the geodatabase.

‎12-06-2023

I've encountered an issue with registering tables now that the new "high precision" datetime field is available in 3.2/11.2, where when testing an identical, empty table and field, occasionally ArcGIS Pro registers it as a regular "low precision" datetime field, and the rest of the time Pro considers it a "high precision" datetime field. This is using MS SQL Server (DATETIME type, not DATETIME2(7)). We do not currently wish to employ the "high precision" datetime type. When creating a table within ArcGIS Pro 3.2, we can create a datetime field and then migrate that field to high precision using the Esri tool afterwards. That's not an issue. However, when we register pre-existing tables created through SSMS using the Register with Geodatabase tool, we encounter some weird behavior. We have done several tests with multiple databases and tables, and sometimes Pro registers the table as a regular datetime field, and sometimes it registers it was a "high precision" datetime field. We performed these tests on the exact same tables in multiple databases, and it is using the regular datetime field type in SQL Server. And sometimes Pro registers it as "high precision", and other times it does not. This is very problematic for us because there is no way (to my knowledge) to "downgrade" to a non-precision datetime field in Esri, and it is only compatible with ArcGIS Enterprise 11.2, meaning we can't publish feature services containing "high precision" datetime fields to lower Enterprise versions. Is there anyway we can "force" ArcGIS Pro to recognize a field as non-high precision when registering a table with the geodatabase? Or is this a bug or something, because we need Pro to be consistent when registering tables with the geodatabase and not just randomly picking and choosing to use "high precision" or not.

Online Status	Online
Date Last Visited	3 hours ago

My Ideas

Latest Contributions by RyanUthoff

Re: Will ArcMap 10.8.2 Support SQL Server 2022?

Re: Will ArcMap 10.8.2 Support SQL Server 2022?

Re: Spatial Analyst Floater Experience?

Re: How have Orgs worked around related tables and Map Viewer and using Enterprise 10.x?

Re: How have Orgs worked around related tables and Map Viewer and using Enterprise 10.x?

Re: High Precision Date Field Issue when Registering Tables

Re: Forced upgrade to ArcGIS Enterprise 11.2?

Re: High Precision Date Field Issue when Registering Tables

Re: Values removed from domain remain in attribute table for historical records?

Re: Values removed from domain remain in attribute table for historical records?

Re: "Lift and Shift" AWS Migration Strategy Question

Re: Pass Username and Date to Survey123 Form

Re: High Precision Date Field Issue when Registering Tables

Re: High Precision Date Field Issue when Registering Tables

High Precision Date Field Issue when Registering Tables

Re: Best Practice to see video data via Online

Re: Best Practice to see video data via Online

Re: SAML Authentication for Third Party

Re: SAML Authentication for Third Party

Re: SAML Authentication for Third Party