Hitchhiker's Guide to Visual Basic and SQL Server

( 2 )

Overview

"The Hitchhiker's Guide to Visual Basic and SQL Server, Sixth Edition", is for hands-on developers, development managers in medium-sized to large MIS development shops, and everyone else who wants to use Visual Basic to tap the power of SQL Server. Readers need a working knowledge of VB, an understanding of how SQL Server is administered, and the ability to create Transact SQL commands and batches. The enclosed CD-ROM contains sample code from the book, a sample database, code building blocks for users' own applications, white papers, and more.

...
See more details below
Available through our Marketplace sellers.
See All Options
Other sellers (Paperback)
  • All (15) from $1.99   
  • New (2) from $8.38   
  • Used (13) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$8.38
Letusbegin
Seller since Fri Jan 01 01:01:01 EST 2010

Feedback rating:

(15)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
1998-10-01 Paperback 6th New New Paperback with Factory Sealed Disc! Pristine unmarked pages, may have very slight warehouse wear, no remainder marks, still a great buy straight ... from book warehouse unread, sealed in plastic, exact artwork as listed, Read more Show Less

Ships from: Ossining, NY

Usually ships in 1-2 business days

  • •Canadian
  • •International
  • •Standard, 48 States
  • •Standard (AK, HI)
  • •Express, 48 States
  • •Express (AK, HI)
$60.00
bluehouse
Seller since Tue Oct 07 09:37:03 EDT 2014

Feedback rating:

(184)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • •Standard, 48 States
  • •Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Sending request ...

More About This Book

Overview

"The Hitchhiker's Guide to Visual Basic and SQL Server, Sixth Edition", is for hands-on developers, development managers in medium-sized to large MIS development shops, and everyone else who wants to use Visual Basic to tap the power of SQL Server. Readers need a working knowledge of VB, an understanding of how SQL Server is administered, and the ability to create Transact SQL commands and batches. The enclosed CD-ROM contains sample code from the book, a sample database, code building blocks for users' own applications, white papers, and more.


This excellent programmer's guide has been revised and updated to include the new features of Visual Basic 6.0 and Microsoft's SQL SERVER 7.0. It is the definitive guide for accessing SQL Servers and developing server applications. In this edition, author William Vaughn includes a plentitude of information on ActiveX Data Objects (ADO) and data access tools. To derive the most benefit from this publication, you should be comfortable programming with Visual Basic and have some familiarity with Microsoft's technologies such as COM/DCOM and data access methods. Knowing something about SQL Servers won't hurt either, if this is new to you then we recommend a tutorial such as Teach Yourself Microsoft SQL Server 6.5 in 21 Days.

Read More Show Less

Editorial Reviews

Booknews
The new edition of this encyclopedic guide to data access is updated to cover Visual Basic 6.0. It includes thorough coverage of the new ActiveX Data Objects ADO interface, as well as RDO, ODBCDirect, and DAO/Jet data interfaces. Also covers designing and building applications, managing SQL Serve data and datacentric applications, and the Data Environment Designer, the Data Object Wizard, and other new data access tools. The included CD-ROM contains sample code and sample databases, archives from the fifth edition, and white papers, presentations, and other information. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9781572318489
  • Publisher: Microsoft Press
  • Publication date: 10/1/1998
  • Series: Microsoft Programming Titles Series
  • Edition description: 6TH BK&CDR
  • Edition number: 6
  • Pages: 750
  • Product dimensions: 7.45 (w) x 9.18 (h) x 1.80 (d)

Meet the Author


William R. Vaughn is a Microsoft employee on the Visual Basic marketing team. Formerly he served as writer and subject-matter expert on data access topics on the user education team. He wrote the Data Access Guide for Visual Basic 3.0 and the data access help topics and client/server material for versions 4.0 and 5.0. Prior to joining the Visual Basic team, lie designed and delivered courseware for Microsoft University. During a career spanning more than twenty years in the computer industry, he has worked for and consulted with numerous clients about the design and implementation of database management systems.

Read More Show Less

Read an Excerpt


Chapter 21: Getting Connected with RDO

You don't have a connection manager to worry about when you use the Remote Data Objects (RDO) interface. You make and break all connections yourself, whenever you need to. But you're still faced with the same challenges when it comes to managing connections. On the one hand, you don't want to overload the server and lock out other users by making too many connections. On the other hand, unless you use server-side cursors, Microsoft SQL Server doesn't support multiple operations on a single connection, so you often have to open additional connections to update rows or perform other operations. You also have to be concerned about leaving idle connections open while the user decides what to do, but you don't want to slow him down when he finally figures out what he wants-or comes back from his two- hour lunch. Properly managing connections can mean that an application is scalable to (or beyond) several hundred users or limited to a few dozen (or less).

Locating and Naming the SQL Server

Like other ODBC-based interfaces, RDO connects to your SQL server using the information kept in the ODBC data source name (DSN) or a file-based DSN or using the information you provide in the connect string. Personally, I'm not always in favor of establishing a permanent DSN, since it can be a source of trouble when your application is installed and run in the field. To work around this problem, you can take one of several approaches:
  • Use the ODBC registry functions to determine whether a suitable DSN already exists This technique is really a lot of trouble, as far asI'm concerned, so I rarely use it. You can use the ODBC API SQLDataSources method to list registered DSN entries.
  • Use the rdoRegisterDataSource function to create a new DSN entry This technique is also troublesome, but it's not as bad as using the ODBC registry functions.
  • Use an already established DSN. Most people who use this approach install the DSN themselves or have the user install it when the application is installed. This approach can be risky, though, and it can lead users to phone you in the middle of the night.
  • Launch the ODBC Control Panel applet directly from your application, and tell the user how to set up a DSN Yeah, right. Unless your users are a bit more comfortable than mine are with this sort of thing, this isn't a viable option. Letting some users take this route is like turning a four-year-old loose with a 17- blade Swiss Army knife.
  • Create a file-based DSN. This relatively new approach is virtually identical to the DSN-less connection technique explained below, except that it requires a file to store the connection information instead of requiring that you provide the information in the connect string itself. When you point to this DSN at run time, ODBC fills in the blanks just as it would with a DSN-less connection. To use the DSN, you can use the ODBC connection management dialog boxes (launched by the ODBCControl Panel applet). The file- based DSN should work fine until the connection file is lost, or not installed with the application. Filebased DSNs can also lead to security problems because it is fairly easy to view or tinker with the file's ASCII contents. This is the technique of choice when you work with middle-tier components in which registered DSNs are not always available. Note that only "system" DSNs are suitable for use with some Microsoft Active Server Pages-based connections.
  • Don't use a DSN entry at all, but include all the driver information in the Connect argument of the OpenConnection method This approach is far less risky. All it assumes is that the name of the SQL server doesn't change, since you've hard-coded it into the application. The drawback to this technique is that it requires you to take all of the default DSN settings (we'll look at these a little later), but it's the fastest way because it doesn't require a Registry hit. It also assumes that the name of the server is cast in stone. Since I'm still connecting to servers that were set up eight years ago, this might not be a problem.
  • Put the name of the SQL server in a Registry entry (my preference) or in an INI file, and fetch the name when the application is run the first time or when the SQL server can't be located When an OpenConnection method fails, the message returned often says that the SQL server couldn't be found- which can mean any of a dozen things. Generally, the name of the server doesn't change after installation, but if the same application is used to access more than one SQL server, permitting the user to select from a list of valid servers is an alternative.
  • Create a UserConnection object to manage the connection Actually, since the UserConnection designer was introduced in Microsoft Visual Basic 5.0, getting connected to SQL Server couldn't be made much easier. We devote a chapter to the UserConnection designer a little later, but in essence, this designer captures all of the connection parameters at design-time and automatically builds the correct Connect string for you at runtime. It supports all types of connections discussed so far including DSN-Iess connections.

Establishing a Connection

Once you know which SQL server to connect to, you have a couple of options for establishing the actual connection. In RDO 1.0, you can use the OpenConnection. method to create an rdoConnection object, which establishes a physical link to the data source. While you can still use this technique in RDO 2.0, you can also declare a stand-alone rdoConnection object and use the EstablishConnection method to hook it to a selected SQL server. This is what the UserConnection designer does for you-except without you having to build the Connect string in code. Let's look at these two techniques a little more closely. To establish a connection, you must somehow identify the network location of the data source, as well as the driver type. Your code also provides a number of parameters for logging the user on to the database. By choosing an appropriate Prompt argument, you can program the ODBC Driver Manager to prompt the user for missing arguments and thereby prevent the use of alternate arguments. However, as I've said repeatedly in my lectures, I feel extremely uncomfortable exposing these dialog boxes. On occasion, the previous login ID is shown, and the next user only has to supply the password. For some unusual applications, this might be just fine. For others, even login names are secure. For these reasons, I always set the rdDriverNoPrompt option to prevent any dialog boxes from appearing. I then must add code to trap the situations in which the user doesn't get logged on. No, this option isn't available in DAO, but it is supported in ADO-well, sort of. ADO's support of ODBC's prompt behavior is generally lacking-especially when you use the Data Environment designer-but we'll talk about that in Chapter 37. The OpenConnection method accepts the following arguments. They can be supplied by name, supplied with Visual Basic named argument syntax, or supplied positionally.
  • The dsName argument. This argument indicates the name of the registered data source. It points to a valid, registered DSN entry (which can include the new file-based DSN). If you supply all the DSN-related parameters in the connect string, you must pass an empty string as the dsName argument. If you supply the dsName argument value, you can use it to identify the connection. Since you might connect to the same DSN more than once, however, or simply pass an empty string, you can't really depend on the name to index the rdoConnections collection. You can always use the rdoConnection object's ordinal position in the rdoConnections collection to choose an open rdoConnection object.
  • The Prompt argument. This argument indicates whether the user is permitted to supply arguments to ODBC connection dialog boxes. If you don't want the user to supply a different DSN, user name, password, or default database, use the rdDriverNoPrompt constant as the Prompt argument. But if the Connect and dsName arguments don't lead to a connection (which you have to deal with in code), a trappable error results and the user doesn't see any ODBC-generated dialog boxes to assist with the connection. This feature is unique to RDO, ADO, and ODBCDirect because the DAO/Jet interface is stuck with Prompt if required, which displays the dialog boxes whenever there's a problem with the login information or with establishing the connection.
  • The ReadOnly argument. This is set to False if the user expects to update data through the connection. Setting it to True can improve performance because the ODBC drivers can skip code needed to support updatability.
  • The Connect argument. This argument gives the ODBC Driver Manager either the entire set of ODBC connection parameters or just the parameters that are not already supplied by the DSN entry. These parameters can include username, password, default database, DSN (which overrides the value provided in the dsName argument), and others. The list of arguments has been expanded for ODBC 3.x. These arguments are described in Table 21-1.

The ODBC Driver Manager uses these Connect string arguments to establish the connection. If you don't provide enough of these arguments, ODBC can't figure out how to connect and it might expose dialog boxes to capture these missing parameters. The ODBC prompt behavior determines whether or not these dialog boxes are shown. In some instances, you might get away with just providing the DSN itself because it can encapsulate enough information to get connected. If you leave out the DSN, you must provide a lot more of the arguments...

Read More Show Less

Table of Contents

Pt. I Understanding Data Access Interfaces
Ch. 1 The Road Ahead
Ch. 2 Data Interfaces
Ch. 3 Data Access: A Jump Start
Ch. 4 Choosing an Architecture
Pt. II Designing SQL Server Applications
Ch. 5 Planning Your Design
Ch. 6 Making Connections to SQL Server
Ch. 7 Designing and Building Queries
Ch. 8 Retrieving Data and Working with Result Sets
Pt. III Using DAO with the Jet Database Engine
Ch. 9 The Jet Database Engine and the DAO Model
Ch. 10 Data Access Objects Up Close
Ch. 11 Configuring and Tuning the Jet Engine
Ch. 12 Using DAO/Jet to Get Connected
Ch. 13 Using DAO/Jet to Access Data
Ch. 14 Executing Transact-SQL Queries
Ch. 15 Using the Data Control
Ch. 16 Understanding the Jet Query Processor
Ch. 17 Using ODBCDirect
Ch. 18 Jet: A Traveler's Diary
Pt. IV Using Remote Data Objects
Ch. 19 Understanding Remote Data Objects
Ch. 20 Remote Data Objects Up Close
Ch. 21 Getting Connected with RDO
Ch. 22 Using the RDO UserConnection Designer
Ch. 23 Building Result Sets with RDO
Ch. 24 Optimistic Batch Updates
Ch. 25 Taking RDO Off Road
Ch. 26 Maintaining Data with the RDO Interface
Ch. 27 Using the RemoteData Control
Pt. V Using ADO and OLE DB
Ch. 28 Understanding ADO and OLE DB
Ch. 29 ActiveX Data Objects Up Close
Ch. 30 Getting Connected with ADO
Ch. 31 Building ADO Recordsets
Ch. 32 Working with ADO Events and Asynchronous Operations
Ch. 33 Taking ADO Off Road
Ch. 34 Migrating from RDO to ADO
Pt. VI Using the New Tools
Ch. 35 Using the Transact-SQL Debugger
Ch. 36 Using the Data View Window and Query Builder
Ch. 37 Taking the Data Environment Designer Out for a Spin
Ch. 38 Test Driving the Data Object Wizard
App. A Setting Up the Test Databases
App. B SQL Server Error Codes Decoded
App. C SQL Server Tips and Tricks
Dusty Archives Chapters on the Companion CD
Read More Show Less

Customer Reviews

Average Rating 3
( 2 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(1)
Sort by: Showing all of 2 Customer Reviews

  • Anonymous

    Posted Sat Sep 08 00:00:00 EDT 2001

    An Excellent Book

    I found the humor in this book refreshing. It's nice to get away from the stodgy, boring BOL rehash and the glorified RFC formats that many of the other books use. Perhaps a hard-core data access model expert wouldn't get much more out of this book, but then an expert doesn't need a hitchhiker's guide. For those approaching DAO, RDO and ADO with a relatively fresh perspective, this book is excellent. I would highly recommend it to anyone who gets tired of reading stereo instructions and would like a cogent, helpful guide to modern data access methods for SQL Server 7 that isn't ashamed that it is written by a human for humans. Vaughn is very knowledgeable and his examples are written from the perspective of a developer that has had to create real products in real business situations. In fact, as one of the developers of many of the data access models, he has the inside track on the past and future of data access model development. I am certainly glad I purchased this book and would recommend it gladly.

    Was this review helpful? Yes  NoThank you for your feedback.   Report this reviewThank you, this review has been flagged.

  • Anonymous

    Posted Wed Feb 02 00:00:00 EST 2000

    Don't pick up Hitchikers - Certainly NOT this Hitchiker!!!!!

    Great Disappointment. The style of this book ruins anything good that might be in it. Too many jokes that eventually detract from the subject matter. The use of sarcasm pointed at Microsoft Competitors gets old and dosen't help explain SQL Server or Visual Basic. Reading this book is like watching TV with someone who keeps hitting the remote and changing the channels. You finially get to the subject at hand and the author decides to tell another funny story. Very distracting!!! I finally gave up and bought the book 'Inside SQL Server'. I just finished reading that. Now that is a serious book. One other book I plan on buying is 'SQL Server in 21 Days'. The reviews are very impressive on both these books. Don't buy this Hitchiker's book - there are too many good ones to pick from. You will thank me.

    Was this review helpful? Yes  NoThank you for your feedback.   Report this reviewThank you, this review has been flagged.
Sort by: Showing all of 2 Customer Reviews
If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)