Listing error. Failed to write query result to XML.

[Anonymous]

This SQL query works just fine for me:

select ID, USERID, LENGTH, WIDTH, HEIGHT, SURFACE, VOLUME, VIEW_PEN_ID, SECTION_PEN_ID, LINETYPE_ID, FILLTYPE_ID, FILL_PEN_ID, FILL_BG_PEN_ID, MATERIAL_ID, LAYER_ID, LIBRARY_PART_NAME, BASE_ELEVATION, LABEL_ID, STORY_ID
from OBJECTS
where LIBRARY_PART_NAME = 'abracadabra_2010'

Among other results, it shows the OBJECTS.ID for 'abracadabra_2010' is '586B7EA9-609A-4827-B30C-1F33CD1388D0'

This next SQL query fails with error message "Listing error. Failed to write query result to XML"

SELECT PP.PARAMETERS.NAME, PP.PARAMETERS.VARIABLE_NAME, PP.PARAMETERS.TYPE, PP.PARAMETERS.VALUE
FROM FLAT(OBJECTS, PARAMETERS) AS PP
WHERE OBJECTS.ID = '586B7EA9-609A-4827-B30C-1F33CD1388D0'

The syntax appears ok, since it has been used many times before and the following query performs as expected:

SELECT OBJECTS.USERID, OBJECTS.ID
FROM OBJECTS
WHERE OBJECTS.ID = '586B7EA9-609A-4827-B30C-1F33CD1388D0'

Does anyone know why the results cannot be written to an XML output? It appears to happen just for this particular, long-used, object. Schedule reports involving the object work as expected.

[Anonymous]

Follow up.

I've established there is no sql syntax error, and enclosed or CALLed macros having binary components appear not to be the problem, because I can query one of them (Man Hands in Pockets 14.gsm) successfully. Also, the output quantity seems not to be a factor, because there is only one instance of the object. Similar queries with other objects have no trouble getting out 4,000 lines or more....

(1) Does anyone know if writing out the query results to XML has limitations relating back to the source object's CALL depth?
(2) Does anyone know if I can have GS-SQL write results in a non-XML format?

[Karl Ottenstein]

Hi Didirik,

The problematic query worked fine for me - copy/pasted it into my query window. I placed a single chair, tested the result with USERID, then used an element schedule to display the Unique ID and used that hex value for the ID and that worked fine too.

The Query window only writes an XML file which is sent to the browser for display. No control over it that I am aware of. (I do not see any entries in the preferences/registry that would affect SQL.)

Cheers,
Karl

PS Please create a Profile, by clicking the blue/gray text link near the top of this window - to the left of Log Out. Enter your machine specs and the version of AC you are using. Thx.

[Anonymous]

(First, thanks for your reply. I see you recognize desperation.)

Right. That's why I'm concluding that there is something peculiar with our object. In test-object variants, I've eliminated the CALLS, included value lists that were formerly modularized, and generally tried to reduce the number of perceived possibilities for XML-result-writing. Of course, my perception is known deficient, and sparse documentation does not help.

As it turns out, the queries work just fine with the sub-objects called. I even tried changing the subType to non-Person, like Furniture. No help. So I'm back to examining the principal object. After looking at it (too much!), I think we can fairly easily rebuild the thing from the ground, up. Then see what's up. When discovered, I'll post the solution to help others.

[Karl Ottenstein]

didrik wrote:
When discovered, I'll post the solution to help others.

That would be great. Thanks. (Please do update your forum profile as suggested below, too, so that we all know what version / platform you are running.)

The situation is quite a head scratcher. Not knowing how GS generates their XML, I wonder if some of their scripts are not too clever when parsing: is it possible that the actual values of any of your parameters look like XML tags, or contain the symbols "<", ">", etc? It should not matter, but sloppy code within AC might get confused between actual XML and parameter values.

Or, is it possible that any of your macros are called in a way that creates a loop / recursion? I would think that the object would not display properly in plan/3D if so, but that code is totally different from the query processing code...

Look forward to hearing your resolution.

Cheers,
Karl

[Anonymous]

Follow up: The issue was never resolved in a proper or informative way. However, creating a new object from scratch with exactly the same contents (but not copy-pasted into the new script) worked fine.

There have been other instances with other objects where the query result could not be written to XML. It appears to relate to the amount of output expected. This is only a hunch.