Hi Mike

-----------------------
I once made VFP COM objects grab data from VFP, and using VBA, had the COM object return requested field values, and navigate through the records. It was the fastest way I could find. Debugging was a nightmare, because the error messages produced by VBA/COM/VFP (God only knows which one was really complaining) were too cryptic to clearly indicate the source of the problem. Gosh, doesn't that sound familiar? ADO and ODBC were slower by far.
-------------------------

I swear this is faster and easier to do *without* XML and without a COM object. You're just driving this the wrong way around. Your users will have more options, it will go fast, and it is not difficult to debug, if you drive this from Excel.

------
XML just seems so much simpler. Fox produces the XML in the blink of an eye.
------

Sure it produces it fast but it's still slower than having Excel read the DBFs directly -- which it is capable of doing, that's why we have ODBC and OLE-DB providers. An intermediate format is simply not necessary.

--------
I imagine populating the range would be like this...
oRange(XMLConstant) = m.lcXML
--------

If you did it this way or anything like this, you are automating Excel from VFP, which is prone to errors, configuration issues on users' machines with different versions of Excel, *and* not particularly fast (plus memory and cleanup issues.

Nevertheless:

------------
but I can't get that to work. The examples I found on the internet were too complicated and not documented well enough. Again unfortunately all too familiar.
-------------

Point me in the direction of the example you found that does what you think you want to do and I'll work through this with you if you want.

-----------------
Is Excel not able to populate a range with XML? XML is supposed to be a way to move data between services? Excel claims to support XML and VFP claims to support XML. So what's wrong with XML in this case?
---------------

What's wrong is your interpretation of the statements, IMHO (g). Seriously, I can't answer the first question properly without knowing "which version" and "through what method you're going". I would also say that *every* application claims to support XML and that claim means something different in each application! So your thinking that 'XML support' in two applications means they can transparently move data is just not the way to think....

In general, even when two applications are equally able to consume and produce XML, you have to map the XML between the environment's expected internal formats. This is actually a trivial process in most cases, and it is what XSLT is for. The thing that makes it "standard" and "easy" is simply that you do the same thing (create a declarative mapping and transforming XSLT document to go between the two XML schemas) no matter what environment you're in.

----------------
More generally, why is there is always 10 ways to do everything? Wouldn't it be simpler to understand if there were fewer ways?
------------------

Michael, please stop whining (gd&rvvvvf).

Yes, it would be simpler. But applications and data schemas model the world and the world is not a simple place. To model it flexibly and ably takes complexity sometimes.

The point here is that you use two tools, an XML parser and an XSLT processor, all the time. It is actually the "one way" you say you want, it is just not a language. There are parsers and processors built to a standard that you can access from any language -- and therefore all environments can share the capability and understand the same data. This is a very, very important/significant change.

------------------
Certainly, it can be done from Excel, but that's another language, with it's own idiosyncracies.
-----------------

Yeah but it would be much less code and less work and faster in Excel (shrug). And you could use the macro recorder to help you figure them out and the debugger is really pretty good.

But...

Once again, you want to see this work and you say you found examples that do what you are trying to do. Although it doesn't make sense to me to do it this way, I'm willing to try to help. Tell me what examples you were looking at when you got stuck.

I probably shouldn't make this guess in mid air, but it's possible that all you need to do is the XSLT transform step because Excel wants a particular XML schema for the import. I'm happy to help you do the conversion from Fox XML schema to Excel's requirements if that's what's going on.

>L<