Hi Den:
 DB>      There You go again, bashing away at poor, poor, pitiful Ms. You
 DB> know I do not Access, I made a logical guessimate, which Abb verified
 DB> was basically correct(Thanks Abber). What Abb said, are you not trying
 DB> to put the cart before your poor horse? You are saying one unit of Ms.
 DB> should have given the file structure of a product to another group at
 DB> Ms., long before the product is released publicly. Do You recall all
 DB> the threats of Lawsuits by Borland, Novell, et al, over even the mere
 DB> possibility of such a thing may have occurred?
Huh?
 DB>      His question was how could He run Access's Query against some
 DB> Visual FoxPro data files. Yes one could use a VFP ODBC driver to allow
 DB> Access 2 to read his VFP data. He would have to install the new driver
 DB> first, as one was not available when Access 2 was built. OLE2 or OLE1
 DB> could also work, but I think that they are overkill. Using DDE would be
 DB> simpler and faster.
Agreed.
 DB>      You would need to create a Database in Access for each one in
 DB> FoxPro with the same number and size of Fields. Then you setup FoxPro
 DB> as a DDE source and Access as the DDE destination. Now you can run your
 DB> Access Query against the Access db which contains the FoxPro data. You
 DB> could take it a step further with link and then each time you ran your
 DB> Access query, the data would already be updated in the Access db!
 DB>                                         I'd use VFP's Query,
So would I, but that wasn't the original question, either.
Again, my point is this:  as our monolithic friend, Microsoft, continues to 
tout its connectivity issues, the fact remains that all its products do not 
communicate effectively with each other.  This, despite the fact they all run 
under the same O/S, theirs by the way, and are written in-house by them.  
They certainly have more talent than I and more money to hire more, if they 
need it.
Yet, ALL my systems and applications share data -- without exception.  And I 
communicate with mini- and mainframe computers, too.
I haven't attempted to read Access files via VFP, but I _should_ be able to, 
right?  Access 97 _should_ be able to read VFP's .DBCs, too.  I still 
remember M$ original Word, which didn't work in their Windows at the time.  
They corrected that.  I'm sure they will correct this situation, too.
I AM  "saying one unit of Ms. should have given the file structure of a 
product to another group at Ms., long before the product is released 
publicly."  I AM suggesting communication between developers in the same 
enterprise is essential.  I DO expect products from the same company to work 
together.  I AM dissappointed that they do not.
I really enjoy VFP.  It is the best of FoxPro there has ever been.  BUT, I 
have been compiling a list of bugs and deficiencies: 142 at present.  Can I 
work around them?  Sure.  Do I _want_ to?  Think about it.  This is a 
complicated product and M$ has the resources to get it right.  It is far 
superior to the VFP3 I purchased 2 years ago, but there are issues.  When new 
technology or methodology is introduced, we expect a steep learning curve.  
It comes with the territory.  Leaving land mines in our path should not.
Again, I've not found a better development tool for my needs than VFP5.  I'll 
put it against everything I've seen so far and I believe I can produce a 
quality application that will outperform all others on a LAN or Client 
Server.  If it's really huge, I can incorporate SQL-Server.  Still, I'm 
looking forward to a product or products that will integrate well and not 
force work-arounds on the developers who use them.
May the force be with you.
David in Dallas.
--- Maximus/2 3.01
---------------