Import from GeoDB in Oracle 11g fails (ERROR 000372)

821
8
Jump to solution
11-25-2013 11:16 PM
AxelMöhring
New Contributor II
Hello,

I'm trying to import feature classes from a GeoDB (file GeoDB from an ArcGIS 9.3 System) in Oracle 11g (11.2.0.3).
For the import itself I'm using a python script which uses the "FeatureClassToFeatureClass_conversion" from "arcgisscripting" to copy my feature classes from my
GeoDB as source to my database connector as target (I'm using direct DB connection, no SDE-Service).
I already used that script with ArcGIs 9.3 and the import was successful.
Now with ArcGIS 10.1 I got ERROR 000372 at most feature classes when trying to import them.

I only have a EDN Licence with base function in ArcEditor, so I can't use most of tools in ArcEditor
and have to build my own python scripts and run them on my ArcGIS Server (With Advanced Licence).

Steps I have done:

1.) Upgraded GeoDB from 9.3 to 10.1 via System-Toolbox in ArcEditor
2.) Created Spatial Type in Oracle DB with a script from:
http://resources.arcgis.com/de/help/main/10.1/index.html#//019v0000000z000000
3.) Setup Enterprise GeoDB in Oracle DB with a script from:
http://resources.arcgis.com/de/help/main/10.1/index.html#//001700000162000000
4.) Successfully tested ST_GEOMETRY installation with "select ST_AsText(ST_Geometry('POINT (10 10)', 0)) from dual;" as SDE user
5.) Created user to import GeoDB into
6.) Successfully tested connection from Oracle clients on GIS-Server and GIS-Client
7.) Executed my python script to import features classes into my Oracle DB and got ERROR 000372 at most feature classes

What I have already tried:

* Recalculate default grid index via System-Toolbox with environment set to gridsize 1: 70k, gridsize 2: 210k, gridsize 3: 630k
(I read in the help that gridsize 2, should be gridsize 1 multiply with 3 and gridsize 3 is gridsize 2 multiply with 3)
* Verified that no feature classes with duplicate name are already in my Oracle DB (I read that this could also trigger ERROR 000372)
* Verified that there is enough TABLESPACE Size left for import
* Re-Created index in GeoDB
* Deleted index in GeoDB (with the idea to re-create it after import in Oracle DB)
* Created new file GeoDB, imported data from the GeoDB to import and tried to import the new GeoDB.

Thanks for reading and i hope you can help me
0 Kudos
1 Solution

Accepted Solutions
AxelMöhring
New Contributor II
Hello,

finally i found the reason, why the feature classes were not be able to import.

In 9.3 I imported all feature classes with default config keyword for geometry storage (ST_GEOMETRY).

... arcpy.FeatureClassToFeatureClass_conversion (input_ws + "\\" + fc, output_ws, fc_name) ...


But now in 10.1 (after update my GeoDB from 9.3 to 10.1) I was no longer be able to import feature classes of type POINT and LINE with the default config keyword (Which is set in ArcGIS 9.3 and 10.1 to ST_GEOMETRY). Setting the config keyword to SDO_GEOMETRY makes the import possible for me:

... # Set config keyword to SDO_GEOMETRY for feature class with type LINE or POINT arcpy.FeatureClassToFeatureClass_conversion (input_ws + "\\" + fc, output_ws, fc_name, "","", "SDO_GEOMETRY") ...


Thanks for helping vince, this thread can be marked as answered;)

View solution in original post

0 Kudos
8 Replies
VinceAngelo
Esri Esteemed Contributor
I don't know what else might be going wrong, but in eighteen years of ArcSDE administration,
I have only once seen a layer that needed three levels of indexing (and its performance
was so awful we removed the features that forced the third level of indexing).  You should
NOT ever add spatial indexes at the minimum interval unless the data really is distributed
so that 1+ million rows are exactly three times as large as the other 1+ million rows.

The easiest way to eliminate spatial index size from possible error status is to choose ONE
index level that is at least 1/2 as large as the gap between the coordref origin and the
center of the data envelope (e.g., with decimal degrees and a -400,400 origin, choose
a grid size of 400 -- that is, {400,0,0}).  Then you can move on to the storage in the SDE
tablespace and whatever other errors which may be appearing in your database logs.

- V
0 Kudos
AxelMöhring
New Contributor II
I don't know what else might be going wrong, but in eighteen years of ArcSDE administration,
I have only once seen a layer that needed three levels of indexing (and its performance
was so awful we removed the features that forced the third level of indexing).  You should
NOT ever add spatial indexes at the minimum interval unless the data really is distributed
so that 1+ million rows are exactly three times as large as the other 1+ million rows.

The easiest way to eliminate spatial index size from possible error status is to choose ONE
index level that is at least 1/2 as large as the gap between the coordref origin and the
center of the data envelope (e.g., with decimal degrees and a -400,400 origin, choose
a grid size of 400 -- that is, {400,0,0}).  Then you can move on to the storage in the SDE
tablespace and whatever other errors which may be appearing in your database logs.

- V


I'm new to maps and not sure what you mean with coordref origin (I think x and y, but there is x min/max and y min/max). Could you take a look on the following screenshots please and tell me which value is the right one to calculate grid size from:

[ATTACH=CONFIG]29357[/ATTACH] [ATTACH=CONFIG]29358[/ATTACH]

Thanks for the help.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
ArcGIS refers to it as the Domain (second graphic), though only the lower-left corner
and scale are set.

You'll probably want to read the coordinate reference white paper before you do anything
more with ArcGIS, since any of your three grid sizes (70k,210k,630k) is completely
inappropriate for Geographic Coordinate System (GCS) data, whose extent is usually
within {-180,-90,+180,+90} degrees [minx,miny,maxx,maxy].

- V
0 Kudos
AxelMöhring
New Contributor II
Hello,

First of all thanks for your help. I read the white paper and it helps me for a better understanding. But what I don't understand is that in ArcGIS 9.3 I was able to import this feature class (the one from where I took the screenshots) and in ArcGIS 10.1 I can't import it.

After reading the whitepaper I re-tried to fix my feature class. I changed it's coords into valid numbers according to what you have written about valid numbers for latitude and longitude. After that I re-calculated the default grid size with the values you gave me. But in the end I still can't import my feature class without getting same error.

Maybe my workflow to fix the feature class is wrong.

Thanks in advance for further help.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
The default geometry storage type changed between 9.3 and 10.1, which is probably
related to your issue.  Can you contact Tech Support?  I think they may be able to
help you through this faster than I can.

Once you get the layer loaded, you'll want to rebuild the spatial index to be efficient
for spatial queries.

- V
0 Kudos
AxelMöhring
New Contributor II
Hello Vince,

I only have EDN Licence without technical support. I'd be glad to get more help from you.

The default geometry storage type changed between 9.3 and 10.1, which is probably
related to your issue


Do you mean the configuration keywords in Table DBTUNE inside sde user?
There is an entry-> KEYWORD: DEFAULTS | PARAMETER_NAME: GEOMETRY_STORAGE | CONFIG_STRING: ST_GEOMETRY

Yesterday I took a closer look on my feature classes and their properties in ArcCatalog.
My idea was to find common settings/properties of feature classes I'm trying to import.
Its interesting, I have 2 feature classes, same type, same properties, different fields (but no other datatypes in fields) and I can import the first, but not the second.
Both have Geometry data. So I think there must something else be wrong (maybe values inside are wrong), or ArcCatalog doesn't display all properties.

Is there a way to validate data inside map layers?
I opened the .MXD-File (linked with the GDB I'm trying to import) in ArcMap.
There is a function "Analyse map..." (I think thats the correct translation from german into english) under the file menu.
After running the function I get 2 reports with level low (Code 30003 layer is displayed in all scales), no warnings and no errors.
The map itself and all layers are displayed fine.

Thanks in advance and have a nice day
0 Kudos
AxelMöhring
New Contributor II
Hello,

finally i found the reason, why the feature classes were not be able to import.

In 9.3 I imported all feature classes with default config keyword for geometry storage (ST_GEOMETRY).

... arcpy.FeatureClassToFeatureClass_conversion (input_ws + "\\" + fc, output_ws, fc_name) ...


But now in 10.1 (after update my GeoDB from 9.3 to 10.1) I was no longer be able to import feature classes of type POINT and LINE with the default config keyword (Which is set in ArcGIS 9.3 and 10.1 to ST_GEOMETRY). Setting the config keyword to SDO_GEOMETRY makes the import possible for me:

... # Set config keyword to SDO_GEOMETRY for feature class with type LINE or POINT arcpy.FeatureClassToFeatureClass_conversion (input_ws + "\\" + fc, output_ws, fc_name, "","", "SDO_GEOMETRY") ...


Thanks for helping vince, this thread can be marked as answered;)
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It seems like something else is wrong if you can't create ST_GEOMETRY layers.

- V
0 Kudos