December 2010 - Posts

SQLBits 8 dates and venue announced
22 December 10 10:36 PM | MartinBell | 1 comment(s)

We are pleased to announce that SQLBits will be beside the seaside from the 7th to 9th April 2011 at the Grand Hotel in Brighton.

The format will be 3 days of top SQL Server content given by SQL Server Experts from around the world.

  • Day 1 - 7th April - Full day deep dive seminars by SQL Server experts on specific aspects of SQL Server. There will be seminars for everyone covering Business Intelligence, Development and Administration

  • Day 2 - 8th April - 20-25 sessions throughout the day spread over 5 rooms covering all aspects of SQL Server

  • Day 3 - 9th April - 20-25 sessions delivered by the UK SQL Server community and this day is FREE

As with all SQLBits events this will be another great opportunity to meet other SQL Server professionals and to learn about SQL Server. There will also be leading providers of SQL Server tools and services for you to review and discuss all in one place. As with previous years there will be food and drink after the sessions have finished where you can discuss the latest T-SQL feature in a relaxed atmosphere.

The Brighton Grand

The venue for SQLBits VIII will be The Grand Hotel. Due to the size of SQLBits we will be taking over the whole hotel, so if you are coming; The Grand will be the place to stay. Sitting on the Brighton seafront the location is amazing. If you want to be right amongst to the action, we strongly advise booking early to make sure you get a room in the hotel. For more details about the travel and accommodation visit the Travel and Accomodation page.

For more information about the session and conference visit the website www.sqlbits.com, remember if you register with the site you can keep up-to-date with the conference by subscribing to our mailing list.

If you are interested in sponsoring SQLBits please contact us. We have numerous sponsorship opportunities available and some new options for this year.

An early Xmas present for SQL 2005 users
17 December 10 11:45 AM | MartinBell | with no comments

On Friday Microsoft release Service Pack 4 for SQL Server 2005 (for SQL Express see here and other 2005 editions see here). Although this is a nice early Christmas present remember that the Three Wise Men didn’t arrive until January 6th! If you want to have a Happy Christmas and a Merry New Year, take a tip from the Maji and don't rush a release out before Xmas and make sure that you test it thoroughly first!

Do you know the difference between .mdf, .ndf and .ldf files?
02 December 10 10:10 PM | MartinBell | 1 comment(s)

This is a typical exam or interview questions e.g.

A SQL Server file with a .mdf extension is the following (tick all options):

    • Primary data file
    • Secondary data file
    • Database log file

The answer could be all of them or none of them! SQL Server does not enforce file names, so you can name the database files to be anything you want with whatever extension that your fancy i.e.

USE [master]
GO

CREATE
DATABASE [ConfusingDB] ON  PRIMARY
( NAME = N'TestDB_Primary', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\ConfusingDB.ldf' , SIZE = 2512KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1KB )
 LOG ON
( NAME = N'TestDB_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\ConfusingDB.mdf' , SIZE = 512KB , MAXSIZE = 2048GB , FILEGROWTH = 1KB)
GO

If you look at the topic "Understanding Files and Filegroups" in Books Online, it  only says that the file extensions are recomended. If a file is used by an attached database you can determine what type of file it is by looking in sys.master_files.

This reminds me of an occasion when a friend rang me becase he was having problems attaching a database. So I asked him what error message he was getting, and it turned out to be the following:

Msg 1829, Level 16, State 3, Line 1The FOR ATTACH option requires that at least the primary file be specified.


Further questioning revealed that he had noticed that the .ldf file was very large, so he’d decided to detach the database, delete the log file and then re-attach the data file. Unfortunately the files names for the log file and data file had been transposed when someone had tried to move them. The error message was dead on the mark and tells you exactly what the problem was.

I was able to determine the timeframe when this happened by looking at the backups using RESTORE FILELISTONLY. It was fortunate that he had those backups and he's learn't not to assume that the

Filed under:

This Blog

SQL Blogs

Syndication