CHAPTER 18 • SECURITY AND SQL SERVER 2000 720 you have a well-designed security plan that incorporates growth, managing your user base can be a painless task. To limit administrative access to SQL Server at the server level, you learned that you can add users to a fixed server role. For limiting access in a specific database, you can add users to a database role, and if one of the fixed database roles is not to your liking, you can create your own. You can even go so far as to limit access to specific applications by creating an application role. Each database in SQL Server 2000 has its own independent permissions. You looked at the two types of user permissions: statement permissions, which are used to create or change the data structure, and object permissions, which manipulate data. Remember that statement permissions cannot be granted to other users. The next section in this chapter described the database hierarchy. You looked at the permissions available to the most powerful user—the sa—down through the lower-level database users. You then learned about chains of ownership. These are created when you grant permissions to others on objects you own. Adding more users who create dependent objects creates broken ownership chains, which can become complex and tricky to work with. You learned how to predict the permissions available to users at different locations within these ownership chains. You also learned that to avoid the broken ownership chains, you can add your users to either the db_owner or the db_ddladmin database role and have your users create objects as the DBO. Permissions can be granted to database users as well as database roles. When a user is added to a role, they inherit the permissions of the role, including the Public role, of which everyone is a member. The only exception is when the user has been denied permission, because Deny takes precedence over any other right, no matter the level at which the permission was granted. We then looked at remote and linked servers, and at how security needs to be set up to make remote queries work. We finished with a look at n-tier security and applications. Now that you have a better understanding of security and administration in gen- eral you are ready to start learning about programming with SQL Server. Let’s start in the next chapter by learning about ADO. 2627ch18.qxd 8/22/00 11:09 AM Page 720 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Development with SQL Server PART V LEARN TO: • Use ADO • Use SQL-DMO • Use SQL Namespace • Use Data Transformation Services • Use the Web Assistant Wizard • Integrate SQL Server with Internet Information Server 2627ch19.qxd 8/22/00 11:11 AM Page 721 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. This page intentionally left blank Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 ADO and SQL Server FEATURING: The ADO Object Model 724 Understanding Cursors 728 Sample ADO Code 732 Other ADO Libraries 756 Summary 760 2627ch19.qxd 8/22/00 11:11 AM Page 723 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. I n most applications involving SQL Server, not all of the development is done on the server itself. This is the essence of client-server computing: Work is parti- tioned between a central server and distributed clients. To view and modify server-side data from a client application, one uses a client data-access library. Over the years, Microsoft has released a number of client data-access libraries that can use SQL Server data, including DB-Lib, Data Access Objects (DAO), and Remote Data Objects (RDO). Although all of these libraries are still in use, they’re no longer undergoing active development. Instead, Microsoft recommends that all new client applications use ActiveX Data Objects (ADO) to interact with the server. ADO is the only client data-access library that we’re going to cover in this book. Even if you’ve used another library for that purpose in the past, you should consider migrating to ADO to take advantage of current advances in the state of the art. In this chapter, we’ll start by describing the ADO object model and then take a look at what you can do with ADO. We’ll close with a brief section on ADOX, an ADO extension designed to help you work with schema information. ADO provides an object model atop the OLE DB interface, which is the low-level “plumbing” that SQL Server uses between its own components. Because of this inti- mate connection, ADO is a good choice for working with data stored in SQL Server. The ADO Object Model Figure 19.1 shows the ADO object model for ADO 2.6, the version that ships with SQL Server 2000. An object model lists the various objects that a library contains and shows their relationships. As you can see, the ADO object model is fairly simple. FIGURE 19.1 The ADO object model Connection Command Parameters Record Fields Recordset Fields Stream Errors 2627ch19.qxd 8/22/00 11:11 AM Page 724 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 725 In addition to the objects shown in Figure 19.1, the Connection, Command, Parameter, Recordset, Record, and Field objects each have a Properties collection of Property objects. This enables your code to easily enumerate the properties of these objects. Objects shown in Figure 19.1 with multiple boxes are collections. For example, the Command object contains a Parameters collection containing individual Parameter objects. NOTE Despite the simplicity of the ADO object model, ADO offers quite a bit of complex- ity in its operations, because there are many alternatives for performing basic operations, as well as lots of optional arguments. In this chapter, we’ll provide the basics of ADO to get you started. For more details, refer to the Microsoft Data Access Components SDK. You can download a copy of this SDK, which has the complete documentation for all ADO objects, from the Microsoft Universal Data Access Web site at http://www microsoft com/data. Understanding Objects Before we dig into the objects offered by ADO, let’s step back a bit and talk about the concept of an object in programming. In software development, an object represents a package of functionality provided for client programs to use. Usually an object repre- sents some “thing” within a particular piece of software. Objects have methods (activ- ities they can perform), properties (characteristics that describe the objects), and events (occurrences that can cause the object to invoke your code) that are set by the provider of the object. As an application developer, you can use those methods and properties to interact with the original product. For example, ADO includes an object called a Recordset. This object represents a set of records (for example, the results of a query) from a data provider. A Recordset object can be used to represent any set of records. The Recordset object has methods, such as MoveFirst (which positions an internal pointer to the first record in the Recordset) and MoveLast (which positions an internal pointer to the last record in the Recordset). It also has properties, such as RecordCount (the number of records in the Recordset) and EOF (a Boolean property that indicates the last record of the Recordset has been retrieved). The Recordset object also has events, such as FetchComplete, which occurs when all of the records from an asynchronous operation are available in the Recordset. Objects can be arranged in collections, which are groups of similar objects. For example, in ADO there is a Parameters collection of Parameter objects. You can use a THE ADO OBJECT MODEL Development with SQL Server PART V 2627ch19.qxd 8/22/00 11:11 AM Page 725 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 • ADO AND SQL SERVER 726 collection to view each object in turn of a similar group. This is called iterating through the collection. Objects can also contain other objects. For example, the ADO Recordset object contains a collection of Field objects, each of which represents one of the individual fields in a record in the Recordset. Objects provide an abstract view of the underlying software. It’s unlikely that there’s actually a data structure within SQL Server that you could point to and say, “This is a Recordset.” By manipulating Recordsets in your code, though, you can access many of the abilities of SQL Server to retrieve and modify data. The Recordset object provides a convenient abstraction for the underlying functionality of storing and modifying data. In the remainder of this section, we’ll discuss the objects that the ADO object model provides. We’ll keep the discussion on an abstract level, without presenting all of the methods and properties of each object. SQL Server Books Online includes an exhaustive list of these methods and properties, as well as those of the other object models that can be used with SQL Server. Connection and Error At the top of the ADO hierarchy, you’ll find the Connection object, which is associ- ated with an Errors collection. Neither of these objects provides a direct connection to data, but they’re both very important in working with other ADO objects. The Connection object represents an open connection to an OLE DB data source. You can create a Connection object and use it to create other objects further down the ADO object hierarchy. However, if you need only a single Recordset object from a par- ticular Connection, it’s probably more efficient to just create the Recordset directly, which will create a Connection object implicitly. You should reserve explicitly creat- ing actual Connection objects for situations where you’ll need to perform multiple, diverse operations on the connection. An Error object represents a single error. Because one data-access operation can generate multiple errors, Error objects are contained in an Errors collection. If the last operation succeeded, this collection will be empty. Otherwise, you can use the For Each operator to examine each Error in turn. Command and Parameter The Command and Parameter objects are the basic query-building objects of ADO. You can use them in various combinations to represent tables, SQL statements, or stored procedures. You can use Command objects both for commands that return 2627ch19.qxd 8/22/00 11:11 AM Page 726 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 727 data and for commands that instruct SQL Server to do something, such as action queries. Think of a Command object as a single instruction to SQL Server to produce or alter data. The easiest way to use a Command object is to create an independent Command object, set its other properties, and then set its ActiveConnection property to a valid connection string. This will cause ADO to create an implicit Connection object for use by this Command only. However, if you’re going to execute multiple Commands on a single Connection, you should avoid this technique, because it will create a separate Connection object for each Command. Instead, you can set the ActiveConnection property to an existing Connection object. A Parameter object represents a single parameter for a Command object. This might be a runtime parameter in a SQL query, or an input or output parameter in a stored procedure. If you know the properties of a particular Parameter, you can use the CreateParameter method to make appropriate Parameter objects for a Command object, which allows you to initialize parameters without any server-side processing. Otherwise, you must call the Refresh method on the Command object’s Parameters collection to retrieve parameter information from the server, a resource-intensive operation. Recordset and Field The Recordset and Field objects are the actual data-containing objects in ADO. A Recordset object represents a set of records retrieved from SQL Server. Because this is the object that allows you to directly retrieve data, it’s indispensable to ADO processing. ADO allows you to open a Recordset object directly, or to create one from a Connection or Command object. As you’ll see later in the chapter, Recordsets have a variety of properties and behaviors depending on how they’re created. A Field object represents a single column of data in a Recordset. Once you’ve retrieved a Recordset, you’ll usually work with the Fields collection to read the data in the Recordset. However, since the Fields collection is the default property of the Recordset object, you won’t often see its name in your code. For example, if you’re working in Visual Basic or a VBA host application, the following two lines of code produce an identical result: Recordset.Fields(0).Value Recordset(0) THE ADO OBJECT MODEL Development with SQL Server PART V 2627ch19.qxd 8/22/00 11:11 AM Page 727 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 19 • ADO AND SQL SERVER 728 Properties The Property object is the building block of the other ADO objects. That is, properties describe the other objects. Although you can iterate through the Properties collection of ADO objects, there’s usually not any reason to do so unless you’re writing special- ized tools to manipulate ADO code. Record and Stream For completeness, you should also know about two other objects introduced in ADO 2.5, although these objects are not useful in working with SQL Server data. The Record object is a dual-purpose object. It can represent a row in a Recordset. It can also represent a file or folder in a file system. However, it’s important to realize that these are not distinct features of the Record object. Rather, the Record object is designed to represent a row in a Recordset when the underlying OLE DB provider nat- urally supports a hierarchical data store. For example, Record objects can be used with providers that supply information from file systems or e-mail storage. Record objects can’t be used with providers that supply information from standard relational data- bases (even if there’s a hierarchy within the database). The Stream object represents binary data associated with a Record object. For example, if you have a Record object representing a file in a file system, its associated Stream object would represent the binary data in that file. Because SQL Server is a relational database, it doesn’t support Record or Stream objects. Understanding Cursors You learned about T-SQL cursors in Chapter 8. A cursor, you’ll recall, is a set of records along with a pointer that identifies one of these records as the current record. ADO also supports cursors, in the form of the Recordset object. When you open a Recordset object to contain a set of records, ADO identifies a particular record as the current record. Thus, if you talk of cursors in an ADO context, you’re normally talking about Recordsets. Unlike T-SQL cursors, though, ADO cursors can have a variety of different behav- iors, depending on the properties you set for the Recordset object. In this section, we’ll discuss the three key properties that control ADO cursor behavior: • CursorLocation • CursorType • LockType 2627ch19.qxd 8/22/00 11:11 AM Page 728 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 729 CursorLocation The CursorLocation property can be set to either adUseServer, for server-side cursors, or adUseClient, for client-side cursors. A cursor is a set of records in memory, and of course some software has to be responsible for keeping track of this set of records. Server-side cursors are maintained by SQL Server using the same native cursors that you met in Chapter 8. Client-side cursors are maintained by the Microsoft Cursor Ser- vice for OLE DB, which attempts to level the playing field by supplying capabilities that are lacking in some servers. If no CursorLocation is specified, a server-side cursor is the default. Just because SQL Server supports server-side cursors doesn’t mean you have to use them. Some functionality is available only in client-side cursors—for example, re-sorting Recordsets or using an index to find records. If you need these capabili- ties, you should use client-side cursors. Otherwise, you may find that server-side cursors provide better performance. CursorType The CursorType parameter further specifies the desired behavior of the Recordset object. You can specify one of four constants: • To open a dynamic Recordset, use adOpenDynamic. A dynamic Recordset allows all types of movement through the Recordset and keeps you up-to-date with changes made by other users. • To open a keyset Recordset, use adOpenKeyset. A keyset Recordset functions like a dynamic Recordset, except that you won’t see new records added or records deleted by other users. • To open a static cursor, use adOpenStatic. A static Recordset does not show you any changes made by other users while the Recordset is open and is therefore most useful for reporting or other applications that don’t need to be kept com- pletely up-to-date. • Finally, to open a forward-only cursor, use adOpenForwardOnly. A forward- only cursor is identical to a static cursor, except that you can only move for- ward in the Recordset to go to a different record. This offers the fastest performance of any of the cursor types, at the expense of flexibility. Some- times you’ll see a forward-only, read-only cursor called a firehose cursor. UNDERSTANDING CURSORS Development with SQL Server PART V 2627ch19.qxd 8/22/00 11:11 AM Page 729 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Server- side, forward-only, batch optimistic Yes Server- side, keyset, read-only Server- side, keyset, read-only Yes Server- side, keyset, pessimistic Server- side, keyset, pessimistic Yes Server- side, keyset, optimistic Server- side, keyset, optimistic Yes Server- side, keyset, batch optimistic Server- side, keyset, batch optimistic Yes Server- side, dynamic, read-only Server- side, dynamic, read-only Yes Server- side,... pessimistic Server- side, dynamic, pessimistic Yes Server- side, dynamic, optimistic Server- side, dynamic, optimistic Yes Server- side, dynamic, batch optimistic Server- side, dynamic, batch optimistic Yes Server- side, static, read-only Server- side, static, read-only Yes Server- side, static, pessimistic Server- side, keyset, pessimistic No Server- side, static, optimistic Server- side, keyset, optimistic No Server- side,... using SQL Server data and the actual Recordsets that are delivered by ADO PA R T V TABLE 19.1: GRACEFUL DEGRADATION OF RECORDSETS Requested Delivered Identical? Server- side, forward-only, read-only Server- side, forward-only, read-only Yes Server- side, forward-only, pessimistic Server- side, forward-only, pessimistic Yes Server- side, forward-only, optimistic Server- side, forward-only, optimistic Yes Server- side,... shows the keywords that you can use in a SQL Server connection string TABLE 19.2: OLE DB CONNECTION STRING KEYWORDS FOR SQL SERVER Keyword Value Comments Provider SQLOLEDB Must be specified This tells OLE DB the type of database with which you want to connect Data Source Name of the SQL Server Must be specified You can also use the special value “(local)” if the SQL Server is on the computer where the client... Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Development with SQL Server 2627ch19.qxd 2627ch19.qxd 734 8/22/00 11:11 AM Page 734 CHAPTER 19 • ADO AND SQL SERVER TABLE 19.2: OLE DB CONNECTION STRING KEYWORDS FOR SQL SERVER (CONTINUED) Keyword Value Comments Server Name of the SQL Server An alternative to the Data Source keyword Initial Catalog Name of the database Must be... Development with SQL Server 2627ch19.qxd 2627ch19.qxd 736 8/22/00 11:11 AM Page 736 CHAPTER 19 • ADO AND SQL SERVER Executing a SQL Statement Once you’ve created and opened a Connection object, you’re ready to work with your server One of the easiest tasks to do via ADO is to execute a SQL statement ADO provides two methods for doing this, either of which can be used for executing SQL statements or... purchase PDF Split-Merge on www.verypdf.com to remove this watermark Development with SQL Server Fields(“CompanyName”) 2627ch19.qxd 752 8/22/00 11:11 AM Page 752 CHAPTER 19 • ADO AND SQL SERVER Adding Records It’s also easy to add new records to a SQL Server table through a Recordset The limitation on adding records is that SQL Server has to be able to figure out exactly what data you want to add So, for every... ADODB.Command Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Development with SQL Server 2627ch19.qxd 2627ch19.qxd 740 8/22/00 11:11 AM Page 740 CHAPTER 19 • ADO AND SQL SERVER Dim lngRows As Long Set conLocal = New ADODB.Connection conLocal.Open _ “Provider=SQLOLEDB ;Server= (local);” & _ “Database=Northwind;Trusted_Connection=Yes” Set cmdProc = New ADODB.Command Set cmdProc.ActiveConnection... ADODB.Recordset Set conLocal = New ADODB.Connection Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Development with SQL Server 2627ch19.qxd 2627ch19.qxd 746 8/22/00 11:11 AM Page 746 CHAPTER 19 • ADO AND SQL SERVER conLocal.Open _ “Provider=SQLOLEDB ;Server= (local);” & _ “Database=Northwind;Trusted_Connection=Yes” Set rstCustomers = New ADODB.Recordset With rstCustomers CursorLocation... ADODB.Connection Set conLocal = New ADODB.Connection conLocal.Open _ “Provider=SQLOLEDB ;Server= (local);” & _ “Database=Northwind;Trusted_Connection=Yes” Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Development with SQL Server 2627ch19.qxd 2627ch19.qxd 738 8/22/00 11:11 AM Page 738 CHAPTER 19 • ADO AND SQL SERVER conLocal.Execute _ “NewPrices” In this case, of course, you won’t . ADO AND SQL SERVER 734 TABLE 19.2: OLE DB CONNECTION STRING KEYWORDS FOR SQL SERVER (CONTINUED) Keyword Value Comments Server Name of the SQL Server An. are lacking in some servers. If no CursorLocation is specified, a server- side cursor is the default. Just because SQL Server supports server- side cursors