<< I was wondering what SQL Server 7.0 would do to the traditional desktop databases as well. I am also wondering what ADO will mean for VFP. Since VFP 6.0 will support ADO, does this mean that straight VFP coding for data access should be changed to ADO references in VFP (or perhaps another language)? I really like VFP for what it gives in terms of data access, OOP, etc. today in comparison to other products like VB. I'm hopeful that feedback from everyone attending DevCon will shed some light. >>

ADO works in VFP 5.0 as well. ADO has some really cool features that aren't implemented in VFP, but I don't think it'll replace how you access data in most traditional VFP apps. The most likely places to use ADO in VFP are in place of where you'd currently use SPT. If you're going to access data over the web you'll probably also want to consider going with ADO/RDO. In most cases it won't make sense to use ADO if the data is actually stored in VFP tables either. Also, if you're doing client-server and using remote views will suffice then it's kind of a toss-up as to whether you want to continue to use views or go with ADO. ADO has limited design surfaces for accessing the data - and these for the most part aren't available in VFP (I'm sure JVP will correct me here if I'm wrong). If you're using VFP as a middle tier you may also want to use ADO for the data access.

We sorta decided to go with a hybrid approach in our framework for Tahoe and I'm really pleased with the results. We've created a cursor object that's about 90% PEM compatible with the ADO record set object as well as a field object that's compatible with the ADO field object. We've also extended a lot of the functionality beyond what ADO does. The advantage here is that you should be able to replace our cursor class with an ADO record set object relatively easily if you want to. One advantage this approach has over ADO is you can control the classes used for the fields collection and the field objects within the collection, with ADO you can only use their native collection and their native field object.