nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Alternatives to using SDE command line tools - Blog Discussion

ChetDobbins

With the release of 10.2 and plans to deprecate the ArcSDE command line tools, you may be wondering how current tasks that use these tools can be completed elsewhere. This blog provides some workflows that have alternate user interface tools in ArcCatalog/ArcMap that will make transitioning as seamless as possible.

http://blogs.esri.com/esri/supportcenter/2013/10/04/do-this-not-that-alternatives-to-using-sde-command-line-tools

We are very interested in hearing feedback from everyone who uses the ArcSDE commands, including questions, concerns, and ideas for making this successful. You can also contact Esri Support Services for specific ArcSDE commands that do not have comparable replacements.

This document outlines the planned changes in platform and functionality in the ArcGIS 10.2 release and
includes a reference to ArcGIS 10.1 deprecation notes.
http://downloads2.esri.com/support/TechArticles/W26496_W25918_DEPRECATION_PLAN_FOR_ARCGIS_101_and_102_FINAL_050713.pdf

Najděte více příspěvků označených jako

Accepted answers

All comments

PF1

With the release of 10.2 and plans to deprecate the ArcSDE command line tools, you may be wondering how current tasks that use these tools can be completed elsewhere. This blog provides some workflows that have alternate user interface tools in ArcCatalog/ArcMap that will make transitioning as seamless as possible.

http://blogs.esri.com/esri/supportcenter/2013/10/04/do-this-not-that-alternatives-to-using-sde-command-line-tools

We are very interested in hearing feedback from everyone who uses the ArcSDE commands, including questions, concerns, and ideas for making this successful. You can also contact Esri Support Services for specific ArcSDE commands that do not have comparable replacements.

This document outlines the planned changes in platform and functionality in the ArcGIS 10.2 release and
includes a reference to ArcGIS 10.1 deprecation notes.
http://downloads2.esri.com/support/TechArticles/W26496_W25918_DEPRECATION_PLAN_FOR_ARCGIS_101_and_102_FINAL_050713.pdf

The only limitation I have run into so far: Fine grained DBMS permissions at the table/layer level.

In arcsde you could grant or revoke 'edit' permissions with either insert, update, or delete:

sdetable -o {grant | revoke} -t <table> -U <user>
-A <SELECT,UPDATE,INSERT,DELETE> [-s <server_name>]
[-i {<service> | <port#> | <direct connection>}]
[-D <database_name>] -u <DB_user_name>
[-p <DB_user_password>] [-I] [-q]

The closest python script tool available appears to be the Change Privileges tool which only allows grant/revoke at the 'edit' or 'select' level:

The RDBMS equivalent commands for the Edit parameter are Update, Insert, and Delete. All three are granted or revoked simultaneously by the Edit parameter.

I run into this frequently as often times we would only like to 'update' features and restrict the 'insert' or 'delete' capabilities.

VinceAngelo

The versioning model doesn't support access resolution beyond {NO_ACCESS, READ_ONLY, READ_WRITE}. This is a design feature. You could not circumvent it with 'sdetable -o grant'
previously either (if all the required permissions weren't present for all tables, then the entire
feature class [or feature dataset] had the next lowest access, if any).

At 10.2, if you have simple feature classes (non-versioned tables, not registered with the
geodatabase), you can use Catalog to right-click Manage... Privileges..., and it will offer the
traditional four checkboxes (SELECT, INSERT, UPDATE, DELETE) by user.

So it seems as if your request is either impossible or already available. Do you have access to
10.2 to see if this meets your requirements?

- V

PF1

The versioning model doesn't support access resolution beyond {NO_ACCESS, READ_ONLY, READ_WRITE}. This is a design feature. You could not circumvent it with 'sdetable -o grant'
previously either (if all the required permissions weren't present for all tables, then the entire
feature class [or feature dataset] had the next lowest access, if any).

At 10.2, if you have simple feature classes (non-versioned tables, not registered with the
geodatabase), you can use Catalog to right-click Manage... Privileges..., and it will offer the
traditional four checkboxes (SELECT, INSERT, UPDATE, DELETE) by user.

So it seems as if your request is either impossible or already available. Do you have access to
10.2 to see if this meets your requirements?

- V

Hi Vince,

We have a lot of backend processing and scripts which update data. Much of the data is not registered as versioned, but is registered with the GDB. So we frequently grant just 'update' to many accounts to necessary feature classes or tables.

I have seen those check boxes you refer to but have not tried them yet. Unfortunatly though those would not be script-able with python so thier use is limited for ad hoc purposes that are hard to track and baseline changes.

That was new news to me though regarding the 'design feature' with versioned datasets. It seams many of the traditional database capabilities are truly limited when using SDE versioning and I try to stay away from it as much as possible. Something as simple as a unique constraint on a primary key field is a prime example...

Appreciate the feedback! Thanks!

Regards,
Patrick

JoshuaBixby

I wasn't sure whether to post the following comments here or over in the Blogs, so I erred on doing both.

I don't mean to be contrary, but I just can't get excited about replacing one suite of simple, script-able tools with an assortment of scattered and mostly GUI-driven tools. For example, how is replacing several of the sdemon commands (-o info -I users/locks, -o pause/resume, -o kill) with tabs in ArcCatalog a step forward? I realize the tabs in ArcCatalog are going to be convenient for the casual SDE administrator, and I think providing them brings some value, but providing them as the exclusive means to manage geodatabases is a step backwards.

I am not necessarily advocating for keeping the command line binaries around, I just think nearly all of the functionality should exist through non-GUI means in one form or another. If Esri wants to migrate away from command line binaries to ArcPy/Python; great, I will work with that. I just can't work with managing thousands of users scattered across hundreds of geodatabases using tabs in ArcCatalog or some other GUI-only option.

I have an interesting observation and wanted to share with you guys and see if you experience the same thing.

I am on ArcSDE 10.2, with Oracle 11.2.0.2.0, OS is RHEL6.1. I was excited that using ArcGIS for Desktop there is an option to create a database view. So I followed the steps listed here
http://resources.arcgis.com/en/help/main/10.2/index.html#/Create_a_database_view_in_ArcGIS_for_Desktop/019v0000000n000000/

and created a simple database view of one of my SDE feature layers.

I also created a similar view using SDE command line tool like I used to do in 10.0 and before. Both methods created the views. However, I discovered that in the view created using the desktop tool, the objectID field data type is Long Integer, whereas the view created by the "traditional" SDE command line tool is ObjectID data type.

There are some advantages of having it as the "object ID" data type, especially using the view in ArcGIS services, etc.

I wonder if anybody else notice this? Is this "long integer" thing a bug? or is it by design choice? I hope to see some documentation about this, but haven't find any. I am very interested hearing how you guys think about this....
Thanks
Rong

ctalleygreenville

The blog here was very helpful:
http://blogs.esri.com/esri/supportcenter/2013/10/04/do-this-not-that-alternatives-to-using-sde-command-line-tools/
but I found what I really needed way down in the comments/questions from others.

Please consider compiling an all-inclusive document that provides all the alternatives to using the sde command line tools as a reference. There are a lot of SDE admins who are very much "part time database admins" who probably don't get to read all about the changes until we are forced to (like upgrading to 10.1 "SDE", SQL 2012, and trying not to install SDE executables). Trying to search through the Online Help seems to make me bounce around to different locations and therefore more confused. I don't think I am alone.

I really, really miss the "ArcSDE Configuration and Tuning Guide for SQL Server" .pdfs that used to be created like this:
http://downloads2.esri.com/support/documentation/sde_/1009ArcSDE_Config_GD_SQLServer.pdf

I do like the GUI options for basic admin tasks - I will be able to hand over some of these tasks to others.

I found the following UC videos helpful even though I had seen the equivalent of these in older versions!:

Geodatabase Admin - Intro (helpful for seeing where new tools are located even if topic isn't new):
http://video.esri.com/watch/2735/geodatabase-administration-an-introduction

ADministering SQL SErver Geodatabase (notice it says nothing SDE - but is) - Shannon S. seems to always answer my questions.
http://video.esri.com/watch/2616/administering-your-microsoft-sql-server-geodatabase

Thanks,
Carmen

JoshuaBixby

For example, how is replacing several of the sdemon commands (-o info -I users/locks, -o pause/resume, -o kill) with tabs in ArcCatalog a step forward?

I have to eat one of my earlier statements. I have since learned that ArcPy now supports AcceptConnections, DisconnectUser, and ListUsers as of ArcGIS 10.1. The sdemon functionality for listing locks and stats still appears to be missing.

As an FYI, there is another related enhancement request someone referenced on the ArcGIS Ideas site:
NIM095119 - SDEMON:Create geoprocessing tools or arcpy functions for operations performed when using the 'sdemon' command.

JoshuaBixby

I have since learned that ArcPy now supports AcceptConnections, DisconnectUser, and ListUsers as of ArcGIS 10.1.

Sigh.... ListUsers requires an administrative SDE workspace/connection, SDEMON didn't, so there is still some progress to be had.

VinceAngelo

'sdemon' certainly did require SDE user access rights, it just passed those access
rights to any connection on the port (which could be construed as a security hole).

- V

FranciscoAcosta_Bazán

That will replace geoprocess for "dbtune" command ?
for loads in custom mode, change keywords etc.
I do not understand that there are no courses 10.1 / 2 where they could study the performance depending on the DBMS:
Oracle (ACTO), SQLServer ACTS ...

Regards
Francisco

mody_buchbinder

Some more options that are missing:
1)            Sdegdbrepair - ??
2)            Sdeexport / sdeimport: should we continue to use this as a way to transfer data?
3)            Sdegroup - ??
4)            Sdelayer -o si_stats : is GDBT going to be part of core? It does not exists for 10.1
5)            Sdelayer -o load_only / normal_io : helps to load a lot of data.
6)            Sdetable -o add_uuid_column / populate_uuid_column - ??
7)            Sdetable -o unregister : should we use that at all?

We tried to get a NIM for all of them but failed�?�
Ofcourse not all of them are the same importance

Thanks
Mody

VytautasGipiskis

1. sdelayer -o stats (useful when working on sdebinary/sdelob)
2. sdelayer -o describe_long (to get a spatial index sizes for sdebinary, UI no longer shows it)
3. sdelayer -o alter -g (alter spatial index for sdebinary, as tools not always provide best estimate for spatial index)
4. sdegroup �?? while caches provides best per performance, sometimes users just need to snap to a vector features. Grouped layer provides best performance for such scenarios
5. sdelayer -o si_stats �?? there is no equivalent for this info in GUI
6. sdedbtune �?? what is a proper way to alter dbtune table ? Use SQL ?
7. sdeversion -o close_state for closing unclosed states ?

DavidKlein1

Is it indeed the case that SDEGDBREPAIR will no longer exist at 10.2??

We have just had our 2nd unplanned outage on our editing geodatabase in 6 weekswhich was fixable by SDEGDBREPAIR. We are now planning our 10.2 upgrade...but the prospect of not having that SDEGDBREPAIR safety net is more than a little unnerving!

Can someone from Esri please chime in on availability of these other SDE command line tools?

DavidGifford

Shp2sde has (had?) the reject output option, where any shapes that weren't "right" would be written to an output shapefile. Really useful for large datasets when importing to SDE. If something similar could be done for Feature Class to Feature Class (maybe outputting the rejects into the same format as the input feature class) this would save users a lot of time. FC to FC currently just writes rejects to a text file listing the OID's which is almost useless in a large dataset.

I have this listed in ArcGIS Ideas (http://shar.es/U3csA).

Regards
-David

MichelleBoivin

Currently I am running through some issues creating spatial views, and according to ESRI the only way to create them is with the sdetable -o create_view command. Reason being is that all of our data currently has to be in SDEBINARY due to a GEOMETRY storage type incompatibility with geometric networks and network datasets (ESRI proven with open-ticket). We rely on numerous views for a great number of applications within the City and I cannot imagine not being able to create those. In the case of deprecation of the command line SDE tools, has this issue been addressed at all?

JohnFletcher

I have an interesting observation and wanted to share with you guys and see if you experience the same thing.

I am on ArcSDE 10.2, with Oracle 11.2.0.2.0, OS is RHEL6.1. I was excited that using ArcGIS for Desktop there is an option to create a database view. So I followed the steps listed here
http://resources.arcgis.com/en/help/main/10.2/index.html#/Create_a_database_view_in_ArcGIS_for_Desktop/019v0000000n000000/

and created a simple database view of one of my SDE feature layers.

I also created a similar view using SDE command line tool like I used to do in 10.0 and before. Both methods created the views. However, I discovered that in the view created using the desktop tool, the objectID field data type is Long Integer, whereas the view created by the "traditional" SDE command line tool is ObjectID data type.

There are some advantages of having it as the "object ID" data type, especially using the view in ArcGIS services, etc.

I wonder if anybody else notice this? Is this "long integer" thing a bug? or is it by design choice? I hope to see some documentation about this, but haven't find any. I am very interested hearing how you guys think about this....
Thanks
Rong

I recently noticed something similar, with GUID type fields in Oracle. Using command-line tools results in a view with the same GUID types as the source tables. Using desktop results in a view with all GUID types converted to text. As GUIDs behave differently than text (importantly, what their respective string representation is), this is problematic.

My suspicion is that the columns in the view created using desktop either do not get inserted into COLUMN_REGISTRY, or they get inserted with the incorrect types. The actual database type is char(38), so without an entry in COLUMN_REGISTRY (or similar) there'll be no way for ArcGIS to know that this is meant to be a GUID. I'm just continuing to use command-line tools to create the views, for the time being.

John

MarcoBoeringa

I recently noticed something similar, with GUID type fields in Oracle. Using command-line tools results in a view with the same GUID types as the source tables. Using desktop results in a view with all GUID types converted to text. As GUIDs behave differently than text (importantly, what their respective string representation is), this is problematic.

My suspicion is that the columns in the view created using desktop either do not get inserted into COLUMN_REGISTRY, or they get inserted with the incorrect types. The actual database type is char(38), so without an entry in COLUMN_REGISTRY (or similar) there'll be no way for ArcGIS to know that this is meant to be a GUID. I'm just continuing to use command-line tools to create the views, for the time being.

John

They certainly should not be inserted into the COLUMN_REGISTRY, as that is an ArcSDE System Table. The tool you are using - Create Database View - is nothing but a "button" or "skin" to access RDBMS database functionality. It is not part of the ArcGIS Geodatabase realm, and hence it would be bad if it inserted data into the COLUMN_REGISTRY.

This may sound like a regression coming from the SDE Command Line tools, but this actually allows you to create (spatial) views in databases that are not "geodatabase enabled" and thus not "geodatabase aware", e.g. any "ordinary" non-GIS database you have on the shelves, like for customer data.

In addition, these tools were not really (or not only) designed to replace the ArcSDE Command Line tools, but to fulfil other ArcGIS users' needs.

Of course, you can do the same thing just as easy from your RDBMS management interface, like SQL Plus, SQL Server Management Studio etc, but this tool allows you to script it in Python using arcpy, or use it in ModelBuilder.

It is probably confusing because ArcGIS now contains both tools and menu options acting against geodatabases only, and tools working in mixed or non-geodatabase RDBMS systems, something many users still need to get accustomed too...

JohnFletcher

They certainly should not be inserted into the COLUMN_REGISTRY, as that is an ArcSDE System Table. The tool you are using - Create Database View - is nothing but a "button" or "skin" to access RDBMS database functionality. It is not part of the ArcGIS Geodatabase realm, and hence it would be bad if it inserted data into the COLUMN_REGISTRY.

This may sound like a regression coming from the SDE Command Line tools, but this actually allows you to create (spatial) views in databases that are not "geodatabase enabled" and thus not "geodatabase aware", e.g. any "ordinary" non-GIS database you have on the shelves, like for customer data.

In addition, these tools were not really (or not only) designed to replace the ArcSDE Command Line tools, but to fulfil other ArcGIS users' needs.

Of course, you can do the same thing just as easy from your RDBMS management interface, like SQL Plus, SQL Server Management Studio etc, but this tool allows you to script it in Python using arcpy, or use it in ModelBuilder.

It is probably confusing because ArcGIS now contains both tools and menu options acting against geodatabases only, and tools working in mixed or non-geodatabase RDBMS systems, something many users still need to get accustomed too...

Thanks Marco, good points. I can see the value in tools that operate on the DB without involving the GDB.

I still do not know how to create a spatial view that preserves the data types of the source feature classes (GUIDs in my case). Well, without using SDE command-line that is. I don't think that it would necessarily be a regression, but I do think that there needs to be some other tool which does allow for this use case.

John

BlairShaman

I'm using SQL to create a table in SQL Server with a geometry column. I need a way to automate registration of that table with the geodatabase. Using arcpy.RegisterWithGeodatabase_management doesn't work if the table is not populated; it complains that there is no geometry type specified.

I'm assuming that I would be able to do this using sdelayer -o register with the entity mask parameter, although I haven't tried. I would also be able to specify the spatial reference using the command line tool. The Register with Geodatabase tool, however, takes no parameters except for the input table.

Is there something I'm missing here, or is this another piece of functionality that isn't yet available in UI/GP/ArcPy?

Blair

ZoeChen_2-1624670781993.png

ShannonShields

I'm using SQL to create a table in SQL Server with a geometry column. I need a way to automate registration of that table with the geodatabase. Using arcpy.RegisterWithGeodatabase_management doesn't work if the table is not populated; it complains that there is no geometry type specified.

I'm assuming that I would be able to do this using sdelayer -o register with the entity mask parameter, although I haven't tried. I would also be able to specify the spatial reference using the command line tool. The Register with Geodatabase tool, however, takes no parameters except for the input table.

Is there something I'm missing here, or is this another piece of functionality that isn't yet available in UI/GP/ArcPy?

Blair

Blair,

is there any reason why you are using SQL to create an empty table then register it with the geodatabase, rather than simply creating a feature class using python directly? RegisterWithGeodatabase is intended for registering existing (e.g. populated) tables, as opposed to brand-new empty ones that could simply be created using GP/UI/Python.

-Shannon

BlairShaman

Blair,

is there any reason why you are using SQL to create an empty table then register it with the geodatabase, rather than simply creating a feature class using python directly? RegisterWithGeodatabase is intended for registering existing (e.g. populated) tables, as opposed to brand-new empty ones that could simply be created using GP/UI/Python.

-Shannon

Shannon,
Unfortunately, that part is beyond my control. This lives within a larger database, the majority of which is non-spatial. There will only be a few tables that contain spatial data. The people that I'm working with are creating and updating the database within a Visual Studio database project, and need to build views and other database objects against the spatial tables. They would much prefer to be able to do all of this in Visual Studio, meaning that it would create tables with a geometry column, and then I would register them after the fact. Not ideal, I know.

Blair

ScottBateman

Surprised there has been no mention of .sdx files for moving data around. Is the .sdx file format going to be supported any longer with the deprecation of the tools that create/consume them?

I agree with bixb0012 about GUI options being a step back for administrators. As your environment grows, automation and anomaly identification become key for monitoring and finding problems. If you want to check things one at a time, GUI is fine but if you want to setup alerts to let you know when a spatial index is missing or sub-optimal GUI is not all that helpful.

Along those lines, haven't heard any response to the si_stats question. I've have problems with GDBT crashing on me a lot in the past so have favored si_stats for spatial index analysis and tuning. let's face it, Windows GUI is slower and much less stable than a simple background thread and doesn't lock up my environment and prevent me from doing other work.

Same point here about GUI vs. command line. If you want to setup a job to check all of your SIs to make sure none have too many features per grid... I don't care what the tool is - SDE command line, python, LOGO, smoke signals... I just don't want to have to sit there and click it all day with my mouse. Much more productive to review a report of anomalies each morning and do analysis and resolution instead of monitoring.

Anonymous User

I'm very interested to hear ESRI's guidance on .sdx as well. For large datasets, sdeexport/sdeimport is probably one of the most efficient means of transferring data. FGDB import/export is orders of magnitude slower. Many of our customers prefer this option because it is simple to implement and very fast.

-Joel

Maartende_Jong

There are currently two ideas about creating spatial views on ideas.arcgis.com:

Create SDE spatial view from ArcGIS Desktop
http://ideas.arcgis.com/ideaView?id=08730000000884aAAA

Create Views In ArcCatalog Like In SDE Command Line
http://ideas.arcgis.com/ideaView?id=087E00000005A9tIAE

The first one is marked as implemented by the Create Database View tool, which I object against, because (as other contributors above have mentioned) the result is not nearly the same as the sdetable -o create_view.

The second one is the request for a replacement for sdetable -o create_view. Please promote the idea if this is something you also run into.

A lot of improvements on the geodatabase side have been made in the lastest ArcGIS releases like renaming and modifying columns and making the sde command line tools available via tools. The possibility of creating proper spatial views however, still needs attention before deprecating the current tools.

MarcoBoeringa

A lot of improvements on the geodatabase side have been made in the lastest ArcGIS releases like renaming and modifying columns and making the sde command line tools available via tools. The possibility of creating proper spatial views however, still needs attention before deprecating the current tools.

It would be more correct to replace the highlighted text with:

"A lot of improvements on the geodatabase side have been made in the lastest ArcGIS releases like renaming and modifying columns and adding (geoprocessing) tools that can substitute functionality of the sde command line tools."

The new tools do not rely on the sde command line tools for their implementation in ArcGIS.

JoshuaBixby

'sdemon' certainly did require SDE user access rights, it just passed those access
rights to any connection on the port (which could be construed as a security hole).

- V

I am not sure playing the security card solicits the intended response for most people with this issue. I know our IT security folks won't feel better knowing Esri viewed the functionality of SDEMON for listing users as weak security, possibly a security hole, and yet never addressed the issue over years and many versions of the software. I felt better about it when I thought it was just incomplete functionality.

BoGuo

There are three important advantages that the SDE-command-line tools offer, beyond the much talked about rich functional capabilities they have:

1) Easily scriptable for automation
2) Run on server with only SDE binary is loaded and without consuming a license (free)
3) Run all platforms

SDE tools are mainly used by admins, most of whom, myself being one, would much rather script for consistency and performance than use GUI for the same tasks.

In perspective, a Windows user (not a programmer) can do most* any tasks and much more using Windows GUI, and yet DOS shell is supported and used by many.

Please, please, please do not ever dump SDE command line tools until equally-capable tools that Admins could use are available.

Anonymous User

sdelayer -o si_stats is indispensible for maintaining some feature classes, and no equivalent is available in desktop at the current version. The GDBT spatial index examination tool at 10.0 sort of works, but command line works better and faster.

Today I had to use sdelayer -o si_stats to examine and redesign the spatial indexes for statewide parcels. Before change, took four minutes to draw at a reasonably large scale. After change, 6 seconds or less. The before-change spatial index was the one "estimated" automatically by ArcGIS desktop when the data were loaded. Take away this command line tool and our ability to provide well-performing data will be crippled.

BetsySchenck-Gardner

We specifically use the sde command-line scripting to handle loading data into sde from non-Windows platforms such as Linux systems. All in all this move away from sde command line is not very helpful for those of us that are just trying to automate loading of shapefiles into SDE/geodatabase in a shell scripting environment on a Linux platform.

ForrestJones

We specifically use the sde command-line scripting to handle loading data into sde from non-Windows platforms such as Linux systems. All in all this move away from sde command line is not very helpful for those of us that are just trying to automate loading of shapefiles into SDE/geodatabase in a shell scripting environment on a Linux platform.

Hi Betsy,

What about using python and Engine or Server on Linux?

This is from the geprocessing tools help:

FeatureClassToGeodatabase example 2 (stand-alone script)
The following stand-alone script demonstrates how to use the FeatureClassToGeodatabase function.


# Name: FeatureClassToGeodatabase_Example2.py
# Description: Use FeatureClassToGeodatabase to copy feature classes
#  to geodatabase format
 
# Import system modules
import arcpy
from arcpy import env
 
# Set environment settings
env.workspace = "C:/data"
 
# Set local variables
inFeatures = ["climate.shp", "majorrds.shp"]
outLocation = "C:/output/output.gdb"
 
# Execute TableToGeodatabase
arcpy.FeatureClassToGeodatabase_conversion(inFeatures, outLocation)

To take this a step further here's an example (pseudo code) that uses a folder location to load data to an enterprise geodatabase.

Pseudo code:


# Import system modules
import arcpy
from arcpy import env

# Process: Create Database Connection File...
# Usage:  out_file_location, out_file_name, DBMS_TYPE, instance, database, account_authentication, username, password, save_username_password(must be true)

arcpy.CreateDatabaseConnection_management("/net/shared/location/connections/",
                                          "zion.sde",
                                          "ORACLE",
                                          "zionserver/ORCL")

# Set environment settings
# Set the workspace to the specified data location
env.workspace = "/net/sharedata/location/data"

outLocation = "Database Connections\zion.sde"

# Get all the feature classes in the environment
# list of fc's should be similar to this: ["accident.shp", "veg.shp"]
inFeatures = arcpy.ListFeatureClasses()

# Process: Load Data (Use the "Feature Class To Geodatabase" Tool...)
try:
   # Execute FeatureClassToGeodatabase
   print "Loading data...\n"
   arcpy.FeatureClassToGeodatabase_conversion(inFeatures, outLocation)

except:
   for i in range(arcpy.GetMessageCount()):
       arcpy.AddReturnMessage(i)

Finally to take this yet another step further, there is a script available that works on Linux and Windows and uses the above concepts to create a database connection file and then load data from a specified directory to the enterprise geodatabase.

It also uses some code from the Upgrade Geodatabase (Data Management) help documentation for parsing the sde connection parameters (similar feel to the sde command line tools).

Full script Usage:

Examples:

(Linux)
/tmp>loaddata_sde_params.py --DBMS ORACLE -i myserver/orcl -u user1 -p user1 --dataloc /net/sharedata/location/data

(Windows)
c:\tmp>loaddata_sde_params.py --DBMS ORACLE -i myserver/orcl -u user1 -p user1 --dataloc \\sharedata\location\data


>loaddata_sde_params.py --help

Usage: loaddata_sde_params.py [Options]

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  --DBMS=DATABASE_TYPE  Type of enterprise DBMS: SQLSERVER, ORACLE, or
                        POSTGRESQL.
  -i INSTANCE           DBMS instance name
  --auth=ACCOUNT_AUTHENTICATION
                        Authentication type options (case-sensitive):
                        DATABASE_AUTH, OPERATING_SYSTEM_AUTH.
                        Default=DATABASE_AUTH
  -u USER               user name
  -p PASSWORD           password
  --dataloc=DATALOCATION
                        Path to the data (either a geodatabase or a directory
                        with shapefiles
  -D DATABASE           Database name (Not required for Oracle)

The full working sample script and code is available here

Hope this helps.

MelissaJarman

Regarding the .sdx SDEexport files - Below is an enhancement for an equivalent arcpy function or tool that will will be considered for a future release. If you contact support services with a good example of why these export files perform more optimally than other data transfer methods (XML workspace documents, etc) we can take a look at these cases and append them to these enhancements for justification. We will need to have a good working example (clear steps to reproduce) of how the SDEEXPORT files are more efficient other methods of data transfer.

NIM095122 - SDEEXPORT/SDEIMPORT: Create geoprocessing tools or arcpy functions for operations performed when using the 'sdeexport/sdeimport' commands.

JimFaulkner

It's true - no SDEGDBREPAIR tool. I am running 10.2.2 now and purposely chose NOT to install the command line utilities because ESRI is no longer supporting them. I am having an issue with intermittent rights / privileges and the first thing they told me to do was run the SDEGDBREPAIR tool.... I told them I did not install it, nor, was I going to install it. I hope they add the option in ArcCatalog!

Screen Shot 2021-06-26 at 7.13.19 AM.jpg

George_Thompson

Hi Jim,

We are supporting the SDE Command Line tools at 10.2.x. Starting at 10.3, the command line tools were not released. You can use the 10.2.2 command line tools and run the SDEGDBREPAIR, if needed, against your 10.2.2 geodatabase.

The SDEGDBREPAIR tools have been ported to a Geoprocessing Tool in ArcToolbox --> Data Management --> Geodatabase Administration toolbox.

Here is some more information on the ArcGIS 10.3 GP tools:

Diagnose Version Metadata

Diagnose Version Tables

Repair Version Metadata

Repair Version Tables

Hope this help....

-George

Screen Shot 2021-06-26 at 7.51.57 AM.jpg

JimFaulkner

thanks - great information to know

LukeBehling

Hello Rong,

Have you found away around this problem. It now appears that I cannot export from my spatial views since the OBJECTID field is seen as Long Integer? I've tried altering the view in SQL to no avail and am now stuck.