The data controller software that Rod and I use (Rod is the primary developer) uses both OLE-DB and ODBC. The ODBC aspect is manifested via SPT. Why? For the VFP environment, it is optimal to render some data directly to VFP cursors. The performance hit is too great when converting data between ADO Recordsets and VFP cursors.

For the purposes of your question, I will focus on the OLE-DB aspects....

First off, what size app do we have this stuff deployed. 500+ users, 24x7, 100+ gb SQL Server database. In another situation, the app is distributed to 15+ sites around the United States, and at each location, is used by 30+ folks at each location. Some of the databases at each location are over 10gb in size.

How is that for real world...< bg >...

The most powerful, robust and mature of the ADO objects? By far, it is the Command Object. Even if you create the command text dynamically on the client, it is very very good. However, it gets even better when you use a combination of stored procs and the command object itself for queries, inserts, updates, deletions. Many people try to manage updates through the Recordset Object. Behind the scenes, a Command Object is still involved. However, it is under different circumstances. The Recordset is good for one thing, holding data and passing data around. After that, you really want to rely on the Command Object directly for handling data manipulation.

Harking back to Miriam's article, she concentrated on ADO, but continually used the OLE-DB Provider for ODBC. Whenever possible, you want to use the native OLE-DB Providers. The SQL Server OLE-DB provider is at least 50% faster than the SQL Server ODBC Driver. Unfortunately, the OLE-DB Provider for ODBC is the default and most articles simply don't go the extra step of discussing the differences. I will say it is getting better.

The biggest pain? Making sure client workstations have the latest software. And occasionally, we run into DLL hell. For the most part however, it runs like a charm.

The keys to success:

1. Used stored procedures...
2. Make use of the ADO Command Object
3. Only use the Recordset for displaying and passing data
4. And as always, adhere to good C/S principles...

HTH....



>Hi All,
>
>Say, who out there has some 'Real World' ADO-DB experience, numbers, stats, etc and would care to give a thumbnail picture of your knowledge/experience?
>
>As John correctly says, who has some 'Real World' experience? <g>
>
>I'm in the process of specifying some data connections and everything I can see leads me away from ODBC and towards ADO-DB. Now, this would also be in connection with COM objects, MTS, and so forth, plus some Internet access as well.
>
>Soooo... Any 'gotchas' or anything else you think would make the basis of knowledge base article/thread?
>
>Best,
>
>DD (off to Wiki-Land..)