BulkAttributeRenamer and ESRI ArcSDE Reader = CRASH

If I change the BulkAttributeRenamer to add a string prefix...the translation does not crash...so seems to be just changing to UPPERCASE...

 

 

Sarah

David, I added a cloner between the SDE30 source and BulkAttributeRenamer and ran it... still crashed.

 

 

Contact tech support you think?

 

 

Sarah

Hi Sarah

 

I get an APPCRASH of fme.exe when its "retrieving features from table T_GUY".... Why would this happen with SDE30 reader?

 

 

To be honest, I doubt it is happening with the reader. Although the log might say that it is retrieving features, it can be sometimes a little misleading.

 

 

Every time FME reads a feature it will pass it on to the BulkAttributeRenamer immediately for processing. So the transformer is processing data before the reader has finished. It's more efficient, but it does cause logging confusion.

 

 

I think we could prove this by adding a FeatureHolder transformer between the reader and the transformer. In that case I would expect all features to be read, and then the translation to fail.

 

 

So, what I would do is try and figure out which feature causes the crash. Is it the first, or a random feature, or all of them? If you don't have that many features you could use Feature Inspection mode to determine which causes the crash.

 

 

But even if you do isolate a bad feature, and workaround the problem, we'd still like to know about it at Safe. We'd want to fix any crash like this so no-one else is affected.

 

 

Hope this helps

 

 

Regards

 

 

Mark

 

 

Mark Ireland

 

Product Evangelist

 

Safe Software Inc.

I added the FeatureHolder between the SDE30 reader and the BulkAttributeRenamer, and yes it seems to read all the attributes just fine before it crashes...

 

 

I added an inspection point between the FeatureHolder and BulkAttributeRenamer and ran the translation with inspection.  I see the first feature, then step to the next connection, and then APPCRASH occurs on fme.exe.

 

 

Here is a picture of the first feature.

 

 

 

Unless others have ideas, I'll wait for tech support to contact me.

 

 

Thanks, Sarah

OK, looks like the first feature to hit it causes the crash. Sounds like we'll have to get a developer to run this and trace the exact cause.

 

 

To submit a case can you write the data to FFS first? For example add a Recorder transformer before the FeatureHolder. That way you can submit the FFS to us and we can rerun the workspace here.

 

 

Thanks

 

 

Mark

Hi Sarah,

 

I see this is fixed in FME2014 and think it's also been backported to FME2013 too (so should be in 2013-SP2). The problem turned out to be the BulkAttributeRenamer getting itself into an infinite loop somehow. Anyway, glad to see we were able to fix the problem

 

 

Mark