Issue in Importing shape file data into into Oracle geodatabase using sde connection

[umasuryasykam1]

Hello all,

We are using arcsde connect string to insert data from shape files into Oracle geodatabase using direct connection strings.

Everything seemed well with test data. When full data set was used to import into oracle, after inserting few thousand records application/script silently dies without throwing any error. It only happens in that environment using sde connections.

Could someone help in this scenario. It is very straight forward where we use feature cursors to read from shape files and insert data.

Regards,

Umasurya

https://community.esri.com/community/gis/managing-data?sr=search&searchId=67836751-85bf-4434-9361-c3...‌ https://community.esri.com/groups/geodatabase?sr=search&searchId=bc31c01f-baa5-40d5-aaa8-ca12052c18a...‌

[umasuryasykam1]

Ok. I will get back to you on the exact details on the s/w spec that we have at data center. Thank you for the suggestion.

[umasuryasykam1]

Please also consider that development goes for a while and we can't change versions as fast as ESRI could make releases every year. This has been working like this for a while locally and once it is being deployed in data center nothing works. We had to change so much code. Eventually this is where we are stuck. When I made the scripts to work,  files from 262 folders(shape files) were successfully getting imported and crashed. Now after testing for a while, it came down to 162 folders and then get crashed. We simply replicated same versions that are working locally in data center. I want to know if any tool you use at ESRI to understand silent crash with ESRI COM components.

[umasuryasykam1]

Hi Vince Angelo,

Version are shown below

Oracle spatial-> 11.2.0.4.0

ArcGIS Engine Runtime ->

Product Name: ArcGIS 10.1 Engine

Release Version: 10.1

Product Version: 10.1.1.3143

OS for ArcGIS :Windows 2008 server

DB: Linux

Please advise if any discrepancies based on above. It works fine in local physical envt.

[VinceAngelo]

ArcGIS 10.1 was released June 11, 2012.  The SP1 service pack was issued October 2012, and the most recent patch to that service pack dates to July 2014. ArcGIS 10.1 will enter Retired support status in six weeks (Jan 2018).  Even if I were to accept the "Esri releases updates too fast" argument (this is the first time I've ever heard it), I'd have to question the wisdom of letting a development project lapse five years (and four, soon to be five, major releases) behind the current build. Staying three months behind is wise. Waiting for the x.y.1 release is prudent. Staying fifteen months behind is conservative (and somewhat tricky, since some products start to lose support status at eighteen months). Falling sixty months behind is risky from OS compatibility, database compatibility, and system security standpoints (any of which could cause the errors you're encountering).

The usual route to address "memory leak"-like behavior is to apply all patches and try again.  If the tool works for over a hundred datasets at a time, then organizing batch processing to limit execution to one hundred folders at a time is your path of least resistance.

- V

[umasuryasykam1]

Hi Vince, Thank you for the advice to get newer versions. Hope APIs are not written so that they get timed out after 5 years time. I am only trying to check what causes a silent death for ESRI com components that skips all of its execution including exceptions, event viewer, finally etc and leave the scene. If there is a way to find it, I can work accordingly. By the way license I got works with 10.3  versions as well.

[VinceAngelo]

I'm not convinced that the application failure is even ArcObjects-related. This could be a COM failure itself (ancient components are written against ancient libraries, after all). There is no way, short of submitting your code for review, to tell what might be wrong.  If you can generate a short code sample which generates the same error using ArcObjects 10.3.1, you can submit it, along with a detailed description of the inputs (type, feature count, and mean vertex count), to Tech Support. There really isn't any way for the good folk of GeoNet to help you, given the information provided.

- V

[umasuryasykam1]

Thank you, Vince. Sure I will check on the version change. Btw, do you see any concern using VMs for ArcGIS softwares? That's the only difference other than location being different. We replicated all the softwares including OS and upgraded processor and RAM to very high end. Concern is that it won't throw any error before leaving the execution.

[VinceAngelo]

I have no concern whatsoever about VM use with ArcGIS 10.2.2 or higher (since I've used that extensively).

Given that it's extremely easy to write memory leaks with ArcObjects, my concern is with your code.

- V

[umasuryasykam1]

Sure Vince. I am upgrading in couple of days for testing. Over the other local physical machines( with less processing power), using simple feature cursors it runs forever. In VMs at a data center consistently after few datasets(2MB on average per dataset) it dies after about 160 consistently(When it was started it used to be 260). It should throw some exception no matter how bad(assumption) my coding may be..

[umasuryasykam1]

Hello Vince,

I got a chance to test the script again and it fails at below line after executing about 162*40 times.

It doesn't go into try block/finally block and silently kills the application after dbbFCursor.flush. Please advise if any inputs.

Console.WriteLine("Before cursor flush:" + srcLayerName);

try

{

dbbFCursor.Flush();

}

catch (COMException comEx)

{

Console.WriteLine("Error in flush::" + comEx.Message);

}

Regards,

Umasurya