Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!:Database Programming: Tools And Design
function GetCookie (name)
{
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen)
{
var j = i + alen;
if (document.cookie.substring(i, j) == arg) {
var end = document.cookie.indexOf (";", j);
if (end == -1)
end = document.cookie.length;
return unescape(document.cookie.substring(j, end));
}
i = document.cookie.indexOf(" ", i) + 1;
if (i == 0) break;
}
return null;
}
var m1='';
var gifstr=GetCookie("UsrType");
if((gifstr!=0 ) && (gifstr!=null)) { m2=gifstr; }
document.write(m1+m2+m3);
Keyword
Title
Author
ISBN
Publisher
Imprint
Brief
Full
Advanced Search
Search Tips
Please Select
-----------
Components
Content Mgt
Certification
Databases
Enterprise Mgt
Fun/Games
Groupware
Hardware
IBM Redbooks
Intranet Dev
Middleware
Multimedia
Networks
OS
Prod Apps
Programming
Security
UI
Web Services
Webmaster
Y2K
-----------
New Titles
-----------
Free Archive
To access the contents, click the chapter and section titles.
Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!
(Publisher: The Coriolis Group)
Author(s): Peter G. Aitken
ISBN: 1576102815
Publication Date: 08/01/98
function isIE4()
{
return( navigator.appName.indexOf("Microsoft") != -1 && (navigator.appVersion.charAt(0)=='4') );
}
function bookMarkit()
{
var url="http://www.itknowledge.com/PSUser/EWBookMarks.html?url="+window.location+"&isbn=0";
parent.location.href=url;
//var win = window.open(url,"myitk");
//if(!isIE4())
// win.focus();
}
Search this book:
Previous Table of Contents Next
Should Visual Basic Be Your Database Development Tool? Before moving to the main subject of how to use Visual Basic to create relational database front–end applications, an important question must be addressed: Should you use Visual Basic at all? I know this may sound like heresy coming from an avowed Visual Basic fan, but I would be remiss in my duties if I skipped this issue. The simple fact is that Visual Basic is not the preferred choice in all circumstances. This statement is not a slur on Visual Basic—no other tool brings such a combination of ease of use and power to database development—but to expect any one tool, no matter how terrific, to be the best choice for all jobs is unrealistic. This section briefly looks at some of the factors to consider when deciding whether to use Visual Basic. Programmer, Know Thyself One of the most important factors when deciding on a database–development tool is to assess your own experience and knowledge. Obviously, you are interested in Visual Basic or you wouldn’t be reading this book. But are you a complete novice at Basic, or do you have many years of Basic programming experience (with, for example, Quick Basic) and are new only to the “Visual” part? Perhaps you are an expert in xBase programming (the language used by the dBase family of database products and several clones, such as FoxPro) and are investigating Visual Basic as an alternate tool. If you currently have a programming project that is a “rush” job, with strict deadlines, you may be wise to go with the development tool that you know best and leave Visual Basic on the shelf until next time. If your timetable is more relaxed, however, that project may be a good opportunity to hone your Visual Basic skills while working on a real–world project.
Is It A Legacy Database? If you are being asked to write new front–end applications for an existing, or legacy, database, the nature of the existing database may place restrictions on your choice of development tools. Clearly, the existing data has to be retained, so the new application must be able to access it. Many old database systems run on mainframes or minicomputers and use obscure or antiquated database file formats. If you are completely revamping the entire system, you may be able to convert existing data files to a different format. If parts of the existing system will remain in use, you can’t modify the data file format. Instead, you have to select a development tool that supports that format. The next chapter provides information about the database formats supported by Visual Basic. The Visual Basic Fan Club As you can see, a few issues might steer you away from using Visual Basic for a specific database–application development project. In the absence of such particular issues, however, the selection of a development tool is still an important decision. I can’t claim to be completely objective, primarily because I have more extensive knowledge of Visual Basic than any other database development tool. That aside, here are some of the reasons why I think that Visual Basic leads the pack in Windows database development:
• Cost—You can distribute as many copies of a Visual Basic application as you like, without paying royalties. Many other development tools require payment of a license fee for each distributed copy of the final application. Furthermore, Visual Basic’s purchase price is considerably lower than many other database–development tools. • Flexibility—As a full–featured programming language, Visual Basic provides much more flexibility than development tools that are designed solely for database development. • Software components—Visual Basic’s support for ActiveX controls means that you have dozens of functional modules that you can drop into your application, providing sophisticated capabilities with little programming effort. • OLE and OLE Automation—With full support for OLE and OLE Automation (which was covered in an earlier chapter), a Visual Basic application has the capability to interact and integrate with other OLE applications. • Visual Basic for Applications—Microsoft is actively pushing Visual Basic for Applications (VBA) as the common control and macro language for all Windows applications. VBA has a great deal in common with Visual Basic, and programmers who learn to use Visual Basic will have a leg up on using VBA to integrate their applications with other Windows programs.
For More Information Visual Basic database programming is a large and complex subject. The next few chapters provide a good start, but not much more. When you’re finished with this book, you should have a firm grasp of the techniques needed to create a single–user, relational–database front end for both a decision–support application and a transaction–processing application. Using Visual Basic for professional database development, however, requires some real, in–depth understanding. Several books cover Visual Basic database programming exclusively, going into much more detail than I can here. If you finish this book and discover that your Visual Basic database programming needs are more demanding, I suggest that you read one of the more–specialized Visual Basic programming books.
The next section covers the database development tools that Visual Basic provides. As the previous chapter discusses, Visual Basic offers several different database technologies. The discussion in this chapter is limited to ActiveX Data Objects, or ADO, the newest and most powerful database tool in the Visual Basic arsenal. The Data Object Model Microsoft and Visual Basic approach databases based on something I call—for lack of an official name—the data object model. Why that name? Because, to a large extent, all the components that make up a database are objects. And what is an object? It’s a type of software component, just like the software components that you use daily in Visual Basic. Objects contain variables (properties) and subprograms (methods), and data objects sometimes contain members that are also objects. At times, objects are referred to as interfaces, because the object’s properties and methods provide an interface between the outside world (the program that is using the object) and its inner workings. The ADO model is the specific data object model addressed here. This model contains the following seven objects:
• Connection object—Represents the link between the datasource in use and the ADO objects. • Command object—Represents a query or statement that is sent to the datasource for processing. • Recordset object—Represents a set of data records that is returned by the datasource in response to a query. • Field object—Represents a single column of data within a Recordset object. • Error object—Contains information about error conditions reported by the datasource. • Parameter object—Represents a single piece of information, or parameter, associated with a Command object. • Property object—Represents a property of an ADO object.
The objects in the ADO model are organized as follows, and as diagrammed in Figure 21.2:
• Each Connection object contains an Errors collection, which in turn contains zero, one, or more Error object(s) representing errors (if any) that have been reported. • Each Command object contains a Parameters collection, which contains as many Parameter objects as are required for the current command. • Each Recordset object contains a Fields collection, which contains one Field object for each column in the record set. • Each of the six object types mentioned in the preceding three bullets contains a Properties collection, which contains the required number of Property objects.
Figure 21.2 The ADO object model. This figure omits the Properties collection and the Property objects that are common to all the ADO interfaces.
In broad outline, a typical ADO session proceeds as follows:
1. Create the Connection object. This includes setting properties appropriate for the desired datasource. For example, the ConnectionString property must include information such as the datasource name, user identification, password, and cursor location. 2. Open the connection. Use the Connection object’s Open method to create the actual link to the datasource. 3. Create the Command object. Set its properties and Parameter objects to create the query or statement that you want to submit to the datasource. 4. Associate the Command object with the Connection object. This has the effect of submitting the query or statement to the datasource. 5. Use the results set. The results of the query are returned in a Recordset object. 6. Terminate the connection to the datasource.