Create a new file and name it anything as long as it has the .udl extension. Open the file, choose a provider:

Click Next >> or navigate to the Connection Tab to provide connection information.  Once you provide server and login credentials, the database list will populate.  At this point, you know the connection is valid. but go ahead and click the Test Connection button anyway.

On the final tab, you can provide extra connection information like Application Name which can come in handy. 

The All tab is beneficial if you want to build a valid connection string to include in your own applications.  If you save the file and then open in Notepad, you’ll find that said connection string:

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=(local);Application Name=TestApp

I hope this tip helps save you some time.  How do you test if you don’t have SSMS installed?

"A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)"

I love this exception. It summarized the issue and leads you down a path to solving the problem.  I do wish the bit about allowing remote connections was left out of the message though. I can’t think of a time when having remote connections disabled caused me grief.  Heck, I can’t ever remember how to enable remote connections unless I Google for the answer.

Anyway, 9 out of 10 times, SQL Server simply isn’t running.  That’s why the exception occurs.  The next time this exception pops up, open up the services console and make sure SQL Server is started.  And if that’s not the problem, only then start digging into the other possible reasons for the failure.

First, you’ll find the ApplicationServices database connection:

Notice the connection string is referencing the aspnetdb.mdf database hosted by SQL Express and it’s using integrated security so it’ll just work for you without having to call out a specific database login or anything.

Scroll down the file a bit and you’ll find each of the three noted sections:

Really. It’s all there. Still don’t believe me.  Run the application, walk through the registration process and finally login and logout.  Completely functional – and you didn’t have to do a thing!

What else?  Well, you can manage your users via the Configuration Manager which is hiding in Visual Studio behind Projects > ASP.NET Configuration.

The ASP.NET Web Site Administration Tool isn’t MVC-specific (neither is the Membership, Profile or RoleManager stuff) but it’s neat and I hardly ever see anyone using it.  Here you can set up and edit users, roles, and set access permissions for your site. You can manage application settings, establish your SMTP settings, configure debugging and tracing, define default error page and even take your application offline.  The UI is rather plain-Jane but it works great.

And here’s the best of all.  Let’s say you, like most of us, don’t want to run your application on top of the aspnetdb.mdf database.  Let’s suppose you want to use your own database and you’d like to add the membership stuff to it.  Well, that’s easy enough. Take a look inside your [drive:]\%windir%\Microsoft.Net\Framework\v2.0.50727\ folder.  Here you’ll find a bunch of files.  If you were to run the InstallCommon.sql, InstallMembership.sql, InstallRoles.sql and InstallProfile.sql files against the database of your choices, you’d be installing the same membership, profile and role artifacts which are found in the aspnet.db to your own database. 

Too much trouble?  Okay. Run [drive:]\%windir%\Microsoft.Net\Framework\v2.0.50727\aspnet_regsql.exe from the command line instead.  This will launch the ASP.NET SQL Server Setup Wizard which walks you through the installation of those same database objects into the new or existing database of your choice. You may not always have the luxury of using this tool on your destination server, but you should use it whenever you can. 

Last tip: don’t forget to update the ApplicationServices connectionstring to point to your custom database after the setup is complete.

At the risk of sounding like a smarty, everything I’ve mentioned in this post has been around for quite a while. The thing is that not everyone has had the opportunity to use it.  And it makes sense. I know I’ve worked on projects which used custom membership services.  Why bother with the out-of-the-box stuff, right?   And the .NET framework is so massive, who can know it all. Well, eventually you might have a chance to architect your own solution using any implementation you’d like or you will have the time to play around with another aspect of the framework.  When you do, think back to this post.

On my Windows 7 machine, I’m able to define my Application Pool Identity and then create an associated database login via the SQL Server Management Studio interface.  No problem.  However, I ran into some troubles when recently installing my web application onto a Windows Server 2008 R2 64-bit machine.  Strange, but the same approach failed as SSMS couldn’t find the AppPoolIdentity user.  Instead of using the tools, I created and executed the login via script and it worked fine. 

Here’s the script, based off of the DefaultAppPool identity, if the same happens to you:

CREATE LOGIN [IIS APPPOOL\DefaultAppPool]
FROM WINDOWS WITH DEFAULT_DATABASE=[master]
USE [Chinook]
CREATE USER [IIS APPPOOL\DefaultAppPool] FOR LOGIN [IIS APPPOOL\DefaultAppPool]

As it turns out, previous installations were always applied to machines (mostly VMs) which weren’t running early versions of the SQL Server and associated tools.  Yesterday, I performed my first upgrade from SQL Server 2008 and SQL Server Management Studio 2005 and it took a painfully long time to get everything in place.

There seems to be general discontent with the SQL Server 2008 installation/upgrade experience – particularly when it comes to SQL Server Management Studio. After yesterday’s debacle, I can understand why.  In retrospect, an upgrade to 2008 is simple if you follow the right steps.  If not, you’re bound to get frustrated and waste a couple of hours. 

If I knew then what I know now…

• You cannot manage SQL Server 2008 with 2005 Management Tools. Go ahead and try it. SQL Server Management Studio 2005 will bark at you.
• A stand-alone SQL Server Management Studio 2008 installer does not exist.  The Management Tools must be installed as a features available via the main SQL Server2008 installer. The Microsoft download for SQL Server Management Studio 2008, as far as I am concern is a hoax.  It is merely the SQL Server 2008 installer given a different file name. Seriously.
• You cannot run SQL Server Management Studio 2005 and SQL Server Management Studio 2008 side by side. An attempt to install SSMS 2008 will fail if you have yet to uninstall SSMS 2005.

Save yourself some trouble.  Before kicking off your SQL Server 2008 / SQL Server Management Studio 2008 installation or upgrade, uninstall SQL Server Management Studio 2005.  If you don’t, you will be able to successfully install SQL Server 2008, but the Management Tools installation will fail (gracefully.) If, per chance, you find yourself in this failure condition, continue with the SQL Server Management Studio 2005 uninstall, rerun the SQL Server 2008 installer and reattempt the Management Tools installation.  This can be done by following the “New SQL Server stand-alone installation of add features to an existing installation” option under the Installation view.  This time around select the Management Tools when the available features are presented and you should be all set.  You may find the management tools take a surprisingly long time to install, but, believe me, this is nothing compared to the time you might waste if you didn’t know the right steps to follow in the first place.

* Relatively standard installation instructions which work consistently well for me:

• Run Setup.exe
• Installation > Select “New SQL Server stand-alone installation or add features to an existing installation.”
• Select the following Features:
  • Database Engine Services
  • Reporting Services
  • Client Tools Connectivity
  • Management Tools – Basic (If SSMS 2005 isn’t installed)
  • Management Tools – Complete (If SSMS 2005 isn’t installed)
• Select the Named Instance/Instance ID based on established naming convention. For example, BGHOMESQL01
• Set the following Service Startup Types:
  • SQL Server Agent – Automatic
  • SQL Server Database Engine – Automatic
  • SQL Server Reporting Services – Automatic
• Use the same account for all SQL Server Services and provide account. On local machine, I suggest using the Current User.
• Set the Authentication Mode:
  • Mixed Mode (SQL Server Authentication and Windows Authentication)
• Provide the built-in SQL Server admin account. On local machine, I suggest using the Current User.
• Configure Reporting Services:
  • Install the native mode default configuration

The next time you are designing a database, do yourself a favor and mimic the pattern to the left.  Always prefix column names with the table name if the column name is likely to be repeated  in more than one table.  ID, Name, Description, DateAdd and DateChange are good examples of column names which tend to show up in multiple places.  When it comes time to build your queries and work with the result sets, you will thank me. 

Consider the two following routines — each returns the same result but the latter is much cleaner, readable, consists of less code and is inherently greater resistant to stupid coding errors especially within the syntax of the join and the column aliases.

-- Poor implementation
declare @Product table
(
    ID int, Name varchar(50)
)

declare @ProductVersion table
(
    ID int, ProductID int, VersionNumber int
)

insert into @Product(ID, Name)
select 1, 'product 1'
union
select 2, 'product 2'

insert into @ProductVersion (ID, ProductID, VersionNumber)
select 1, 1, 1
union
select 1, 2, 1

-- Note the column aliases and
-- join on less-than-obvious columns
select P.ID as ProductID, PV.ID as ProductVersionID from
@Product P inner join
@ProductVersion PV on (P.ID = PV.ProductID)

go

-- Proper implementation
declare @Product table
(
    ProductID int, Name varchar(50)
)

declare @ProductVersion table
(
    ProductVersionID int, ProductID int, VersionNumber int
)

insert into @Product(ProductID, Name)
select 1, 'product 1'
union
select 2, 'product 2'

insert into @ProductVersion (ProductVersionID, ProductID, VersionNumber)
select 1, 1, 1
union
select 1, 2, 1

-- Note there's no need for aliases and
-- the join obvious
select P.ProductID, PV.ProductVersionID from
@Product P inner join
@ProductVersion PV on (P.ProductID = PV.ProductID)

Keep this tip in mind.  It will save you heartache throughout your next project.

Thanks for the pointer to SSMS Tool Packs. It looks really interesting. One thing I’m having trouble picturing is the overlap between the two [SubSonic and SSMS Tool Pack]. Once you have a DAL, what do you need CRUD routines for? Bulk operations, or something that’s a result of the existing architecture?

For those familiar with SubSonic you can appreciate Jon’s question.  Since SubSonic’s generated DAL provides you with CRUD methods and easily allows you build resulting parameterized queries, you are no longer dependent upon having compiled routines sitting in the database. 

Almost on queue, Caffeinated Coder recently a great article on why one should “Just Say No to Manual CRUD” which provide a list of resources which present good counter arguments against the conventional stored proc wisdom.

So, why the heck am I still using stored procedures?

If I were to be honest, the number one reason I’m sticking with SPs is they are familiar and they provide me with a sense of comfort.  Most of my uneasiness with “embedding” data access into the application code is tied to deployment and maintenance.  For example, I like to have multiple “outs” when it comes to rollbacks and I like to keep emergency fixes as isolated as possible. Since stored procedures could be considered more atomic than even the most lightweight DLL, I can update a live application by altering a single stored procedure with more confidence than copying/replacing application file(s.)  Assuming you have a single database and a web application running on multiple web servers, in my opinion, the stored procedure update is best solution since time to implement is low, risk is minimal and downtime is eliminated. 

I had a good follow up conversation with Jon about all of this last week and the bottom-line is that one needs to put the right architecture in place based on their coding, deployment and maintenance needs.  I am currently sticking with stored procedures but this approach isn’t necessarily right for everyone.

I typically roll the dice with these types of presentation knowing they may turn out to be a refresher course, way over my head, or worse, an absolute bore.  This one was worth sitting through as I picked up the following nugget: Mixing DDL and DML Operations Can Cause a Recompile.

What does this mean?  DDL (Data Definition Language) and DML (Data Manipulation Language) almost always exists in our stored procedures.  Examples of DDL are our DECLARE variable and CREATE TABLE statements.  DML, on the other hand, includes our SET, SELECT and INSERT to name a few.  A key cause of stored procedure recompiles is the interleaving of DML and DDL statements — especially DDL following DML statements.  In other words, according to Microsoft best practices, place all of your DDL statements at the top of your stored procedures and then do your actual query work. Now, are recompiles always going to happen if you have interleaved DDL and DML?  Nope, not in all case, but you should do everything possible to prevent recompiles (even if it is super easy.)

Really quickly, you can setup SQL Server to run in one of two security modes: Windows Authentication or Mixed Mode.  Mixed Mode is exactly as it implies and allows users to connect using Windows NT Authentication or using SQL Server Authentication.  I’m a fan of Mixed Mode which allows for application accounts to reap the benefits of Integrated Security while allowing considerably easier SQL Auth access for developers, support personnel, etc. 

Please consider the following scenarios: 

1. An instance of SQL Server is setup in the Development Environment and it isn’t running in Mixed Mode.  This implies that one needs to be a member of the appropriate domain and have appropriate permissions in order to access the SQL Server.  Not a big deal, right?  Well, I would agree if I were a developer working onsite and the Dev Network was readily available to me. But I happen to work remotely on occasion and there isn’t an entrance point into this particular domain through VPN.  Boy, SQL Authentication sure would come in handy in this case. 
2. Let’s say your environments (perhaps Dev, QA and Production) are hosted in separate domains.  It would be painful to switch between domains in order to access each SQL Servers, wouldn’t it?  (I know what you are thinking, “Why would a developer need to access QA or Production?”  Special assignment.  Let’s leave it at that.)

Fortunately, there’s a workaround.  If you are me, you beg and plead and moan and request that security mode be changed (not that that’s easy.) OR you discover an even better solution in the appropriately named RunAs command which allows a user to run specific tools and programs with different permissions than the user’s current logon provides.  

The following are a few of  my favorite commands which I’ve wrapped up neatly in their own .cmd file for quick execution (you will need to update the domain and user values accordingly):

• runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe”
• runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”"
• runas /user:domain\user isqlw

This tip actually came from a wise, remote developer working in Canada who was confronted with Scenario 1 above.  Pretty neat, eh?

select   c.LastName
from     Customer c with (nolock)
where    c.LastUpdated < getdate()

You might think “no big deal.” It’s just a function, but for sql server, it almost always turns a deterministic query into a non-deterministic one.  The difference?  Index usage.

Most of the time, sql server will ignore any index on a column that is used in a WHERE clause expression containing a function, turning an index seek into an index or table scan, with the obvious performance penalty.

So instead of the above query, replace it with:

declare  @CurrentDate datetime
select   @CurrentDate = getdate()   

select   c.LastName
from     Customer c with (nolock)
where    c.LastUpdated < @CurrentDate

The function is gone and sql server will use an index on LastUpdated if it exists.

The same holds true for this example:

select   c.LastName
from     Customer c with (nolock)
where    c.LastUpdated < dateAdd(day, -1, getdate())

becomes:

declare  @CurrentDate datetime
select @CurrentDate = dateAdd(day, -1, getdate())select   c.LastName
from     Customer c with (nolock)
where    c.LastUpdated < @CurrentDate

Sometimes there is simply no workaround for a function in the WHERE clause but, knowing their impact, make every effort to eliminate them. 

1. Though I know there are many .NET coders who also happen to be very capable database designers and developers, I believe that the many of us still have a lot to learn.  I would say that we all know at least the basics, but there’s an awful lot of DB knowledge that has eludes us over the years.  If nothing else, the “DBTalk” distribution list has proven to be a non-intrusive way to educate an entire group of developers on SQL Server Best Practices and a few Tips & Tricks.

2. The moderator does a really nice job of getting everyone involved.  Those of us who frequent technical blogs know this isn’t always easy — especially when your audience isn’t necessarily comfortable with the topic.  Fortunately, the moderate provides information on varying topics for all levels and he throws out carrots all the time.  For example, he’ll present a Tip of the Day and ask if anyone has an alternative solution or he will simply submit a problem and ask for possible solutions.  It seems with most conversation at least someone on the distribution list is willing to bite.

Anyhow, with permission, I’ll be posting a number of the topics and tips which have been discussed over the past several months.  They may come all at once, in chunks or one every once in a while.  I haven’t yet decided.

Here are the ingredients in my current ideal solution:

1. The table must include the following columns: a Unique Identifier such as RequestID, Status, LockedBy, and LockedTime.  I also like to include RequestedTime and CompletionTime columns as I’ve found that capturing these values help when/if system stats are required.
2. The key is to lock the current request at the time of processing.  To do so, you should use a transaction and an update lock.
3. I think it is important to pull requests off the queue in an intelligent order.  FIFO is the best bet under most circumstances.  In this case, the RequestedTime column becomes imperative (unless your RequestID is an auto-incrementing identity column and you are comfortable ordering on it.)
4. Finally, I like to make sure no request is left behind.  Let’s say Service A locks a request for processing and then the application server crashes.  I want the lock to eventually expire so Service B can pick up the row and save the day.

Assuming new requests are added to the queue as ‘Pending’ , one may use a routine similar to the one below to safely pull the next request off the queue:

create procedure [GetNextItemInQueue]
(
    @LockedBy varchar(75)
)
as 

set nocount on 

declare
    @Error                     int,
    @ExitCode                  int,
    @RowCount                  int,
    @PendingStatus               int,
    @MinutesBeforeBreakLock       int,
    @RequestId                   int

select
    @Error                      = 0,
    @ExitCode                   = 0,
    @RowCount                   = 0,
    @PendingStatus                = 1,
    @MinutesBeforeBreakLock        = 30 

begin tran ProcessQueue 

select top 1 @RequestId = RequestId
from Queue with (updlock)
where Status = @PendingStatus
and (LockedTime IS NULL OR
DateDiff(mi, LockedTime, GetDate()) >= @MinutesBeforeBreakLock)
order by RequestedTime Asc 

select @RowCount = @@RowCount, @Error = @@Error 

if (@RowCount = 0)
    goto ExitProc 

if (@Error <> 0)
    goto ErrorHandler 

update Queue
set    LockedBy = @LockedBy,
    LockedTime = GetDate()
where RequestId = @RequestId 

select @Error = @@Error
if (@Error <> 0)
    goto ErrorHandler 

select @RequestId as RequestId 

select @Error = @@Error
if (@Error <> 0)
    goto ErrorHandler 

goto ExitProc 

ErrorHandler:
    raiserror   (@Error, 16, 1)
    if @@trancount > 0
        rollback tran ProcessQueue
    select      @ExitCode =  -100 

ExitProc:
    commit tran ProcessQueue
    return      (@ExitCode)

Once the request is processed, a database call will be made to update the row’s Status to ‘Complete’ and CompletionTime. 

Note, you may choose to change the status of each row from ‘Pending’ to ‘Processing’ when you do the initial lock.  This is perfectly fine, but I’ve found that is unnecessary as the Processing status can be determined based on the value of other columns.

Again, that’s my current preferred implementation.  Perhaps there are better solutions out there?

This wasn’t the first time this installation gave me trouble. In fact, the screen shot above comes from one of my laptops which I opted not to “patch.” But since I was surely going to need SQL installed on the new machine, I didn’t have the luxury of abandoning the installation this time around.

I attempted to install a few times with no luck. I googled for help with little luck. In the end, I uninstalled every “Microsoft SQL Server…” program and then reinstalled. It worked! I assumed this attempt was successful because I had uninstalled a version of SQL Server 2005 Express along with all the other programs. A google search implied that this may be causing the issues. However, the laptop which I still haven’t patched doesn’t have the Express Edition running.

I’m not sure if I’ll ever figure this one out. Actually, I’m not sure if I want to. I know well over a dozen individuals who have successfully installed SQL 2005 without any problems and now I have botched up the installation on two separate occasions on two different machines using two different installation discs. I’m either unlucky, cursed or dumb (or a combination of the three) and I don’t care to know which…

Integrated authentication allows for SQL Server to leverage Windows NT authentication to validate SQL Server logon accounts. This allows the user to bypass the standard SQL Server logon process. With this approach, a network user can access a SQL Server database without supplying a separate logon identification or password because SQL Server obtains the user and password information from the Windows NT network security process.

Choosing integrated authentication for ASP.NET applications is a good choice because no credentials are ever stored within your connection string for your application.   Thus, security is improved.  Another reason to incorporate Integrated Authentication is to facilitate account and password policy enforcement through a domain controller.  For example, this might require passwords be recycled every 90 days.

“Integrated Authentication is not difficult to implement.”  I’ve heard this time and time again.  Actually, in an ideal scenario, this is a correct statement and the implementation requires just a few steps:

1. Set SQL Server Authentication to Mixed Mode.

2. Set identity impersonate to true and assign the username and password in the IIS.

3. Update you connection string to use one of the following variations:

    a. data source=myServer;initial catalog=myDB;Integrated Security=SSPI 
    b. server=myServer; database=myDB;Trusted_Connection=true

Easy, right?  Sure.  But what if you are converting to NT Authentication and your existing network and application(s) are not ideally setup?  In this case, there are a number of potential (read probable) gotchas. 

There are three obstacles I wish to discuss, but today I am going to focus on one of them. This issue is the most obscure and I would bet that the majority of those tasked with estimating a conversion to NT Authentication would not even consider this condition.  I’m also calling attention to this gotcha first because, in my opinion, it comes with painless and noteworthy solution.

Gotcha # 1:

Our web applications call upon a number of Windows Services.  These services should be considered legacy components.  They have been around for a while and they continue to do their job so they get little attention.  Each of these components store connection string information in the registry. 

As you have noticed, connection string formats vary based on the authentication method.

Integrated Authentication
data source=myServer;initial catalog=myDB;Integrated Security=SSPI;

SQL Server Authentication:
data source=myServer; initial catalog=myDB; user id=myUsername; password=myPassword; 

In this case, the registry held the four primary SQL Server connection parameters and the service would use the associated values to build the string on the fly.  Can you see where this is going?   Fortunately, we identified this little issue early on and we estimated time to rework the functionality, rebuild, test and redeploy the services.  This was risky since these services were rarely modified/deployed and it was going to be expensive since there were more than a dozen services which required these changes.

This was until a colleague of mine uncovered an elegant hack. [Is that an oxymoron?]  He discovered that once the Integrated Security parameter of the connection string is set to SSPI parameters such as User ID and Password are virtually ignored.  (He also found out that extra semi-colons don’t make a lick of difference either.) 

In the end, we hacked our registry entries to allow our services to build and use NT Auth compliant connection strings. 

Sample registry entries:

Resulting connection string:

datasource=myServer;integrated security=SSPI;initial catalog=myDB;user id=;password=;

This reduced risk and simplified our deployment to modifications to the registry through the execution of a single .reg script. 

Opening up the services and redeploying may have been the best solution, but this hack got the job done safely and effectively and on the cheap.  And we learned a bit more about how connection strings work.  Who knows?  This tip may help you out of a pinch someday.

     Data Source=myServer;
     Initial Catalog=myDB;
     User Id=myUsername;
     Password=myPassword;
     Application Name=myApp;

Consider this example:  There are multiple .NET applications running on a single web server.  Each application shares a common SQL Server Server which is suddenly performing very poorly.   You are tasked with determine which of the applications is causing havoc.  You launch SQL Profiler and run a trace.  Since you have included the optional parameter in your connection string, you may now filter the application specific queries and troubleshoot the problem far more effectively.  If you hadn’t specified the application name, you would have some work ahead of you.  In this case, all of the queries would have had a generic app name, .NET sqlClient Data Provider, and that isn’t very helpful, is it?  

Do yourself a favor and be sure to add this practice to your coding standards…