Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypr

EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypram.com 1 EXPRESS OLE DB LIBRARY User’s Guide SYPRAM TECHNOLOGY Copyright © 2001. EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypram.com 2 EXPRESS OLE DB LIBRARY : USER’S GUIDE 1. EXPRESS OLEDB LIBRARY: AN OVERVIEW i. THE DILEMMA OF DATA ACCESS a. Native Library b. ADO c. OLE DB Consumer Templates ii. INTRODUCTION TO EXPRESS OLE DB LIBRARY iii. CLASS HIERARCHY a. Operations classes b. User Interface classes c. Utility classes d. Enhanced consume template classes iv. LIMITATIONS v. SOFTWARE REQUIREMENTS 2. INSTALLATION AND SETUP i. Installing the library ii. Configuring Visual C++ iii. Setup and testing 3. GETTING STARTED i. USING THE LIBRARY IN VISUAL C++ PROJECT ii. USING THE CLASSES iii. CONNECTING TO DATA SOURCES a. Connecting to data source using standard properties i. Connecting to a JET database ii. Connecting to an SQL Server database iii. Connecting to an ORACLE database iv. Connecting to an ODBC data source b. Connecting to data source using custom properties c. Setting the connection timeout property d. Using OLE DB service components iv. WORKING WITH RECORDSETS a. Opening a recordset b. Cursor Locations c. Navigating through rows d. Fetching data EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypram.com 3 v. INSERTING, EDITING, AND DELETING ROWS a. Add new record b. Editing a record c. Deleting a record vi. WORKING WITH BLOB DATA a. Read BLOB value from database b. Storing BLOB value in the database vii. EXECUTING AN ACTION QUERY viii. EXECUTING STORED PROCEDURES ix. TRANSACTIONS 4. CONTACT INFORMATION i. GETTING MORE INFORMATION ii. TECHNICAL SUPPORT ******************************************* EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypram.com 4 EXPRESS OLEDB LIBRARY: AN OVERVIEW THE DILEMMA OF DATA ACCESS When it comes to choosing the right data access technology for application development, most Visual C++ programmers face a puzzling set of choices. Not only are these choices limited, but also they are conflicting in terms of performance requirement and ease of use. Whether it is a stand-alone application, a client/server application or a web application, a C++ programmer would never like to compromise the factors of decision such as performance, speed, and resource management. The simple reason for this fact is the underlying tenet that the C++ programmers are supposed to churn out the smartest applications in the programming world. Although the type and make of the database as well as the nature of application can largely influence the decision, it is not as easy as it seems. Let us try to understand and analyze some of the most obvious data access choices: Native Library: Native libraries are supplied by many database vendors and they provide fastest data access for the respective databases. However, due to the well-known fact that the code written using a native library is not portable to other databases, your application gets locked into the database vendor’s technology. Moreover, each native library is totally different in nature compared to other libraries. So, we will not devote any time discussing this option in detail and leave it to the developers to explore further on this topic. ADO: Since its introduction, ADO has been the most widely used option for data access on Windows platform. Though primarily designed and developed for Visual Basic and scripting languages, it is not used less in Visual C++ world. After ODBC, ADO is the major library that is proven and tested for data access on the Windows platform. Thousands of developers, using various programming languages on the windows platform, rely heavily on ADO for the data access needs of their applications. Having said that, you might wonder why ADO is not an ideal choice for Visual C++ developers. Well, here is why: a. ADO is designed for use with the automation-based languages. So, everything it speaks is in terms of VARIANT, a data type that is hated most by C++ developers. When it comes to using VARIANTs and EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypram.com 5 BSTRs, C++ developers get a hitch. The reason for this disliking is clearly understandable. Converting a VARIANT to and from the native data types of C++ is really a pain. Not only does it call for extra work, but also it affects the overall performance of the application. b. ADO is a set of wrapper classes that are built on top of OLE DB interfaces. So, it puts an extra layer as far as C++ is concerned since OLE DB interfaces can be directly accessed through C++. Theoretically, an application that uses OLE DB interfaces is considerably faster than the one that uses ADO. c. Using ADO in Visual C++ also comes with other drawbacks and limitations. If you use #import statement, you cannot avoid jump-to- exception situation even if you want to avoid it. Additionally, you loose flexibility of having default arguments to the methods. You must provide all method arguments. If you use ADO SDK or raw COM interfaces, you have to check for HRESULT values at each and every point. Since data access code normally requires frequent method calls, it becomes cumbersome to check these values. Concluding on all the points mentioned above, we could say that ADO should be the choice of data access for C++ programmers only if there is no other better choice. OLE DB Consumer Templates: To overcome the limitations of using ADO in C++, Microsoft provided OLE DB consumer templates for C++ developers. Like ADO, they are a set of template classes that are also built around OLE DB interfaces. However, unlike ADO, these classes put only a thin layer on OLE DB and therefore they are lighter, faster, and much more powerful. Besides, consumer templates make a native C++ class library, i.e., it is a pure C++ class library and hence it uses the native C++ data types. So, using these classes eliminate the need for using VARIANTs or BSTRs. Putting all these facts together, one can easily conclude that OLE DB consumer classes have an edge over ADO. Yes, they definitely have. You might w onder then, why in the world would any C++ programmer use ADO at all. Adding to your wonder is the fact that more C++ developers use ADO in their applications than OLE DB consumer templates. But, wait a minute. There are several good reasons for this fact. Let us see. I am going to list a few of these reasons below. a. Memory leaks & bugs : The OLE DB consumer templates contain several EXPRESS OLE DB Library: User’sGuide Copyright©2001. Sypram Technology. www.sypram.com 6 classes with bugs and memory leak problems. Most notable of them are the methods of CDataSource class that leak memory and the column binding in CDynamicAccessor class that does not handle wide characters properly. As of Service Pack 5 of Visual Studio 6.0, these problems are not fixed. b. Lack of features and flexibility: Although consumer templates are much easier to use than raw OLE DB interfaces, they lack several features and functionalities compared to ADO. Checking EOF/BOF status in a rowset, handling BLOB data, refreshing and updating a rowset, and fetching error details from HRESULT values are just a few of them to list. Using a data access library without these features in your application is a lot of work in itself. c. Error reporting: Most methods of consumer template classes return some HRESULT value. Getting error details from these values requires a fair amount of effort, especially if you want to get the error messages from database server. There is no easy shortcut in consumer templates to do this. d. Lack of XML support: There is no XML support so far in the consumer template classes. Looking at the .NET version of Visual C++, it seems like Microsoft is planning to incorporate XML support in .NET consumer templates. But till then, you have to resort to your own knowledge of database and XML if you use consumer templates. e. Cryptic and sparse documentation: If you have moved from ADO to consumer templates, you would find the documentation of consumer templates suffocating. The documentation provided in MSDN is short and sparse and very limited in terms of providing examples and samples. In addition to all these facts, there is hardly any good book in market on OLE DB consumer classes that provides the complete coverage of all the classes. f. Binding to controls: Unless you are writing a middleware component or a web application, you need to display your data in some form of GUI components. It could be as simple as a text box or as complex as a compound spreadsheet grid. In any case, you need to bind your data to the user interface at some point of time in your application development cycle. Most commercial controls provide data-binding support for ADO. However, since consumer templates are a low- level interface to data, the binding responsibility is rested upon the developer. And binding data to a control is not as simple as point-and-click. This is uploads/Geographie/ prog-guide 2 .pdf