[ Pobierz całość w formacie PDF ]
.SummaryDay 21 explains how to integrate error handling into OLE DB applications.You learned how toimplement basic error-handling techniques and how to check the HRESULT of a method with theSUCCEEDED and FAILED macros to determine whether the method executed correctly.Then youlearned how to use the ISupportErrorInfo interface to determine whether an OLE DB objectsupports extended error information.You used the IErrorRecords and ISQLErrorInfo methods to create the DispErrorInfo procedure, which can display extended error information for any OLE DB object.Q&AThis section answers some common questions related to today's topics.Q Should my application look for and try to interpret specific HRESULT values?A If you look at the OLE DB error information, you will see that as each method isdefined, the most common HRESULT values that the method can return are listed.Auseful exercise is to try to interpret certain warning result values.You can be assuredonly that an OLE DB provider supports the methods and interfaces that are required.Ifyou attempt to access an optional interface, you will need to be sure that yourapplication can still function if the data provider doesn't support that interface.Q Is there any way other than checking the HRESULT value of each method call toadd error handling to my OLE DB application?A Unfortunately, no.To ensure the highest degree of error checking in your applications,you must check each method's HRESULT value.You must realize that one failed methodcan cause a cascading error effect.Again, the best technique is to design yourapplications to be robust so that they offer only the functionality provided by the OLEDB data provider.A robust application is one that can handle all error conditionswithout crashing for the end user.As an application developer, you are responsible forhandling all errors that your application might generate.WorkshopThe Workshop quiz questions test your understanding of today's material.(The answers appear inAppendix F, "Answers.") The exercises encourage you to apply the information you learned today toreal-life situations.Quiz1.Name the two macros used to check the result of an OLE DB method call.2.Which interface checks whether an OLE DB object supports extended error information?3.What are the special requirements of OLE DB error handling that aren't resolved byAutomation error-handling objects?4.What information does the GetBasicErrorInfo method return? Describe the elements ofthis structure.5.How do you retrieve a custom error object? What custom error objects does OLE DB provide?6.List the basic techniques for OLE DB error handling.7.Which method does a data provider use to add a new error?8.Explain the difference between HRESULT constants with the prefix DB_S and those with theprefix DB_E. Exercises1.Review the generic HRESULT return values.They can be found in the Visual C++documentation.2.A sample called DECODE is available in the Microsoft Software Library.The DECODEapplication enables you to enter an HRESULT in a dialog and have it decoded to its textdescription.3.Integrate the DispErrorInfo procedure and error checking into one of the data consumerexamples created in an earlier lesson.4.Listing 21.4 shows how to call the DispErrorInfo procedure from within another program.© Copyright, Sams Publishing.All rights reserved. Teach Yourself Database Programmingwith Visual C++ 6 in 21 daysWeek 3.In ReviewIn Day 15, to start your final week of study, you learned to view ODBC and DAO APIapplications and understand the mechanisms used to process databases.You took a lookat using the MFC wrapper classes.Also, you saw that data binding is automaticallyperformed and the RFX mechanism is configured.In Day 16's lesson, you saw how OLE DB builds on and expands the capabilities ofODBC.Because OLE DB providers can be written for nonrelational data sources, OLEDB provides an interface to relational, as well as nonrelational, data sources.OLE DBtakes an object-oriented approach to database client development, whereas ODBC takesa function-based API approach.The OLE DB object hierarchy consists of just a fewobjects, which expose COM interfaces to perform well-defined sets of functions.You learned on Day 17 the process of integrating OLE DB into applications byexamining the relationship between COM and OLE DB and seeing how COMtechnology influences the OLE DB programming model.On Day 18, you examined OLE DB objects, specifically the Session and Commandobjects, and the interfaces they provide.You learned how to create a Session objectby using the IDBCreateSession interface of the DataSource object and how tocreate a Command object by using the IDBCreateCommand interface of theSession object.The section on Command objects includes a brief review ofStructured Query Language (SQL).Examples also focus on using the OLE DB ODBCdata provider to access a SQL Server data source. In Day 19's lesson, you started with a discussion of the Rowset object and itsassociated interfaces.You brought together the concepts presented in the previous threelessons so that you could begin to make productive use of OLE DB.You learned, on Day 20, three important topics in OLE DB application development:properties, transactions, and the Index object.Other topics covered include how to useproperties to control the state of an object, the Transaction object, and the Indexobject [ Pobierz caÅ‚ość w formacie PDF ]
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • agnieszka90.opx.pl