This action might not be possible to undo. Are you sure you want to continue?
The .net framework is an integral windows component that supports building and running the next generation of applications and xml web services. The .net framework is designed to fulfill the following objectives:
To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but internet-distributed, or executed remotely.
To provide a code-execution environment that minimizes software deployment and versioning conflicts.
To provide a code-execution environment that promotes safe execution of code, including code created by an unknown or semi-trusted third party.
To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments.
To make the developer experience consistent across widely varying types of applications, such as windows-based applications and web-based applications.
To build all communication on industry standards to ensure that code based on the .net framework can integrate with any other code. The .net framework has two main components: the common language runtime and
the .net framework class library. The common language runtime is the foundation of the .net framework. You can think of the runtime as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that promote security and robustness. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code. The class library, the other main component of the .net framework, is a comprehensive, object-
oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by asp.net, such as web forms and xml web services. The .net framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features. The .net framework not only provides several runtime hosts, but also supports the development of third-party runtime hosts. For example, asp.net hosts the runtime to provide a scalable, server-side environment for managed code. Asp.net works directly with the runtime to enable asp.net applications and xml web services, both of which are discussed later in this topic. Internet explorer is an example of an unmanaged application that hosts the runtime (in the form of a mime type extension). Using internet explorer to host the runtime enables you to embed managed components or windows forms controls in html documents. Hosting the runtime in this way makes managed mobile code (similar to Microsoft® activex® controls) possible, but with significant improvements that only managed code can offer, such as semi-trusted execution and isolated file storage. The following illustration shows the relationship of the common language runtime and the class library to your applications and to the overall system. The illustration also shows how managed code operates within a larger architecture.
.NET FRAMEWORK IN CONTEXT
Features of the common language runtime The common language runtime manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime. With regards to security, managed components are awarded varying degrees of trust, depending on a number of factors that include their origin (such as the internet, enterprise network, or local computer). This means that a managed component might or might not be able to perform file-access operations, registry-access operations, or other sensitive functions, even if it is being used in the same active application.
The runtime enforces code access security. For example, users can trust that an executable embedded in a web page can play an animation on screen or sing a song, but cannot access their personal data, file system, or network. The security features of the runtime thus enable legitimate internet-deployed software to be exceptionally feature rich. The runtime also enforces code robustness by implementing a strict type-andcode-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety. In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common application errors, memory leaks and invalid memory references. The runtime also accelerates developer productivity. For example, programmers can write applications in their development language of choice, yet take full advantage of the runtime, the class library, and components written in other languages by other developers. Any compiler vendor who chooses to target the runtime can do so. Language compilers that target the .net framework make the features of the .net framework available to existing code written in that language, greatly easing the migration process for existing applications. While the runtime is designed for the software of the future, it also supports software of today and yesterday. Interoperability between managed and unmanaged code enables developers to continue to use necessary com components and dlls. The runtime is designed to enhance performance. Although the common language runtime provides many standard runtime services, managed code is never interpreted. A feature called just-in-time (JIT) compiling enables all managed code to run in the native
machine language of the system on which it is executing. Meanwhile, the memory manager removes the possibilities of fragmented memory and increases memory localityof-reference to further increase performance. Finally, the runtime can be hosted by high-performance, server-side applications, such as Microsoft® sql server™ and internet information services (iis). This infrastructure enables you to use managed code to write your business logic, while still enjoying the superior performance of the industry's best enterprise servers that support runtime hosting.
Design goals and principal features
The .NET Framework was designed with several intentions:
Interoperability - Because interaction between new and older applications is commonly
required, the .NET Framework provides means to access functionality that is implemented in programs that execute outside the .NET environment. Access to COM components is provided in the EnterpriseServices namespace of the framework, and access to other functionality is provided using the P/Invoke feature.
Common Runtime Engine - Programming languages on the .NET Framework
compile into an intermediate language known as the Common Intermediate Language, or CIL; Microsoft's implementation of CIL is known as Microsoft Intermediate Language, or MSIL. In Microsoft's implementation, this intermediate language is not interpreted, but rather compiled in a manner known as just-in-time compilation (JIT) into native code. The combination of these concepts is called the Common Language Infrastructure (CLI), a specification; Microsoft's implementation of the CLI is known as the Common Language Runtime (CLR).
Language Independence - The .NET Framework introduces a Common Type System,
or CTS. The CTS specification defines all possible datatypes and programming constructs supported by the CLR and how they may or may not interact with each other.
Because of this feature, the .NET Framework supports development in multiple programming languages.
Base Class Library - The Base Class Library (BCL), sometimes referred to as the
Framework Class Library (FCL), is a library of types available to all languages using the .NET Framework. The BCL provides classes which encapsulate a number of common functions, including file reading and writing, graphic rendering, database interaction and XML document manipulation.
Simplified Deployment - Installation of computer software must be carefully managed
to ensure that it does not interfere with previously installed software, and that it conforms to increasingly stringent security requirements. The .NET framework includes design features and tools that help address these requirements.
Security - .NET allows for code to be run with different trust levels without the use of a
separate sandbox. The design of the .NET Framework is such that it supports platform independence. That is, a program written to use the framework should run without change on any type of computer for which the framework is implemented. At present, Microsoft has implemented the full framework only on the Windows operating system. Microsoft and others have implemented portions of the framework on non-Windows systems, but to date those implementations are neither complete nor widely used.
.NET FRAMEWORK CLASS LIBRARY
The .net framework class library is a collection of reusable types that tightly integrate with the common language runtime. The class library is object oriented, providing types from which your own managed code can derive functionality. This not only makes the .net framework types easy to use, but also reduces the time associated with learning new features of the .net framework. In addition, third-party components can integrate seamlessly with classes in the .net framework.
For example, the .net framework collection classes implement a set of interfaces that you can use to develop your own collection classes. Your collection classes will blend seamlessly with the classes in the .net framework. As you would expect from an object-oriented class library, the .net framework types enable you to accomplish a range of common programming tasks, including tasks such as string management, data collection, database connectivity, and file access. In addition to these common tasks, the class library includes types that support a variety of specialized development scenarios. For example, you can use the .net framework to develop the following types of applications and services: • • • • • Console applications. Windows GUI applications (windows forms). Asp.net applications. Xml web services. Windows services. For example, the windows forms classes are a comprehensive set of reusable types that vastly simplify windows GUI development. If you write an asp.net web form application, you can use the web forms classes.
CLIENT APPLICATION DEVELOPMENT
Client applications are the closest to a traditional style of application in windowsbased programming. These are the types of applications that display windows or forms on the desktop, enabling a user to perform a task. Client applications include applications such as word processors and spreadsheets, as well as custom business applications such as data-entry tools, reporting tools, and so on. Client applications usually employ windows, menus, buttons, and other GUI elements, and they likely access local resources such as the file system and peripherals such as printers.
Another kind of client application is the traditional activex control (now replaced by the managed windows forms control) deployed over the internet as a web page. This application is much like other client applications: it is executed natively, has access to local resources, and includes graphical elements. In the past, developers created such applications using c/c++ in conjunction with the Microsoft Foundation Classes (MFC) or with a Rapid Application Development (RAD) environment such as Microsoft® visual basic®. The .net framework incorporates aspects of these existing products into a single, consistent development environment that drastically simplifies the development of client applications. The windows forms classes contained in the .net framework are designed to be used for GUI development. You can easily create command windows, buttons, menus, toolbars, and other screen elements with the flexibility necessary to accommodate shifting business needs. For example, the .net framework provides simple properties to adjust visual attributes associated with forms. In some cases the underlying operating system does not support changing these attributes directly, and in these cases the .net framework automatically recreates the forms. This is one of many ways in which the .net framework integrates the developer interface, making coding simpler and more consistent. Unlike activex controls, windows forms controls have semi-trusted access to a user's computer. This means that binary or natively executing code can access some of the resources on the user's system (such as GUI elements and limited file access) without being able to access or compromise other resources. Because of code access security, many applications that once needed to be installed on a user's system can now be deployed through the web. Your applications can implement the features of a local application while being deployed like a web page.
SERVER APPLICATION DEVELOPMENT
Server-side applications in the managed world are implemented through runtime hosts. Unmanaged applications host the common language runtime, which allows your custom managed code to control the behavior of the server. This model provides you with all the features of the common language runtime and class library while gaining the performance and scalability of the host server. The following illustration shows a basic network schema with managed code running in different server environments. Servers such as IIS and SQL server can perform standard operations while your application logic executes through the managed code.
Server-side managed code
Asp.net is the hosting environment that enables developers to use the .net framework to target web-based applications. However, asp.net is more than just a runtime host; it is a complete architecture for developing web sites and internet-distributed objects using managed code. Both web forms and xml web services use iis and asp.net as the publishing mechanism for applications, and both have a collection of supporting classes in the .net framework. Xml web services, an important evolution in web-based technology, are distributed, server-side application components similar to common web sites. However, unlike web-based applications, xml web services components have no GUI and are not targeted for browsers such as internet explorer and Netscape navigator. Instead, xml web services consist of reusable software components designed to be consumed by other
applications, such as traditional client applications, web-based applications, or even other xml web services. As a result, xml web services technology is rapidly moving application development and deployment into the highly distributed environment of the internet. If you have used earlier versions of asp technology, you will immediately notice the improvements that asp.net and web forms offer. For example, you can develop web forms pages in any language that supports the .net framework. In addition, your code no longer needs to share the same file with your http text (although it can continue to do so if you prefer). Web forms pages execute in native machine language because, like any other managed application, they take full advantage of the runtime. In contrast, unmanaged asp pages are always scripted and interpreted. Asp.net pages are faster, more functional, and easier to develop than unmanaged asp pages because they interact with the runtime like any managed application. The .net framework also provides a collection of classes and tools to aid in development and consumption of xml web services applications. Xml web services are built on standards such as SOAP (a remote procedure-call protocol), xml (an extensible data format), and WSDL ( the web services description language). The .net framework is built on these standards to promote interoperability with non-Microsoft solutions. For example, the web services description language tool included with the .net framework SDK can query an xml web service published on the web, parse its wsdl description, and produce c# or visual basic source code that your application can use to become a client of the xml web service. The source code can create classes derived from classes in the class library that handle all the underlying communication using soap and xml parsing. Although you can use the class library to consume xml web services directly, the web services description language tool and the other tools contained in the sdk facilitate your development efforts with the .net framework. If you develop and publish your own xml web service, the .net framework provides a set of classes that conform to all the underlying communication standards, such as soap, wsdl, and xml. Using those classes enables you to focus on the logic of your
service, without concerning yourself with the communications infrastructure required by distributed software development. Finally, like web forms pages in the managed environment, your xml web service will run with the speed of native machine language using the scalable communication of iis.
COMMON LANGUAGE RUNTIME
The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET initiative. It is Microsoft's implementation of the Common Language Infrastructure (CLI) standard, which defines an execution environment for program code. The CLR runs a form of bytecode called the Microsoft Intermediate Language (MSIL), Microsoft's implementation of the Common Intermediate Language. Developers using the CLR write code in a high level language such as C# or VB.Net. At compile-time, a .NET compiler converts such code into MSIL (Microsoft Intermediate Language) code. At runtime, the CLR's just-in-time compiler (JIT compiler) converts the MSIL code into code native to the operating system. Alternatively, the MSIL code can be compiled to native code in a separate step prior to runtime. This speeds up all later runs of the software as the MSIL-to-native compilation is no longer necessary.
Source code Bytecode Native code
C# compiler ___________ C# ----------------------->| | | | | | VB.NET compiler | | CLR VB.NET ------------------->| MSIL Code |---------> native code | | | | Other compiler | | Other .NET --------------->| | Language |___________| \________________________________/ \____________________________/ | | Compile-time runtime
Although some other implementations of the Common Language Infrastructure run on non-Windows operating systems, the CLR runs on Microsoft Windows operating systems.
Compilers and tools expose the runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services. To enable the runtime to provide services to managed code, language compilers must emit metadata that describes the types, members, and references in your code. Metadata is stored with the code; every loadable common language runtime portable executable (PE) file contains metadata. The runtime uses metadata to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set run-time context boundaries. The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way are called managed data. Garbage collection eliminates memory leaks as well as some other common programming errors. If your code is managed, you can use managed data, unmanaged data, or both managed and unmanaged data in your .NET Framework application. Because language compilers supply their own types, such as primitive types, you might not always know (or need to know) whether your data is being managed. The common language runtime makes it easy to design components and applications whose objects interact across languages. Objects written in different languages can communicate with each other, and their behaviors can be tightly integrated. For example, you can define a class and then use a different language to derive a class from your original class or call a method on the original class. You can also pass an instance of a class to a method of a class written in a different language. This crosslanguage integration is possible because language compilers and tools that target the runtime use a common type system defined by the runtime, and they follow the runtime's
rules for defining new types, as well as for creating, using, persisting, and binding to types. As part of their metadata, all managed components carry information about the components and resources they were built against. The runtime uses this information to ensure that your component or application has the specified versions of everything it needs, which makes your code less likely to break because of some unmet dependency. Registration information and state data are no longer stored in the registry where they can be difficult to establish and maintain. Rather, information about the types you define (and their dependencies) is stored with the code as metadata, making the tasks of component replication and removal much less complicated. Language compilers and tools expose the runtime's functionality in ways that are intended to be useful and intuitive to developers. This means that some features of the runtime might be more noticeable in one environment than in another. How you experience the runtime depends on which language compilers or tools you use. For example, if you are a Visual Basic developer, you might notice that with the common language runtime, the Visual Basic language has more object-oriented features than before. Following are some benefits of the runtime: • • • • Performance improvements. The ability to easily use components developed in other languages. Extensible types provided by a class library. New language features such as inheritance, interfaces, and overloading for objectoriented programming; support for explicit free threading that allows creation of multithreaded, scalable applications; support for structured exception handling and custom attributes. • If you use Microsoft® Visual C++® .NET, you can write managed code using Visual C++, which provides the benefits of a managed execution environment as
well as access to powerful capabilities and expressive data types that you are familiar with. Additional runtime features include: • • Cross-language integration, especially cross-language inheritance. Garbage collection, which manages object lifetime so that reference counting is unnecessary. • Self-describing objects, which make using Interface Definition Language (IDL) unnecessary. • The ability to compile once and run on any CPU and operating system that supports the runtime. • You can also write managed code using the C# language, which provides the following benefits: • • • • • • Complete object-oriented design. Very strong type safety. A good blend of Visual Basic simplicity and C++ power. Garbage collection. Syntax and keywords similar to C and C++. Use of delegates rather than function pointers for increased type safety and security. Function pointers are available through the use of the unsafe C# keyword and the /unsafe option of the C# compiler (Csc.exe) for unmanaged code and data.
Common Language Infrastructure
Visual overview of the Common Language Infrastructure (CLI) The Common Language Infrastructure (CLI) is an open specification developed by Microsoft that describes the executable code and runtime environment that form the core of the Microsoft .NET Framework. The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures. To clarify, the CLI is a specification, not an implementation, and is often confused with the Common Language Runtime (CLR), which contains aspects outside the scope of the specification.
COMMON TYPE SYSTEM OVERVIEW
A set of types and operations that are shared by all CTS-compliant programming languages.
Classification of Types
The common type system supports two general categories of types, each of which is further divided into subcategories:
Value types directly contain their data, and instances of value types are either allocated on the stack or allocated inline in a structure. Value types can be built-in (implemented by the runtime), user-defined, or enumerations. For a list of built-in value types, see the .NET Framework Class Library.
Reference types store a reference to the value's memory address, and are allocated on the heap. Reference types can be self-describing types, pointer types, or interface types. The type of a reference type can be determined from values of self-describing types. Self-describing types are further split into arrays and class types. The class types are user-defined classes, boxed value types, and delegates. Variables that are value types each have their own copy of the data, and therefore operations on one variable do not affect other variables. Variables that are reference types can refer to the same object; therefore, operations on one variable can affect the same object referred to by another variable. All types derive from the System.Object base type. The following diagram illustrates how these various types are related. Note that instances of types can be simply value types or self-describing types, even though there are subcategories of these types.
Values and Objects
Values are binary representations of data, and types provide a way of interpreting this data. A value type is stored directly as a binary representation of the type's data. The value of a reference type is the location of the sequence of bits that represent the type's data. Every value has an exact type that completely defines the value's representation and the operations that are defined on the value. Values of self-describing types are called objects. While it is always possible to determine the exact type of an object by examining its value, you cannot do so with a value type or pointer type. A value can have more than one type. A value of a type that implements an interface is also a value of that interface type. Likewise, a value of a type that derives from a base type is also a value of that base type.
Types and Assemblies
The runtime uses assemblies to locate and load types. The assembly manifest contains the information that the runtime uses to resolve all type references made within the scope of the assembly. A type name in the runtime has two logical parts: the assembly name and the name of the type within the assembly. Two types with the same name but in different assemblies are defined as two distinct types. Assemblies provide consistency between the scope of names seen by the developer and the scope of names seen by the runtime system. Developers author types in the context of an assembly. The content of the assembly a developer is building establishes the scope of names that will be available at run time.
Types and Namespaces
From the viewpoint of the runtime, a namespace is just a collection of type names. Particular languages might have constructs and corresponding syntax that help developers form logical groups of types, but these constructs are not used by the runtime when binding types. Thus, both the Object and String classes are part of the System namespace, but the runtime only recognizes the full names of each type, which are System.Object and System.String, respectively. You can build a single assembly that exposes types that look like they come from two different hierarchical namespaces, such as System.Collections and System.Windows.Forms. You can also build two assemblies that both export types whose names contain MyDll.MyClass. If you create a tool to represent types in an assembly as belonging to a hierarchical namespace, the tool must enumerate the types in an assembly or group of assemblies and parse the type names to derive a hierarchical relationship.
Metadata is binary information describing your program that is stored either in a common language runtime portable executable (PE) file or in memory. When you compile your code into a PE file, metadata is inserted into one portion of the file, while your code is converted to Microsoft intermediate language (MSIL) and inserted into another portion of the file. Every type and member defined and referenced in a module or assembly is described within metadata. When code is executed, the runtime loads metadata into memory and references it to discover information about your code's classes, members, inheritance, and so on. Metadata describes every type and member defined in your code in a language-neutral manner. Metadata stores the following information: • • • • • • • • • • Description of the assembly. Identity (name, version, culture, public key). The types that are exported. Other assemblies that this assembly depends on. Security permissions needed to run. Description of types. Name, visibility, base class, and interfaces implemented. Members (methods, fields, properties, events, nested types). Attributes. Additional descriptive elements that modify types and members.
Benefits of Metadata
Metadata is the key to a simpler programming model, eliminating the need for Interface Definition Language (IDL) files, header files, or any external method of component reference. Metadata allows .NET languages to describe themselves automatically in a language-neutral manner, unseen by both the developer and the user. Additionally, metadata is extensible through the use of attributes. Metadata provides the following major benefits:
Common language runtime modules and assemblies are self-describing. A module's metadata contains everything needed to interact with another module. Metadata automatically provides the functionality of IDL in COM, allowing you to use one file for both definition and implementation. Runtime modules and assemblies do not even require registration with the operating system. As a result, the descriptions used by the runtime always reflect the actual code in your compiled file, which increases application reliability. Language interoperability and easier component-based design. Metadata provides all the information required about compiled code for you to inherit a class from a PE file written in a different language. You can create an instance of any class written in any managed language (any language that targets the common language runtime) without worrying about explicit marshaling or using custom interoperability code.
The .NET Framework allows you to declare specific kinds of metadata, called attributes, in your compiled file. Attributes can be found throughout the .NET Framework and are used to control in more detail how your program behaves at run time. Additionally, you can emit your own custom metadata into .NET Framework files through user-defined custom attributes.
COMMON LANGUAGE SPECIFICATION
To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), which is a set of basic language features needed by many applications, has been defined. The CLS rules define a subset of the Common Type System; that is, all the rules that apply to the common type system apply to the CLS, except where stricter rules are defined in the CLS. The CLS helps enhance and ensure language interoperability by defining a set of features that developers can rely on to be available in a wide variety of languages. The CLS also establishes requirements for CLS compliance; these help you determine whether your managed code conforms to the CLS and to what extent a given tool supports the development of managed code that uses CLS features. If your component uses only CLS features in the API that it exposes to other code (including derived classes), the component is guaranteed to be accessible from any programming language that supports the CLS. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components. Most of the members defined by types in the .NET Framework Class Library Overview are CLS-compliant. However, some types in the class library have one or more members that are not CLS-compliant. These members enable support for language features that are not in the CLS. The types and members that are not CLS-compliant are identified as such in the reference documentation, and in all cases a CLS-compliant alternative is available. The CLS was designed to be large enough to include the language constructs that are commonly needed by developers, yet small enough that most languages are able to support it. In addition, any language constructs that makes it impossible to rapidly verify the type safety of code was excluded from the CLS so that all CLS-compliant languages can produce verifiable code if they choose to do so.
.NET Framework 3.0
Architecture of the .NET Framework 3.0 .NET Framework 3.0, formerly called WinFX,includes a new set of managed code APIs that are an integral part of Windows Vista and Windows Server “Longhorn” operating systems. It is also available for Windows XP SP2 and Windows Server 2003 as a download. There are no major architectural changes included with this release; .NET Framework 3.0 includes version 2.0 of the Common Language Runtime. The .NET 3.0 installer available from Microsoft checks to see if .NET 2.0 is already installed. If not, it
installs it and then installs .NET 3.0 components. Otherwise it just installs .NET 3.0 components. This means that if you do not have .NET 2.0 installed, you do not need to install it; you can install .NET 3.0 straight away. .NET 1.1 and its service-pack, however, must be installed separately, preferably before installing .NET 3.0.
.NET Framework 3.0 consists of four major new components:
Windows Presentation Foundation (WPF), formerly code-named Avalon; a new user interface subsystem and API based on XML and Vector Graphics, which uses 3D Computer Graphics hardware and Direct3D technologies. See WPF SDK for developer articles and documentation on WPF.
Windows Communication Foundation (WCF), formerly code-named Indigo; a service-oriented messaging system which allows programs to interoperate locally or remotely similar to Web Services.
Windows Workflow Foundation (WF) allows for building of task automation and integrated transactions using workflows.
Windows CardSpace (WCS), formerly code-named InfoCard; a software component which securely stores a person's digital identities and provides a unified interface for choosing the identity for a particular transaction, such as logging in to a website.
OVERVIEW OF ADO.NET
• ADO.NET provides consistent access to data sources such as Microsoft SQL Server and XML, as well as to data sources exposed through OLE DB and ODBC. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, manipulate, and update the data that they contain. • ADO.NET separates data access from data manipulation into discrete components that can be used separately or in tandem. ADO.NET includes .NET Framework
data providers for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, placed in an ADO.NET DataSet object in order to be exposed to the user in an ad hoc manner, combined with data from multiple sources, or remoted between tiers. The ADO.NET DataSet object can also be used independently of a .NET Framework data provider to manage data local to the application or sourced from XML. • The ADO.NET classes are found in System.Data.dll, and are integrated with the XML classes found in System.Xml.dll. When compiling code that uses the System.Data namespace, reference both System.Data.dll and System.Xml.dll. For an example of an ADO.NET application that connects to a database, retrieves data from it, and then displays that data in a command prompt. • ADO.NET provides functionality to developers writing managed code similar to the functionality provided to native component object model (COM) developers by ActiveX Data Objects (ADO).
Design Goals for ADO.NET
As application development has evolved, new applications have become loosely coupled, often based on the Web application model. More and more of today's applications use XML to encode data to be passed over network connections. Web applications use HTTP as the fabric for communication between tiers, and must explicitly handle maintaining state between requests. This new model is very different from the connected, tightly coupled style of programming that characterized the client/server era, where a connection was held open for the duration of the program's lifetime, and no special handling of state was required. In designing tools and technologies to meet the needs of today's developer, Microsoft recognized that an entirely new programming model for data access was needed, and built it upon the .NET Framework. Building on the .NET Framework ensured that the data access technology would be uniform, because components would share a common type system, design patterns, and naming conventions.
ADO.NET was designed to meet the needs of this new programming model: disconnected data architecture, tight integration with XML, common data representation with the ability to combine data from multiple and varied data sources, and optimized facilities for interacting with a database, all native to the .NET Framework. In creating ADO.NET, Microsoft embraced the following design goals:
• • •
Leverage current ActiveX Data Objects (ADO) knowledge. Support the n-tier programming model. Integrate XML support.
Leverage Current ADO Knowledge
The design for ADO.NET addresses many of the requirements of today's application development model. At the same time, the programming model stays as similar as possible to ADO, so current ADO developers do not have to start from the beginning. ADO.NET is an intrinsic part of the .NET Framework yet retains familiarity to the ADO programmer. ADO.NET also coexists with ADO. Although most new .NET-based applications will be written using ADO.NET, ADO remains available to the .NET programmer through .NET COM interoperability services.
Support the N-Tier Programming Model
The concept of working with a disconnected set of data has become a focal point in the programming model. ADO.NET provides first-class support for the disconnected, n-tier programming environment for which many new applications are written. The ADO.NET solution for n-tier programming is the DataSet.
Integrate XML Support
XML and data access are closely tied. XML is about encoding data, and data access is increasingly becoming about XML. The .NET Framework does not just support Web standards; it is built entirely on top of them.
XML support is built into ADO.NET at a very fundamental level. The XML classes in the .NET Framework and ADO.NET are part of the same architecture; they integrate at many different levels. You therefore no longer have to choose between the data access set of services and their XML counterparts; the ability to cross over from one to the other is inherent in the design of both.
Data processing has traditionally relied primarily on a connection-based, two-tier model. As data processing increasingly uses multitier architectures, programmers are switching to a disconnected approach to provide better scalability for their applications.
There are two components of ADO.NET that you can use to access and manipulate data:
.NET Framework data providers The DataSet
.NET Framework Data Providers
The .NET Framework Data Providers are components that have been explicitly designed for data manipulation and fast, forward-only, read-only access to data. The Connection object provides connectivity to a data source. The Command object enables access to database commands to return data, modify data, run stored procedures, and send or retrieve parameter information. The DataReader provides a high-performance stream of data from the data source. Finally, the DataAdapter provides the bridge between the DataSet object and the data source. The DataAdapter uses Command objects to execute SQL commands at the data source to both load the DataSet with data, and reconcile changes made to the data in the DataSet back to the data source.
The ADO.NET Dataset is explicitly designed for data access independent of any data source. As a result, it can be used with multiple and differing data sources, used with XML data, or used to manage data local to the application. The DataSet contains a collection of one or more DataTable objects made up of rows and columns of data, as well
as primary key, foreign key, constraint, and relation information about the data in the DataTable objects. The following diagram illustrates the relationship between a .NET Framework data provider and a DataSet.
Choosing a DataReader or a DataSet
When deciding whether your application should use a DataReader or a DataSet, you should consider the type of functionality that your application requires. Use a DataSet to do the following:
Cache data locally in your application so that you can manipulate it. If you only need to read the results of a query, the DataReader is the better choice. Remote data between tiers or from an XML Web service.
Interact with data dynamically such as binding to a Windows Forms control or combining and relating data from multiple sources. Perform extensive processing on data without requiring an open connection to the data source, which frees the connection to be used by other clients. If you do not require the functionality provided by the DataSet, you can improve the performance of your application by using the DataReader to return your data in a forward-only, read-only fashion. Although the DataAdapter uses the DataReader to fill the contents of a DataSet , by using the DataReader you can boost performance because you will save memory that would be consumed by the DataSet, as well as avoid the processing required to create and fill the contents of the DataSet.
XML and ADO.NET
ADO.NET leverages the power of XML to provide disconnected access to data. ADO.NET was designed hand-in-hand with the XML classes in the .NET Framework; both are components of a single architecture. ADO.NET and the XML classes in the .NET Framework converge in the DataSet object. The DataSet can be populated with data from an XML source, whether it is a file or an XML stream. The DataSet can be written as World-Wide Web Consortium (W3C) compliant XML, including its schema as XML Schema definition language (XSD) schema, regardless of the source of the data in the DataSet. Because of the native serialization format of the DataSet is XML, it is an excellent medium for moving data between tiers, making the DataSet an optimal choice for remoting data and schema context to and from an XML Web service.
ADO.NET Platform Requirements
The Microsoft .NET Framework SDK (including ADO.NET) is supported on Microsoft® Windows XP, Windows 2000, Windows NT 4 with Service Pack 6a, Windows Millennium Edition, Windows 98, and Windows CE. The .NET Framework Data Provider for OLE DB and the .NET Framework Data Provider for ODBC requires MDAC 2.6 or later, and MDAC 2.8 Service Pack 1 (SP1) is
recommended. You can download MDAC 2.8 SP1 from the Data Access and Storage Developer Center The ADO.NET classes are found in System.Data.dll, and are integrated with the XML classes found in System.Xml.dll. When compiling code that uses the System.Data namespace, reference both System.Data.dll and System.Xml.dll. Remoting or Marshaling Data Between Tiers and Clients The design of the DataSet enables you to easily transport data to clients over the Web using XML Web services, as well as allowing you to marshal data between .NET components using .NET remoting services. You can also remote a strongly typed DataSet in this fashion. For an overview of XML Web services, see XML Web Services Overview. In ADO.NET 2.0, DataTable objects can also be used with both remoting services and XML Web services.
.NET Framework Data Providers
A .NET Framework data provider is used for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, placed in an ADO.NET DataSet in order to be exposed to the user in an ad hoc manner, combined with data from multiple sources, or remoted between tiers. .NET Framework data providers are lightweight, creating a minimal layer between the data source and your code, increasing performance without sacrificing functionality.
The .NET Framework Data Provider for SQL Server
The .NET Framework Data Provider for SQL Server uses its own protocol to communicate with SQL Server. It is lightweight and performs well because it is optimized to access a SQL Server directly without adding an OLE DB or Open Database Connectivity (ODBC) layer. The following illustration contrasts the .NET Framework Data Provider for SQL Server with the .NET Framework Data Provider for OLE DB. The .NET Framework Data Provider for OLE DB communicates to an OLE DB data source
through both the OLE DB Service component, which provides connection pooling and transaction services, and the OLE DB Provider for the data source. The .NET Framework Data Provider for ODBC has a similar architecture to the .NET Framework Data Provider for OLE DB; for example, it calls into an ODBC Service Component.
Comparison of the .NET Framework Data Provider for SQL Server and the .NET Framework Data Provider for OLE DB
To use the .NET Framework Data Provider for SQL Server, you must have access to SQL Server 2000 or later. The .NET Framework Data Provider for SQL Server classes are located in the System.Data.SqlClient namespace. For earlier versions of SQL Server, use the .NET Framework Data Provider for OLE DB with the SQL Server OLE DB Provider (SQLOLEDB). The .NET Framework Data Provider for SQL Server supports both local and distributed transactions. For distributed transactions, the .NET Framework Data Provider for SQL Server, by default, automatically enlists in a transaction and obtains transaction details from Windows Component Services or System.Transactions.
The DataSet object is central to supporting disconnected, distributed data scenarios with ADO.NET. The DataSet is a memory-resident representation of data that provides a consistent relational programming model regardless of the data source. It can be used with multiple and differing data sources, with XML data, or to manage data local to the application. The DataSet represents a complete set of data, including related tables, constraints, and relationships among the tables. The following illustration shows the DataSet object model.
DataSet object model
The methods and objects in a DataSet are consistent with those in the relational database model. The DataSet can also persist and reload its contents as XML, and its schema as XML Schema definition language (XSD) schema.
An ADO.NET DataSet contains a collection of zero or more tables represented by DataTable objects. The DataTableCollection contains all the DataTable objects in a DataSet. A DataTable is defined in the System.Data namespace and represents a single table of memory-resident data. It contains a collection of columns represented by a
DataColumnCollection, and constraints represented by a ConstraintCollection, which together define the schema of the table. A DataTable also contains a collection of rows represented by the DataRowCollection, which contains the data in the table. Along with its current state, a DataRow retains both its current and original versions to identify changes to the values stored in the row.
A DataSet contains relationships in its DataRelationCollection object. A relationship, represented by the DataRelation object, associates rows in one DataTable with rows in another DataTable. A relationship is analogous to a join path that might exist between primary and foreign key columns in a relational database. A DataRelation identifies matching columns in two tables of a DataSet. Relationships enable navigation from one table to another within a DataSet. The essential elements of a DataRelation are the name of the relationship, the name of the tables being related, and the related columns in each table. Relationships can be built with more than one column per table by specifying an array of DataColumn objects as the key columns. When you add a relationship to the DataRelationCollection, you can optionally add a UniqueKeyConstraint and a ForeignKeyConstraint to enforce integrity constraints when changes are made to related column values.
The DataSet, DataTable, and DataColumn all have an ExtendedProperties property. ExtendedProperties is a PropertyCollection where you can place custom information, such as the SELECT statement that was used to generate the result set, or the time when the data was generated. The ExtendedProperties collection is persisted with the schema information for the DataSet.
What's New in ADO.NET
The following features are new in ADO.NET version 2.0.
Provides support for enumerating active instances of Microsoft SQL Server 2000 and later. Asynchronous Processing
Allows you to perform asynchronous database operations using an API that is modeled after the asynchronous model used by the .NET Framework. Multiple Active Result Sets (MARS)
Allows an application to have more than one SqlDataReader open on a connection when each instance of SqlDataReader is started from a separate command. Bulk Copy Operations
Enables you to perform fast bulk inserts using the .NET Data Provider for SQL Server. New SQL Server Max Data Types
Provides support for varchar(max), nvarchar(max), varbinary(max) data types in SQL Server 2005. SQL Server User-Defined Types
Provides support for user-defined data types (UDTs) in SQL Server 2005. SQL Server Notifications
Allows .NET Framework applications to send a command to SQL Server and request that a notification be generated if executing the same command would produce result sets different from those initially retrieved. Transactions with SQL Server Snapshot Isolation
Provides support for snapshot isolation, a SQL Server 2005 mechanism designed to reduce blocking in OLTP applications. Database Mirroring in SQL Server 2005
Provides support for database mirroring in SQL Server 2005 with new connection string syntax for specifying a failover partner server. Provider Statistics
Provides support for retrieving runtime statistics in SQL Server 2005. Currently 21 different counters are available from the .NET Provider for SQL Server. Change Password in SQL Server 2005
Allows .NET Framework applications to change password of a user account without requiring administrator intervention. Batch Processing
Enhances application performance by reducing the number of round-trips to the database when applying updates from the DataSet. Tracing
ADO.NET 2.0 introduces new built-in data tracing functionality that is supported by the .NET data providers. Partial Trust
All Microsoft data providers are now supported in partially trusted environments. Connection Pooling Control
ADO.NET 2.0 introduces two new methods to clear the connection pool: ClearAllPools and ClearPool. SQL Server XML Data Type Support
SQL Server 2005 has a new XML data type, and System.Data.SqlClient provides robust support for it on the client. The XML values are exposed using the System.Xml framework for seamless integration with the .NET programming model. Integration with System.Transactions and Promotable Transactions Optimization for SQL Server 2005
.NET 2.0 includes a new transactions framework, accessible through the System.Transactions namespace. When combining System.Transactions for distributed transaction management, System.Data.SqlClient for database access, and SQL Server 2005 as the back end, it is possible to optimize distributed transactions so that the extra cost of making them "distributed" is only incurred when the transactions are actually needed.
The new DataTableReader presents the contents of a DataSet or a DataTable in the form of one or more read-only, forward-only result sets. DataSet Enhancements
A new index engine improves the performance of insert, delete, and modify operations to DataTable and DataRow objects. An index or primary key must be defined in the base table. Binary Serialization for the DataSet
This new option enables a DataSet and a DataTable to be serialized in binary format when using binary transports over remoting. In most cases this will result great performance improvements and a noticeable reduction in both memory and CPU usage when using DataSet/DataTable objects in applications that use remoting to connect to different tiers. DataTable as a Stand-Alone Object
Many methods that were only available in the DataSet in previous versions are now available in the DataTable as well (such as ReadXml and WriteXml). Also, a DataTable can be serialized by itself, so it’s no longer necessary to have a DataSet with a single table just to expose the table through Web services or any other mechanism that requires serialization. Create a DataTable from a DataView
You can now create a DataTable from a DataView. The new DataTable will have the same set of rows as the current DataView. Optionally the columns of the new DataTable can be a subset of the DataView columns. The rows can be either all rows or only distinct rows. For more information, see ToTable. Schema Inference Engine Enhancements
The schema inference engine has been enhanced to infer types when enough information is available; it is also significantly faster. Namespace-Qualified Tables
A DataSet can now support tables that have the same TableName but with a different Namespace, providing a mechanism to avoid naming conflicts.
New DataTable Loading Capabilities
The new Load method for DataTables and DataSets can stream a DataReader into a DataTable directly. The Load method also has new options for load behavior that extend the functionality available through the DataAdapter. Row State Control
The new SetAdded and SetModified methods allow applications to explicitly manipulate the row state for DataSet and DataTable rows. Enhanced Support for Custom Defined Types
The DataTable provides more support for custom, user-defined types. XML serialization has been extended to support polymorphism. For example, a Person Column can store an Employee instance that gets serialized and de-serialized to and from XML without loss of any type fidelity. Additionally users can now implement the new change tracking interfaces that enable the DataTable to track changes for such objects. XML/XSD Enhancements
Added support for reading and writing simple types in XSD. Added support for reading and writing of multiple schemas to a stream. Added support for reading and writing of XSD/XML where a single table or XML Element is nested inside two or more parent tables. DataRow Enhancements
The new IndexOf can be used to find position of row in DataTable.Rows collection. Change Position of Column in DataTable
The new SetOrdinal method allows users to change the position of the column in a DataTable. DataView Performance Improvements
The DataView in ADO.NET 2.0 uses a new update algorithm resulting in significant improvement in DataView maintenance. DataColumn Expressions
An expression in a DataColumn can include columns from the same DataTable. The expression can be updated, and the column value is maintained. Schema Serialization for Typed DataSet
Typed DataSets can skip the schema component from being serialized by setting the SchemaSerializationMode enumeration to ExcludeSchema.
.NET Data Provider Enumeration
Provides support for enumerating installed data providers. Provider Independent API Enhancements to the System.Data.Common namespace provide access through a single API to databases across multiple providers. Schema Discovery
Schema discovery allows applications to request managed providers to find and return information about the database schema of the database a given connection is connected to. Different database schema elements such as tables, columns and stored-procedures are exposed through the GetSchema methods of each provider's Connection class.
SQL Server 2000 Overview
SQL Server™ 2000 a scalable, reliable, and easy-to-use product that will provide a solid foundation for application design for the next 20 years.
Features of SQL Server 2000
In t ern et In t eg ra t i on .
The SQL Server 2000 database engine includes integrated XML support. It also has the scalability, availability, and security features required to operate as the data storage component of the largest Web sites. The SQL Server 2000 programming model is integrated with the Windows DNA architecture for developing Web applications, and SQL Server 2000 supports features such as English Query and the Microsoft Search Service to incorporate user-friendly queries and powerful search capabilities in Web applications.
S ca l a b i l it y a n d Avai l ab il i ty.
The same database engine can be used across platforms ranging from laptop computers running Microsoft Windows® 98 through large, multiprocessor servers running Microsoft Windows 2000 Data Center Edition. SQL Server 2000 Enterprise Edition supports features such as federated servers, indexed views, and large memory support that allow it to scale to the performance levels required by the largest Web sites.
En t erp ri s e- Lev el Dat ab ase F eat u res.
The SQL Server 2000 relational database engine supports the features required to support demanding data processing environments. The database engine protects data integrity while minimizing the overhead of managing thousands of users concurrently modifying the database. SQL Server 2000 distributed queries allow you to reference data from multiple sources as if it were a part of a SQL Server 2000 database, while at the same time, the distributed transaction support protects the integrity of any updates of the distributed data. Replication allows you to also maintain multiple copies of data, while ensuring that the separate copies remain synchronized. You can replicate a set of data to multiple, mobile, disconnected users, have them work autonomously, and then merge their modifications back to the publisher.
Ea se o f i n st a l l at i on , d ep l oy men t , an d u se.
SQL Server 2000 includes a set of administrative and development tools that improve upon the process of installing, deploying, managing, and using SQL Server across several sites. SQL Server 2000 also supports a standards-based programming model integrated with the Windows DNA, making the use of SQL Server databases and data warehouses a seamless part of building powerful and scalable systems. These features allow you to rapidly deliver SQL Server applications that customers can implement with a minimum of installation and administrative overhead.
Da t a wa reh o u si n g .
SQL Server 2000 includes tools for extracting and analyzing summary data for online analytical processing. SQL Server also includes tools for visually designing databases and analyzing data using English-based questions.
SQL Server 2000 Component Overview
This diagram is an illustration of the relationships between the major components of Microsoft® SQL Server™ 2000.
INTRODUCTION TO SQL
Structured Query Language (SQL) is the set of commands That all programs and users must use to access data within the Oracle database. Application programs and Oracle tools often allow users to access the database without directly using SQL, but these applications in turn must use SQL when executing the user's request. This chapter provides background information on SQL used by most relational database systems. Topics include:
• • •
History of SQL SQL Standards How SQL Works
History of SQL
The paper, "A Relational Model of Data for Large Shared Data Banks," by Dr. E. F. Codd, was published in June 1970 in the Association of Computer Machinery (ACM) journal, Communications of the ACM. Codd's model is now accepted as the definitive model for relational database management systems (RDBMS). The language, Structured English Query Language (SEQUEL) was developed by IBM Corporation, Inc. to use Codd's model. SEQUEL later became SQL. In 1979, Relational Software, Inc. (now Oracle Corporation) introduced the first commercially available implementation of SQL. Today, SQL is accepted as the standard RDBMS language.
Oracle SQL complies with industry accepted standards. Oracle Corporation ensures future compliance with evolving SQL standards by actively involving key personnel in SQL standards committees. Industry accepted
committees are the American National Standards Institute (ANSI) and the International Standards Organization (ISO), which is affiliated with the International Electro technical Commission (IEC). Both ANSI and the ISO/IEC have accepted SQL as the standard language for relational databases. When a new SQL standard is simultaneously published by these organizations, the names of the standards conform to conventions used by the organization, but the technical details are exactly the same.
How SQL Works
This section describes many of the reasons for SQL's widespread acceptance by relational database vendors as well as end users. The strengths of SQL benefit all ranges of users including application programmers, database administrators, management, and end users. Technically speaking, SQL is a data sub language. That is to say, the purpose of SQL is to interface to a relational database such as Oracle, and all SQL statements are instructions to the database. In this it differs from general purpose programming languages like C and Basic. Among the features of SQL are the following: • It processes sets of data as groups rather than as individual units. • It provides automatic navigation to the data. • It uses statements that are complex and powerful individually, and that therefore stand alone. Flow-control statements were not part of SQL originally, but they are found in the recently accepted optional part of SQL, ISO/IEC 9075-5 : 1996. Flow-control statements are commonly known as "Persistent Stored Modules" or PSM, and Oracle's PL/SQL extension to SQL is close to PSM. Essentially, SQL lets you work with data at the logical
level, only being concerned with the implementation details when you want to manipulate them. SQL provides commands for a variety of tasks including: • querying data • inserting, updating, and deleting rows in a table • creating, replacing, altering, and dropping objects • controlling access to the database and its objects • Guaranteeing database consistency and integrity SQL unifies all of the above tasks in one consistent language.
Oracle and Standard SQL
This appendix discusses the following topics: • Oracle's conformance to the SQL standards established by industry standards governing bodies • Oracle's extensions to standard SQL • Locating extensions to standard SQL with the FIPS Flogger
INTRODUCTION TO DATA DEFINITION LANGUAGE
The data Definition Language is used to create an object alter the structure of an object and also to drop the table created. A table is a unit of storage which holds data in the form of rows and columns. The DDL can be classified in to following categories. • Create table command • Alter table command
• Drop table command 1. Create: This command is used to create a table in the data base. create table <table name>(column definition1,column definition2,....); 2. Alter command: alter command cater to the need of the following situations. • When the user wants to add a new column to the existing table. alter table <table name> add (column definition...); • When the user wants to modify the existing column definition.
alter table <table name> modify (column definition...); 3. Drop table command: This command is used to drop the table from the data base. drop table <table name>;
DATA MANIPULATION LANGUAGE COMMANDS
Data Manipulation Commands are most frequently used SQL commands. They are as follows, • Insert • Select • Update • Delete
INSERT COMMAND: This command is used to add one or more rows to the table. While using this command the values are separated by commas and the data types char and date are enclosed in apostrophes. The values must be entered in the same order as they are defined in the table. Insert into <table name> values (a list of data values); SELECT COMMAND: To perform a query we use the select command. The query is a request for the information. It is the most common data base operation used. Select column name..... From <table name>; Select * from <table name>; It will give all the information in the table. UPDATE COMMAND: Update command is used to alter the column values in the table. The update command consists of a ‘set’ clause and an optional ‘where’ clause. Update <table name> set field=value... where condition; e.g. update EMP set Sal=10000 where name=’Reddy’; DELETE COMMAND: or
This command is used to delete several rows from the table. After inserting rows in a table we can also delete then if required. The delete command consists of a ‘from clause’ followed by an optional ‘where clause’. Delete from <table name> where conditions;
TRANSACTION CONTROL COMMANDS
Commit: This command is used to end a transaction. Commit work; Or Commit; Rollback: A rollback command is used to undo the work done in the current transaction. Rollback; Grant The GRANT command (System Privileges and Roles) is an extension to standard SQL. The GRANT command (Object Privileges) supports the following other privileges on other objects in addition to the DELETE, INSERT, REFERENCES, SELECT, and UPDATE Privileges on tables and views supported by Entry SQL-92: • ALTER • EXECUTE • INDEX • READ This command also supports granting object privileges to roles.
This section describes additional operators and additional functionality of standard operators.
Oracle supports these operators that are not part of Entry SQL-92:
• || character operator (character concatenation) • !=, ^=, and ¬= comparison operators (inequality) • MINUS set operator • INTERSECT set operator • (+) operator (outer join)
An integrity constraint is a mechanism used by Oracle to prevent invalid data entry into the table. The following are the various types of integrity constraints. • Domain integrity constraint • Not Null constraint • Check constraint • Unique constraint • Referential integrity constraint Not Null When a ‘Not Null’ constraint is enforced on a column or a set of columns in a table, it will not allow Null values. e.g. Create table <table name> (column definition1 constraint <constraint name>Not Null, column definiton2..,);
Check constraint: These are rules governed by logical or Boolean expression. e.g. Create table EMP (eid number (4) constraint con check (eid>100)); This constraint is used to prevent the duplication of values within the rows of a specified column in the table. e.g. Create table EMP (eid number (4) constraint con unique); This constraint avoids duplication of rows and does not allow Null values, when e.g. enforced in a column or set of columns. Create table EMP (eid number (4) constraint con primary key); To establish a ‘parent-child’ or a ‘master-detail’ relationship between two tables having a common column, we make use of referential integrity constraints. Primary Key Constraint: Unique constraint:
Referential Integrity Constraint:
Basic components related to this constraint are:
Foreign Key: A column or combination of columns include in the definition of referential integrity which would refer to a referenced key. Referenced Key: It is a unique or primary key which is defined on a column belonging to the parent table. Child Table: This table depends upon the values present in the referenced key of the parent table, which is referred by a foreign key. Parent table: This table determines insertion or updating of data can be done in child table. This table would be referred by child’s table foreign key. e.g. Create table EMP (eid number (4) constraint con references dept (deptid));
On Delete Cascade clause
If all the rows under the referenced key column in a parent table are deleted, then all rows in the child table with dependent foreign key column will also be deleted automatically. e.g. Create table EMP (eid number (4) constraint con references dept (deptid) on delete cascade);
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.