.NET news » Database

This article is about LINQ which I think is one of the most exciting features in Orcas. LINQ makes the concept of querying a first-class programming concept in .NET. The data to be queried can take the form of XML (LINQ to XML), databases (LINQ-enabled ADO.NET: LINQ to SQL, LINQ to Dataset and LINQ to Entities) and objects (LINQ to Objects). LINQ is also highly extensible and allows you to build custom LINQ enabled data providers (e.g.: LINQ to Amazon, LINQ to NHibernate, LINQ to LDAP).

As developers assume more of the security burden, the first web application vulnerability that many developers learn about is a particularly dangerous form of command injection known as SQL injection. Command injection in its archetypal form is any vulnerability that allows an attacker to run an unintended command on your server by providing unanticipated input that alters the way you intended the web application to run. Because it's so well-known, SQL injection attacks are common, dangerous, and pervasive. Fortunately, you can prevent SQL injection easily once you understand the problem. Even better, a new Microsoft data access technology offers .NET developers the opportunity to eliminate SQL injection vulnerabilities altogether—when used properly. That technology is called Language Integrated Query (LINQ), and it will ship in the upcoming release of Visual Studio "Orcas" and .NET Framework 3.5. This article explores LINQ's potential for hardening your web application's data access code so that it's impossible to attack through SQL Injection.

ADO.NET in the next release of Visual Studio code-named "Orcas" features the new Entity Framework. It allows developers to focus on data through an object model instead of through a logical/relational data model. The Entity Framework helps abstract the logical data schema into a conceptual model and allows for multiple ways to interact with the conceptual model through Object Services and a new data provider called EntityClient. This month’s column discusses what the Entity Framework is, how it fits into an application, and how it can be designed and programmed against.

With Microsoft SQL Server 2000 it was possible to debug stored procedures from directly within Query Analyzer (see Debugging a SQL Stored Procedure from inside SQL Server 2000 Query Analyzer for more information). With SQL Server 2005, however, this functionality was moved out of SQL Server Management Studio and into the Visual Studio IDE. Using this technique, it is possible to step into your stored procedures, one statement at a time, from within Visual Studio. It is also possible to set breakpoints within your stored procedures' statements and have these breakpoints hit when debugging your application.

All editions of SQL Server 2005 include debugging support (including the Express Edition). However, only the Team Systems and Professional editions of Visual Studio enable stored procedure debugging from within the IDE. In short, if you are using Visual Web Developer or Visual Studio Standard Edition then you cannot step through a stored procedure or enter the stored procedure via application debugging.

In this article we will examine how to debug SQL Server 2005 stored procedures through the Visual Studio IDE. We will look at both stepping into a stored procedure directly from the IDE as well as how to set breakpoints within the stored procedure that are then hit when debugging the application.

Connection pooling can increase the performance of any application by using active connections of the pool for consecutive requests, rather than creating a new connection each time. And at the same time, the developer who is the best judge of his/her application, can configure the connection pooling.

Bringing the Common Language Runtime (CLR) into SQL Server presents an entirely new set of challenges with regard to privilege and some of the rules that SQL Server developers are used to do not completely translate. Simple grant/deny/revoke logic still applies, but the CLR also brings its own set of specialized permissions, which require slightly different handling in order to properly manipulate.

By not carefully considering these issues when designing your SQLCLR code base, you may be allowing your code too much access.

This article focuses on what the SQLCLR permission sets do to control security and reliability, and what you need to understand when working with them in order to design a system that takes advantage of least privilege. By not carefully considering these issues when designing your SQLCLR code base, you may allow your code too much access, thereby creating potential vectors for security problems down the road..

The application which will be used in this article is based on an UltraLite 10 database and will use a technology called MobiLink 10 to allow for data exchange between the mobile UltraLite database and the central database. Although MobiLink has the ability to synchronize to most major databases (including SQL Server, IBM DB2, Oracle and Sybase) for the this sample we will be using SQL Anywhere as the central (consolidated) database. All of these tools are included in the free SQL Anywhere 10 Developer Edition.

Transferring data from one source to another is common practice in software development. This operation is preformed in many different scenarios which includes migration of the old system to the new system, backing up the data and collecting data from different publishers. .NET 2.0 framework includes the SqlBulkCopy class that helps to copy the data from different data sources to the SQL SERVER database. In this article, I will demonstrate the different aspects of the SqlBulkCopy class.

This article explains how to integrate SQL Reporting Services with Windows SharePoint Services 2.0.

Sometimes you have to send/receive date using MSMQ from MS SQL Server. Although MS SQL Server 2005 uses MSMQ for replication job, there are no functionality in T-SQL to access MSMQ. Lets fill the gap..