AnsweredAssumed Answered

Data loss bug : Spontaneous and erroneous import matching of new fields in specified imports !

Question asked by Vincent_L on Aug 30, 2009
Latest reply on Apr 27, 2010 by Cable2001

Summary

Data loss bug : Spontaneous and erroneous import matching of new fields in specified imports !

Description of the issue

Hi I've reported this more than one year ago (15 april 2008) to FileMaker Italia Reply [Case ID #: 907402], that was escalated to the US : "Regarding the technical case open the US team told me that the issue is still under investigation but unfortunately we don't have any update at the moment."  I gave a sample file demonstrating teh problem and even made a video about it (too bad we can't put attachment in here) Waht's the bug is about ? everytime I'm adding a field in my database, I've to recheck every specified import whose target is this table, to uncheck the matching that FMP automatically and erroneously created itself to that new field. Yes you heard it right, filemaker will automatically add a field import in saved imporrts ! As I've just spend two hours once again, to tediously fix FMP mistakes, I decided to repost it.    --- Original Message ---Hi,I think I've discovered a bug that destroyed a lot of user inputted data inmy solution for several times.New created fields have their data replaced by scripted specified XML/XSLTUpdate matching records imports that were created before the new fields. Asif someone would add the new fields as targets by hand.So every time I add a new field in my solution, I have to change all myscripted specified XML/XSLT Update matching records imports to remove thenew fields that Filemaker has, by itself, set as targets !!!The scenario is this one.I've a product catalog where user input new products, their sku, theirdescription etc.Every morning the inventory is imported via a scheduled XML with XSLT importthat gets the skus and their inventory count, as well as some otherinformation.I edited my solution to put a new field that user needs to input, like"complementary information" for instance.The users filled that extra field for all day.The next morning they complained because all the data they've inputted wasgone, replaced by some other values.So I looked at the import script steps (specified) and noticed thatFilemaker added by itselfBefore my import wasSKU = SKUQty -> Invetory countD1 - Product nameD2 - I've added in database definition a new field called "new complementaryinformation" and then Filemaker changed my import script steps toSKU = SKUQty -> Invetory countD1 - Product nameD2 -> new complementary informationI've more complex solution where it is like that :SKU = SKUQty -> Invetory countD1 - Product nameD2 - info 1- info 2- info 3-> new complementary informationSo Filemaker decided by itself to put the data of D2 in my new field, ofcourse overwriting all the data that was inputted !I tried to reproduce the bug and wasn't able to reproduce it withtab-tab-return imput file, nor from Filemaker file, nor from XML withoutXSLT as the inputI guess this only occurs with XSLT, and specifically the msdso_attrib.xsltexample xslt Filemaker ships with as an example.To help you figure out the problem, I've made a movie using the "XMLExamples" folders that is installed with Filemaker advancedThis is very serious and I've no workaround I need to use this XML/XSLTimport 

Outcomes