Wrong field receiving data

Discussion created by DDoughtie on Jun 25, 2014
Latest reply on Jun 25, 2014 by keywords

I am asking this question to see if anyone has experienced it.... not asking anyone to replicate it because I don't think it can be replicated. I suspect the solution might have some corruption. I can't post the solution because it's proprietary.


Here's the scenario. I have experienced this twice within the same table with different 2 different fields.


I have a field called "Card Address" I have a field called "Card Address_Enter". I have a script that looks at what was entered into "Card Address_Enter", copies the contents (uses "inserted calculated result" with the result being the "enter" field) and then inserts it into the "Card Address." I then have the "Card Address" set to hide when it contains data so the info is obscured. I also clear the "Enter" field after inserting. I do this with about 10 fields related to business info. All work perfectly except this one field. This portion of the script was copied from the ones that work so it's identical to the other steps that work.


When the script runs it inserts the results back into the "Enter" field and nothing shows up in the Address field. Next I tried capturing it with a variable and have it display the variable in a custom dialog to make sure I'm grabbing it. I then clear the Enter field. I then try inserting the variable into the "Card Address" field but once again it gets inserted into the "Card Address_Enter" field and nothing shows up in the "Card Address" field. I originally created the "Card Address_Enter" by duplicating the Card Address field and renaming it.


Troubleshooting I then deleted that field. Created a new one from scratch. Replaced it in the scripts and it worked once then the problem came back. It is as if the field labels and the internal field ID's are messed up. I then did away with the enter field and then when data is entered into the "Card Address" field (and the other 10 fields) it simply sets a status flag and I obscure the data based on the flag. That seemed to have solved the problem for that one.


So, I then used this new technique with another field. I had originally used the same "enter" approach. I created a status flag for "Tax ID Status". This script is independent of the first one because it is handled on a different tab layout. The script basically looks to see if the data has been entered into "Tax ID #" (I would never use a # in a field name but I have to live with what they used because another system expects it). If the field has data then it sets the status flag to 1. I then hide the field based on "1". Once again I used Insert Calculated Results with the value being 1.


I ran the script and the 1 got inserted into the "Tax ID #" field instead of the status field. It replaced the ID that was entered. Here's where it got really strange. I had the field off to the side when I was using the "Enter" approach. I moved the original "Tax ID #" field onto viewable page. I ran the script. The 1 shows up in the "Tax ID #" field on the data entry part of the layout but it did not showup on the original field that I placed at the top of the page for testing. I had others look to make sure I wasn't dreaming that the same field with the same name (field and table name) on the same layout.


I then removed all instances of the field on the layout and created all new layout objects. I then placed them where they needed to be and the script then worked like it was supposed to. So, either the fields had some screwy internal id's or the layout objects did.


This is such a basic script that everyone uses a million times a day I doubt anyone could replicate it with a new file. The history of the file is that it started as FMP 11. Moved to 12. The changes are being made in 13 for use on an iPad.


I'm just seeing if anyone else has seen this behavior. (I''ve seen other 12 to 13 issues where "Hide When Printing" objects created in 12 aren't honored in 13. That I can replicate).

Dan Doughtie

Augusta, GA