Latest Contributions by collindegueurce

‎09-04-2015

SQL Server. Same instance. Thanks for the link!

‎09-03-2015

We currently use SDE with versioned editing. Our installation was done several years ago. I know that there have been many changes and performance enhancements since that time and some of the suggested installation parameters may have changed. I am thinking of creating a new geodatabase and transferring our existing data to it. My question is, is there a way to migrate users without having to manually create new connections, repair map data sources, etc.?

‎09-03-2015

I thought maybe the status 33554433 denoted a public version that was in the process of editing, but further testing negates that theory. Sure would be nice to get an answer to this question. Just out of curiosity.

‎09-02-2015

There is much discussion about compression and I am hoping someone can clear up an issue I am having. We are using versioned editing. Each user has a version that they have created under their own connections. We were having an issue with compression ending states being high - around 40. Many of the versions were old and some were stale. So I rec/posted and deleted the versions. end state was 1. Then I asked everyone to create a new version for themselves. The problem with this is that not everyone used the same name in creating their new version so many of the datasources in their maps became broken. It was a hassle, but the performance gains of the near-full compression were notable and worth the trouble. However, now that users have recreated their versions my state count is going up again after compression. Even if I reconcile the versions first, I can't get below 10 ending states - we have 10 versions. I would like to script the deletion and recreation of the versions as part of an automated workflow, but since the users own their versions, I would have to have a connection as each user to be able to do that. Is that correct? I have the same issue with rebuilding indexes and analyzing datasets...I need to do it under the data owner connection - is that correct? Should I just force all versions to be owned by DBO? Am I missing something that will allow me to achieve what I want without users having to constantly recreate their own versions? Is it normal that each version will account for at least 1 end state after compression even if it is first reconciled?

Re: Keeping track of user licenses · ‎08-12-2015

Thank you Sent from my iPhone

Keeping track of user licenses · ‎08-12-2015

As part of new job function I am tasked with keeping track of user licenses across several departments. At the beginning of each year each department receives a breakdown of their license usage and an internal bill to their department. In the past we have maintained a spreadsheet to try to track the license type of each user in each department but this is cumbersome. Is anyone else having success at keeping track of user licenses or are there any tools that might make this easier that you know of?

‎07-14-2015

I stand corrected. The update cursor did in fact work. Thank you guys!

‎07-14-2015

I'll run it...give me one minute...

‎07-14-2015

The numbering doesn't really have to start from 101, it's just been requested. I'm more concerned with why it happens on just some feature classes. The fact that it is versioned hasn't caused it to skip any yet when doing the field calculator. so far they are all sequential (even if they don't start from 101 as I want). I have run into the versioning skip issue with some insert triggers, but not here. It's not really a mission critical issue, I just want to understand why it's happening. I appreciate your reply!

‎07-14-2015

Versioned SDE Geodatabase 10.2.2 / ArcMap 10.2.2 / Python27 I have a text field called FEATURE_UNIQUE_ID that consists of a 4 letter asset code and an increment number. I have added this field to several existing feature classes. To populate the field initially, I have a simple python script that I run in the field calculator (python codeblock) that assigns the value sequentially to the field. For example: WWTK101, WWTK102, Etc. For the most part it works great. However, on some feature classes the number assignments start at an arbitrary value greater than that of the starting value assigned by the script. I cannot figure out why? I have tried editing as the data owner as well as geodatabase administrator. I have tried initializing rec to 100, to force the script to start at the value of 101. I have tried editing from the default version as well as running the script both before and after compressing / rebuilding indexes on those feature classes. I really need to figure out what is causing this issue, or I'm going to have to reorder these by hand -> not fun. You will see in the screenshot below that in this particular feature class the numbering starts at 281 even though the OBJECTID starts at 1. The values are sequential, as in there are no values less than 281 in the column. they go from 281 up. Any help is appreciated. please see below for screenshots and script code. Thanks. This code goes in the codeblock: rec=0 strRec = "" def autos(): global rec, strRec pStart = 101 pInterval = 1 if (rec == 0): rec = pStart else: rec += pInterval strRec = "DRCB" + str(rec) return strRec and the function autos() is called underneath. 90% of the feature classes I have used this on start numbering from 101 without issue.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:24 AM

My Ideas

Latest Contributions by collindegueurce

Re: Migrating to a new geodatabase

Migrating to a new geodatabase

Re: Arcsde 10 - versions table, status 33554433

SDE Compression and named versions

Re: Keeping track of user licenses

Keeping track of user licenses

Re: Field calculator python script and OBJECTID ordering issue

Re: Field calculator python script and OBJECTID ordering issue

Re: Field calculator python script and OBJECTID ordering issue

Field calculator python script and OBJECTID ordering issue