THE IN-PROCESS DATA PROVIDER features of SQL Server

THE IN-PROCESS DATA PROVIDER features of SQL Server 2005 mentioned in previous chapters. This code is as secure, reliable and scalable as T-SQL itself, as we have seen in previous chapters, so it makes no sense to require it to build a connection to the database as required of extended stored procedures. A connection requires significant resources in SQL Server 2005 itself and, probably more importantly, serializes all commands and results into a bit stream. When T-SQL accesses the database, it just uses the context in which it is running to access the database directly. .NET code running inside the database can use the same interfaces as SqLCient code; this is called the SQL Server Programming Model (SPM). Code inside the database does not depend on making connections to the database; it accesses SQL Server 2005 directly through the context in which it runs in a way very similar to T-SQL itself. This capability is exposed using the ADO.NET data provider model. It is accessed through classes in the namespace System.Data.SqlServerand a few others. With the first release of .NET, two different providers were available, located in the System.Data.OleDband the System.Data.SqlClientnamespaces, respectively. Because the SqlClientprovider is optimized for SQL Server, you can use it to access only SQL Server, whereas you can use the OleDbprovider to access data from any data source with a compliant OLE DB provider. Note that this architecture differs somewhat from the previous provider architectures ODBC, OLE DB, ADO, and so on in that with .NET you have different providers, depending on the data source. This gives provider writers the ability to add data store specific functionality to the provider on the class level without breaking the model. In OLE DB, provider writers had to add functionality through interfaces that in most cases ADO wouldn t see. This led to a trend where most providers implemented the same functionality and the ADO developer merely changed a property (or the connection string) in order to determine the data source to which to connect. The positive implication of this was that, as an ADO developer, you could code very generically, as Listing 4-1 shows. Notice that the equivalent code in ADO.NET, shown in Listing 4-2, is not as generic as in ADO. Listing 4-1: Connections in ADO Connections in ADO – Visual Basic.NET Dim oConn as ADODB.Connection Dim strConn As String Dim oCmd As New ADODB.Command

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

Bookmark the permalink.

Comments are closed.