Mixing DAO and ADO (2000sp3)

Topic

New Reply

I have some bits of stock code that I’d like to use in a database that’s been written, by someone more up to date than I, using ADO. I’ve never used ADO, and really don’t have the time to learn right now. All my objects are explicitly declared as DAO, and I’ve added a reference to DAO to the db, but left it below ADO in the ref list, as I don’t know if all the ADO objects were explicitly declared as such.

Can I expect problems? Will they be easily traceable, or is it more likely to be a case of weird and unpredictable behaviour.

Thanks

Reply | Quote

Replies

I think you’ll be OK. Since ADO is above DAO in the references list, VBA will use ADO for ambiguous objects that have not been declared as ADO or DAO explicitly. Even if the other developer has not explicitly declared his objects as ADO, they will still be interpreted as ADO objects. Your code does explicitly declare objects as DAO, so there should be no problem with them.

Of course, you could search the project for ambiguous declarations, by looking for As Recordset and As Field, to name the most obvious ones.

Reply | Quote

I think you’ll be OK. Since ADO is above DAO in the references list, VBA will use ADO for ambiguous objects that have not been declared as ADO or DAO explicitly. Even if the other developer has not explicitly declared his objects as ADO, they will still be interpreted as ADO objects. Your code does explicitly declare objects as DAO, so there should be no problem with them.

Of course, you could search the project for ambiguous declarations, by looking for As Recordset and As Field, to name the most obvious ones.

Reply | Quote

In addition to Hans suggestions, do NOT try to mix DAO and ADO in the same routine. In other words, don’t try to call ADO code from a DAO routine and vice versa. It sometimes is OK and other times dumps you unceremoniously back to the desktop without even the courtesy of an error message. I’ve built projects using both models, but I learned early to avoid mixing them in a single routine.

Reply | Quote

In addition to Hans suggestions, do NOT try to mix DAO and ADO in the same routine. In other words, don’t try to call ADO code from a DAO routine and vice versa. It sometimes is OK and other times dumps you unceremoniously back to the desktop without even the courtesy of an error message. I’ve built projects using both models, but I learned early to avoid mixing them in a single routine.

Reply | Quote

I also try to make sure I disambiguate any object references, e.g.
Dim Rst1 As ADODB.Recordset
Dim Rst2 As DAO.Recordset

– oh, just upgraded to Access 2003 and now the default references in a new database include DAO and second ADO

Reply | Quote

Yes, even though Microsoft has declared DAO obsolete, they seem to have recognized that ADO isn’t suited to handle the application objects the way DAO is and so they have resuscitated it in 2003. Including both references means that disambiguating your declarations is NOT an option, it is absolutely vital. Oh, and you still can’t interact between DAO and ADO objects, so don’t try it.

Reply | Quote

Thank you all for your reassurance.

Just to clarify, Charlotte, when you talk about a DAO routine calling ADO code, you’re referring to “built in” code: if a user written sub routine using ADO calls a user written function which uses DAO it should be OK? This is the situation I have, as my stock bits of code are called regularly (one is a custom message box function, for instance).

Thanks again

Reply | Quote

No, it may not be OK. If all you’re doing is popping up a messagebox, it will be OK because those are built-in VBA functions rather than DAO or ADO. But you can’t mix objects. ADO Table objects are not the same as DAO TableDef objects, for instance, and you can’t manipulate them the same way. You can’t use a DAO recordset to perform manipulations with ADO. Interface objects like forms and controls are not object model specific, but the way you interact with them through code is. The Forms collection and the AllForms collection don’t have the same methods and properties. The former is used with DAO and the latter with ADO.

Reply | Quote

No, it may not be OK. If all you’re doing is popping up a messagebox, it will be OK because those are built-in VBA functions rather than DAO or ADO. But you can’t mix objects. ADO Table objects are not the same as DAO TableDef objects, for instance, and you can’t manipulate them the same way. You can’t use a DAO recordset to perform manipulations with ADO. Interface objects like forms and controls are not object model specific, but the way you interact with them through code is. The Forms collection and the AllForms collection don’t have the same methods and properties. The former is used with DAO and the latter with ADO.

Reply | Quote

Thank you all for your reassurance.

Just to clarify, Charlotte, when you talk about a DAO routine calling ADO code, you’re referring to “built in” code: if a user written sub routine using ADO calls a user written function which uses DAO it should be OK? This is the situation I have, as my stock bits of code are called regularly (one is a custom message box function, for instance).

Thanks again

Reply | Quote

Yes, even though Microsoft has declared DAO obsolete, they seem to have recognized that ADO isn’t suited to handle the application objects the way DAO is and so they have resuscitated it in 2003. Including both references means that disambiguating your declarations is NOT an option, it is absolutely vital. Oh, and you still can’t interact between DAO and ADO objects, so don’t try it.

Reply | Quote