Latest Contributions by PaulKroseman

You can publish the NEAR tool as a GP Tool. Portal for ArcGIS has the Find Nearest tool available OOTB. The Near GP tool didn't work. It fails with schema is read-only error even when the near fields already exist. It also appears I would have to publish the GP tool once for each different input feature class. The Portal tool might work. I don't have Portal installed currently so I'm stuck with my current solution. without prepare the data (Quadtree ect.) with structure precalculated you could trivially increase the radius of the circle until it intersects at least one feature and then loop only on these. I do it for example with a soe. This is close to what I do currently. I start with a radius that is likely to return 1 feature, then double the radius until at least 1 feature is found, finally iterate the results to find the nearest. ... View more

I think what the stackexchange post is asking is to create the user as a local Windows user on the server where SQL resides. Add this user (servername\username) to the SQL instance security. Open the Credential Manager on the client computer and add a Windows Credential for the server username. I only use domain authentication and have no idea if what I said is correct. Having a domain makes this infinitely easier. ... View more

Timothy Pitts wrote: We use Active Directory to manage users, so it is definitely not preferred to try to manage user permissions at the database level since we'd need custom roles to do that. Currently, we have three roles: GIS Admin, GIS Editor, and GIS Viewer, with obvious database privileges attached at each level. That was my plan. Use AD groups for Admin, Editor, Viewer for users. Dataset permissions assigned to roles. Currently all edit roles are assigned to Editor group but I could create a group for each role if I want to restrict more. ... View more

Writing a procedure for editors to follow, rather than rigid permissions, sounds like the best option. I could create a public version that QA posts to then use a script to post that to DEFAULT. ... View more

I would guess all of your versions are set as Protected. I don't see a way to prevent posting to or editing a Public version. ... View more

1.  Editor - permission to Edit a Version, but not Reconcile/Post version to default.  Once Editors work is completed, notifies QA/QC person to review. 2.  QA/QC - permission to View the Editors Version, Reconcile, and Post to default, but not Edit the Version they are reviewing.  The QA/QC person evaluates the version, but is not permitted to edit it themselves (instead they notify Editor if changes are needed). Having the editor contact the reviewer could work. How do you prevent the editor from modifying DEFAULT and allow QA user to post to DEFAULT? QA user can't be a geodatabase admin. ... View more

I want to allow a QA/QC user to be able to post to DEFAULT but I don't them able to edit on DEFAULT. Seems like a contradiction in terms. Posting does edit sde.default. I don't want them to start an edit session or run a tool directly against DEFAULT. Posting is fine. They perform their own edits and push to DEFAULT, but don't need geodatabase admin priveleges.Check and see if sde.default is PUBLIC for them; my guess is it is. Yes it is public. We have only a few users with edit permissions, but will be getting more. Setting DEFAULT to Protected would require me to post all of their edits or give them sysadmin in the database. I only create datasets/feature classes for them. I guess you'll need to decide what your role in managing the database is.  As mentioned, I take control of sde.default.  If anything goes haywire on it, the buck stops with me.  When you have multiple people 'in charge' you stand to get a blame game of World Series proportions when things go south.  Not that it ever happens.... I manage the database, services, users, etc. But I would like to not be involved in the editing process for data I'm not responsible for. ... View more

I want to allow a QA/QC user to be able to post to DEFAULT but I don't them able to edit on DEFAULT. End users should be able to post to the QA version when they have finished an edit in their version, but should not have edit on the QA version. Maybe I'm thinking backwards. There is also another group that has their own data/version tree. They perform their own edits and push to DEFAULT, but don't need geodatabase admin priveleges. Setting DEFAULT to Protected would require me to post all of their edits or give them sysadmin in the database. I only create datasets/feature classes for them. ... View more