There is ADO. However, you are still left with accessing and working with your data in a completely different way. The solutions I have worked on have been exclusively in the SQL Server arena. If your folks are happy with Fox data, my suggestion would be to stay in Fox. Fox Data is best handled in Fox. Now, if you were going to make the leap to SQL Server, then you have several options.

The first of course is to stay in Fox, and there is nothing wrong with that. If that is what your people know, then you may not have much of a choice. However, to cede to the limitations of Remote Views and the DBC can cause problems. My suggestion is to use DataClas 2000. It is the best way to incorporate Fox and SQL Server. It is n-tier in architecture, but for the most part, on a physical level, it is 2-tier since VFP cursors are used to display child data on the client.

There is a new version of DataClas 2000 called DataClas COM which was written in VB by yours truly. This is not only n-tier from a logical standpoint, it is n-tier from a physical standpoint as well. You can hook this into VFP. In fact, while the core DLL is in VB, you can hook your Fox business classes - written in Fox I might add, into the architecture. Of course, the child data is represented as ADO recordsets. So, you would need to write a translation layer that would migrate to a VFP cursor from an ADO recordset and vice versa. Personally, I detest this approach. But, there are folks who feel they must work with a VFP cursor. In reality, working with an ADO recordset is almost the same as working with a VFP cursor.

For the most part, I would recommend folks wanting to adopt DataClas COM to use it in VB. However, they can easily use it in Fox if they want. Of course, there is still DataClas 2000 that represents a native Fox solution.

Stop by the TakeNote booth at DevCon if you are going to be there...

< JVP >

>
Is there in the VB world a reasonably transparent way of accessing/updating data in Fox tables?
<