Serious Bug found in FMP13

[fed]

I upgraded to FMP13 recently, and most things work fine.  When I ran my billing renumeration, a severe issue arose.  I spent 2 hours narrowing it down to the following issue, which I presume is a bug in FMP13:  

 

Please see the attached file and use FMP13 Advanced Debuging

 

$text is set to the content of the field 'text'

$Excerpt is set to the field 'Text Excerpt', which is a calculation field based on the field 'text'

when $Excerpt is defined, $text changes!!!

 

I cannot figure out what is the issue.  This did not happen with FMP11.  If I shorten the length of the 'text' field, the error does not occur, so I guess it is a limitation of the string size itself.  Again, the size of the field string WAS NOT AN ISSUE WITH FMP11.

 

 

Please help.  This effect billing in my business.

 

I changed all text to "a" to protect confidentiality of my clients.

 

Thank you in advance,

 

Fed

 

PS  It seems I am "not permitted to upload this kind of file."  I don't understand why I cannot upload a FMP12 file.

Any ideas?

 

Thanks again,

 

Fed

[LaRetta]

You must zip a file before upload.  Please try again Fed :-)

[Lee Smith]

Follow these steps to attach a file. How to attach a file to a post.

[fed]

Thanks.

 

Here it is.  I've included a second record showing the size where things do not change.

TextError.fmp12.zip

[fed]

I submitted a report to FileMaker.

[LaRetta]

Well the script is simple:

 

Set Field [ Text Error::new text; "" ]

Set Variable [ $text; Value:Text Error::text ]
Set Variable [ $Excerpt; Value:Text Error::Text Excerpt ] 

Set Field [ Text Error::new text; $text ] 

 

Data Types

Text is text

Excerpt is number = Middle ( text ; 22 ; 8 ) 

New text is text

 

If I disable the third line ($Excerpt) then it works duplicating the contents of text into new text.  But if the third line is active, the result in new text is the value from $Excerpt which is only the numbers (since Excerpt is defined as a number).  It should be defined as text but still that would not explain this issue.

 

Additionally bizarre, if I make Excerpt unstored but leave the third line active, your script will work.  But neither $Excerpt nor Excerpt should matter at all in setting New Text ... it should end up with same value as text.  This obviously is new file so corruption is out.

 

It shouldn't be field size since FM13 can take 10,000,000 characters in text field.  It would be good also if you posted it here, since this is the official Report An Issue site http://forums.filemaker.com/hives/1eea103f05/summary

 

Very bizarre.

[Ocean West]

change the Excerpt field storage options to not be indexed it should be unstored. 

 

 

 

OR

 

remove the excerpt field from the fields and place that logic in the script

 

Middle ( $text ; 22 ; 8 )

 

and set that field as needed...

 

The issue here is that the calculation engine updated the $text value when it tired to evaluate the indexed value in the Excerpt - because its scope is still open & active, i suspect when tries to query the Excerpt field.

[fed]

I did submit it to the Filemaker site.

[fed]

I shouldn't need to change anything since the table, and script, I use in my billing database also involves many other calculations, each having this same devastating effect. I've tried workarounds, but there are so many problems, all based on this issue, that a workaround is not possible.

More important, THIS WAS NOT AN ISSUE WITH FMP11!!!

I sincerely feel this is a bug with FMP13 that needs correcting.

[fed]

I made a similar file in FMP11 to show that this error was not present in FMP11, but is in FMP13.

TextErrorFMP11.fp7.zip

[LaRetta]

I submitted a report to FileMaker.

 

But did you report it to that link I gave you?  I mention that link because it is where many people look to see if bugs are reported.  And many people keep up on reading it so they know what is happening and when they search Knowledge Base.   It also is the site where (currently) FM publicly responds to bug posts (usually).

 

And if the bug is serious, others can post on the thread in support.  It provides more visibility for an issue.

 

It may not be a bug in FMs mind but it is not what I would expect from the behaviour.  When I set a script variable, it should stay as it is (I think).  I know there have been some behaviour changes in refresh but that was mostly in 12 if I recall.

 

Anyway, good on you for speaking up and wanting to get to the bottom of identifying it.  This is the only way we can learn the behaviour to finer degree AND the only way FM will know when they need to fix something.  :-)

 

 

change the Excerpt field storage options to not be indexed it should be unstored. 

 

Really, unless you mean UNSTORING the calc only to fix this ONE issue, the field would not need to be unstored; in fact it shouldn't be.  I know you know this but I wanted to mention it so in case others might misunderstand (or I misunderstood, LOL) it would be more clear or less clear. 

 

EDITED:  Changed auto-type 'un stir' to UNSTORING.

Edited February 17, 2014 by LaRetta

[Wim Decorte]

As an aside (not related to the issue): try not to name fields for "data types" like "text", "number", "date".

It just complicates things and these are typically reserved keywords in all sorts of environments

[fed]

LaRetta, yes, I did submit it there.  I am the first one on the list currently.  Please support me there.  One person has already posted that they have reproduced the error independently.

http://forums.filemaker.com/posts/8b31a6cade?commentId=278463#278463

 

I can't see how "it may not be a bug in FMs mind," seeing as how it was not an issue in a previous version of FMP.  Then again, anything is possible.

 

 

 

Wim Decorte, you are correct.  I was concerned about confidentiality and haste when I made the TextError testing database rather than clarity, sorry.

[bruceR]

I also note that merely changing the order of variable declaration in the example file "fixes" the problem.

This does not seem like expected behavior, and also reminds us of the mystery of when FileMaker automatically assigns data types.

[Rick Whitelaw]

i don't see this entry in the Report an Issue forum.

[LaRetta]

I found it, Rick, it is here:

 

http://forums.filemaker.com/posts/8b31a6cade

[fed]

Someone in the Filemaker forum duplicated the error on windows too. Also, it doesn't seem to occur in FMP12

[fed]

Filemaker has responded:

 

Thank you for your post.

I am able to replicate the issue with FileMaker Pro 13.0v1 under Mac OS X 10.9.1 and Windows 7.

Assuming it was a length issue, I reduced the number of characters to 256K (262,144) and it worked.  I added one character (262,145) and it then failed.

I have forwarded your post to our Development and Testing departments for review.  I will keep you updated as information becomes available to me.

TSGal
FileMaker, Inc

[fed]

Here is a new File which shows that another script step can produce the error as well - setting a field to an arbitrary variable.

TextError.fmp12.zip

[Ocean West]

fed, I suspect this will be resolved in a future vRev.

[fed]

Apparently they have been aware of the issue since dec 4, 2013, and are unwilling to let me know the status of the fix.  I need a solution ASAP, as my billing is in jeopardy.

 

I thought an upgrade was supposed to make things better...

[fed]

Got a fix. Put the large variable in a global field and treat it like a variable. My script runs slower, but it works.

Thanks everyone!!

[LaRetta]

Apparently they have been aware of the issue since dec 4, 2013, and are unwilling to let me know the status of the fix.  

 

Now this is what gets me ... when did the first article appear warning people, FMI?

 

When they discover something like this, they should put out an immediate bulletin.  Maybe they did and I missed it but do not think so. There have been many bugs which were not reported by them ... this lack of communication HURTS US.

 

Now I'm angry.  This is the ONE THING they do that really upsets me ... their lack of putting out important information hurts us and our businesses and it simply is not right.

 

// END RANT

[fed]

Agreed. Simply, it is unprofessional.

[LaRetta]

In all fairness, FMI *has* improved a thousand percent in these past few years.  Slip-ups are bound to happen.  I too think they'll have it fixed in 13's first updater.

[fed]

I got my fix, so I'm happy. I was just worried because this is my billing...

Thanks again for your support!

[fed]

Correction - it is a LOT slower. I hope my computer doesn't crash...

[fed]

Posted on the FMP forum regarding this issue:

"

This has been fixed in FileMaker Pro 13.0v2. You can download the update through Knowledge Base Article #13313:

http://help.filemaker.com/app/answers/detail/a_id/13313/

"

Unfortunately, I don't find the fix in the link. I'll give it a try.

Fed