Hi there again Mike,

Thanks for the reference.

A couple of things:

1) You will notice that the article is in the archives. It's not supported content. In fact, I would guess that you would have problems with this method if any of your users have Excel 2003. This is one reason I asked you what version(s) of Excel you were working with!

2) You say "No solution is perfect. ;) ODBC/Ole-DB would create configuration issue(s)" and this implies, to me, that you don't understand that Excel is using ADO under the covers for its XML usage (at least in Excel 2002, which is what the article covers). The XML you're looking at in that article is in fact ADO style.

You are not going to get away from the issues and details of component development if you use XML, IOW, simply because Excel is leveraging existing components outside itself -- and so is Fox -- to handle XML.

Neither application re-invented the wheel and re-implemented XML parsing. They're both using MSXML DLLs, and Excel is, in addition, using ADO here. ADO is in some ways the primary way that Excel "understands" datasets that are table- or cursor-shaped <s>.

3) My "mid-air" guess was correct: *IF* you could count on the technique shown in the article being available in other versions of Excel (and it is my experience that it will not work), the solution might be a trivial problem of transforming Fox's XML via XSLT to ADO format in whatever variant Excel expect.

They actually allude to this in the article, although they show it in the other direction (transforming the ADO format to what a web server expects in a post).

However, I'm not going to do the required XSLT or whatever jimmying it might take to get VFP to create ADO-style XML -- because I really, really, don't think that is going to work for you cross version. When you try that critical line:

theRange.Value(XMLConstant) = the_var

... you are going to get a "feature not implemented" error...

Instead, I want you to accept that component architecture is at work here, and not fight it so hard.

Once you accept that, if you still wish to drive it from Fox there is in fact a way to do what you want to do. It looks like this:

  * ox is previously set up as Excel
  * application your worksheet is open, etc

  * the_var is your XML string but
  * it is not the original string -- you have
  * taken your cursortoxml results and moved it
  * into ADO recordset format, courtesy of XSLT
  * at this point.

  * NB: if you have an XMLDOM object available
  * after your transform (courtesy of the TransformNodeToObject method)
  * you can probably load this directly into the recordset
  * instead of using the stream object as I show here.
  * The syntax is: oy.Open <XMLDOMDocument>

  rg = ox.Range(ox.Cells(1),ox.Cells(300)) && or whatever

  * load a recordset from XML string:
  oy = CREATEOBJECT("adodb.recordset")
  oz = CREATEOBJECT("adodb.stream")
  oz.Open
  oz.WriteText(the_var)  
  oz.Position = 0  && move back to the beginning
  oy.Open(oz) && load the stream into the recordset
  oz.Close
  oz = NULL && don't need the stream any more

  * now the recordset has the XML

  * so you can pass it to the range:

  rg.CopyFromRecordSet(oy)

The ADO recordset is a format with which Excel is quite a bit more comfortable than it is with XML at this stage in Excel "history".

My point here, though, is why in heaven's name would you bother with the XML? Much as I love XML and XSLT, why wouldn't you just load the ADO recordset by telling it to connect to the Fox table or whatever? There is probably some "natural" connection in VFP these days, via a cursoradaptor or something, not that I've paid much attention to this <s>. Using XML to pass the data just gets in the way. Frankly you might as well use DataToClip and tell your users to paste it in whatever range they want!!!

I've given you the part of the solution that I think is pertinent to your real requirement: you can programmatically move data directly into a range. As you can see from the sketch, XML does *not* have to be involved at all. CopyFromRecordSet is a very efficient way of moving data into a range and XML is only a very-incidental part of this scenario.

I hope this helps,

>L<