vcgfm.htm

Visual C++与数据库的连接经典实例

<A NAME="E68E7"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>A Database Developer's View of Visual C++</B></FONT></CENTER></H3>

<BR>

<P>Making the choice between Access, Visual Basic, Visual FoxPro, Paradox for Windows, dBASE for Windows, Delphi, or Visual C++ as your primary database development platform is not a simple matter, especially for seasoned developers of character-based applications. Most programmers don't consider Visual C++ to be a database development tool, so they adopt one or more of the popular Windows desktop database systems or Visual Basic.

<BR>

<P>FoxPro for Windows offers xBase language compatibility and, without question, is the fastest of all the Windows desktop databases. Access has a unique user interface that lets you run simple to moderately complex database applications with a minimum of effort, and it also supports OLE controls (OCXs). Visual Basic offers more programming flexibility than Access, and you can incorporate a variety of commercial and shareware OLE controls to simplify database front-end development. The Paradox for Windows desktop RDBMS has a wider variety of field data types than any RDBMS, Windows or DOS, including client-server database systems. Each of these products has its own feature set, together with limitations that might not become apparent until you're embroiled in your first large-scale client-server database front-end application. Chapter 1, &quot;Positioning Visual C++ in the Desktop Database Market,&quot; compares Visual C++ to your alternatives among the major combatants in the Windows database wars.

<BR>

<P>If you've invested several years in developing xBase or PAL programming skills and are reluctant to abandon xBase RDBMSs or Paradox for a new object-oriented, event-driven Windows programming language, welcome to the crowd. COBOL programmers have the same problem when their employers downsize from mainframe &quot;legacy&quot; databases to client-server systems running on PCs. Unfortunately for PAL programmers, the ObjectPAL programming language of Paradox for Windows bears little resemblance to the character-based PAL of Paradox. xBase and PAL, however, all have their roots in the original Dartmouth BASIC. The C programming language has a structure similar to PL/I or PASCAL. Thus, you might find the structure of Visual C++ applications similar to the xBase or PAL programs you're now writing.

<BR>

<P>If only C++ were as simple as C! C is, for the most part, easy to use, but when many programmers are exposed to C++ for the first time, they find it to be totally different than C. Nothing could be further from the truth, however. C++ is easy to learn and adapt to if you remember that the original C language is a subset of C++. The quickest conversion from C to C++ is to simply rename the file.

<BR>

<P>Simply choosing Visual FoxPro, dBASE for Windows, or Paradox for Windows because you're accustomed to writing xBase or PAL code isn't likely to be a viable long-term solution to your Windows database development platform dilemma (notwithstanding John Maynard Keynes' observation that &quot;in the long term, we are all dead&quot;). If you create Windows applications for a living, either as an in-house or independent developer, you're expected to provide your firm or client with applications that incorporate today's new technologies. You need to prepare now for OLE, with its in-place activation and OLE Automation (OA), and Visual C++ OLE controls. Windows is where the action is. More than 60 million copies of Windows (a mixture of Windows 3.x, Windows 95, and Windows NT) give Microsoft the marketing clout to make OLE, ODBC, and OLE controls the &quot;standards&quot; of the desktop computers of the world (whether the &quot;industry&quot; agrees or not). The alternative vaporware standards proposed by groups of software vendors organized to combat the Microsoft behemoth are very unlikely to replace OLE, ODBC, and OLE controls in the foreseeable future.

<BR>

<P>Windows desktop database applications present a challenge to developers accustomed to writing a thousand or more lines of code to create character-based RDBMS applications in Visual Basic, xBase, PAL, C, or other programming languages. You can create a very simple but usable Visual C++ database application with AppWizard and very little Visual C++ code. One example in this book contains no programmer-written code at all. Microsoft Access offers code-free capabilities&#151;if you don't consider Access macros to be code. You'll need to write substantial amounts of code to create a usable database application with dBASE, Visual FoxPro's xBase, or Paradox's ObjectPAL. However, the reality is that you have to write a substantial amount of code to create a commercial-quality production database application with any of these products. The issue isn't how much code you have to write, but in which language you will write the code. Here are some of the language issues that will affect your career opportunities or the size of the numbers on your 1099s:

<BR>

<UL>

<LI>xBase and PAL are yesterday's most prevalent desktop database programming languages. Will xBase and ObjectPAL ultimately survive the onslaught of Microsoft's present Object Basic dialects, such as Visual Basic and the Visual Basic for Applications (VBA) variants of Microsoft Word 7, Access 7, and Excel 7?

<BR>

<BR>

<LI>Visual C++ lets you write incrementally compiled database applications that don't require helper libraries such as VBRUN300.DLL. Borland's Delphi offers fully compiled .EXEs but uses a variation of Pascal as its programming language. Does Delphi's Pascal really stand a chance of replacing C++ as the preferred language for writing commercial Windows applications or of making Object Basic/VBA extinct as an application programming (macro) language?

<BR>

<BR>

<LI>Visual C++ 4, Access 7, and Visual Basic 4 act as containers for OLE Custom Controls. Excel, Word, and Project also support OLE controls. Will many of the new applications systems that will be released in the next few years also support OLE controls?

<BR>

<BR>

<LI>Visual C++ 4 allows cross-platform development for a number of different platforms, including applications for Macintosh computers. Microsoft now has a Macintosh version of Visual C++ that enables Windows developers to easily port their Windows applications to the Macintosh. Most development done under Windows NT can be directly ported to Windows 95 with minimum modifications.

<BR>

<BR>

</UL>

<P>This book doesn't purport to answer these questions directly, but you're likely to reach your own conclusions before you finish reading it.

<BR>

<P>At the time this book was written, Visual C++, Visual Basic 4, and Access were the major database development platforms to fully support OLE, OLE Automation, and OLE controls. Visual C++ is the only development platform, other than Visual Basic, that lets you create your own OLE Automation miniservers. Chapter 16, &quot;Creating OLE Controls with Visual C++ 4,&quot; and Chapter 17, &quot;Using OLE Controls and Automation with Visual C++ Applications,&quot; describe how OLE, OLE Automation, and OLE controls fit into your decision-support database front ends.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>NOTE</B>

<BR>

<BR>Access 2 was released before the OLE Custom Control specification was finalized and many months before the retail release of Microsoft Visual C++ 2.0's Control Development Kit (CDK), which developers need in order to implement OLE controls. Access 2's OC1016.DLL isn't compatible with the final version of commercial OLE controls designed for use with Visual C++, which use OC25.DLL. The Access 2 Service Pack updates Access 2.0 to accommodate 16-bit OLE controls based on Visual C++ 1.5's OC25.DLL. If you find that you need to work with Access 2, you should keep these restrictions in mind. Access 7 doesn't present these problems.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Whatever language you ultimately choose, you must adapt to the event-driven approach to application design, inherited from the Windows graphical user interface (GUI). You also need to face the fact that Windows applications won't perform with the blazing speed of your Clipper or FoxPro applications running directly under DOS. Few, if any, Windows applications can match their DOS counterparts in a speed contest, but this situation is likely to change when you run your 32-bit database front end under Windows NT on a high-powered RISC workstation. Fortunately, most Windows users have grown accustomed to the sometimes sluggish response of Windows. It's possible, however, to design Visual C++ client-server front ends that rival the performance of their character-based counterparts. Chapter 15, &quot;Designing Online Transaction-Processing Applications,&quot; and Chapter 20, &quot;Creating Front Ends for Client-Server Databases,&quot; provide examples of &quot;plain vanilla&quot; front ends that deliver excellent performance.

<BR>

<BR>

<A NAME="E68E8"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Visual C++ and Microsoft BackOffice</B></FONT></CENTER></H3>

<BR>

<P>When this book was written, Microsoft Office (both 4.2x and Office 95) had garnered more than 80 percent of the Windows productivity application suite (front-end) market. Microsoft Office 4.2 includes Excel 5.0, Word 6.0, PowerPoint 4.0, and a Microsoft Mail 3.2 client license. Microsoft Office 95 includes Excel 7, Word 7, and PowerPoint 7, all in 32-bit versions that run under both Windows 95 and Windows NT. The Professional Versions of Microsoft Office also include Microsoft Access (Office 4.3 contains Access 2.0, while Office 95 includes Access 7). Encouraged by the success of Office, Microsoft introduced its server (back-end) suite, BackOffice, in the fall of 1994. Microsoft BackOffice comprises a bundle of the following server products:

<BR>

<UL>

<LI>Microsoft Windows NT 3.51 Server, the operating system on which the other components of BackOffice run as processes.

<BR>

<BR>

<LI>Microsoft SQL Server 6 , a client-server RDBMS. Will be upgraded to Microsoft SQL Server 6.5 in the spring of 1996.

<BR>

<BR>

<LI>Microsoft SNA Server 2.11, which provides connectivity to IBM mainframes and AS/400 series minicomputers via IBM's System Network Architecture.

<BR>

<BR>

<LI>Microsoft Systems Management Server (SMS) 1.1, which helps you distribute software and track client hardware and software. Version 1.2 is scheduled to be released to beta sites sometime in 1996.

<BR>

<BR>

<LI>Microsoft Exchange Server, which integrates e-mail, group scheduling, electronic forms, and groupware applications on a single platform that can be managed with a centralized, easy-to-use administration program. It's designed to make messaging easier, more reliable, and more scalable for businesses of all sizes.

<BR>

<BR>

<LI>Microsoft Mail Server 3.5, a file-sharing e-mail system. Will be upgraded to Microsoft Exchange Server when it becomes available in the spring of 1996.

<BR>

<BR>

</UL>

<P>Like Microsoft Office, you get a substantial discount (of about 40 percent) from the individual server license prices when you purchase the BackOffice bundle. Unlike earlier versions of Windows NT Server and SQL Server, which were available in &quot;Enterprise&quot; versions with unlimited client licenses, BackOffice doesn't include client licenses. The commercial success of BackOffice, is by no means assured. It's not likely that large numbers of major corporations, the target market for BackOffice, will adopt this bundle until final versions of all of its promised components are delivered, which might not happen until 1997.

<BR>

<P>Microsoft SQL 6.0 and Exchange Server use OLE and OLE Automation pervasively. The Messaging API 1.0 (Extended MAPI), on which Exchange is based, uses Messaging OLE objects, and Schedule+ 7.0 has its OLE/Schedule+ object collections. The development tools for Microsoft SQL Server 6.0 RDBMS and Exchange e-mail system use VBA. (Exchange Server is a nonrelational database optimized for messaging services.) Ultimately, all of the members of the BackOffice suite are likely to offer VBA extensions for customization. Microsoft has positioned Visual C++ as a development platform for &quot;building solutions&quot; based on BackOffice servers. Visual C++ developers stand to gain a huge new revenue base writing database applications for Microsoft Exchange and SQL Server 6.0.

<BR>

<BR>

<A NAME="E68E9"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Who Should Read This Book</B></FONT></CENTER></H3>

<BR>

<P>This book is intended primarily, but not exclusively, for the following categories of readers:

<BR>

<UL>

<LI>Visual C++ developers who want to take maximum advantage of Visual C++'s database connectivity to create high-speed, production-grade graphic front ends for a variety of desktop and client-server databases.

<BR>

<BR>

<LI>Access developers who have found that they need more control over their data display and editing forms than is afforded by the present version of Microsoft Access. Visual C++ database applications also consume far fewer Windows resources than equivalent Access applications.

<BR>

<BR>

<LI>Visual Basic developers who want to take advantage of Visual C++'s automated access to the Windows APIs, gain function callback capability, and manipulate pointers.

<BR>

<BR>

<LI>Developers of character-based DOS database applications whose clients or organizational superiors have decided to migrate from DOS to Windows applications.

<BR>

<BR>

<LI>Users of xBase or Paradox products who need to create industrial-strength, 32-bit database front ends running under Windows 95 or Windows NT 3.51. (Windows NT 3.51 might not yet be a major player in the operating systems numbers game, but firms that adopt Windows NT 3.51 are major employers of database consultants.)

<BR>

<BR>

<LI>Programmers who would like to develop database applications by expending less than 25 percent of the time and effort required to create equivalent applications with C and C++. Those addicted to C++ can quickly create prototype database applications with Visual C++. (It's amazing how many prototype Visual C++ applications become production database front ends.)

<BR>

<BR>

<LI>Victims of the corporate downsizing revolution, principally COBOL, PL/I, or FORTRAN programmers who need to acquire C, C++, and Windows database development skills to remain gainfully employed.

<BR>

<BR>

<LI>Users of proprietary GUI front-end development applications for client-server databases who are tired of forking over substantial per-seat licensing fees for each client workstation that is attached to the server.

<BR>

<BR>

<LI>Chief information officers (CIOs) or management information services (MIS) executives who need to make an informed decision as to which Windows front-end generator their organization will adopt as a standard.

<BR>

<BR>

<LI>Others who are interested in seeing examples of commercially useful Visual C++ database applications that earn developers a comfortable or better-than-comfortable living.

<BR>

<BR>

</UL>

<P>This book assumes that you have experience with Visual C++ or one of the traditional PC programming languages for Windows, such as Microsoft or Borland C or C++, Turbo Pascal for Windows, or the Windows version of SmallTalk. This book doesn't contain an introduction to C/C++ programming techniques; many excellent tutorial and references books are available to fill this need. (The bibliography that appears later in this Introduction lists some of the better books and other sources of information for beginning-to-intermediate-level C/C++ programmers.) Instead, this book begins with an overview of how Visual C++ fits into the desktop and client-server database market and proceeds directly to dealing with data sources in Visual C++. The entire content of this book is devoted to creating useful Visual C++ database applications, and most of the examples of Visual C++ code involve one or more connections to database(s).

<BR>

<P>All the code examples in this book, except for minor code fragments, are included on the accompanying CD. Sample databases in each of the formats supported by the Access 7 database engine are provided. Some of the sample databases are quite large, so you can use their tables for performance comparisons. Tips and notes based on the experience of database developers with Visual C++ and Access appear with regularity.

<BR>

<BR>

<A NAME="E68E10"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>What You Need to Use This Book Effectively</B></FONT></CENTER></H3>

<BR>

<P>You need Visual C++ 4 (or later) to re-create or modify the sample applications that appear in this book. Although you can use Visual C++ 2.x , Visual C++ 4 (or later) is a necessity for serious database development using the 32-bit environment provided by Windows 95 and Windows NT, mostly due to the fact that Visual C++ 4 supports DAO. Executable versions of selected sample applications are included on the accompanying CD, as are a number of programs, demos, and other items.

<BR>

<P>I strongly recommend that you purchase a copy of Microsoft Access if you intend to use Access .MDB database files in commercial applications. You can't really create new databases and add tables using the ODBC drivers that are supplied with Visual C++; however, DAO does allow the creation of Access databases. You can use Access's query design window to create a query graphically, test the result, and then copy the Access SQL statement underlying the query to your Visual C++ code. Using Access's Relationships window to establish rules for enforcing referential integrity and creating business rules that maintain domain integrity is much simpler than Visual C++'s code-centric approach. An additional benefit of acquiring Access is the availability of database design and documentation tools for Access that are not yet available to Visual C++ database developers. Some of the new design and documentation tools for Access databases are described in Chapter 4, &quot;Optimizing the Design of Relational Databases,&quot; and in Chapter 22, &quot;Documenting Your Database Applications.&quot; If you develop Visual C++ database applications for a living, you'll save many times your investment if you buy a copy of Access.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><B>NOTE</B>

<BR>

<BR>If you don't have Excel or Word for Windows, it might be well worth the investment to get the Microsoft Office Professional Edition, which includes Word for Windows, Excel, Access, and PowerPoint.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Developers of commercial database applications with Visual C++ are likely to want the additional features offered by third-party, data-aware custom controls. As these controls become available (WinWidgets/32 is an example), they can save the programmer substantial effort in developing applications. Although Microsoft has co-opted the data-aware grid, combo box, and list box OLE control market by providing 16- and 32-bit OLE control versions of these controls with Visual C++ 4, many third-party publishers offer quite useful enhancements to Microsoft's set. Several third-party custom controls are used to create the sample applications in this book. Sources of these OLE controls are provided in Appendix A, &quot;Resources for Developing Visual C++ Database Applications.&quot;

<BR>

<P>Most Visual C++ database applications for Windows 3.1+ and Windows 95 will perform satisfactorily on 80386DX/33 or faster computers with 8M or more of RAM. If you plan to use Access, you should have a minimum of 16M of RAM. If you plan to take full advantage of OLE and OLE Automation, 12M to 16M of RAM is recommended, regardless of which applications you will be running. All of the 32-bit versions of the sample applications in this book run satisfactorily under Windows NT Workstation 3.51 with 16M of RAM, and on a Windows 95 80386DX/33 with 8M of RAM. All development work was done on a Pentium 90 with 32M of RAM, a machine of acceptable performance. The authors recommend running Visual C++ 4 with at least 16M of RAM on a fast 486 (or better) processor.

<BR>