Latest Contributions by RyanUthoff

Correct. I structured it exactly like it said and it doesn't detect the parquet files. However, if I add a subfolder containing shapefiles into the source folder, it picks up the shapefiles, but not the parquet files. If I use the actual Create Multifile Feature Connection tool, it says it succeeded with the shapefile, but it failed with the two parquet subfolders. Unfortunately, the tool provides no additional error messages or reasons on why it failed. This is literally all the information it gives me.   ... View more

Nope, I just gave up. I'm assuming it's either a bug or I'm misunderstanding how that functionality works considering how little documentation there is about it. 50/50 on which one it is.  ... View more

That is very interesting that that is a bug. Judging from the messages I received when I attempted the WebGISDR restore, I thought that was by design. I tried restoring the backup several times and it wasn't until I updated the DB credentials in the Portal Admin Directory and used those credentials as the ISA in the new Portal site did it work. This was awhile back and I don't have any of the logs from that anymore. The WebGISDR itself didn't give any useful information. However, I believe the Portal PostgreSQL logs (C:\arcgisportal\logs\database\pg_log) is what gave me the information to realize what was going on. Even though the username was the same, it was saying something about the password or something like that. And that's when I realized that maybe the PG password has to match too. So, I made the password match and that magically fixed it. I might try and see if I can replicate that again in my spare time and report back if I can. ... View more

And your last paragraph is definitely what messed me up. It's saying to use the same credentials (which I did, even though it wasn't the ISA, just the same credentials from the same admin account in both Portals). And considering any admin account can run the WebGISDR, I didn't think that the source and target MUST be the same ISA. I thought two admin accounts in both Portals was good enough, which is what the documentation leads me to believe. Now that I think of it, it might be fine to use any admin account to backup/restore on an existing installation of Portal (I'm not 100% sure on that), but the ISA definitely needs to be the same if you're restoring on a fresh installation of Portal. If that's the case, I feel like Esri's documentation needs to be clarified to reflect that. Last thing I want is an organization to lose their entire Enterprise because they don't know the credentials to the original ISA because the documentation leads users to think (imo) it can be any admin account.  ... View more

Darn, well I would have bet that would have been it. I'm not sure what would cause them to have to sign in if they're already signed in to begin with, especially if it only happens intermittently. It might be worth reaching out to Esri support.  ... View more

You have a couple considerations to think about. One is the SQL Server version compatibility, which you can find more details about here. There are only two versions that both ArcMap and 11.3 support at this point.  https://desktop.arcgis.com/en/system-requirements/latest/database-requirements-sqlserver.htm The other consideration is more directly related to your question, and that’s the EGDB compatibility with ArcMap. It works……but ONLY if you don’t use any of the functionality released in higher versions (like the new field types). But, the moment you enable that new functionality, it’s over. You’ll get an error message just trying to connect to the DB in ArcMap. So yes, it’s possible, but definitely tread carefully and be super super super sure you don’t accidentally enable any of the new functionality in your EGDB if you want to continue to access it in ArcMap. If you do proceed with the upgrade, my recommendation is to upgrade to ArcGIS Pro 3.3 first, create a copy of your EGDBs, then upgrade them to the latest version and verify you can still access them in ArcMap. You should be able to do all that without upgrading Enterprise. Then if everything works like normal, proceed with caution in upgrading your Enterprise and ensure you never enable any of the new EGDB functionality.    ... View more

The only thing I see is since you're searching for a text value, I believe you need to put the value you are searching for in single quotes, which would be %27 as the encoded value. Below is an example of what that would look like.   The other thing is that you might need to replace "dataSource_1" with the actual data source ID you're using. ... View more

Are you using ArcGIS Online or ArcGIS Enterprise? ... View more

You might want to check the Portal logs and see if it gives you any additional information. ... View more

If I understand correctly, you want to remove surveys from the inbox in your initial survey after you marked it as complete? If that's the case, I believe you can do that using the inbox query expression and just create an expression that says "complete='yes'" or something like that. You could include that field as a hidden field in your survey and just set the default value as "no." Then you can manually change it to "yes" later, which should remove the survey from your inbox. You can find more information about that in the "Enable the inbox" section here. Now it might get a little more complicated when relating your necropsy table back to your initial survey and marking surveys as complete that way. I had an idea.....but as I was typing it out, I realized it might not work. However, I'll go ahead and give you the documentation here. It shows you how to use a custom S123 URL to open a previously sent survey, which you could use to open your initial survey. However, it requires you to know the GlobalID of the record you want to edit, which you won't have in your necropsy survey. So it might not work, but just putting it out there in case it gives you any ideas. Others might have some better ideas, but that's the way I know of how to (sort of) accomplish it. ... View more

I think your solution is going to depend on how "sensitive" your data is. If you're going to make this layer "publicly" available, you need to be prepared for people to access the entire dataset. Yes, you can "hide" it by obscuration, but it doesn't eliminate the risk of someone being able to get their hands on it. For example, it only takes me about 60 seconds to open an EB app, open dev options in my browser to retrieve the internet traffic and see the rest endpoint of the feature service, then add it to ArcGIS Pro or another web map in AGOL and then I'm able to freely access the layer however I like within the capabilities of how the feature service was published. This potentially includes being able to change the symbology, visibility, etc. so I can see the entire layer. At the end of the day, the most important question that needs to be asked (imo) is how much risk are you and/or your organization willing to take with this "sensitive data"? Is security by obscuration good enough? Or is it vitally important no one have access to the entire dataset? If it's vitally important no one have access to the dataset, it shouldn't be publicly accessible to begin with. As another person commented, hosted service views are a good way to limit access to data, although I'm not sure how it could be applied to your scenario for when someone clicks on a specific location. I don't really have much more advice for your situation for AGOL. If you were using ArcGIS Enterprise, you might be able to create a custom SOI or EB widget to accomplish what you want (although that goes waaaay over my head). But with AGOL, you can't use custom widgets or SOIs, so your options might be limited. ... View more

I'm using the latest version of Connect and can replicate the same behavior in 11.2. I'm assuming this behavior is by design, although it doesn't quite make sense because the question type in S123 is the exact same and should honor the domain. One possible reason for this is because S123 has the functionality to "filter" the domain by using cascading choices. Hosted feature services in Portal don't have that functionality, therefore everything will be visible even if it's not a "possible" value based on the cascading choice. And maybe Esri is being overly cautious and just doesn't apply the domain at all? I'm not sure. Regardless, there is one workaround that I know of that you can implement. Manually add the domain to the hosted feature service in Portal. Unfortunately, it would mean maintaining a domain in two different places (S123 and the hosted feature service), but at least you would be able to have a domain in the hosted feature service to reduce human error.   ... View more

The instructions in the Select data section of your documentation (right above the Filter data sources section you referenced) explains how to retrieve the data source ID. "Each data source in an app has its own data source ID. When you select a data record, the data source's ID is added to the app's URL, along with the selection type and selection condition. " So you would replace "dataSource_1" with the data source ID using the workflow above. Regarding the field you're filtering on, below is an example from their documentation on what it would look like. So from your example, you would replace "name" with your field name. "The following is another example URL with two encoded filter parameters (objectid=1 and fieldA>2):" https://experience.arcgis.com/experience/<AppId>/?data_filter=ds1:objectid%3D1,ds2:fieldA%3E2   ... View more

Another thing to try is running the describedatastore command (Data Store Command Line). Just make sure the data store status is good and all the other parameters it outputs looks correct. And making sure it's in ReadWrite mode and not ReadOnly (although if you can create hosted feature services through zip files, that shouldn't be the case). ... View more