Quickduck

Have you ever wanted to script all the db objects in your database and customize how you format the scripts?

So have I!

Ideally, I wanted to script all the db objects (eg. procs, udfs, grants, defaults, permissions, tables, etc) and have each object output into a separate file and formatted a particular way.

So I’ve created a couple of sprocs that allow you to do this.

Usage:
EXEC dbo.CreateSqlScripts
‘<directory>’, ‘<sqlServerInstance>’, ‘<dbname>’, ‘<object type or null>’, ‘<formattingoptions>’

Example:
EXEC dbo.CreateSqlScripts
‘c:\temp\sql\’, ‘localhost\SQLLOCALMACHINE’, ‘MyDB’, NULL, 73879 — all db objects

Example:
EXEC dbo.CreateSqlScripts
‘c:\temp\sql\’, ‘localhost\SQLLOCALMACHINE’, ‘MyDB’, ‘P’, 73879 — stored procedures only

A bonus feature of having your db scripted out is that you can use a 3rd party program like DBGhost to generate a new db from the scripts directory.

This is really handy if you want to have your db source controlled.

A daily question from a while back that had perplexed me for ages:

Q: In a DataBound control, what’s the difference between using a <%= %> block, and a <%# %> block?

Of course I actually did know the difference, and when I should use each one, but Bender summed up the correct answer the best:

A: You use a <%# %> block if you need access to the underlying DataSource of the repeating control (e.g. you need to access the DataItem with an Eval statement, or you need access to the Container element).

When you do not need to access the underlying DataSource, use a <%= %> block instead.

I can never remember the syntax to format a string when using the Eval statement, so once and for all I decided to try and commit it to memory by writing it down here.

In a DataBound control, you can use Eval to evaluate a public property on the DataItem that is being bound to the control. For example, if your DataItem has a public property called Name, you may use this statement to output the value of the property:

<%# Eval("Name") %>

The Eval method also has an overload which takes a format string. So far as I can figure, this format string is used in a similar vain to String.Format, whereby you supply the formatting string by numbered parameters. (Aside: The numbering system seems pretty pointless to me, since you’d almost always have only a single parameter to pass, wouldn’t you?).

Anyway - to get to the point - you can use the format string as follows: Presuming your DataItem has a property called “StartDate” which returns a DateTime, you can format the DateTime in the format “1 Nov 2006″ using the following code:

<%# Eval("StartDate", "{0:dd MMM yyyy}") %>

A while back, Bender sent me a link to a prototype.js file that pretty much claimed to be a web developers best friend. It certainly has some interesting features, and one that I really liked was the “$” function. Basically, the developer had written the function to return you an array of the elements that you asked for by id. So in effect, if you wrote -

var elements = $("txtName", "txtPhone", "txtCountry");

- then you would be returned an array containing a reference to each of those form elements (presuming that they exist, of course ;-))

Well that’s all fine and dandy, but more often than not I find myself trying to find elements in that are declared as: runat=”server”. And if those elements are nested in a UserControl, then you have to know how their id will be transformed at runtime by ASP.NET (for example, “txtName” may become “ctl00_main_sidebar_txtName”). So, with this in mind, I wrote my own version of the $ function which took care of this situation for me:

/*
 * Find an element based on the provided strings
 *
 * elementId:   Server-side id of the element to find (e.g. "txtName")
 * tagName:     The runtime tag of the element (e.g. "input")
 * elementType: The runtime value of the "type" attribute for the element,
 *              if it exists (e.g. "text")
 */
function $(elementId, tagName, elementType) {
    if (!tagName || tagName == "") {
        return document.getElementById(elementId);

    } else if (tagName) {
        var elements = document.getElementsByTagName(tagName, "gi");
        var typeRegex = elementType && elementType != "" ? new RegExp(elementType) : null;

        for (var i = 0; i < elements.length; i++) {
            if (typeRegex) {
                if (!elements[i].type || !typeRegex.exec(elements[i].type)) {
                    continue;
                }
            }

            if (elements[i].id && elements[i].id.indexOf(elementId) >= 0) {
                return elements[i];
            }
        }
    }

    return null;
}

It’s possibly not the most efficient piece of code that you’ll ever come across, but it does the job perfectly.

NHibernate 1.2.0 Beta 2 has been released! Huge changes have occurred since NHibernate 1.0, not the least being that it now supports many features of .NET 2.0 (e.g. Generics, woohoo!).

Being a keen early adopter, I have actually been playing with Beta 1 for a few weeks. I was expecting a fairly seemless upgrade to the new beta, however was a little stumped when I got this error:

<session-factory> element was not found in the configuration file.

“Bless their souls”, I thought, “what on earth is going on?!”. After a quick troll through the source code though, I found out that they’ve updated their configuration schema to version 2.2. So to fix the problem, all I had to do was:

1. Change the configuration entry in my Web.config file from version 2.0 to 2.2:
   
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2“>

2. Change all of my mapping files in the same manor:
   
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2” namespace=”Blah” assembly=”Blah”>


Don’t forget to Rebuild (not Build!) after that last step too, kids!