0

I'm trying to find a way to access a feature class in an Oracle database through arcpy scripting, without having to be prompted to enter a user name and password after the script has started running. It seems like arcpy.management.CreateDatabaseConnectionString can be a good way to do this. I'm testing it by establishing a connection that way, and then running Feature Class to Feature Class to make sure I can successfully access the data. The problem is, this works with one feature class, but doesn't work with a different feature class in the same database. I would like for it to work consistently. Here is the Python code I'm using:

import arcpy
import os

# get current user name
username = os.getenv('username')
userpw = "********"

# database connection string - for accessing a specific feature class
databasefc = arcpy.management.CreateDatabaseConnectionString("ORACLE", "DATABASE_NAME", "DATABASE_AUTH", username, userpw, "", "FC_NAME")

# Feature Class to Feature Class - for testing connection to FC established above
outpath =       "C:/Projects/ExampleGDB.gdb"
outname =       "TESTING_OUTPUT"
arcpy.conversion.FeatureClassToFeatureClass(databasefc,outpath,outname)

Is there a reason why this would work with some feature classes but not others?

When I say it doesn't work, it does produce an output, but the output is an empty feature class (it should be a direct copy of the input feature class).

The only differences in the properties of the two FCs are: The FC that did not work is a line FC, while the one that worked is a point FC (not sure why this would matter); and the line FC that did not work has the properties "COGO Enabled: No" and "Split Model: Update/Insert" while the point FC that worked does not have these properties.

I have ArcGIS Pro 3.3.1 installed. I'm running this script in VS Code. I have the python interpreter set to use Python 3.11.8 64-bit (from the ArcGIS Pro installation). I'm using Windows 10 Enterprise 64-bit.

6
  • 1
    Are all the feature classes registered with the geodatabase? If you use native SDO_Geometry and Query Layers, sometimes the FC2FC won't work. More information about the differences between working and non-working tables may be necessary. Geometry storage, field types, feature dataset participation,...
    – Vince
    Commented Aug 16 at 19:21
  • I compared properties of the two feature classes. The only differences I can see are: The FC that did not work is a Line FC, while the one that worked is a Point FC (not sure why this would matter); and the one that did not work has the properties "COGO Enabled: No" and "Split Model: Update/Insert" while the one that worked does not have these properties. Commented Aug 19 at 19:00
  • Please Edit the Question in response to requests for clarification
    – Vince
    Commented Aug 19 at 19:14
  • The database has multiple feature classes with the same name but different schema "prefixes". The FC names look like "DSGN.ENG_TRACK" and "ENG.ENG_TRACK" - when the tool is run, it accesses the wrong ENG_TRACK. I tried entering "ENG.ENG_TRACK" as the instance parameter and tried entering "ENG" as the schema parameter. Still, we cannot figure out how to make this tool access the correct feature class. Commented Aug 22 at 14:18
  • The solution I've arrived at is a different approach: I set up the script to run as a custom script tool within ArcGIS Pro, and I made the workspace a parameter for the tool, so the user can enter a saved .sde database connection as input in the tool interface. When they do so, they will be prompted to enter user name and password for that database if they haven't already. Then the tool runs. Within the script that the tool is referencing, feature classes from within the workspace will be accessed as input for arcpy tools. It seems to work. Commented Aug 22 at 14:20

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.