John,

Exactly what I'm looking for. Thanks... <g>

A couple questions if you would..

>The data controller software that Rod and I use (Rod is the primary develop0er) uses both OLE-DB and ODBC.

Is this the product that's around 10K? Too rich (sadly) for our project but if you could point me to any info on it that would be helpful.

> 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.

SPT? Ughh.. My Acronym Translator (AT or AX <g>)) isn't working too well today.

I'd think that for some things that using ODBC would indeed be quicker. Small hit/size stuff?

>
>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 >...

Uhhh.. ok.. <g>

That's more than the current projected size of what we're doing but I want to plan for growth, based on a little bit of experience. <g>

>
>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.

Well, I'm a big fan of placing the working code in the proper location and I'm also a big fan of Stored Procedures. It doesn't make any sense to me to do work farther away from the engine rather than closer to it....

I'll go get myself up to speed on the command object.

>
>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.

Right. I also heard from my buddy Craig that one needs to be careful to NOT call the ODBC driver inadvertantly via ADO. <g> By not placing a DSN entry.

>
>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.

Right. Since I'll be the individual establishing the ultimate level of workstation quality I can make sure I yell at everyone <g> who breaks the rules. *bg* Actually, upgrading the workstations is another issue yet to be worked on.

>
>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....

It does indeed. I've also just raided your web site for PDF files. <g>

Thanks again John,

Anyone else want to go swim in the deep end of the pool? <g>

Best,

DD
>
>
>
>>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..)