Threw your calc on FMPA 14.0.2 on OS X 10.10.5
Curious to know if your calc is text result or number and also if there is any difference if you included:
GetAsNumber ( Sqrt ( 4 )) & ¶ & GetAsNumber ( Sqrt ( 9 )) & ¶ & GetAsNumber ( Sqrt ( 16 ))
my thinking is that normally a number does not have returns in them.
Text would be the preferred result, since you are including returns, however, this might be an issue for the Sqrt calc??
Don't really know what else to suggest...?
I have also tried this on Mac with FM 14.0.2 and get the correct result.
change your calc to "unstored" and try again
Yes, but then insert a new pdf and, poh, the result is crazy again. !
Well, I just tried it on my copy, but then discovered something interesting. When inserting large pdfs, I would get crash - I admit, I'm running on Mac OS 10.11, so I don't expect stability, however, when removing the Base64 calc off the layout (just dragging to the right off the edge of the layout) then the same pdf works and the calc is happy,
so, I suspect that you could be seeing a problem with the size of the pdf taking up too many resources to "decode" and display the result, thus causing problems with the calc displaying properly?
Strange, I have FMPA 14.02, Win 8, and made only two changes to your file:
Define Calculation as unstored (now gives 2¶3¶4)
Insert PDF (still shows 2¶3¶4) so, it works as it logically should
Define c as unstored, still gives the correct answer
Insert another PDF in Container, still gives the correct answer
I suppose the different results you're getting could be due to Win 7/Win 8 differences, or FMPA/FMP differences, but would be surprised by either one. Both PDFs I used were sub-Meg sizes, so maybe Peter's correct about pdf size being relevant?
Very interesting. all values are ^10 ed.
But same environment, I can't reproduce it, only existing result is crazy.
Duplicating the record return correct result.
I duplicated the record, I changed the calculation to a simple Sqrt ( number ), I emptied the container, I placed the calculated field with Base64Decode out of the layout....
Nevertheless the result is still wrong !
This is a Bug !
test.fmp12.zip 65.0 K
Updating tests: the error does not depends on the Base64Encode function, which can be removed. It is important that, in the layout, there is a container and that it contains a pdf.
As soon as the error occurs, the container may be emptied and nothing will change the wrong result, if not close and reopen Filemaker.
This file, duplicated record also show crazy value. But, entering number get only correct value.
It seems in first file, duplicated record is re-calculated with unknown reason. (And on my PC calculated result is always correct)