Latest Contributions by MKF62

2022 and still no way to do this?? ... View more

Yes - here are the setting in IIS, both the Portal and Server web adaptor have these settings:   On Portal these are the login settings I could find. My users use ArcGIS Built-In accounts, they do not login to the Portal with Windows credentials:     ... View more

All of our fieldworkers are just using their fingers on mobile phones (iphone and android) since all they do is drop points. ... View more

Okay, well, I tried connecting as a user and a publisher and it still doesn't work, so there's obviously still something weird going on. ... View more

Ugh. Out all the concepts involved with ArcGIS, this is the one that has always confused me the most and I never seem to gain any clarity on it. To me, it seems like there's only one difference between DBO and SDE users. DBO controls everything while SDE only control the ArcSDE things. Beyond that, I don't see how SDE is any more organized than using DBO. In my diagrams above, the prefixes to the tables created with the DBO user are all different. I think you're telling me that that's what the SDE tables should look like also? I thought the point of the SDE user was to only have one user that's responsible for creating and maintaining feature classes/tables instead of 2+. You'd then have other logins loading actual data into those feature classes/tables, but not creating the actual fcs or tables.  So, let me use a real example and then maybe you can tell me how it would differ if we had used an SDE user instead of DBO user. Our current set up is using the DBO schema, our collection of tables looks like this in SQL Server: Now, we have a login/user on that database called FocalAreasWriter. It's default schema is FocalAreasWriter. Logged in as that user, if I wanted to create a new table called "Quail", it would show up in that database as FocalAreasWriter.Quail. So, reasonably speaking, you could have FocalAreasWriter or any other number of users recreate the pictured tables above in their own schema name (e.g. Surveyor.CoveyObservation).   Now switch to an SDE schema set up, I guess all the special spatial tables (circled in red) would turn to 'sde' prefixes?  And the rest of the tables you'd want to create with different, more descriptive user/schemas, ending in something like these names: Surveyor.CoveyObservation Manager.FA_RA_CENTROIDS Analysis.FAManagedDensity Manager.FAUser Manager.FOCALREFERENCEAREAS Surveyor.FocalSpecies   I guess I'm not getting how that differs from dbo. You could make it just as organized in a dbo schema if you wanted to. How does the SDE schema help you organize? Or is the SDE schema really only about locking down your db further by: 1) Keeping the geodatabase admin (sde) from going outside their realm and messing with stuff in the overall database instance 2) Giving the geodatabase admin (sde) the same power as a database admin over granting permissions to various users working with spatial data   Appreciate your insight and patience.    ... View more

Tell me about it. I am terrified to be doing this!!  I am happy to say I do know what an "order by" clause is at least; I saw the word "schema" and my brain latched on to that, making me think about reorganization of the table structure instead of application to rows. It's rather late at night here, I think I need to go to bed, haha. Thanks for the explanation on the spatial fragmentation; I always thought drawing order was somewhat arbitrary. If it's the case that they can be organized at something like a state level, where you order all the rows by state, moving from left to right and top to bottom (e.g. start the table with features in Washington, end with features in Florida), I could easily rewrite the feature classes with python (more my speed 😅) to be in such an order. Then I assume a newly calculated spatial index would be more efficient, as you've described? Anyway, thanks for the guidance! Our datasets are fairly small so I think for now, I better stick to having this all culminate in a functional implementation vs an optimized one, given my inexperience and short timeframe to figure it all out. Just trying to understand all you are describing for my own edification 🙂 ... View more

I apologize in advance for what are probably dumb questions/interpretations, but I am not a DBA of any sort and (extremely unfortunately) am wildly out of my realm of expertise on this project. I'm the only person they have that has any resemblance of database knowledge, thus I've been tasked with this migration project (hurray...). So, all that said, I would still like to try to understand what you're describing if you don't mind explaining further. I'm going to start at the "ORDER BY" part of your post first; are you saying that you're reordering/restructuring the fields of your feature class before you export to the FGDB for optimization purposes? Then, if you back up to the first part of your post about the spatial index optimization, it sounds like you use the SQL you have to recreate an empty table in the PG database, but you're reordering fields(?) again to create a more efficient spatial index (and potentially match the adjustments made when you exported data to your FGDB). After doing that, you register the table with the geodatabase and load your data into the empty table from the now-optimized data you exported to the FGDB. Am I way off (I am assuming I am)? ... View more

Good call. Thanks for the tip about the CSVs too.  ... View more

Thanks - I forgot to put the most important part of this all in my post (will edit), but I will not have access to our old server during migration. Unfortunately, all I'll have to work with is the backups I take with me (.bak files from MSSQL and the stuff I'm porting to fgdb/csv). I guess maybe once I mint the new PostgreSQL database as a enterprise geodatabase, then I just copy/paste layers over from my FGDB. That might be the only way to do it, I guess. ... View more