18 Feb 12 12:27
>Have you a short example of the code required?
As mentioned: "not have to use the DC for this, except as an object to pass your recordset to"
You basically do it the same way with the ADODB DataGrid, except you assign the recordset to the DC which was set the the Grid's datasource.
The recordset will be passed thru to the data grid's datasource.
I have used this method a long time with concurrent users and never ever had any problems as ther are with the typical DC problems, simple because the DC isn't handling the connection but your in-code connection object is doing the work.
So, add a DbGrid and a DC and set in the properties window the grid's datasource to the DC: But do not change anything in the DC - no recordset info and no connection info!!!
Add a DAO recordset object variable at module level, and open it (just as you are now doing with the ADODB DataGrid's recordset)
In code assign the DC's Recordset property to the recordset object variable.
2. DAO will be faster simply because there isn't that extra layer used between your code and the dbms. The dbms itself - Jet 4 -is basically the same. It is a matter of getting data to and from it, where DAO directly interfaces with JET, and ADODB doesn't.
I am not sure if "7 times" is always a fair representation - it depends on "for what and how". I can return the first thousand records of a 100,000 record-recordset for display in a grid 10, 20, 50 times faster with ADO than DAO, simply because under ADO you can use Async fetching.
As long as DAO, (and any DAO-bound controls used with it - though these are not needed) works for your needs on all future operating systems, then there is no reason to change to ADO...until it doesn't.
If one day DAO ceases to work on an OS (or your requirements change: More data, more concurrent users, different dbms, etc), then you will be in need of a fast change of code in order to adjust your application to using ADODB.