>Hi Michelle.
>
>>This line:
>>lnNumRecs = XMLTOCURSOR(tcDataString, "tc_addrs")
>>
>>takes 98 seconds on my Celeron 600 with about 4800 records. Each record has 12 fields. This is way too slow for my needs.
>
>I've run into the same problem. The issue is that XMLTOCURSOR() uses the XMLDOM for parsing, which is pretty slow for large documents. When I mentioned this to Erik Moore at the MVP Summit this past weekend, he suggested looking at the SAX parser, which doesn't load an entire document but instead fires events as it hits each node. I haven't had a chance to look into this yet, but will post something once I do.

I think that the need to use XML here is poorly thought out; while the use of XML is appropriate to passing data between tiers, it's unnecessary when the tiers are coresident in a common file system. Rather than creating a cursor, converting the cursor to XML, passing the XML, and reconverting to a cursor, if the file systems are coresident and compatible, a simpler mechanism would be to pass a file reference between tiers, and the transport overhead is now minimized. Rather than requiring the transport of the data, we now transfer the common reference to the data, reducing the transport cost to the cost of transporting the location of the data in the form of a common file name - it can be an absolute local file reference, a UNC if a common file system is in use, or a URL if a common virtual filesystem exists. In the case of moving around a cursor, I'd assume a common file system existed, and use logic along the lines of:

<i>Create a cursor</i>
lcCursorFileName = FULLPATH(DBF())
DECLARE INTEGER WNetGetConnection IN WIN32API STRING @ lpLocal, STRING @ lpRemote, INTEGER @ lpnLength
LOCAL lcCursorFileName, lcPassedFilename, lcBuffer, lnLength
IF LEFT(lcCursorFileName,2) = '\\' && It's a UNC, so it can be passed
   lcPassedFileName = lcCursorFilename
ELSE
   lcBuffer = REPL(CHR(0),262)
   lnLength = 262
   IF WNetGetConnection(LEFT(lcCursorFileName,2),@lcBuffer,@lnLength) = 0
      lcPassedFileName = ADDBS(CHRTRAN(lcBuffer,CHR(0),'')) + SUBST(lcCursorFilename,4)
   ELSE
      && not on a share, so it has to be moved to another shared file system
      && location, and the new location passed in lcPassedFileName
   ENDIF
ENDIF

This now passes the reference, the shared filesystem serves as the transport mechanism, and the overhead is minimal. If the data does not reside on a common file system, then the data has to reside in a commonly referencable location, and the reference is passed across the layers.

This is not foolproof; it assumes that the data handlers on either side of the interface know how to handle the common file; that the processes on both sides have equivalent rights and permissions to the shared reference point, and there may be consequences to having to move the file to a common reference point from where it gets created initially. Also, it's relatively easy to safely represent hierarchical and network data structures in an XML format, and file system issues are avoided. However, the bulkiness of the data transfer, not to mention the marshalling cost enforced by using XML transport across layers (it costs a whole lot more to move an entire file than the name of a file when all you do is pass it along without examining the data) is avoided.

It works in a moderately homogeneous environment with shared resources pretty well; when file format and data format considerations across platforms become an issue, you have to pay the piper and move the data in a commonly-agreed form such as XML rather than exchange references.