POST
|
It is typically not recommended to manually edit the geodatabase items through the backend because it can lead to unexpected behaviors. In this circumstance restoring a database backup is likely the safest solution. If you restore the database to the condition prior to unregistering as versioned, do you see the Definition field populated? It may be a good idea to do a clean export and re-import of the data from that backup. When you export the feature class to a file geodatabase and re-import it, it will not be registered as versioned. However, it would be worth going through the workflow of registering and unregistering as versioned to see if the issue persists.
... View more
06-29-2020
09:34 AM
|
0
|
0
|
36
|
POST
|
In that case, I would avoid saving passwords on the admin connections when you create them, which is typically a good habit to practice in general if you can. Here is some other good doc as well: User accounts and groups—Help | Documentation
... View more
03-11-2020
09:56 AM
|
0
|
1
|
88
|
POST
|
Hi Neel, If you have a headless account (db authentication) creating/owning the data, managing domains, etc. you will not have to worry about future user changes to the environment (e.g. user turnover, new users, etc.). A headless user can be easily managed by a single user, or multiple, and you can change the password as you wish if necessary. If the geodatabase system tables are owned by sde, then that sde user mapped to the geodatabase is your geodatabase administrator, no need for a new user called "sde_admin". OS authenticated users are certainly helpful for efficiently tracking edits, versioning, etc. in the geodatabase. So if you would like to use OS authenticated users, then it sounds like a possible configuration could be having a db authenticated user create the data and domains, then map OS authenticated users to the database and grant necessary privileges on the datasets that they will be editing. Extra documentation: Privileges for geodatabases in SQL Server—Help | Documentation Modifying and deleting attribute domains—ArcGIS Help | Documentation Hope this helps! Colin
... View more
03-10-2020
03:57 PM
|
1
|
3
|
88
|
POST
|
Hi Eric, Does the Shape column still exist table? You can verify by right clicking on the table/feature > Properties > Fields. Additionally, have you ran the Check Geometry tool for the features in your file geodatabase? If geometry issues do exist, this tool will generate a report of the geometry problems. You could then run the Repair Geometry tool, but its typically best practice to have a backup copy of the geodatabase to be safe.
... View more
03-04-2020
11:21 AM
|
2
|
1
|
17
|
POST
|
Hi Yatharth, Did it participate in SQL Server replication or enterprise geodatabase replication? Objects published via SQL Server replication cannot be dropped or renamed. This could be expected behavior and may not have to do with the geodatabase itself. If you want to delete or rename a feature class that participates in SQL Server replication you would first have to remove the object from the publication, or disable replication.
... View more
03-03-2020
07:41 PM
|
0
|
0
|
29
|
POST
|
Hi Dylan, I suggest re-posting this on the https://community.esri.com/community/arcgis-ideas page for greater visibility!
... View more
03-03-2020
07:29 PM
|
2
|
0
|
14
|
POST
|
Hi Alfonso, I believe a related conversation is happening over at Auto-Increment Field within SDE. There should be some information throughout that thread that you may find valuable to your workflow. Colin
... View more
06-06-2019
09:57 AM
|
0
|
1
|
75
|
POST
|
Mike, I just did some brief testing. What I found was that I am able to increase the field length when the table is unregistered as versioned, however, if I tried to decrease the field length I would be prompted with a "table or feature class is not empty" error. Colin
... View more
06-04-2019
04:54 PM
|
2
|
1
|
48
|
POST
|
Hi Mik, Typically it is not recommended to follow this workflow because of the version view table. A possible workaround could be to un-register it as versioned in ArcMap, and use the field properties dialog box to change the field length, then re-register it as versioned again. Best, Colin
... View more
06-04-2019
01:58 PM
|
3
|
0
|
48
|
POST
|
Hi Erik, If you are using Survey 123 connect I believe there is a configuration setting to display your date/time field in 24hr format (i.e. hh:mm:ss). Check out the highly detailed post on Dates and Time in Survey123 for ArcGIS for instructions on how to do so. If you are using the Survey 123 website or the Survey 123 field app, you should check if configuring your device date time settings to 24hr format helps display it that way as well. If you are displaying the data in ArcGIS Online from those applications you can manipulate the time display on the time field in the Configure Attributes window from the Configure Popup settings. Best, Colin
... View more
03-07-2019
04:17 PM
|
1
|
0
|
225
|
Online Status |
Offline
|
Date Last Visited |
01-08-2021
10:13 AM
|