|
POST
|
The number of items and number of fields match, and the list is populated with data. I have tried the script out on a file geodatabase and it works just fine...so I guess the problem is inserting them into the SDE database. Does ESRI require the data be versioned for working with SDE databases and cursors? I see no mention of that being a requirement in any of the help documentation. Guess I will continue my investigation there.
... View more
10-18-2017
10:03 AM
|
0
|
0
|
9764
|
|
POST
|
I made sure to add the delete statement for the insert cursor, that's been there since I changed the script so I'm all good there. I reloaded the table cache in ArcMap and it didn't do anything, so it must not be adding the rows, or maybe it's doing it temporarily but not saving or something? This is being done on DEFAULT, this data isn't versioned and won't ever be. I might try using the insert cursor in an edit session, if I can get the edit session to work with my non-versioned data, that way I can hardcode the "saving" by committing the edits and stopping the edit session. Perhaps that will shed some light on the issue. Edit: inserting rows inside an edit session (edit.startEditing(False, False) and edit.stopEditing(True)) didn't work. Hmm...
... View more
10-18-2017
08:37 AM
|
1
|
2
|
9764
|
|
POST
|
Thanks, I think that'll work well. I was getting hung up on the looping - I definitely see your point on why you don't have to loop through an insert cursor (duh!). I've gotten rid of all the start/stop editing calls, and now it runs "successfully" as in the exit code is 0 and there's no error messages...but when I open my Patches feature class, no rows were inserted at all. Any idea why that could be? I'm inserting the appropriate data types and matching fields for each row as far as I can tell.
... View more
10-18-2017
08:21 AM
|
0
|
6
|
9764
|
|
POST
|
**Edit** - I have since closed my python script and reopened it. Now when I run it, I get the error "Cannot open workspace" when edit = arcpy.da.Editor(arcpy.env.workspace) is called. I imagine this is because the SDE database is not versioned, so I have set edit.startEditing('False', 'True') and also tried edit.startEditing('False', 'False') however that does not solve the problem either. I have a script that takes data from a shapefile (using a search cursor) and copies it to a SDE feature class (using an insert cursor after some data manipulation). Obviously, the shapefile is in a different workspace than the SDE feature class. I've read that this error occurs because you need to do your nested cursor actions in an edit session, but that does not seem to solve my problem. I don't think this has anything to do with registering layers with the SDE database as the feature class was created inside the SDE database using ArcMap, therefore it shouldn't need to be registered (right? My knowledge on registering things is limited). It's not versioned and will not be in the future as there is no need. Here's the main portion of the script: #Set the workspace to access feature classes in the HbMonitoringTest SDE database
arcpy.env.workspace = r'C:\Users\user\AppData\Roaming\ESRI\Desktop10.5\ArcCatalog\myServer_HbMonitoringTest.sde'
#Getting feature class from database
PatchesFC = "Patches" #Get input shapefile from different workspace InputFC = r'C:\Users\user\Desktop\GIS_Testing\HbtatTesting\ExpTestFC.shp' #create fields variables and a few other things here #Start editing session on the SDE database
edit = arcpy.da.Editor(arcpy.env.workspace)
edit.startEditing()
edit.startOperation()
with arcpy.da.SearchCursor(InputFC, scFields) as sCursor: #Search cursor acts on shapefile
for row in sCursor:
rowList = list(row)
PatchID = '{' + str(uuid.uuid4()).upper() + '}'
ObserverID = None
rowList.insert(2, PatchID)
rowList.append(ObserverID)
rowTuple = tuple(rowList)
with arcpy.da.InsertCursor(PatchesFC, icFields) as iCursor: #Insert cursor acts on SDE database
iCursor.insertRow(rowTuple)
#Stop editing session
edit.stopOperation()
edit.stopEditing('True')
... View more
10-18-2017
07:32 AM
|
0
|
8
|
15091
|
|
POST
|
Thanks, although less stream-lined than I'd like, that'll work and is probably the best way.
... View more
10-18-2017
05:55 AM
|
0
|
0
|
1331
|
|
POST
|
So, I understand that GUID fields aren't supported by shapefiles, and when you do a join manually in ArcMap (right click layer in TOC > join), it converts the GUID field to a string to join a table with a GUID to a shapefile. I figured it would do the same thing in arcpy as it does in ArcMap when using JoinField_management, but instead the tool fails. Is there any way to have that GUID field convert to string so I can join it with my shapefile? The only way I can think to do it is to copy the SDE database and change the GUID field to string field before joining it with my shapefile in arcpy, but I really want to avoid doing that as it isn't practical.
... View more
10-18-2017
05:04 AM
|
0
|
2
|
1453
|
|
POST
|
I've looked for the Production Editing toolbar and I do not have it available in ArcMap which is strange as we have an advanced license. It's not even under Customize Mode. In my original question I was just testing this process with a file geodatabase as I can't get it to work in my enterprise geodatabase where I actually need it to work. In the enterprise geodatabase, the GUID fields were not my doing as someone created this database before I got here and now that it's established in the production database which a bunch of web applications are built on top of, I have to stick with the current GUID system. My goal is to append records from a feature class to the enterprise geodatabase table which contains a non-nullable GUID field. Every time I try to do so (with the "Load Objects" button on the editor toolbar) the GUID field gets populated with the series of 0s and then fails because there cannot be more than one record with the same GUID (it keeps trying to add all the new features with the same GUID of 00000000-0000-0000-0000-0000000000000). The table field names/data types are the same between the feature class I am trying to append and the existing feature class in the enterprise geodatabase. The only time I can get it to successfully load the features into the SDE feature class is if I populate the GUID field of the feature class I'm appending manually using Field Calculator before attempting to load it into the SDE feature class. Of course, when I use field calculator to populate the GUID field before loading the data in, there's a chance it will create a duplicate key to a record that already exists in the SDE feature class, thus not solving the issue.
... View more
10-03-2017
10:46 AM
|
0
|
0
|
1841
|
|
POST
|
I have a feature class with a field set up as a GUID data type that cannot be null. When I'm in editing mode and add a new point to the map, the GUID is populated with an ID made up of entirely 0s and dashes, and if I add multiple points, they all have the same GUID. I don't understand why it's not creating unique IDs as that's kind of the whole purpose of the field. What's wrong here?
... View more
10-03-2017
09:10 AM
|
1
|
2
|
2705
|
|
POST
|
Nevermind, all I had to do was change the Alias which somehow was set as the old database name...
... View more
10-03-2017
04:54 AM
|
1
|
0
|
1348
|
|
POST
|
I copied and pasted a feature class from one enterprise geodatabase to another. In the catalog window, the naming scheme shows up correctly for the new database, but when I add the layer to the map, the naming scheme changes to the old database. New database is called FocalAreasTest1, old database is called FocalAreas. It only appears to affect the feature classes I copied over and not the tables. Any idea why this might be happening and how to fix it? The source looks correct, it's just the name in the TOC. New database in catalog window naming scheme (FocalAreasTest1): Added MonitoringPoint feature class to the TOC, along with a table that I also copied from old database to new using the same procedures as the feature classes, notice how they are both children of a single parent database (the new one): Source window for the newly added MonitoringPoint feature class where it looks to come from the correct source:
... View more
10-03-2017
04:50 AM
|
0
|
3
|
1416
|
|
POST
|
I can see in the GDB_ITEMRELATIONSHIPS table that some relationships are being carried over though I cannot tell what ones given it's just a list of various IDs. I'm assuming this is what you were referring to in your previous post about these relationships only existing in the geodatabase. Thing is, I can't tell what these relationships actually are considering it's just a listing of various ID strings. This table has no meaning to me. If I just copy over the feature classes in ArcCatalog and leave the SQL-derived tables, I just get a feature classes in the database, nothing else comes with it (aside from two rows in the GDB_ITEMRELATIONSHIPS table). I think the problem could be that the table relationships were actually originally established in SQL Server, not in ArcMap/Catalog.
... View more
09-29-2017
07:18 AM
|
0
|
1
|
4516
|
|
POST
|
Well then can you maybe help me understand what the person in this position before me did because I can see the relationships for the MonitoringPoint table in the SSMS just fine in the production database. In the image below of (in the production database), the MonitoringPoint table contains point features, so it is spatial. Count and CoveyCount are not spatial. Did the person create these tables in SQL Server and not ArcCatalog and that's why they're showing up in the dependencies for MonitoringPoint in the production database? When creating the test database I copied/pasted everything using ArcCatalog. Should I be copying/pasting only the spatial layers (feature classes) using ArcCatalog and copying/pasting the rest of the SQL-made tables using SSMS? I want to be able to make sure the relationships are preserved and viewable...
... View more
09-29-2017
06:57 AM
|
0
|
3
|
4516
|
|
POST
|
I just followed through with my outlined steps above and after copying the data over, it does not appear the relationships carried as you stated they would. How are you getting the table relationships to carry over? When I look at dependencies for a particular table that I know should have many relationships in SQL Server Management Studio, there are none...
... View more
09-29-2017
06:38 AM
|
0
|
5
|
4516
|
|
POST
|
Yeah, we've got 2012 R2 OS on the server, MS SQL 2014, and 10.5.1 Desktop, so we're in a slightly better position! I already had to update the drivers when I was connecting to all the other databases as I originally encountered failure with them as well. Curious - what driver are you using, 11 or 13?
... View more
09-29-2017
04:47 AM
|
0
|
1
|
3446
|
|
POST
|
I have a database in production and need to update an old copy of it, the "test" database, where I can only assume the person in this position before me did a backup & restore to create the test database, but renamed it during the restore process thus I cannot actually connect to it in ArcMap because all the SDE tables have the production database name, not whatever he renamed it to (cause renaming is a no-no with SDE geodatabases). I can't revert this test database back to the original name because the production database exists in the same SQL Server instance and you can't have two databases named the same. Plus, the data in it is old and I want to update it. So, what is the proper workflow for creating a copy of a database with a new name? I'm thinking it'd look something like this: 1) Use Create Enterprise Geodatabase tool with the new name "MyDatabaseTest" 2) Add users (is there any way to copy users from the production database to the new test one or do you really have to go through and do it manually again?) 3) Use ArcCatalog to copy/paste feature classes and tables from production database to new test database How does this copy/paste process affect existing table relationships in the RDMS? I worry about losing all of that. Will this workflow work? I assume after going through this, I would be able to use direct connection in ArcMap to connect to the new test database, as that is really the goal. For reference, working with SQL Server 2014 and Desktop 10.5. I'm not sure what version of SDE we're working with, if it's the same as Server it'd be 10.4.1.
... View more
09-29-2017
04:44 AM
|
1
|
13
|
6896
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-18-2020 10:31 AM | |
| 2 | 09-16-2025 02:17 PM | |
| 3 | 09-12-2025 09:26 AM | |
| 1 | 08-16-2023 05:11 PM | |
| 1 | 02-27-2024 06:48 AM |
| Online Status |
Offline
|
| Date Last Visited |
09-16-2025
02:16 PM
|