The simple way to do this is with UNION ALL.

A UNION statement returns the UNION of two SELECT’s but removes duplicates.  If you use UNION ALL, the records returned are all the records including duplicates.

One method is to use a “TIMESTAMP” field in the database table.  The “TIMESTAMP” field is automatically updated each time the record is updated.  Then the UPDATE Stored Procedure would check to see if the “TIMESTAMP” has changed since the record was first read by the application.  If so, then it aborts the UPDATE and alerts the calling application.  The key is that this “TIMESTAMP” value must be always returned by the “SELECT” Stored Procedures so the calling application can provide it to the UPDATE Store Procedure for comparison.  For example, below is a short Update Stored Procedure that updates “Salary” or “Password” or both:

CREATE  PROCEDURE UpdEmployee
@PASSWORD VARCHAR(20) = NULL,
@Salary  DECIMAL(14,4) = NULL,
@EmployeeID INT,
@RecVer  BIGINT

DECLARE 
@QueryCheck CHAR(20),
@ErrorNum INT,
@RowCount INT

BEGIN TRANSACTION

————————————————————————-
– Update the Employee record specified by the Primary Key
–  (@EmployeeID) with the values if specified.  Note the
– COALESCE statement allows the @Password and @Salary
– parameters to be optional and if not specified (NULL) then
– the original values will be written back.  Also notice the
– RecVer is compared to the existing RecVer in the table
– and if not the same then the update is not executed.  We
– cast the the RecVer from BIGINT to TIMESTAMP to make
– the comparison proper since we don’t pass TIMESTAMP as
– a parameter.  The SELECT procedure would return this value
– as a BIGINT to the caller since it is easier to store it as such
– in most programming languages.
————————————————————————–
UPDATE Employee
SET Password = COALESCE(@Password, Password),
 Salary = COALECE(@Salary, Salary)
WHERE EmployeeID = @EmployeeID
 AND RecVer = CAST(@RecVer AS timestamp)

SET @QueryCheck  = CAST(@@ERROR AS char(10)) +
                                            CAST(@@ROWCOUNT AS char(10))
SET @ErrorNum   = CAST(LEFT(@QueryCheck, 10) AS int)
SET @RowCount   = CAST(RIGHT(@QueryCheck, 10) AS int)

—————————————————————————
– Checking if we had an error.  We always do this for every
– UPDATE or INSERT but this has nothing to do with this
– article but I put it here for reference.
—————————————————————————
IF @ErrorNum <>  0
 BEGIN
  ROLLBACK TRANSACTION
  RAISERROR(@ErrorNum, 16, 1)
  RETURN @ErrorNum
 END
———————————————————————–
– If the specified row was not updated, @RowCount = 0,
– then the RecVer was not the same so alert the calling
– application so they can tell user and maybe refresh the
– data again in their application.
———————————————————————–
IF @RowCount <> 1
 BEGIN
  ROLLBACK TRANSACTION
  RAISERROR( ‘Update Problem’, 16, 2)
  RETURN 123456
 END
————————————————————
– If you got this far, everything is OK, so commit change
————————————————————
COMMIT TRANSACTION

AS

RETURN (0)

 The calling application can then just provide “TRY/CATCH” blocks around the call to the SQL Server Stored Procedure and if the procedure throws an error the Return value “123456′ would indicate that it was due to an attempt to modify data that had been modified since first reading.  The application has to be written to handle this situation, but at least the database provides safeguards against this sort of situation from corrupting your data by using the “TIMESTAMP” datatype.

We were able to find an easy way to solve this problem.  We converted all entries to use “GETUTCDATE()” which is the current UTC time which does not vary by time of year or timezone.  Therefore, all the time was based off the same timezone and it never changed for daylight savings.  When computing people’s paycheck and summing the hours worked we were able to perform simple calculations and could guarantee the correct number of hours no matter where they clocked-in or clocked-out or whether they worked during a daylight savings time change.
Using GETUTCDATE instead of GETDATE was a simple solution to a complicated problem to solve timezones and daylight savings changes.

One wat would be to open up SQL Query Analzyer in SQL Server and write an “UPDATE” statement but this always worries me because an “UPDATE” statement can be very dangerous if not properly formed and when you are in a hurry.  Imagine updating a password for a database of 300,000 users and forgetting to put the “WHERE” clause and whoops, you just reset everyone’s password.  This actually happened to me once when I was in a hurry and I was lucky that I had executed the UPDATE statement on a copy of the production database before trying it on the real one.

My preferred method when doing a quick one-time change is to use SQL Server Management Studio for SQL Server 2005 or 2008 and “right-click” my mouse on the particular table and choose “open”.  Depending on the size of the recordset, I might stop the listing or let it continue.  I then select the “SQL” icon in the toolbar in the upper menu to open the database table in SQL mode to allow me to write SQL statements to limit the resulting recordset.  By default the SQL displayed in the SQL window is the standard “SELECT” with all rows.  I then add my “WHERE” clause such as “WHERE username=’gotchanow’ if wanting to update the password for that particular user.  Once it displays the row or rows based on the updated SQL statement, I then select the field to change, type in the new value and then apply the change.

So this is my recommended way of making a safe and simple change to a row or rows in a database without risking a mistake with an “UPDATE” statement.  I’m sure there are other ways using SQL Server 2005 or SQL Server 2008 Management Studio, and I would welcome hearing from you so we can share your suggestions with others.

SQL Server 2005/2008 Database Mirroring:  (Recommended)

Overview:  This works by having SQL Server write each transaction to both SQL Server databases at the same time on 2 different servers so that they are synchronized.  Depending on the mode you choose, the transactions are committed either synchronously or asynchronously.

Pros:  The advantage of this option is that it is a standard feature of SQL Server and its free.  It has 3 modes for those that desire performance and those that must have reliability.  The 1st mode is the synchronous mode with automatic  failover (High availability and Reliability), the 2nd mode is asynchronous without automatic failover (High Performance) and the 3rd mode is synchronous without automatic failover (High Reliability).  The 1st mode requires a witness server to establish a quorum in order for the SQL Servers to know who is the primary and who is the secondary.  A nice thing about this mirroring solution, and something we appreciate, is the simple user interface.  It is so simple that even a novice IT person should be able to figure it out.

Cons:  The mirroring is on a database by database basis so it is possible that you have the primary and secondary for a group of databases spread across the 2 SQL Servers.  This is not much of a problem if you have 2 reliable servers equally paired and you can always fail over the individual databases as needed if you prefer them to be in sync on the same server.

Configuration Point:  Depending on your needs, it is in my opinion, to configure SQL Server Database Mirroring in either the 1st or 3rd mode depending if you want automatic failover or not.  We have seen issues with database corruption with the 2nd option, but the 1st and 3rd options prevent this.  In our situation we prefer the 1st mode because we desire immediate failover and our software is written using ADO which is designed to handle failing over if the 1st connection fails.  Also, the witness server doesn’t have to be an expensive server since it is just designed to provide a quorum.

Double-Take: 

Overview:  This is a block level file replication option that works by monitoring the database and log files and replicating any changes in them to the other server.  Their marketing material says that the change is at a very low I/O level thereby “almost” guaranteeing no file corruption but if you read the fine print, they can’t guarantee no corruption.

Pros:  They are considered an industry standard and have a long track record.  If you talk to most IT people and ask them about the company, you’ll hear nothing but glowing remarks.  The replication is more than just SQL Databases so you can use the product to replicate regular files too.  Also, this is supposedly a great option for replicating over a WAN, but that was not our need.

Cons:  Expensive option compared to SQL Server Database Mirroring.  We purchased 4 licenses with SQL Server replication and it cost us about $12,000 in the Fall of 2008.  The actual price may have varied somewhat but it was pretty close.  The configuration was not simple and we had to have 2 DBA’s on the phone with Double-Take tech support for 2 days trying to get our simple configuration working.  At the time there was an issue with the 64-bit version but this has been fixed.   Also, there wasn’t one program or interface to configure it all and it was confusing.  To Double-Take’s defense, the tech support people were available and very helpful.  One negative for us, which some would say is a positive, was the switch from Secondary back to Primary was a manual process that took a few steps and required a delay while the Secondary was replicated back to the Primary.

Writer’s Comment:  One unfortunate moment happened after running Double-Take for about 1 month.  We had a hardware failure on the primary SQL Server and discovered that the Double-Take failed to switch over and therefore, our applications went down.  We also discovered that the replication had stopped earlier for some reason and therefore, the database on the secondary server was completely out of sync.  Fortunately, we were able to recover the databases from our Primary server’s hard drives and install them on another server.  This failure caused us to be down for several hours while we were struggling with it.  This incident was both frustrating and scary because after spending $12,000 dollars on a product to protect against a failure, it failed to work itself.  Some might say that it was our configuration that was at fault, and while I never want to say it was never our fault, remember that Double-Take helped us configure it over a 2 day period.  The end result of this was that we decided to look for another solution.

Configuration Point:  We installed the Double-Take on 2 servers being replicated.  These servers were Dell 2950’s running 64-bit Server 2008 and SQL Server 2005.  The databases being replicated were small and few in number.  The average size was less than 1GB and we probably only replicated about 5 databases.

 Summary:  As I said earlier, there is no right answer.  Also, I’m sure Double-Take would disagree with my earlier statements and they are more than willing to disagree but this was our experience.  We deal with sensitive information and we lost confidence in Double-Take and have been pleased with SQL Server Database Mirroring (Replication).  I’m not saying don’t buy Double-Take because it might be the perfect solution for you, but I’m saying that we had issues and prefer the simple and integrated solution of SQL Server Database Mirroring.

Operand data type bit is invalid for max operator
or
Operand data type bit is invalid for min operator
or
Operand data type bit is invalid for sum operator

 The answer to the problem is to first cast the bit field to an integer (INT) datatype and perform the MAX or MIN operator on that and then cast it back to a BIT field.

For example suppose you have 3 record sets from a table called “Stores” with a bit field called “ObserveDaylightSavings” and your goal is to determine if any of the records have this bit set to “1″ or true, meaning that at least one of the stores observes daylight savings time.  This is the equivalent tothe “OR” logic operator where if any of the colums are true then the result is true.  The SQL to determine this is as follows:

SELECT CAST(MAX(CAST(ObserveDaylightSavings as INT)) AS BIT) AS ObserveDaylightSavings
FROM Stores

The result would be “1″ if any of the records has the value set to “1″ or “true” or “0″ if none of them had a bit value of “1″.

The reverse is just as simple.  For example if you needed to determine if all of the stores observed daylight savings time, then this would be the equivalent “AND” logical operator.  Meaning if all of the stores had the “ObserveDaylightSavings” bit field set to “1″ or “true” then the result of the query would be “1″.  If any one of them did not have the field set to “1″, then the resulting column would be “0″ or “false”.  The SQL to do that is as follows:

SELECT CAST(MIN(CAST(ObserveDaylightSavings as INT)) AS BIT) AS ObserveDaylightSavings
FROM Stores

The only difference is that the MAX was replaced with the MIN operator.

So basically, if you are faced with the error:  “Operand data type bit is invalid for max operator” or “Operand data type bit is invalid for min operator” or even “Operand data type bit is invalid for sum operator” then the answer is to cast the value to an INT and then back to a BIT and you’ll achieve an equivalent AND/OR type of solution for the field.  This allows you to aggregate bit fields in SQL.