[fdo-users] Re:

[Jackie Ng]

The .net garbage collector is your #1 enemy (huh?). 

Depending on how you have coded with the FDO API, the GC may prematurely
reclaim certain FDO objects, resulting in null pointers on the unmanaged
side, and before you know it: BOOM! System.AccessViolationException out of
nowhere

Avoid compound statements like X.Y.Z() if you want to call Z() on Y, have a
temp variable of Y

eg. Instead of this:

insertCmd.PropertyValues.Add(oPropertyValue) 

Do this:

Dim props as PropertyValueCollection = insertCmd.PropertyValues
props.Add(oPropertyValue)

Secondly, only fill the PropertyValueCollection of your insert command once,
and tweak the values for each insertion. See example here:

http://code.google.com/p/fdotoolbox/source/browse/trunk/FdoToolbox.Core/ETL/Operations/FdoOutputOperation.cs#301

I've put all the PropertyValues to be inserted into a dictionary, and for
each feature I want to insert, I set all PropertyValues to null and then
assign the appropriate values from the feature to be inserted.

Another thing to improve stability is to (ironically) avoid using as much of
the FDO API as possible. 

>From that same example, I don't interact with the PropertyValueCollection of
the insert command. I only interact with it to fill it with the
PropertyValue objects to be inserted. 

I put these same PropertyValue objects in a *managed* dictionary, and
interact with that instead when I need to set feature property values for
insertion.

Having to resort to such tactics does expose some of the flakiness of the
current .net wrapper. But at the end of the day, knowing these little quirks
and how to avoid them makes the FDO development experience much more
comfortable.

- Jackie

 


-- 
View this message in context: http://osgeo-org.1803224.n2.nabble.com/Attemp-to-read-write-to-protected-memory-exception-when-reusing-fdo-command-tp5766778p5768677.html
Sent from the FDO Users mailing list archive at Nabble.com.