Latest Contributions by TanuHoque

@LindseyStone can you pls share the ticket number? ... View more

@LindseyStone  It should work. Only issue that I am aware was with legend not displaying and we fixed which should be part of 11.5. can you pls reach out to Esri support and open a ticket? we can take a look. In case you have something public, I can take a look at that too. ... View more

@mthompson there is nothing to apologize for 🙂 'Time in computer' is a confusing topic by itself. Can you publish feature services when editor tracking is in Database Time? I believe it used to throw an error and wouldn't let you. I just gave it a try and I don't see any analyzer error as long as you set the time zone on the Sharing pane during publishing time.   for the scenario you mentioned above, if you already have your feature class populated with data, then you should keep your editor tracking fields' time zone in UTC. If it is a brand new and empty feature class, you can choose either UTC or local/database time zone - depending on what works best for you.  For you other date/time fields, I'd suggest setting your layer's time zone (if you are in Pro 3.6 and Server 12.0) or service time zone (pre-3.6  or pre-Server 12.0) to EST. You should set the preferred time zone to EST as well. As you might have noticed in the newer releases client apps such as ArcGIS Pro or Map Viewer allows you to switch map's time zone to any time zone. I believe Map Viewer displays date/time values in the machine local time zone. Whereas Pro displays them in preferred time zone when set, otherwise in UTC; but starting at 3.6 you can change the map's time zone to any time zone even when preferred time zone is not set to the service.   If I set the service time zone to UTC and the preferred time zone to EST will the regular date/time fields and the editor tracking both display the correct time in EST in the services? that is correct, on the client side date/time values are always displayed in one time zone. If your map is in EST (in pre-3.6, ma, all data from any date/time fields (including editor tracking) will be displayed in EST.   Also I'd like to share this recording from an Esri event about 4 years ago. Obviously a lot of things changed/improved since then, but the basic concept remains the same for how date/time values from esriFieldTypeDate travels/stored etc. https://www.youtube.com/watch?v=esb8X-1TtPk   ... View more

@mthompson  That recommendation is mostly in the context of editor tracking and when data shared and distributed across multiple time zones. For the case, when data are all in the same time zone, you can use local/database time zone for the editor tracking workflow as noted in the help: Database time is based on the local time zone in which your database resides and should only be used when your data is confined to the same time zone.   Aside for the editor tracking workflow, for general usage of date/time values, we don't recommend any particular time zone over other. Whatever works best for your workflow. As long as you work within ArcGIS Pro with your local datasets (with all feature/records/data from the same time zone), you don't need to worry about the time zone. The moment you share your data as a service, we strongly recommend you to specify time zone to your layers before publishing/sharing to enterprise or ArcGIS Online.  That being said, in recent releases, we have introduced 3 new field/data types to store date & time. If you pick esriFieldTypeTimestampOffset, then you don't need to worry about time zone; that is because time-zone-offset are stored with data themselves. This allows you storing data from multiple time zones in a single layer/table. They other two types (esriFieldTypeDateOnly and esriFieldTypeTimeOnly) are NOT time zone aware. Values from these two field types are passed around as-is even when they are shared as services and consumed in web clients. I hope you find this helpful. ... View more

@HarryPlendl  Thanks for sharing the detail error messages, and the solution. It is odd that the upgrade process failed to update the definition of the out-of-the-box print service. ... View more

Thanks @DavidOGrady. Can you pls the bug id here?  ... View more

thanks @JohnFannon  That is interesting. Print service should take about the same time that Pro takes to do the same task on same setup. At this point, it is better if possible for you, to reach out to Esri Support if the issue continue to persist. Regards ... View more

@MattieWiseman  I'm not if I should be happy, sad or scared 🤦🏽‍:male_sign: The code was supposed to save it as an aprx file and not do anything to resolve your issue. Good to know that it is working for you for now. Because you have an issue open with the support, I'd say please let the analyst know about this; and we will look into this. Thank you! ... View more

hi @DavidOGrady  Would you mind reach out to Esri Support and have an issue logged? We need your exact (or sample) data and exact steps to look into this issue. Thank you for reaching out. ... View more

@JohnFannon  If you haven't already, could try exporting reports (using data from your services, NOT LOCAL datasets) from Pro and see how long it takes? Print service usually takes about the same time as Pro. ... View more

@MattieWiseman  here is what I'd do: find the line in your py code that calls convertWebMapToArcGISProject() function note the name of the variable that will hold a reference to the result of the function call; Let's say the variable is named result. I think after this line, there are bunch of function calls we have that updates dynamic text element's once all these works are done, get hold of the in-memory ArcGIS Pro project reference and save it as a file by calling result.ArcGISProject.saveACopy(<file-path>). once the task it complete, open the aprx in Pro and take a look at the layers and dynamic text elements on the layout. This usually gives a good clue about what could go wrong. Hope this helps. ... View more

@MattieWiseman  Unfortunately I don't think I can be much of help without knowing all the details. I'd recommend you to reach out to support. Also, if it is possible for you, then I'd recommend you to upgrade to 11.5 - where dynamic text elements are supported out of the box. Because you are using ExB app, you should be able to make use of this capability without any customization. ... View more

The error basically means the database was asked to perform some unsupported task i.e. return unique/distinct geometries from a table. I'm glad you reached out to the support. Hopefully we will have some resolution soon. ... View more

Thanks@MatthewStull1 for adding your note here. You are right, this is fixed for both map service and feature service in 11.3. Once you have both sides of a relates in your map in Pro, if you open the layer/table's Properties page and go to Relates tab, you will see an option to provide user defined ids for relationships.   Note: please note that we have an issue -- if you already have 'allow assignment of unique ids...' option checked at the map level, and you added the layers/tables; you might not see this option; You need to reset (or toggle it if you wanted to preserve your already assigned layer ids) that at the map level to see this text box to enter your desired id. We apologies for this issue; we are hoping to fix this issue in a future release. Thank you! ... View more