Thanks to everyone who responded. My first problem was using the UTF8 text without length constant instead of “UTF-8”. Who knew they would be different! Thanks for pointing that out, Justin.
The main reason I didn’t want to have a BOM character was that JSON Parse chokes on such documents. I’ll file a bug for this. In the mean time, I’ve figured out a way to move forward and make peace with BOM characters while not affecting legacy systems until they are upgraded. It basically amounts to manually removing the BOM on a few files on FTP sites for awhile, but not the end of the world. Thanks again for everyone’s help. -- Cannon.Smith Synergy Farm Solutions Inc. Hill Spring, AB Canada 403-626-3236 <can...@synergyfarmsolutions.com> <www.synergyfarmsolutions.com> > On Aug 30, 2017, at 5:31 PM, Justin Carr via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > The first thing I notice is that you are using the old BLOB to text and TEXT > TO BLOB constant (UTF8 text without length) with the TEXT TO DOCUMENT > command. This command uses either strings such as "UTF-8" or the > corresponding MIBEnum ID (the documentation for CONVERT FROM TEXT lists these > out). The UTF8 text without length constant has a value of 6 which > corresponds to ISO-8859-3 using MIBEnum IDs. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
