ount yourself lucky if the data you need is always in the database you happen to be using. Most of us must retrieve data from all kinds of sources, and sometimes it isn’t easy. The good news for SQL Server users is you can access remote data from another SQL Server database with a simple view. You don’t need a convoluted stored procedure, user-defined function, or object library; a quick and easy view can get the job done if you know the right syntax.

Views, which have been around since SQL Server 2000, provide an easy and efficient solution for accessing data. You probably use them already to access data in the current database. Views allow you to do the following, which makes them a better solution than accessing the table itself:

• Limit who sees the data
• Determine which data the user sees
• Limit who can manipulate the data

Views are like tables, except that they don’t store data. Instead, a view stores the instructions the server needs to retrieve data. The server executes the instructions to return the view data, but doesn’t store the data itself. In addition, because views are evaluated on the server, you can limit the amount of data dragged across the network?always a good practice. (If you’re moving up from a Microsoft Access database, a view is similar to a query.)

Views do have a few restrictions you’ll need to consider when determining whether they are the right solution for a given task:

• A view can’t include a COMPUTE or COMPUTE BY clause.
• A view can’t include an ORDER BY clause unless there’s a TOP clause in the SELECT list.
• A view can’t include the INTO keyword.
• A view can’t reference a temporary table or a table variable.

The good news is that even with these restrictions, views are still a viable tool most of the time.

Remote Viewing
To create a view, use the TRANSACT-SQL (T-SQL) CREATE VIEW statement in the following form:

CREATE VIEW [databasename].[owner].viewname[ (column [n, ...])][WITH attribute [n, ...]]AS selectstatement[WITH CHECK OPTION]

Everything’s optional except viewname and the columns that comprise it.

After you’ve created the view, users can execute it via a SELECT statement in the following form:

SELECT *|fieldlist FROM database.owner.viewname 

As long as the view is in the current database, you can omit database. However, if you want to view data in another database, the statement needs the explicitly declared database argument as shown in Figure 1. From inside a database named Sales, the SELECT statement executes a view named vUpdateProductionLocation in AdventureWorks (a sample database that you can download). It really is that easy.

Figure 1. View Data in Another Database: Views enable you to identify another database explicitly to execute an existing view.

The actual view is a simple SELECT statement that displays three fields of data from Production.Location, a table in AdventureWorks:

SELECT Name, CostRate, AvailabilityFROM Production.Location

Only the second SELECT (see Figure 1) returns data, because that statement specifies the database AdventureWorks. That’s the key to viewing data in another database, the easy way. It’s so simple that you might not realize you can do it!

The view specifies the table and columns, and it can include a WHERE clause to limit the results. The calling SELECT statement identifies the database and the view.

Add Flexibility with a Stored Procedure
Some developers complain that views don’t accept parameters, but that’s no reason to avoid them. When a view alone isn’t flexible enough, use a stored procedure to call it. Combined, a view and a stored procedure create a versatile, flexible, and easy way to retrieve data from another SQL Server database.

You can easily call a view from a stored procedure as follows:

CREATE PROCEDURE [databasename].[owner].storedprocedurename@variable datatypeASSELECT * | fieldlist FROM database.owner.viewname WHERE field = @variable 

For example, you could create the following stored procedure to limit further the records retrieved by vUpdateProductionLocation:

CREATE PROCEDURE spRunViewWithPara @costrate smallmoneyAS SELECT * FROM AdventureWorks.dbo.vUpdateProductionLocationWHERE CostRate > @costrate

Being able to change the parameter provides a more dynamic solution than a view by itself. Figure 2 shows the result of executing this stored procedure from inside the Sales database.

Figure 2. Calling a View from a Stored Procedure: Combined with a stored procedure, a view becomes a versatile tool for retrieving data from another database.

The view can limit data via the SELECT field list and a WHERE clause.

Noteworthy Tips for Quick, Easy Views
As you have seen, views can make retrieving data from another SQL Server database quite easy. To enhance your view solution even further, keep the following tips in mind:

• For more flexible filtering, pass a parameter via a stored procedure (see previous section).
• If you are worried about the performance of views, consider an indexed view.
• Views can work with linked databases, but the syntax is different:

  CREATE VIEW [databasename].[owner].viewname[ (column [n, ...])][WITH attribute [n, ...]]ASSELECT *|fieldlist FROM linkeddb...table AS alias[WITH CHECK OPTION]