Error 1 : ' ', hexadecimal value 0x1C, is an invalid character. Line 1, position 865.

[skyjohn]

I was trying to make an automation to generate a report. It worked well until recently it stops working and showing me this error message. 

"Error 1 : '', hexadecimal value 0x1C, is an invalid character. Line 1, position 865."

<<Start: [AIR FREIGHT LIST]>>

CUSTOMER	<<[CUSTOMER]>>	EXPECTED SHIPMENT DATE	<<[EXPECTED SHIPMENT DATE]>>
BILLING ADDRESS	<<[ADDRESS]>>	PACKAGE ID	<<[PACKAGE ID]>>
RECIPIENT	<<[RECIPIENT]>>	SKY TRACKING CODE	<<[SKY TRACKING CODE]>>
SHIPPING ADDRESS	<<[SHIPPING ADDRESS]>>	PRICE BASED	<<[PRICE BASED]>>
DESCRIPTION	<<[DESCRIPTION]>>
QR CODE	<<[QR CODE]>>	PACKAGES	<<[PACKAGES]>> PACKAGES INCLUDED

TRACKING NUMBERS  <<[PACKAGES]>> PACKAGE/S

CARRIER	TRACKING NUMBER
<<START: [RELATED TRACKING AIRS]>> <<[carrier1]>>	<<[TRACKING NUMBER]>>  <<END>>

EDNO: <<[AIR TRIGGER N]>> /<<[CUSTOMER]>>/<<[PACKAGE ID]>>/<<[DESCRIPTION]>>/<<NOW()>>

PAGE ENDS FOR <<[CUSTOMER]>>

<<END>>

That's the template above. Thank you.

[WillowMobileSys]

---

@skyjohn wrote:

It worked well until recently it stops working and showing me this error message. 

"Error 1 : '', hexadecimal value 0x1C, is an invalid character. Line 1, position 865."

---

Where are you seeing this error message?

I would check the data to see if some bad information crept in.  Hopefully the error message is giving you an indication of which row has the issue.

[skyjohn]

It doesn't tell which row. In the automation when I test the process.

[WillowMobileSys]

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.

Did you double-check your data at the datasource?

[Saleem_Tareen]

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. 

[WillowMobileSys]

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.

I hope this helps!

Column originally set to "Automatic" formatting

Value assigned as "12345e27" assigned to the Report ID columns was converted to Scientific Notation due the "Automatic" format

When cell is first changed to "Plain Text" assigning value of "12345e28" remains

[Saleem_Tareen]

@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.