Is anyone using Windows Authentication with versioning? The problem I am having with it is that I cannot find a way to create the new versions nightly during my compress process. The best option I have come up with so far is to use an ArcObjects script that creates the version for each user when they log in by adding it to their Active Directory login script. I would appreciate any other ideas that may be out there that would allow me to keep the fully automated versioning process but with the advantages of Windows Authenticated users.
What issues are you facing while creating the versions using Windows Authenticated logins? Any errors?
Are you facing this issue only after upgrading to ArcGIS 10.3?
I can create versions with no problems. The problem is that each user has to manually create their version every day. Currently I use database authentication and I have connections for each user that allows me to re-create the versions after I perform the reconcile-post and delete and then the compress process. I am looking for a way to create user's versions with an automated script during the daily compress process so that everyone has fresh versions to start with in the morning. I have never been able to find a way to do this regardless of the version of ArcGIS and therefore have continued to use database authentication but due to turnover rates and permissions management of a growing department having the ability to manage users with Windows would be very useful.
Why don't you try with a storage procedure in sql. Look in ArcGIS Help 10.1
EXEC sde.create_version 'sde.DEFAULT', 'myedits12111', 1, 2, 'version for my mv edits';Does this allow me to set the owner of the version to the applicable user? I already have a table with all users in it that I use to run my python script so the stored procedure would be a great option but looking in the documentation I do not see a way to modify the owner of the version. It appears that the version is created with the user that runs the procedure as the owner.
- 1 person found this helpful
After looking and thinking about this I ran a quick test and was able to create a version and then perform an update statement that changed the owner in the SDE_versions table that then allowed a specific user to access their private version. Are there any potential problems with this procedure?
- 1 person found this helpful
var mv_version = < User.versión_name>;
sde.version_user_ddl.create_version
('sde.DEFAULT',
mv_version,
sde.version_util.c_take_name_as_given,
sde.version_util.c_version_private,
'Multiversion'
);
- 2 people found this helpful
Based on the advice from Teresa Villena I was able to find a way to solve this issue. Here is the T-SQL code I am using to create each version in case it will help someone else. This creates a private version.
exec sde.create_version 'sde.Default', '{VersionName}', 2, 0 , 'Owners Version';
update data.sde.SDE_versions
set owner = '"{Domain}\{User}"'
where name = '{VersionName}'
The rest of the versioning process must still be done in python to Reconcile, Post and Delete versions followed by killing connections and compressing the states. Does anyone know of a way to compress the states other than a custom script that moves the edits from the delta tables to the base tables?
Based on the advice from Teresa Villena I was able to find a way to solve this issue. Here is the T-SQL code I am using to create each version in case it will help someone else. This creates a private version.
exec sde.create_version 'sde.Default', '{VersionName}', 2, 0 , 'Owners Version';
update data.sde.SDE_versions
set owner = '"{Domain}\{User}"'
where name = '{VersionName}'
The rest of the versioning process must still be done in python to Reconcile, Post and Delete versions followed by killing connections and compressing the states. Does anyone know of a way to compress the states other than a custom script that moves the edits from the delta tables to the base tables?