ADO version of QueryDef

[philfer]

Looking at the ADO object model is there an equivalent way of creating a stored query as you can with the QueryDef object in DAO or do you have to revert back to DAO (which I assumes was being phased out in favour of ADO)

Thanks
Phil

 

[Banana]

To answer your question at hand, I suppose the closest equilivant object would be Command but it's not that straightforward because you can just use ADODB recordset with a SQL command that does the same thing.

That said, I think we need to clear up some misconceptions. DAO isn't being pushed out in favor of ADO. On the contrary, MS reversed their position and took up DAO, and improved upon it. Access 2007 references a DAO library which is now developed by Access team. It used to be a separate project along with MDAC (Microsoft Data Access Compononents), and thus wasn't under the team's control back then. From Data Access Technology standpoint, it's obsolete so C++ programmers won't be using it anytime soon. But from standpoint of developing with Access, the DAO is the best way to work with Jet, in fact, it's very optimized for Jet. DAO also still have functionalities that ADO have yet to provide (e.g. managing schemas, permissions and security).

But! If you do have a backend such as SQL Server, you may find ADO is the better choice; it provides you with flexibility to create disconnected recordsets, execute query asynchronously, along other things. So, there is nothing wrong with using both, and that's what I actually do with the current project- DAO for local processing, ADO for interaction with the SQL Server.

HTH.

 

[dkinley]

I have been noticing a continuing theme of your questions ... you can do searches on the internet with phrases such as ADO vs DAO or vs SQL or vs JET for MS Access. You will hear many sides to all the arguments as people opine to what the future is going to be.

In my opinion, know your environment for where the application is going to be deployed and what their strategic plan is (expansion, scalability, etc) and make the best decision you can. If you build something and it doesn't work two years later, who's fault is that? Is it because you didn't do a proper requirements analysis or because the company strategy shifted after deployment?

In most cases, my design is whatever I feel comfortable with in the scope of requirements. If the environment changes and the application still has use ... great. If not, then they will need an upgrade or seek another way to compensate for the loss of the application. This is not a foreign concept to business - every time a new version of Windows comes out they are almost forced into this decision. For instance, they can pay extra up-front to write all the queries in SQL just in case they think they will go there one day. Or save money now and pay that cost in the future. It's their risk, as long as you do your duty to point it out in a risk assessment as part of the requirements - you did your job.

Anyhow - sorry to get off the mark but here is a link that may help with the different flavors that Access has ... well, access to. It goes into the implementation and some differences in each .....

http://www.functionx.com/vbaccess/

If you are unsure which method to use - again, I think it goes back to requirements because if you search - there are a plenty of arguments for one over the other.

-dK