• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 30. Working with ADO Recordsets,... > In the Real World—Adapting to ADO

In the Real World—Adapting to ADO

Many Access (and Visual Basic) developers with a long-term investment in memorizing the DAO hierarchy are loathe to adopt ADO and its flattened object model. One of the tenets of business process reengineering—which has finally received some of the bad press it deserves—is empowering cubical dwellers and assembly-line workers by flattening corporate organization charts. The underlying theory is that empowered employees are happier and more productive, which results in improvements to the bottom line of income statements.

Unfortunately, ADO doesn't empower DAO programmers, because ADO/ADOX 2.1 doesn't yet have feature parity with DAO 3.x, nor is the performance of ADO 2.1 substantially better than DAO 3.6. Problems with the ADODB.Find method are just one of the issues raised by DAO proponents as a reason for avoiding migration to the Lotusland of Universal Data Access. Few Access and Visual Basic programmers have indicated that ADO 2.x, at least so far, has made them happier, more productive, or improved the bottom line of their employers or their own businesses.


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint