Skip to main content
  • EN
I've encountered a combination that seems to make FME engine crash when running the very simple translation.

 

 

My source is a SDE standalone table called T_GUY.  I created a simple translation to isolate the crashing problem i found in a more complicated translation.  I added an GEODATABASE_SDE reader and SDE30 reader that connects to the same T_GUY table and simply write the output to an Excel writer.  The translation runs just fine in this configureation.

 

 

Then I add a BulkAttributeRenamer between the SDE30 reader and Excel Writer, run the translation, and I get an APPCRASH of fme.exe when its "retrieving features from table T_GUY".  The BulkAttributeRenamer is configured to rename all attributes to UPPERCASE.

 

 

Adding the BulkAttributeRenamer with the same UPPERCASE functionality between the GEODATABASE_SDE reader and Excel writer does NOT cause fme.exe to crash.

 

 

Has anyone encountered this before?

 

 

Why would this happen with SDE30 reader?

 

 

I would prefer to use the SDE30 reader because my T_GUY table has NO geometry.

 

 

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

 

 

Sarah
Hi,

 

 

that is indeed strange. What happens if you insert a Cloner (it does nothing unless you change its default value) between the input features and the BulkAttributeRenamer?

 

 

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

 

 

Contact tech support you think?

 

 

Sarah
Yeah, sounds like a case for Safe...

 

 

David
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.
Thanks for responding Mark. 

 

 

I have reported this question to tech support and awaiting their first response.

 

 

In the meantime, i'll add a FeatureHolder transformer like you suggested and see what happens.

 

 

I did add a BulkAttributeRenamer later on in the translation and it worked just fine.

 

 

I'll post back with my results of adding the FeatureHolder.

 

 

Sarah
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
Sorry I see that picture is way too small to see...

 

trying again...

 

 

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
Ha, heres a funny one...

 

 

I decided to add an AttributeKeeper after the FeatureHolder but before the BulkAttributeRenamer and just select attributes one by one until the crash happens. 

 

 

I have a couple of date fields, DateModified & DateCreated. Everytime I selected these attributes to keep, FME crashed at the BulkAttributeRenamer (or that's when it seems to crash).  If I did not keep those, then the translation worked fine. 

 

 

My ArcSDE database is on SQL Server and the data type on those fields is "datetime".

 

 

Weird.  I asked this question in another post and have submitted a case to tech support about FME's handling of dates in 2013...but it seems like this particular DateTime datatype is giving FME problems...

 

 

Sarah

 

 

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

 

Mark, Got an idea when SP2 will be released / finalized?  I'm working on converting my translations to FME 2013 now and I would rather have SP2 installed before I go to production.

 

 

Sarah

Reply


Community Stats

30,157
Posts
114,473
Replies
37,802
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.