Jim,

I'll address what I can speak about.

>Hi all,
>Well I bought and started to install VS 6.0, but (possibly fortunately) my brand new SCSI hard drive blew during install. This left me with only the single supplied book to read to get acquainted with the product.
>
>Reading it top-to-bottom was quite revelatory as regards the level of "integration" of VFP into VS 6.0. In a word, IT ISN'T!!!
>
>Knowing that VFP made its first appearance in VS 5, and interpreting at that time that it was done in 'rush' fashion, I opted to wait for the next version of VS then. DEVCON seemed to indicate that that was a sensible strategy and that I could expect significant integration.
>
>For those who may be interested, here's a summary of what I found:
>
>Developing for the Enterprise was the book
>
>Chapter: What's in the Enterprise Edition?
>
>In the third paragraph VB and VC++ are mentioned as having separate Enterprise Edition packages, while VJ++ and Visual InterDev are noted as not being offered that way. VFP is *not* mentioned.

VFP has one version...Professional.

>
>The table of "Features" nominates VFP in several areas!! But I have to ask myself:
>1) Why can't VFP use COM Transaction Integrator for CICS and IMS(COMTI)???
> - This would greatly extend the "reach" of VFP, especially considering that many mainframe shops have been long-time users of FP/VFP.
>
>2) OLE DB Provider for AS/400 and VSAM data is also limited to VB and VC++.
> - VFP needs this capability for the same reason listed above.

Technically speaking, VB can't use OLE-DB because it can't manipulate pointers. ADO is used by other products. VFP can use ADO, therefore it can be used. The problem is a documentation error.

>
>3) All of "Data Object Wizard", "RDO User Connection Designer" and "RemoteData Control" are limited to VB.
> - Can we truly state that VFP is fully integrated into VS 6 given this situation *and* #1 and #2 above???

No one said that VFP was fully integrated into Visual Studio.

>
>4) Obviously, in support of all of the above, VFP needs to be able to use the services of "SNA Server 4.0".
> - But it doesn't! SNA Server 4.0 is limited to VB and VC++
>
>5) Visual COmponent Manager has all languages EXCEPT VFP!!
> - this speaks for itself
>

VFP uses late binding. This causes the limitation.

>6) Visual Modeler is limited to VB and VC++.
> - This also speaks for itself.
>

That is direct use of of VM. There are Wizards available in VFP that give you VM integration.

>Chapter: Choosing the right Data Access Technology
>
>Focus is STRONGLY on OLE DB, ADO, RDO, ODBCDirect and SNA Server, NONE of which are supported by/for VFP!!!

Wrong...VFP supports ADO.

>
>pg 82: Mention that OLE DB and ADO *can* be employed by VFP. However, based on the initial section it is clear that VFP has extremely limited scope for COM-based technologies.

True, VFP has limitied support for ADO. I think you'll see VFP 7.0 fully support ADO. There have been several threads about this.

>pg 100: sectio: 'Accessing data with ADO' lists, under "external databases", FoxPro version 2.0 and 2.5. I suppose that means that VFP databases and tables are not supported!

Documentation error. OLE-DB can, by definition use an ODBC driver.

>pg 105: "ODBC is not suitable for non-relational data such as ISAM. . ." This would seem to exclude FP and VFP!

ODBC *can* be used for ISAM...but it has limitations when compared to non-ISAM files. At least is was explained to me this way. I don't know any details.

>
>Chapter: Implementing Mainframe Data Access
>pg 126: "Because DCOM is language independent, you can build your client application using the languages and tools with which you are most familiar, including. . ." and there follows a list of 7 languages, both MS and other) but NO VFP!!!

Were all MS languages included? I don't have this manual.

>
>The Island Hopper News samples have not a single usage/reference to VFP!
>
>Yes, I know, 'these things take time'.
>
>That VFp became a part of VS was touted as the salvation for VFP and the way to get a lot more attention from developers using other languages. I'm afraid that those developers will have no excuse to even install VFP, given the record cited above!!!
>
>Are we all happy with this situation???
>
>Regards,
>
>Jim N