memory.Refresh()

Andras Belokosztolszki from Red Gate posted an interesting article about the sp_rename stored procedure in SQL Server and the pitfalls that can occur after its use.

When a stored procedure is created, an object is created in the sysobjects table (or the sys.objects view in SQL Server 2005), and the textual definition is stored in the syscomments table (or the sys.sql_modules view in SQL Server 2005).

When using sp_rename to rename a stored procudure, the definition is left intact and only the name is changed in the sysobjects table (or sys.objects view). This means that the definition of the stored procedure stored in database now has the wrong name.

The best way of renaming a stored procedure is to completely delete it and then recreate it with the new name.

The following SQL displays the definitions of all stored procedures in a database alongside their names:

SQL Server 2000

SQL Server 2000
SELECT V2.[name], V1.[text]
    FROM syscomments AS V1, sysobjects AS V2
    WHERE V1.[id] = V2.[id]
    AND (V2.[xtype] = 'P' OR V2.[xtype] = 'F')

SQL Server 2005

SQL Server 2005
SELECT V2.[name], V1.[definition]
    FROM sys.sql_modules AS V1, sys.objects AS V2
    WHERE V1.[object_id] = V2.[object_id]

It is worth noting that enterprise manager uses the sp_rename stored procedure when using the right-click rename option (although SQL Server 2005 management studio does try to correct this problem if you view the definition of a renamed stored procedure by replacing the original stored name with the new one).

Aaron Stebner posted a recent article about the available installation modes for the .Net Framework 2.0.

There are three supported modes:

Standard Mode

All UI screens are displayed, including warnings about missing prerequisites, existing beta versions, errors and reboots.

The setup includes a multi-lingual UI that chooses the correct language from the user’s operating system UI language settings, so a user should always see the install in their preferred language.

Unattended Mode

All UI screens are suppressed, except for a progress dialog during installation.

To install in unattended mode, use the following command line:

dotnetfx.exe /q:a /c:"install.exe /qb"

Changing /qb to /qb! will hide the cancel button on the progress dialog, stopping the user from aborting the install.

Silent Mode

All UI screens are suppressed. This is useful for a custom installer to install the .Net Framework.

To install in silent mode, use the following command line:

dotnetfx.exe /q:a /c:"install.exe /q"

If using silent mode, any errors, previous beta versions or reboots must be handled by the hosting installer since the .Net Framework installer cannot display any dialogs to prompt the user. Aaron also provides details of possible return codes from the installer, how to detect previous beta versions of the framework and how to manage reboots.

Nikhil Kothari has made a nice little Web Development Helper for ASP.Net. It works as a plugin for Internet Explorer and is similar to the Internet Explorer Development Toolbar, but with more of an ASP.Net twist.

Some of its most useful features are:

-Rich error information for script errors, including call stack, script url and line number.

• a DOM inspector with filtering to enable easy viewing of particular items.
• a view state browser.
• trace information can be shown in a separate dialog instead of in the page itself.
• a full HTTP/HTTPS logger showing all traffic between the browser and the server.

The Web Development Helper requires .Net 2.0 to run and can only work on the same machine as the server, but this should not be a problem during development.

After installation, I had the same problem that lots of other people seem to have in that clicking the newly installed toolbar button did nothing. The suggested fix of installing the Internet Explorer Development Toolbar solved the problem though. Nikhil also suggested that a reboot (or killing explorer.exe) may also work because information about plugins is cached on startup.

In .Net Windows Forms, any form or control that derives from a Component has a DesignMode property that tells you whether the control is being rendered in design mode in Visual Studio. This is useful if your control has different behaviour at runtime than at design time (for example, if you show a connection dialog when a form opens but you don’t want it to happen in design mode inside Visual Studio).

The DesignMode property has its quirks though. Using Lutz Roeder’s Reflector reveals the implementation of the DesignMode property:

protected bool DesignMode
{
    get
    {
        if (this.site != null)
        {
            return this.site.DesignMode;
        }
        return false;
    }
}

This shows that design time support is not hooked up until the control is sited. Siting happens after the control is created, but before any properties are set, so if you check the DesignMode property in the constructor of a control, it will always be false.

There is also a bug with the DesignMode property whereby a custom control inside a custom control will always report its DesignMode property as false. Microsoft has more details of this in knowledge base article KB839202 and in their Visual Studio feedback website.

A workaround to both of the above problems it to use the following:

Application.ExecutablePath.ToLower().IndexOf("devenv.exe") > -1

A bit crude, but it works.

SQL Server Management Studio provides a simple results view to show the data contained in a table. With this view, it’s possible to edit the data in the table but there is no obvious method of setting a nullable field to null - emptying the cell simply sets the value to empty, which may or may not work depending on the type of the column.

To set a null value, you have to use the Ctrl-0 (Control + Zero) shortcut. Why is there no option in the GUI to do this?