SQL Server Redundancy without Client Application Changes We have a custom .NET build application that has different clients which access the DB residing on SQL Server 2005 Standard. Now we want to add another SQL Server to create redundancy so that in case of failure of the existing SQL Server, the secondary server is able to cater the requests from the clients.

I have gone through Replication (and its different types), Mirroring and Clusters. But i am a bit confused about selecting the right option. My requirement is to have a secondary server without having any major changes to the client applications. Any suggestions ???
Clustering:
For minimal changes to your client application clustering is transparent, you wouldn't need to change a thing.  Although it will require the most work to setup.  To go from a stand-alone installation which you have to a clustered setup, this will be a lot of work.  You'd basically have to build a new clustered instance &amp; move the database across.  You'll also need shared storage to make this work.

Mirroring:
With SQL Server Standard you are stuck with High Safety mirroring which can mean a performance hit. Good news is that you don't need shared storage and you should be able to build a new 2005 instance and then setup mirroring. Bad news is you'll  need to change your connection string to include a fail-over partner if you want to have a seamless fail-over.  This also only fails over the user database, so you'll need a process to manage moving/synching SQL Agent jobs and logins.

I wouldn't recommend using SQL Server replication for redundancy. 

You might also want to consider log-shipping. This would be a lower-complexity alternative to mirroring although failover is only manual.