"A lot of text" means a hundred characters? thousand? Maybe test with copy paste 100, 200, 300 to find a failure point?
It does not happen when opened locally? It is a Text field? No calculations or scripts attached to it?
An important point I forgot to mention: The field is within a portal.
Yes, it is a text field with no calculations, and in both cases, there were only couple hundred characters.There is a script that would send the content of the field in an email that's activated by a button.
It is difficult to test because the problem does not occur consistently. So far, we've entered about 50 records, and it only occurred twice. I'll enlist more people to help me test it out today.
The problem only occurs when using WebDirect so far. It hasn't happened locally or connecting remotely with FM Pro.
Is the portal filtered? Is one of the match fields used to define the relationship that makes the portal possible visible and editable in the portal row?
Could a match field in the Layout's table have been modified.
Such a change to a match field on either side of the relationship can break the connection and make the data you entered disappear as the record is then no longer linked to the current layout record.
Confusion over what data exists in the portal might also ensue if you have two nearly duplicate records in the layout table and the portal record is only linked to one of the two.
And all of the above data integrity issues could produce such intermittent problems.
Yes, it's filtered. But that doesn't seem to be the problem, because all the other fields for the filtered record have been behaving normally. The match field was most likely not changed, since it's not on any layout. We'll have to do more testing to see what triggers the issue.
The possibility raised by having a filtered portal is that you might create a portal record that does not have the values needed to "pass" the filter. Then, when records are committed, the filter kicks in and omits the record. If this is the case, searching on a layout based on the portal table should enable you to find the record and confirm that this is the case.
As far as I can tell, the portal record did pass the filter. The record has both a title field and a detail field. The title field shows up in the portal and behaves normally, but the detail field would sometimes clear during an edit.
I had a look at the layout based on the portal table to see if anything strange is going on, and nothing jumped out at me. There're no duplicated records, no records with empty match field...not sure what else to check.
What I am describing would cause the entire record to disappear from the portal. If you have two fields from the same table in your portal and one retains data while data is lost from the other, issues with your portal filter are not the cause. Are both title and detail fields from the same table occurrence? (If you click them while in layout mode, you see the same exact name to the left of the :: in "Display data from" in the Inspector.) Is this the same table occurrence as that specified for your portal? (This name matches that shown in portal setup | Show Records From.)
Yes, both fields are from the same table occurrence.
We haven't been able to reproduce the issue all day yesterday. For now, I've disabled "Save record changes automatically" and added a "commit record" button. Will report back later on how that works out.
Thanks Phil & David for all your help!
But are they from the same table occurrence as that specified for the portal?
Yes, they are all from the same table occurrence.
Update: We have not been able to reproduce the error and we are still not sure what went wrong. Fingers crossed that it won't happen again down the line.
Thank you everyone for all your help!