Skip to main content

I keep getting this error when trying to write out large amounts of data from a workbench to the Default version of a versioned feature class in a SDE:

|Error while retrieving an ArcObjects update cursor for the table/feature class 'ILMOCDBO.gtlf_ln'. The error number from ArcObjects is: '-2147216072'. The error message from ArcObjects is: {Underlying DBMS error [[Microsoft][SQL Server Native Client 11.0][SQL Server]The app domain with specified version id (11) was unloaded due to memory pressure and could not be found.] [ilmoccmp.ILMOCDBO.gtlf_ln]}



From what I've learned, that error means that the SDE ran out of RAM on the server that it is installed on. This happens because when FME is writing out the data, it is being written to a view in the SQL and the view lives on RAM while this happens. The error occurs when trying to write out large amounts of data, but can vary depending on the size of the data being written out and the amount of free memory.


What I am looking for is a way to commit the view that is being written to in smaller intervals so the RAM doesn't fill up.

Unversioning the data would be one solution to this, but the output SDE is used in replication with this data. I have considered creating a workbench that would do the work of the replication, but would like to stick to the ESRI processes.

Another option I thought was to have an arbitrary number of outputs allowed with a filter, and keep running the workbench until all edits have been found. This workbench can take 3-5 hours a time to run, so that might be time consuming. Currently failing is time consuming and doesn't work, so at least that would work.

I considered trying to write my own SQL SDE Writer, but that was challenging with the data versioned and applying the changes to the correct A/D table, and associated geometry.I tried using the feature writer instead of the normal output writer and had the same error.

 




Any other ideas or solutions would be appreciated.

Hi @brooks, have you tried playing around with the "Features Per Transaction" parameter in the Navigator? By default, it's set to 1000.


Hi @brooks, have you tried playing around with the "Features Per Transaction" parameter in the Navigator? By default, it's set to 1000.

Hi Tia,

 

Yes, I have had it as high as 100,000 and as low as 500. Either way it seems to be writing to the view in that chunk size and the view is where the memory overload is happening.

 

 

 


Reply