ADO (the much maligned ADO, that is) is truly a great technology. You have a choice of recordset, Connection, Command and Parameter objects to create your recordset. They can be used in Access forms easily by setting the recordset property of a form to an ADO recordset (A2K only). This will temporarily unbind your Form, but so what! You could create an unbound form with unbound controls and set their values to the fields in the recordset. And the beauty is that you don't even need to have tables linked to your application. They would link as a VB form would. You could use ADO to reuse forms easily. And performance is increase by leaps and bounds. I was a DAO stalwart until I had to create an Access app that summerized data stored in a SQL Server 7.0 database. DAO was as slow as using querydefs. But, ADO Commands, Connections and Recordset sped up all of my forms. That's why I believe that backend processing is being done without Jet involved. The only drawback (though not really in this world of changing technologies) is that ADO requires that you use SQL syntax that is natural to the database you are connecting to. For instance, with SQL Server, you will have to use Transact-SQL language process your sql statements. Still, if you are interested in enterprise development, which Access is a great development tool for, you would have to learn Backend languages anyway. I personally see Access as a development tool that has a database engine with it - you don't have to use that engine if you don't want to. Plus, you can create and execute stored procedures on the database that process data faster than normal queries, and they can be dynamically created or sent parameters without adding the SQL to your code - its already on the database. Although it is a little difficult at first (very frustrating at times really) once you've mastered creating a connection string, you have everything you need to get ADO to do all of the work for you.
Sorry this was so long.
Bob
