>I tought that since there are existing functions (VFP7+)
>CursorToXml / XmlToCursor,
There is and a lot of people are getting good utility from them. In my case, working with manifest XMLs (not tables) that object was un-usable.

I thought it was a VFP 6 project - pre XML2Cursor.

>I really appreciate your effort!
You's do it for is
>
>If this is the case, I mean complexity + low speed - then why some people here advice using XML to pass cursors even between vfp session objects and
forms?

The XML is fast as long as it does not have to be translated the way I did it into a cursor. BTW - I found a faster way - cuts 50% for 2400x 50 records. The "new" method poulates an array and appends from "array" instead of a long EXECSCRIPT() replace string.

It's not "eternally" complex! Remember when "grids" were complex?

Convertinting the 2400x50 records to an XML string took less than a second. Loading that string into a DOM container took less than a second. HTTP response and Requests (SEND GET) for big XMLs is less than a second.

Buy itself - as long as it does not have to be moved to a containier orher than a very larger character string or DOM, XML is fast. We could write databse programs using XML as the database. We could. It's beauty is how easily data can be converted to a set of XML tags and how quickly DOM can load and how quicky script can navigate the DOM. Once you're done, just save the the DOM image as a string - and reload it later.

You could create a bunch of DOMs - like multi-tables - or you can keep all the tables in one.

Now if we had a sharable DOM object - so clients could "open" it like a multi-user table - then we would have something to think about.