.NET news » Database

For low-volume databases, those that are predominantly read and not written to, or database tables that are designed to not be updated or only updated under rare circumstances, a DBA or developer may be interested in being notified whenever the data in a particular table is modified. Or you may have certain records in a table that are assigned to a particular user and, upon that record being updated, that user should be notified of the change. While this sort of logic can be implemented at the code level, Microsoft SQL Server has all of the technologies needed to achieve this aim built directly into it. Triggers can be used to perform some action when data is inserted, updated, or deleted from a table, and Microsoft SQL Server's xp_sendmail extended stored procedure can be invoked to send an email to one or more recipients. Combining triggers with xp_sendmail provides a means for alerting specified users via email when the data in a particular table is modified...

This article describes best practices for leveraging the benefits of NHibernate, ASP.NET, Generics, and unit testing together.

A reusable component which extends the DataGrid and adds functionality for real time filtering.

SQL Server Reporting Services makes it easy to build reports from database data, but what if the data isn't in a database? This article shows you how to take advantage of Reporting Services' unique extensibility model to build reports from ADO.NET datasets.

As database developers, many of us have had to dip our feet into the wide ocean of XML.It should come as good news that in SQL Server 2005, you can store XML in the database with a new XML datatype. Although this is good news, many developers have been storing XML in the database for some time now. Without implicit support for XML, developers have been shoving XML documents into text fields since XML's inception.

Data is the blood in your system; it sits in its comfortable home of a database, and camps out in the tent of XML, but it deserves to be worked with in a reliable and consistent manner.But why should only data-related operations be reliable? Shouldn't you want to write reliable code for your other operations? The introduction of System.Transactions in .NET 2.0 brings a paradigm shift of how you will write reliable transactional code on the Windows platform. This article dives deep in the depths of how System.Transactions works, and how you can use it to your advantage. You will also see how you can leverage existing System.Transactions integration within ADO.NET, and why you need to really understand what is under the magic carpet.

SQL Server 2005 offers a number of new features over its predecessor, including many features aimed at making working with databases more like writing .NET application code. For example, in SQL Server 2005, stored procedures, triggers, UDFs, and so on can be written using any .NET Framework programming language (such as Visual Basic or C#). Another feature, and the focus of this article, is SQL Server 2005's support for TRY...CATCH blocks.

Prior to SQL Server 2005, detecting errors resulting from T-SQL statements could only be handled by checking a global error variable, @@ERROR. Because the @@ERROR variable value is reset after each SQL statement, this antiquated approach leads to rather bloated stored procedures, as the variable must be checked after each statement with code to handle any problems...

A dynamic web application needs an admin section for CRUD action of the Records/Tables in database, wouldn't it be nice to have a database admin, which can be plugged to any web application, Just give your sql connection string and it dynamically manages all table operation in just 5 pages

This month, John Papa answers questions on typed and untyped XML columns, TRY/CATCH exception handling in T-SQL, and triggers for table schema changes.

Data Application Block for Firebird SQL intended to speed development of applications.