Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I'm receiving an error writing geometry (in ArcObjects) that has a large number of vertices (around 900). So big, but not ridiculously big. I would expect this to be no problem and I don't recall this issue in SQL Server or PostGreSQL. The geometry storage is ST_GEOMETRY.

The error is:
ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column

..and it appears to be related to the number of vertices that the polyline has on it. Lots of vertices: I get the above-mentioned error. Less vertices: no problems.

As a test, I generalized the geometry down to two points: success.

I've started to work my way up and gotten up to 120 vertices with success. Is there a better way to determine that limit? Is there a way to increase the number of vertices that I can have on a line? Is there a DBTUNE parameter that manages this? I've googled the actual ORA error, but I'm uncertain as to how to apply this to an ArcSDE repository.

A couple of notes:

  1. I don't own or administer the ArcSDE repository and can't modify it.
  2. Breaking the long polyline feature into several smaller ones is not an option (for this project).
  3. Write using feature.Shape = geometry; feature.Store();
  4. Code executes as expected for most of the features--I have 2 that have high number of points that cause the ORA error.

Oracle version:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

share|improve this question
2  
Based on this answer at stackoverflow, I would try creating a new featureclass with the same fields as your current featureclass, but make the shape field the last field, and see if you get the same error. –  Kirk Kuykendall Dec 19 '11 at 2:07
    
Yes, I created a new featureclass in my schema and I am able to successfully store! Then add a new field at the end and get the error again. I also tested with sde binary which worked with no problems. –  Jay Cummins Dec 19 '11 at 3:00
    
Hmm, that's a bit disturbing. Last I checked you can only add fields to the end of the field list and you cannot have two shapefields in a featureclass. That sure creates some maintenance headaches. Have you reported this as a bug to Esri? I'm starting work on a project that uses Oracle, would like to know if there's an easier workaround. –  Kirk Kuykendall Dec 19 '11 at 17:06
    
I just reported it to Esri, but I think this is an Oracle bug? Based on what I'm reading, other software systems are affected this not just Esri. Maybe Esri has other options for the ST_GEOMETRY data type (I'm pretty sure the ST_GEOMETRY Point BLOB is the issue here). –  Jay Cummins Dec 20 '11 at 14:18
    
I recall an enhance request a long time ago to allow fields to be added at an arbitrary position in a table (not just at the end). I don't think it was ever implemented. The priority of the enhance request might be escalated if it is the only workaround for the bug you report. –  Kirk Kuykendall Dec 20 '11 at 14:52
show 1 more comment

2 Answers 2

Try casting the geometry to ITopologicalOperator2, set IsKnownSimple to false, then call Simplify.

share|improve this answer
    
That has no affect, still get the error. Kirk's comment/link pretty much explains it. –  Jay Cummins Dec 19 '11 at 3:04
add comment

I am not familiar with Arcobjects and Oracle, but from the error message it looks like that sde is probably trying to create the shape incorrectly (bind variables) see http://ora-24816.ora-code.com/ You say the storage type is ST_GEOMETRY- does this means that you are trying to send it as WKT? If so, can you not try it as a native SDO_GEOMETRY object? Is this an option in Arcobjects? Maybe posting part of the code would help

share|improve this answer
    
the ST_GEOMETRY is the geometry storage type, you don't change anything on AO side. It's still a feature.Shape = geometry; feature.Store();. I am not working with any WKT. And this works for thousands of other features--just a couple of these big geometries are falling out due to the ORA error. –  Jay Cummins Dec 18 '11 at 20:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.