Bug: Fuel v0.9.22

[Brian]

After upgrading Fuel to v0.9.22, I get the following error when
attempting to export to google docs.....

_________
An unknown error occurred. Am invalid XML character (Unicode: 0x19)
was found in the element content of the document
_________

I have tried several times and still get the same error. I tried to
look at the last record that was successfully written and the record
immediately after that and I can't seem to find anything unusual.

[Rob (rbtwhiz)]

Hi, Brian.

Apologies for the inconvenience.

Reading up on that particular error (which appears to be surprisingly common), Unicode 0x19 is a control character (End of Medium). Several articles I've read suggest that this will often creep into strings (text) through copy/paste from word processors such as Word and/or OpenOffice - through their [default] use of "smart quotes" (curved quote) in place of "dumb quotes" (straight quote). Have you done any copy/paste from one of these applications to a spreadsheet in Google Docs, that you then imported with Fuel? Or have you used the [Sym] key and the popup on the device to insert a symbol into one of the fields that allow text, directly within Fuel?

Ultimately, like the '&' issue that was fixed in 0.9.22, the problem appears to be with characters that conflict with those that have a special meaning in code. While I can do (and have done) things in an attempt to resolve these kinds of issues, it happens at the expense of being able to easily read that data while in the spreadsheet. For instance, the ampersand character ('&') has a special meaning in the protocols used to transfer the data from your device to Google Docs. As such, it must be 'escaped' (converted to a series of characters that follow a specific pattern so that they can be reliably converted back, later) in order to transfer it without it being interpreted as its special meaning. So, what was a simple '&' character in the text field in Fuel gets sent to and stored in the spreadsheet as '%026' when you export. Because it follows the requisite pattern, it can be 'unescaped' when you import the data back into Fuel... but it's ugly and hard to read while in spreadsheet form on Google Docs. The same is true of multi-line text fields (like addresses) that while in Fuel appear as you would expect, but in the spreadsheet are represented with the syntax for a newline character ('\n').

-Rob

[Rob (rbtwhiz)]

Correction... That should have said "%26" instead of "%026".

-Rob

[Brian]

I found similar results when I googled the error but it didn't help me
so I was hoping it would make more sense to you. No, I have never
imported records from google docs, I have always entered records in
the app and then export to google docs as a form of back up. If it
helps, the last record that it writes & the first rrcord that fails
both have addresses that were detected by gps.

[Kevin Tessner]

I've seen both my Pre and Pre 2 occasionally create a space plus a junk character that looks a bit like an H when I do the opt+finger-drag to move the cursor around an edit field. I forget the exact steps to reproduce it and can't seem to get it to happen on purpose now, but maybe something like that happened to you when creating the record in Fuel?

Maybe take a screen shot of the last record (opt+sym+p) so that you have the data, then swipe-delete it in the main screen to get rid of it and try to re-export.  If that works, then re-create the deleted record manually from the screen shot and try exporting again...

Just a thought,

...K

-- Sent from my Palm Pre 2

--
You received this message because you are subscribed to the Google Groups "webos_rbtwhiz" group.
To post to this group, send email to webos_...@googlegroups.com.
To unsubscribe from this group, send email to webos_rbtwhi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/webos_rbtwhiz?hl=en.

[Rob (rbtwhiz)]

Good suggestion, Kevin.

I've seen the junk character you mention, too. Though when I've seen it, it wasn't from an opt+drag operation... rather it was returned as part of an address lookup. I haven't seen it for quite a while though, so I assumed it was a bug in the service that got fixed in an update (to either webOS or Google Maps). Its interesting to me that Brian mentions the addresses.

Brian, if you don't mind, can you try what Kevin suggested to help isolate where this issue is coming from? You can also use either App Menu > Data > Send As Email... or App Menu > Data > Send As SMS... while viewing the details of the event to capture the data in text form. If deleting the record, as Kevin suggests, allows you to export without the error and then re-entering the record and using the GPS coordinates to lookup the address again puts you back into the same situation... If you email me the GPS coordinates or post them here (whichever you are more comfortable with), I can try and replicate the issue and isolate the problem character(s).

I could try to use a regular expression (i.e. /[\w\s-\.,#*]+/  - which basically means any letter, number, underscore, space, return, hyphen, period, comma, pound, any number of times in any sequence) to limit the accepted characters in the address, which would cull any problem characters out... But I'd like to keep from having to do that because it will likely be too restrictive and has the potential to modify data someone wanted to keep. For instance, in the case of an address in parts of the world that I'm not familiar with which allow additional characters - accented characters, parenthesis, square brackets, colons, semi-colons, etc...

-Rob

[Brian]

Ok, now I'm even more confused. I emailed the last exported record
and the first failed record to myself. I didn't see any difference.
I decided to try to export each table individually and oddly enough,
all 5 tables exported successfully. I only get an error when I try to
export a 'complete set'. Then every time, when the grey progress bar/
button gets to "Fuel History Rows... 37%" the xml error pops up below
it. Then the progress wheel just spins forever until I back gesture
to exit the export screen. This being the case, it seems like it
isn't an issue with my data since the individual tables export
successfully.

On Oct 9, 12:56 pm, "Rob (rbtwhiz)" <rbtw...@gmail.com> wrote:
> Good suggestion, Kevin.
>
> I've seen the junk character you mention, too. Though when I've seen it, it
> wasn't from an opt+drag operation... rather it was returned as part of an
> address lookup. I haven't seen it for quite a while though, so I assumed it
> was a bug in the service that got fixed in an update (to either webOS or
> Google Maps). Its interesting to me that Brian mentions the addresses.
>
> Brian, if you don't mind, can you try what Kevin suggested to help isolate

> where this issue is coming from? You can also use either *App Menu > Data >
> Send As Email...* or *App Menu > Data > Send As SMS...* while viewing the

[Rob (rbtwhiz)]

Not all characters are ones you can see as text, so I'm not surprised that you didn't see a difference. Add to that, the fact that the Send As Email... option utilizes a completely different code path than the export options, one that doesn't involve XML at all, and I become even less surprised.

Considering that I export a Complete Set every time I add a record (in case my failing hardware decides it is finally done)... and considering that every record I add is complete (meaning every field has a value, including the address - which I get the same way you do)... and given that I don't have a bunch of reports of this happening to other users... I have little choice but to think it is something about the data itself. This is supported by the fact that the error occurs in exactly the same spot (Fuel History Rows... 37%) each time you export, and the fact that the code that builds the body of a worksheet is the same (not just an identical copy, but the exact same path) between the various export modes. The only differences between the Complete Set and the others is how it creates the spreadsheet and the worksheets within it.

Everything I'm seeing points to the data itself; in particular, the contents of a text field (not necessarily a visible character) in a record that is ~37% down the list of Fueling Events.

-Rob