Hi Lisa

First thing! No more whining. I'll leave that to Jim Nelson. ;)

>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.

I hear you, but I'm stubborn. <g> BTW it's nice to see someone can still use "you're" vs "your" in the same sentence without getting it wrong. ;)
However, as Jim Carey put it in one of the Batman movies "If you kill him, he won't learn nothin". IOW, this is a good opportunity for me to learn. I want to try the different options so I can see which is faster.

>------
>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 suppose I could make a Dbase III / Foxbase+ style DBF, and let the user import that into Excel, but again, I need to just fill in a range, not create a new sheet, because the user would have to redo all the cosmetics.

>
>--------
>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.
>

No solution is perfect. ;) ODBC/Ole-DB would create configuration issue(s) for the users, not to mention they'd potentially have access to the VBA and could mess it up. I was thinking to let them control cosmetic stuff. There is a complicated query that is producing the data. There will be a number of sheets and I know of no way to have several sheets share the same query.

>Nevertheless:

Nevertheless ;)

>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.
>

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoffpro01/html/xmlofficexpparti.asp


>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.
>
>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.

IMO, I can either drive it from VFP, drive it from Excel or model the real world and have the data be passed between the two apps.

>
>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.

Understood.

<snip>

>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.

Fantastic! You'll note the author of that article even says there are better ways to do this, but goes on to show a range being populated and shows no example of the alternative means of doing that!

Thanks!