What Will This Book Do for Me?

[Previous] [Next]

There is no substitute for a clear understanding of the requirements for the application you want to build or for experience with the tools you want to use to build that application. I can't stress this point strongly enough. While this book won't help you define the requirements, it will help you develop proficiency with ADO.

I don't believe there's a "best way" to use ADO. How you build your database applications will depend on what type of database you're accessing, the number of simultaneous users, the amount of code you're willing to write, and the amount of control you require over what's happening in your application, as well as your delivery schedule. This book will help you develop enough expertise with ADO so that you can decide what way is best for you, depending on the requirements of your application. It is designed to serve as an in-depth reference for the object model, as an explanation of much of the functionality of the cursor engine, and as a starting point for you to determine how to build your applications.

To begin Part I, we're going to cover the ADO object model. This material might already be familiar to those of you who have perused the ADO documentation that's included with many products and in the Data Access SDK, but I have a couple of reasons for not relegating it to an appendix. First, the simple act of reading through the list of features available in the ADO object model can help you come up with ideas. You never know when intuition will strike. Second, the properties, events, and methods that have caused the most confusion for developers are presented in more detail than in the ADO documentation.

After covering the object model in Chapters 2 through 6, we'll look at two more topics—cursors and update techniques—before closing Part I of the book. The type of cursor you use and how you plan to update your database are probably the two most important choices you'll make in how you use ADO, so we'll cover those topics in some detail.

Part II focuses on the ADO Cursor Engine. Chances are that when you develop your applications, you'll go one of two routes: either you'll depend primarily on the functionality made available by the ADO Cursor Engine, or you'll rely completely on your own code. Regardless of which path you choose, this material on the ADO Cursor Engine should be considered required reading.

Obviously, if you are going to use features of the ADO Cursor Engine, you should develop as much expertise with them as possible. The more you learn about how these features work, what their limitations are, and what's really going on behind the scenes, the less likely you'll be to code yourself into a corner. You'll also shorten your development time by leveraging features available in the ADO Cursor Engine.

Warning and Apology

The next few chapters are boring, especially if you're already familiar with the object model and the documentation. And for those who haven't done much programming with ADO, these chapters will still be boring. Regardless of which group you fall into, you can read Chapters 2 through 6 at your own discretion. They build character, and studies have shown they can cure insomnia.

Even if you plan on handling the task of updating your database by writing your own data access code, you can learn a lot from reading the chapters on the ADO Cursor Engine. You might decide that the features implemented by the ADO Cursor Engine are so logical and well thought out that you should do something very similar in your code. Perhaps when you read about the limitations in client-side recordsets, you'll understand the cause of those limitations, and therefore avoid such problems yourself. You may even come to the conclusion that the ADO Cursor Engine is the coolest thing you've ever seen and that you're going to use it rather than write large amounts of your own code. Hey, you never know.

There's even a middle ground. Some developers employ a mix of ADO features and their own code—using the ADO Cursor Engine to maintain their data and interact with the client application while using their own code to modify the contents of the database. Other programmers plan their applications so that they can initially rely on ADO features and then smoothly migrate to features they built themselves. Regardless of your plans, the information in Part II should prove useful.

Included as an appendix to this book is an introduction to Microsoft ActiveX Data Objects Extensions for Data Definition Language and Security (ADOX) and Jet and Replication Objects (JRO). These two libraries were implemented as part of ADO 2.1 to be used in conjunction with ADO.

ADOX is designed to mirror DAO's data definition features. You can use it to retrieve schema-type information about your database. In contrast to DAO, however, ADOX does more than retrieve this data in read-only mode. You can use ADOX to modify the structure of your database by adding and deleting tables, columns, and indexes. The ADOX object model also provides objects for managing security.

JRO adds Jet-specific features to ADO that were previously available only through DAO. As its name implies, you can use JRO to replicate Jet databases. JRO provides other Jet-specific features such as compacting databases and refreshing the Jet cache.

We'll cover ADOX and JRO in Appendix A.