>Bob,
> It's been a while since I have seen a post so far off the mark.
>
>>What is ADO to me? Take a shotgun and blow a hole in VFP's head and you have >ADO. Actually, ADO is a great idea if you spend your days accessing data in >spreadsheets and text files etc. I prefer to use a database. I use VFP with >SQL Server. ADO does that too. It uses ODBC. VFP also uses ODBC. So now if we >could just get VFP to use ADO (so it could do the ODBC instead of VFP doing it >directly) we would get to:
>
>>>1. retrieve strings of data that we could then parse into a cursor we would >>have to define.
>
>All records sets have fields collections that you can retrieve column data from.
>You do not have to manipulate data from databases as a set of strings. I am not familiar with any data access technology from MSFT that does not use some representation of a fields collection.
>
>>>2. not have indexes available on the ado data.
>There is a property on a field object called optimize. It builds and index and the uses that index for optimization.
>
>>>3. not be able to use the tableupdate or tablerevert command on the ado object.
>
>Gee there are methods called Update and CancelUpdate on the recordset object. There are also methods called UpdateBatch and CancelBatch as well. This sounds like table buffering to me.
>
>>>Finally be reduced to the level of VB programmers trying to work with >>database files.
>
>Gee: lets see here we have an object based approach to accessing data. Direct manipulation of data is nice but it sure has its share of problems as well. We have been using a similar approach to accessing data and it sure doesn't include manipulating data directly. Ever heard of N-TIER development ?
>
>>>So we should be excited about ADO because we can let it use ODBC instead of >>us using it directly via remote views? This is progress? Of course, I know >>that most of us need to read excel databases and word databases all the time >>and we've just being dying for ADO to save us.
>>>Bob
>
>I don't know where you got your information but being able to query data stores in Exchange or file systems in WIndows NT 5.0 sound like good things to me.
>
>I don't know where you studied ADO but I believe that it is a much better and deeper than you give it credit for. I recommend that you learn a technology a little better before you dismiss it as you seem to have done with ADO.
>
>Rod

Hi Rod;

The big issue with my whining is that we have excellent features in VFP now that can satisfy in very elegant ways our need to write database applications. ADO and OLE DB expand the universe and will be very useful but I still think using VFP Connections and ODBC is a better way to access SQL Server data (or Oracle) than using ADO for the sake of using ADO.

I'm not dismissing ADO and I am learning as much as I can about it (more to use it with VB than VFP). I think it is a lot more relevant for VB programmers.

Sometimes we hear all the new hype about new technologies and think they always apply to the things we are doing. They don't. Not every new database application needs to be n-tier. If you are going to build a shrink wrap system you better be careful about n-tier. It's going to cost an awful lot more to support than a fat client system, even if both use remote sql data. This doesn't make either one bad it's a question of what is really necessary and we don't always stop to consider that.

If the only data I need is SQL Server, why would I choose to use ADO over remote views? I don't see that it brings any extra benefits to a VFP application.