FM14: Odd script trigger bug

[normanicus]

The client has wanted to move from FM13 to FM14 for a while. What was stopping us was a strange data entry problem where the Retail Price field had a script trigger attached. This set another field to the VAT (sales tax) included price. There were a number of other price fields, each with a script trigger to adjust the other prices. All but the one on the Retail Price field worked. The script activated but it would get set back to the same value.

Anyway, he bit the bullet and moved to 14. I had to find the problem and, in exasperation was about to redo the whole bunch of scripts on those script triggers. Then I noticed that the problem field was calling the wrong script. It was one below the correct one in the script list. Bad luck had it that that script set the Retail Price form the VAT included field. Hence it kept bouncing back to the same value.

So, I open the solution with FM13 and the right script is called. I open it with FM14 and it is the wrong one. I have now changed it. I wonder what will happen if I open the 14 version in 13?

Had this behaviour already been noted? If not should Filemaker Inc be informed?

[LaRetta]

Hi, 

I haven't heard of any bug which might cause this issue.  It sound more like it might be corruption ( and I don't make that suggestion lightly ).  What happens if you copy everything in that script, delete it, paste the steps again and reattach it to the field?  It might be that there was corruption and, since FM assigns an internal ID to all objects, and that internal ID was broken, it selected the next available script.  Odd yes.

Are you using FileMaker Server and if so, what version and has the latest updater been applied?  Otherwise all I could suggest is that you attach a zipped, empty clone of the file for review.  It never hurts to report it to FileMaker and get their input on it as well.  

Sorry I couldn't offer more assistance.

[normanicus]

Yes, it could be file corruption. If that was the case it is interesting to wonder how FM14 would have showed this up when FM13 did not. Am I right in assuming that the upgrade does not involve any file conversion?

Happily, once I had got the script trigger running the correct script, the problem disappeared. There has been another odd issue but it does not appear to be due to the same type of error.

I did reopen the database with the corrected script trigger in FM13 and it behaved correctly. Then reopened it in FM14 and there was not a problem.

An issue that might have contributed to the problem is that somehow numerous copies of seemingly every script have appeared in the file. I don't know how this happened. Any ideas?

Thanks for the reply.

[LaRetta]

7 hours ago, normanicus said:

Yes, it could be file corruption. If that was the case it is interesting to wonder how FM14 would have showed this up when FM13 did not. Am I right in assuming that the upgrade does not involve any file conversion?

You are correct that no file conversion takes place but there are still internal changes between 13 and 14.  FMI has also improved Recover as it moves up in versions but when it comes to corruption, any strange behavior is possible as a result.   Have you made sure you are on latest Updaters for both client and server?  

7 hours ago, normanicus said:

An issue that might have contributed to the problem is that somehow numerous copies of seemingly every script have appeared in the file. I don't know how this happened. Any ideas?

This too sounds like *corruption if you are sure you are on latest FM versions.  I would consider your file very suspect and if possible, it would be wise to revert to a pristine backup copy of the file prior to these script issues appearing (importing your data into the copy) AND I would strongly pursue reasons for the corruption.  Be sure you are served properly (not on shared volume, auto restart should be off etc) and establish a solid disaster recovery process to import into new pristine clone.  Files should be treated like pure gold.  If corruption happens in them, there is nothing that can fix them.

* My assumption of corruption is based upon lack of reports of all scripts duplicating themselves but that does not mean it can't be a bug.  El Capitan with FM 14.0v4 has been out long enough that if others experienced scripts duplicating themselves, we would have heard about it by now.  However, It also never hurts to report this to FileMaker because if everyone assumes it is corruption and nobody reports an issue then ... well, you know the consequences of silence.

[comment]

1 hour ago, LaRetta said:

you know the consequences of silence.

Acquittal?

[LaRetta]

 

All it takes is silence for broken things to remain broken.

[normanicus]

Does the silence quote refer to me?

The multiple script duplication took place in FM13, not FM14. As the client is quite knowledgeable and, if the remote connection is painfully slow, sometimes does updates. For this reason I had thought that he may have done some manipulation that lead to all these duplicates.

If it were to be due to a damaged file then I suppose that this would take place at the automatic recovery stage on restarting the solution. I did not check the log files at the time and they will have long since disappeared. I seem to have been remiss in not checking this stuff. However, seems to me that the recovery process should be a bit more 'in the face' about reporting any changes made.

Can I be confident that 'Save as clone' and importing records gives a clean file?

[Wim Decorte]

10 minutes ago, normanicus said:

Can I be confident that 'Save as clone' and importing records gives a clean file?

No, unfortunately not.   Corruption comes in many flavors so the real trick is to find out what exactly got corrupted.

What does the recovery log say when you recover an older backup of the file?  Or even the current version?

[normanicus]

Thanks for the prompt reply. Once the client is active I'll check those things and report back.

[LaRetta]

1 hour ago, normanicus said:

Does the silence quote refer to me?

No, just that if everyone thinks a strange behavior is corruption in their file and nobody reports it, then it can self-perpetuate the misconception that a bug does not exist because nobody has heard of it.  Everyone thinks someone else has reported it so it never gets reported.   Similarly, not every odd behavior is a bug; most times, it is something amiss in the file which can be corrected (developer error) and only rarely is it corruption.

1 hour ago, normanicus said:

As the client is quite knowledgeable and, if the remote connection is painfully slow, sometimes does updates. For this reason I had thought that he may have done some manipulation that lead to all these duplicates.

This person has design privileges?  It is possible they selected all scripts and hit 'duplicate script', I suppose, but they could not have caused the first issue of different script firing in 14 but working in 13.