You may need to ALSO check the logs in the Audit log. For this kind of error, I believe there is a log entry there as well since a row couldn’t be processed - I am not certain. If there is, that that should clue you in on the row causing the problem.
Though it is an old thread, however, I got a similar issue a few days ago. AppSheet monitoring and log both displayed the same message
I was able to solve the error by first removing sections from the template to find the table that was causing the error. Then filtering the data of the table and moving rows to Notepad++ to view the ASCII characters in the data that were causing the issue. These errors are generated by nonprintable ASCII codes such as “STX start of text” in my case. This ASCII code was most probably added by a typo error by pressing “Ctrl&B” in the text field. My issue is fixed after removing this error.
I am thinking of adding error trapping to my text fields using the Replace function triggered through an action at the save time. It might help if we get a script section in column settings similar to the initial value that can be triggered when the column focus is lost to check the data validity.
Since this original posting, there was re-discoverance of an old issue that occurs when using the UNIQUEID() function (or assigning similar values in some other way) with Google sheets columns defined as “Automatic”. Values entered in the format of “nnnnnenn” - where n is a numeric value - will be automatically converted into a Scientific Notation type value. See images below.
If this IS your issue you will see a value in your sheet such as "1.23E31"
The occurrence is not very frequent, but to prevent it altogether, simply redefine any columns that are assigned the random values as “Plain Text”. In fact, I would recommend redefining the entire sheet as “Plain Text” and then only adjust other columns as needed. If you are using your sheet purely as a datasource, you will likely never need to re-adjust the columns
NOTE: Any values already converted will need to be manually changed back and if the assigned value is used elsewhere, such as for a REF column, then you will want to make sure all values match exactly.
@WillowMobileSys Thank you for replying. This is indeed very helpful information.
In my case, the data did not convert to scientific notation. The column is a longtext field in AppSheet used by field staff to enter notes. Daily inspection reports are generated from this timesheet table. Reports were working fine. However, on 17 Nov the report didn’t work out. Upon checking I found out that it was a typo “ctrl&B” that added STX ASCII code in the plain text.
I think if we have a pre-save section for the columns then we can check data validity before saving.
