I chalk out some difference between the ISNULL and COALESCE Keywords in SQL Server Engine.

You can Google around for more deep explanations, but consider this a starting point.

ISNULL – Propitiatory T-SQL function

COALESCE – ANSI SQL Compliant

ISNULL – Takes only 2 parameters [ISNULL (NULL, NULL) will return valid result as INT]

COALESCE – Takes variable Number of Parameters and requires some type definition to produce valid results as INT

Example: [COALESCE (NULL, NULL) will produce errors]

[COALESCE CAST (NULL as INT), NULL] will produce valid results.

ISNULL – will always return results as INT (converted to int when result is produced)

COALESCE – will have to provide some type as defined in the example above.

Both can produce Different QUERY PLANS, of which COALESCE produces the WORST PLAN, when used in sub-queries then ISNULL since COALESCE internally operates like a CASE Statement.

When writing Complex Joins and computed Columns, Pl pay close attention, if you are using ISNULL or COALESCE

A Users Group meeting a Pittsburgh ended up with some basic questions bowled at me and here is the roundup of the explanation :

Question 1: how can we check that for how long SQL Server has been running?
ANSWER: Several ways to check how long SQL Server has been running or to REPHRASE this Question: When was SQL Server last restarted.
In Windows–> Administrative Tools–>Event Viewer look for SQL Server Restart info.Run a query in analyzer (Select * from master..sysprocesses where spid=1)This is the first system ID which logs into the SQL Server, after the SQL has been restarted.Mind it, the login_time will be off by a Few minutes vs. the Event Viewer, which will anyway show you the exact time the SQL server Started.
OR Check the SQL Server Error Log and see the DATE for the first logged Event in the Error Log, this should match with the Event Viewer and should be the time When SQL Server was Started.But again: SQL Server Error Log can be Recycled without Restarting SQL Server, So will need a Proper analysis, based on the above Theories.

Question 2: How to monitor Database Corruption using DBCC logs and what they actually mean?
ANSWER: Lengthy Answer and discussion, but in short….Command used to Check Database Consistency Check and are set of Database Console Command(s)DBCC CHECKDB ()Check for syntax and more on SQL Server Books Online.
This will Read through The internal Structure of the Database and Report for corruptions in Pages and Extents.
The Result set should be something like this:CHECKDB found 0 allocation errors and 0 consistency errors in database.
The Problem Statement for CHECKDB goes something like this: CHECKDB needs a consistent view of the database Why does it need a consistent view? Because, usually its running on a live database(s) with all kinds of things going on. we need to read and analyze the complete database but it can’t do it immediately and instantaneously, so it has to take a diff approach and to make sure it what it reads is transactionally consistent.
From SQL 2000, the DBCC is a online operation, which even reads through to Log to make sure it did not miss anything.
I will Skip to Fast Facts here:
DBCC Does various internal Database Allocation(pages and Extents) Checks and Chains (Index allocation maps etc)
A Full CHECKDB on the DATABSE will do a Lot of Stuff and will require more time to complete on a ONLINE DB and a Big DB.
So there are other options you should try and the best one is DBCC CHECKDB () WITH PHYSICAL_ONLY .
This is greatly Reduce the Time it takes to run the command and also REDUCE the SURFACE SCAN of the DATABASE to IMP INTERNAL STRUCTURE ONLY.(ALLOCATION MAPS ETC..)

Question 3: Why do you need to backup the Database to TRUNCATE the LOG and how do you Truncate the LOG.
ANSWER: By Backing up the Database, you Virtually Backup the last available Transaction along with the Database. So you have a Transaction log backup also if you do a FULL Backup. Then you can Truncate the LOG, to minimize the Transaction LOSS.Here is the Syntax and Explanation of how this can be DONE:
Do a Regular Full backup from EM(Enterprise Manager) or SSMS(SQL Server Management Studio)then check for available space in the Database files with this Query to see if there is space available in LOG File that could be shrunk etc.
SELECT name ,size/128.0 – CAST(FILEPROPERTY(name, ‘SpaceUsed’) AS int)/128.0 AS AvailableSpaceInMB_Files FROM sys.database_files
USE []DBCC SHRINKFILE (N” , 0, TRUNCATEONLY)–how to find the Database log File name [] USE [ADTTRC] select name,filename from sysfiles–and copy the log file name from name column
Or Change the RECOVERY MODEL to SIMPLE then run the Truncate Command.or right click Database Name–> Tasks–>Shrink–>Files
I hope i answered some basic questions to their satisfaction.