>Cetin,
>Since our existing app relies heavily on local views, using ODBC would actually save us from a rewrite and a lot of cost as we just need to upgrade these to remote views. In your view, in the longer term, will this route (ODBC) hit a nail (in that when we have lots of volume, speed becomes an issue). Or its better to invest in a rewrite on ADO. Or is there a shorter path (converting from local views to ADO)?
>Thanks
>Yau

Yh,
Some of the things I'd say should sound awkward,radical or like that - might need flamesuit in between:)
I don't see a problem in using ODBC. You're saying SQL server (possibly it's SQL server2005). As I could see it SQL2000 was already faster than VFP (on large tables and complex joins), SQL2005 have many new cool features added. You could push your speed problem there (ie: design your data and stored procedures, views, functions etc in SQL server to benefit from fast data retrieval,insertion ... manually rather than using tools like VFP upsize, or MSSQL DTS,SSIS).
Using cursoradapters in place of views (you might start with views if it'd let you do a more quick and easy transition) you also would have a chance to try and change from ODBC to ADO as you see fit. ADO has features that are not possible with ODBC (at least not as direct as ADO does) and I'd understand those as reasons to use ADO as you see fit.
The real problem is SQL2005 by itself is a huge thing to learn (I don't mean to start using it, I mean getting all of its benefits).
Cetin