RAD Studio for Microsoft .NET - Embarcadero Technologies

1.1 Developing Database Applications with RAD Studio for Microsoft .NET Stored Procedure Overview
• Borland.Data.AdoDbxClientProvider
• Borland.Data.Common
• Borland.Data.Schema
• Borland.Data.Design
AdoDbx.NET Data Types
AdoDbx.NET maps SQL data types to .NET Framework data types, eliminating the need for you to learn a database-specific
type system. Every attempt has been made to implement consistent type mappings across database types, allowing you to write
one set of source that you can run against multiple databases. You can achieve a similar effect with the .NET Framework data
providers by communicating with their interfaces directly and by using untyped ancestors. However, once you use strongly typed
accessors, your application becomes less portable. AdoDbx.NET does not support any database-specific typed accessors. For
more information, see the AdoDbx.NET Data Types topic.
AdoDbx.NET Interfaces
You can extend AdoDbx.NET to support other DBMSs by implementing a subset of the .NET Provider interface. AdoDbx.NET
generalizes much of the functionality required to implement data providers. While the .NET Framework gives you the capabilities
to create individual data providers for each data source, CodeGear has simplified the task by offering a generalized set of
capabilities. Instead of building separate providers, along with corresponding DataAdapters, DataReaders, Connection objects,
and other required objects, you can implement a set of AdoDbx.NET interfaces to build your own data source plug-ins to the
AdoDbx Client Provider.
Building plug-ins is a much easier task than building a completely new data provider. You build an assembly that contains the
namespace for your provider, as well as classes that encapsulate provider-specific functionality. Much of the functionality you
need to connect to, execute commands against, and retrieve data from your data source has already been defined in the
AdoDbx Client Provider interfaces.
See Also
ADO.NET Overview ( see page 14)
AdoDbx.NET Component Designers ( see page 21)
AdoDbx.NET Data Types ( see page 11)
1.1.10 Stored Procedure Overview
All relational databases have certain features in common that allow applications to store and manipulate data. A stored
procedure is a self-contained program written in a language specific to the database system. A stored procedure typically
handles frequently repeated database-related tasks, and is especially useful for operations that act on large numbers of records
or that use aggregate or mathematical functions. Stored procedures are typically stored on the database server.
Calling a stored procedure is similar to invoking a SQL command, and RAD Studio provides support for using stored procedures
in much the same ways as it supports editing and using SQL command text.
Stored procedures can enhance your database applications in the following ways: improve the performance, security, and
reliability of your applications.
• Performance—stored procedures can improve the performance of a database application by taking advantage of the server’s
usually greater processing power and speed, and reducing network traffic by moving processing to the server. Also, the
compiled SQL used in a stored procedure executes faster typically than standard SQL command text.
• Security—by creating a layer between clients and the database, stored procedures can enhance security for your data. You
don't need to grant database permissions to individual users. Instead, you can grant users permission to execute a stored
procedure independently of underlying table permissions.
29
1