Fixed
Status Update
Comments
ma...@caringvillage.com <ma...@caringvillage.com> #2
Hi, sorry for the trouble. I am working on improving our radio HAL. Unfortunately, it will take a while because it is very large. Please do not send non-ASCII characters in SMS.
da...@google.com <da...@google.com> #3
Hi, I don't know if it may be implemented as quick fix on the actual code, but looks like Ñ is the only alphabet letter having the issue (at least between ones widely used within GSM 03.38 GSM 7-bit).
I've tried with ÄÇÖÜàèéìòùäñöü and all of them are correctly sending only one SMS and not two concatenated.
I've tried with ÄÇÖÜàèéìòùäñöü and all of them are correctly sending only one SMS and not two concatenated.
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #4
I've tried with ÄÇÖÜàèéìòùäñöü and all of them are correctly sending only one SMS and not two concatenated.
I see, maybe we missed that one Unicode somewhere then. Could be easier to fix then. I will take a look this week. Thank you for pointing this.
da...@google.com <da...@google.com>
pr...@google.com <pr...@google.com> #5
Just to get the full picture, I've tested with all characters included here https://en.wikipedia.org/wiki/GSM_03.38 both in Basic Character Set (they should take 1 char of the 160) and Basic Character Set Extension (they should take 2 char, first is ESC prefix) and the only one causing the issue is Ñ
Sending a character outside that set, like á, message it's correctly split into 2 parts, first one of 70 chars as expected.
Sending a character outside that set, like á, message it's correctly split into 2 parts, first one of 70 chars as expected.
Description
I'm using:
My databases are configured with:
When a destructive migration occurs we're getting an error on Android (and I believe we're getting a similar error on iOS, but am awaiting confirmation on that).
I pulled the db from device explorer, and it looks like the "destructive" part of the migration never completed? All the tables and views are is still present - but it's all in the .wal file (first time I just pulled the .db file, and it was empty).
Clearing storage, or uninstall+reinstall resolves the issue, but that's less than ideal, and as soon as the db version is bumped again, even if no other changes are made to the code, it happens again.
It's odd that this appears to have just popped up recently, after a couple of minor changes, after appearing to have been working fine for the last ~15 or so destructive migrations.