Persons familiar with TOAD for Oracle know about the fairly elaborate search function that lets you search for particular text in procedures, functions, views, column names, triggers, pretty much anything.

There's a way to do that in SQL Server as well, though you kind of have to "do it yourself." 

Use the query below.  Make sure that you are "in" the database that you mean to search before you run this query.

select * from sysobjects o, syscomments c where o.id=c.id

and c.text like '%your search text here%'

You can also limit your search by object type.  For example:

This is something I ran across as part of my job.  The query at first seems to work by magic, but some thought into what it must be doing helped.  I share my conclusions here.  I looked up some Microsoft documentation on it, which was tantalizing and confusing at the same time, as is typical.

Here's the Microsoft documentation:  http://www.databasejournal.com/features/mssql/article.php/3485291

Here's the science behind the magic.

Let's talk about this query:

where exists (select null from credential c2

where c.key = c2.key and c.id > c2.id

What this query does is that given the case where a set of records have a certain key, this query will return all records from that set EXCEPT for the one with the lowest id.

Where this is particularly powerful is in a case like this:

delete c from credential c

where exists (select null from credential c2

where c.key = c2.key and c.id > c2.id

That is, for a given set of records with a certain key, this query will DELETE all records from that set EXCEPT the one with the lowest id (presumably the oldest one).  VERY useful when cleaning up data corruption having to do with duplicate records!

What's it doing?

Note the where clause.  First, it ensures that the 'key' field matches.  Otherwise, the query is doing a cross-product of the credential table with itself.  It then asks the question, Is the id from table 1 greater than table 2?  If it is, it returns (deletes) that record.  Otherwise, it does not.

Let's look at that with some data.

Below is the cross-product it does, and the answer to its question, by row:

...which means that, for the delete query, it will remove records as follows.  The Id=30 is repeated and will be "deleted" twice.

This leaves, of course, what we wanted, which was to have a single record for each Key, and the Id that is left over is the lowest one for each Key:

So, not really magic after all.  And very powerful.  I don't know about you, but I love to know what is going on behind the scenes -- that's what makes the creativity and the fun possible!

This is aimed at the novice programmer.

When an application exception occurs, it can happen that the error causes a cascade of errors as it bubbles up to your exception handler (whether it be a custom exception handler, or the .net default exception handler).  As each exception occurs, it becomes the "current" exception that is recorded in the Exception object.  The original information is not lost, however -- a reference to it is stored in the Exception object's InnerException read-only property.

The issue is this:  In the case of this kind of "cascading" exception, the default behavior is just to show the last error that occurred.  This exception will have ittle or nothing to do with the problem that actually occurred, and will have little or not information to aid in resolving the issue.  There is an easy way around this, using recursion.

Below is a function that will return a string that is the aggregate of all of the error messages that occurred, so the developer can trace the problem back to the original source.

        //Recursively build exception/innerexception description string
        void BuildExceptionReport(Exception ex, StringBuilder exceptionReport)
        {
            if (ex.InnerException != null)
                BuildExceptionReport(ex, exceptionReport);

            exceptionReport.Append(ex.Message);
            exceptionReport.Append(" :::: ");
        }

You'd call it this way:

Why Stringbuilder?  Note, I use the Stringbuilder class because it's the most efficient way to build a string of arbitrary length and with an arbitrary number of steps.  It would have been more straightforward to code it as below, but not as performant:

        //Recursively build exception/innerexception description string
        string BuildExceptionReport(Exception ex)
        {
            string returnValue = string.Empty;

            if (ex.InnerException != null)
                BuildExceptionReport(ex);

            returnValue += string.Format("{0} :::: ", ex.Message);
            //returnValue += ex.Message +  " :::: ";  //even worse

            return returnValue;
        }

The reason it's not as performant is due to the way that .net concatenates strings.  Put simply, when joining two strings, .net creates a brand-new third string object, copies the first one into it, and then the next one.  It does this even if your code appears to do it "in place," as in the following example:

string a = a + b;

.net avoids this with the StringBuilder class used in the first example.  The StringBuilder class does what you'd expect it to:  It simply appends any new string to the existing object, reather than creating/copying as in simple string concatenation.

Best practice note:  One could argue that in any given case there aren't likely to be more than 1-4 nested exceptions, and exceptions themselves are rare, so it may be overkill to use the StringBuilder for recursive exception reporting.  That is a legitimate argument, and I would leave it to taste and the needs of your particular application to help you make the determination.

I noticed a posting on Generics on the main page, and I thought I would add my own 2 cents. Hopefully this will help clear up what Generics are, how they are different from derived classes, and when a designer might choose to use them over derived classes.

First, a definition: Generics are nothing more than a class template, into which the compiler will drop whatever type(s) you like (within the generic definition's constraints, of course). In other words, roughly put, instead of cutting and pasting to create several functionally identical classes whose only difference is the types they operate on, let the compiler do the "cutting and pasting" for you.

So, when would one use generics as opposed to, say, derived classes? Here's a simple example.

Let's say that you have separate FIFO queues, each of which handle different types.

You could define a class that simply stores the queue items as objects. But these are not type-safe, you would need to do casting, and there's that boxing/unboxing problem for value types. Plus the overhead incurred from the compiler having to maintain virtual method pointer tables (with the caveat that I remember this from my old C++ compiler days, it's possible the .net runtime has optimized this).

So you create derived classes from the base class that each are of the required type. So that buys you type-safety and eliminates casting, but it doesn't help you with the boxing/unboxing of value types, which would still be stored as an Object reference in the base class. Worse, if there are any other methods that need to be type-safe, which there almost certainly will be, then you have to duplicate (cut/paste/modify) each of those methods in each of your derived classes. So we're starting to get pretty far away from "code reuse."

Generics promise full code reusability.  You write the code once, and literally drop in the types that the class will operate on when you instantiate the class.  Type-safe, fast, flexible, extensible, and fully reusable.