I've just encountered this for the first time as well - very strange. It's never been an issue with FileMaker Server v12 and the PHP API.
Just wondering if you found a way to locate the records that have this character, e.g. by exporting to a text editor etc?
FileMaker 12/11/10/9/8 Certified Developer
- - - - - - - - - - - - - - - - -
Phone: +61 2 9484 6565
Mobile: +61 418 468 103
we exported all fields of some tables, yes.
The problem is, that the newline-character exports with the same code (0x0B) and we got plenty of them.
We have tables with 10000+ occurrences after export - no chance to manually extract them.
Ugh! the 0x0B is the VerticalTab (VT, ascii 11) that is often the character to which FM converts the "return-in-field" for some of the export formats (.tab, for example) to account for the return character being the end-of-line.
I would expect that the XML export (as CWP is XML regardless of using PHP to process or not) does no conversion, except for characters it deems as standard to convert (') of the "export" which should NOT be!!
If you query the same data set and don't use the API (get a small set of records to limit the testing) with just an xml call, do you get the same results (0x0B) in the data? If you actually Export the same small set as XML (without an XSLT), do you get the same or different results as the other two tests?
Also, what OS, version, etc. might you be using to narrow down the probabilities of this error?
OS is Windows Server 2008 R2 Standard SP1 German.
Active roles: Webserver IIS and ActiveDirectory (Secondary Domaincontroller)
We use the PHP-Version and PHP-API shipped with FMS13.
Tests are not possible atm because we run FMS12 again. Most of our servers run on linux and we only have two servers on Windows (One Server 2008 R2 Standard, one Server 2008 Standard).
We could try an installation on a Windows 7 Pro machine, but i don't know if that works (with CWP and all) ...
For clarification: The "newline" exports as 0x0B only to textfiles. It works perfect with XML.
The problem with XML is, if there is already a 0x0B (♂) in one of the fields.
We altered the FileMaker-API for PHP (FMResultSet.php). Instead of using the php xml parser "xml_parse" (where the error is generated) we wrote a quick and dirty xml to fmresult parser (using _start, _end, _cdata from the original parser) and now everything works fine with FMS13.
Well, this is no solution for a production environment, but i hope it helps finding the bug.
The XML-Export (for the FMResultSet) from FMS12 and FMS13 are not identical - maybe the new WPE 22.214.171.124 is causing this?
Example: If an "unknown" symbol exists in a field, it is present in a FMS13 resultset (as 0x1F or 0x0B aso) causing an error, in a FMS12 resultset this symbol is missing.
While not exactly on point for your situation - I got past that using the Troi URL plugin and including:
TURL_SetCustomHeader( "-unused" ; "Content-Type: text/xml; charset=utf-8" )