The DATEDIFF() function returns the time between two dates.

Syntax

Where startdate and enddate are valid date expressions and datepart can be one of the following:

Example

Now we want to get the number of days between two dates.

We use the following SELECT statement:

Result:

Example

Now we want to get the number of days between two dates (notice that the second date is “earlier” than the first date, and will result in a negative number).

We use the following SELECT statement:

Result:

Reference – http://www.w3schools.com

Renaming a table

The basic syntax for renaming a table is:

ALTER TABLE table_name
RENAME TO new_table_name;

For example:

ALTER TABLE suppliers
RENAME TO vendors;

This will rename the suppliers table to vendors.

Adding column(s) to a table

Syntax #1

To add a column to an existing table, the ALTER TABLE syntax is:

ALTER TABLE table_name
ADD column_name column-definition;

For example:

ALTER TABLE supplier
ADD supplier_name  varchar2(50);

This will add a column called supplier_name to the supplier table.

Syntax #2

To add multiple columns to an existing table, the ALTER TABLE syntax is:

ALTER TABLE table_name
ADD (	column_1	column-definition,
	column_2	column-definition,
	…
	column_n	column_definition );

For example:

ALTER TABLE supplier
ADD (	supplier_name	varchar2(50),
	city	varchar2(45) );

This will add two columns (supplier_name and city) to the supplier table.

Modifying column(s) in a table

Syntax #1

To modify a column in an existing table, the ALTER TABLE syntax is:

ALTER TABLE table_name
MODIFY column_name column_type;

For example:

ALTER TABLE supplier
MODIFY supplier_name   varchar2(100)     not null;

This will modify the column called supplier_name to be a data type of varchar2(100) and force the column to not allow null values.

Syntax #2

To modify multiple columns in an existing table, the ALTER TABLE syntax is:

ALTER TABLE table_name
MODIFY (	column_1	column_type,
	column_2	column_type,
	…
	column_n	column_type );

For example:

ALTER TABLE supplier
MODIFY (	supplier_name	varchar2(100)	not null,
	city	varchar2(75)		);

This will modify both the supplier_name and city columns.

Drop column(s) in a table

Syntax #1

To drop a column in an existing table, the ALTER TABLE syntax is:

ALTER TABLE table_name
DROP COLUMN column_name;

For example:

ALTER TABLE supplier
DROP COLUMN supplier_name;

This will drop the column called supplier_name from the table called supplier.

Rename column(s) in a table
(NEW in Oracle 9i Release 2)

Syntax #1

Starting in Oracle 9i Release 2, you can now rename a column.

To rename a column in an existing table, the ALTER TABLE syntax is:

ALTER TABLE table_name
RENAME COLUMN old_name to new_name;

For example:

ALTER TABLE supplier
RENAME COLUMN supplier_name to sname;

This will rename the column called supplier_name to sname.

Acknowledgements: Thanks to Dave M., Craig A., and Susan W. for contributing to this solution!

Practice Exercise #1:

Based on the departments table below, rename the departments table to depts.

CREATE TABLE departments
(	department_id	number(10)	not null,
	department_name	varchar2(50)	not null,
	CONSTRAINT departments_pk PRIMARY KEY (department_id)
);

Solution:

The following ALTER TABLE statement would rename the departments table to depts:

ALTER TABLE departments
RENAME TO depts;

Practice Exercise #2:

Based on the employees table below, add a column called salary that is a number(6) datatype.

CREATE TABLE employees
(	employee_number	number(10)	not null,
	employee_name	varchar2(50)	not null,
	department_id	number(10),
	CONSTRAINT employees_pk PRIMARY KEY (employee_number)
);

Solution:

The following ALTER TABLE statement would add a salary column to the employees table:

ALTER TABLE employees
ADD salary number(6);

Practice Exercise #3:

Based on the customers table below, add two columns – one column called contact_name that is a varchar2(50) datatype and one column called last_contacted that is a date datatype.

CREATE TABLE customers
(	customer_id	number(10)	not null,
	customer_name	varchar2(50)	not null,
	address	varchar2(50),
	city	varchar2(50),
	state	varchar2(25),
	zip_code	varchar2(10),
	CONSTRAINT customers_pk PRIMARY KEY (customer_id)
);

Solution:

The following ALTER TABLE statement would add the contact_name and last_contacted columns to the customers table:

ALTER TABLE customers
ADD (	contact_name	varchar2(50),
	last_contacted	date );

Practice Exercise #4:

Based on the employees table below, change the employee_name column to a varchar2(75) datatype.

CREATE TABLE employees
(	employee_number	number(10)	not null,
	employee_name	varchar2(50)	not null,
	department_id	number(10),
	CONSTRAINT employees_pk PRIMARY KEY (employee_number)
);

Solution:

The following ALTER TABLE statement would change the datatype for the employee_name column to varchar2(75):

ALTER TABLE employees
MODIFY employee_name varchar2(75);

Practice Exercise #5:

Based on the customers table below, change the customer_name column to NOT allow null values and change the state column to a varchar2(2) datatype.

CREATE TABLE customers
(	customer_id	number(10)	not null,
	customer_name	varchar2(50),
	address	varchar2(50),
	city	varchar2(50),
	state	varchar2(25),
	zip_code	varchar2(10),
	CONSTRAINT customers_pk PRIMARY KEY (customer_id)
);

Solution:

The following ALTER TABLE statement would modify the customer_name and state columns accordingly in the customers table:

ALTER TABLE customers
MODIFY (	customer_name	varchar2(50) not null,
	state	varchar2(2) );

Practice Exercise #6:

Based on the employees table below, drop the salary column.

CREATE TABLE employees
(	employee_number	number(10)	not null,
	employee_name	varchar2(50)	not null,
	department_id	number(10),
	salary	number(6),
	CONSTRAINT employees_pk PRIMARY KEY (employee_number)
);

Solution:

The following ALTER TABLE statement would drop the salary column from the employees table:

ALTER TABLE employees
DROP COLUMN salary;

Practice Exercise #7:

Based on the departments table below, rename the department_name column to dept_name.

CREATE TABLE departments
(	department_id	number(10)	not null,
	department_name	varchar2(50)	not null,
	CONSTRAINT departments_pk PRIMARY KEY (department_id)
);

Solution:

The following ALTER TABLE statement would rename the department_name column to dept_name in the departments table:

ALTER TABLE departments
RENAME COLUMN department_name to dept_name;
 

Reference – http://www.techonthenet.com

The script for renaming any column :
sp_RENAME 'TableName.[OldColumnName]' , '[NewColumnName]', 'COLUMN'

The script for renaming any object (table, sp etc) :
sp_RENAME '[OldTableName]' , '[NewTableName]'

This article demonstrates two examples of renaming database object.

1. Renaming database table column to new name.
2. Renaming database table to new name.

In both the cases we will first see existing table. Rename the object. Test object again with new name.

1. Renaming database table column to new name.

Example uses AdventureWorks database. A small table with name “Table_ First” is created. Table has two fields ID and Name.

Now, to change the Column Name from “Name” to “NameChange” we can use command:

USE AdventureWorks
GO
sp_RENAME 'Table_First.Name', 'NameChange' , 'COLUMN'
GO

Following Fig. show use of SP_RENAME Command

You can see the column name “Name” is now changed to “NameChange”.

USE AdventureWorks
GO
SELECT *
FROM Table_First
GO

Following fig. verify that the column name has been changed.

2.Renaming database table to new name.

We can change the table name too with the same command.

sp_RENAME 'Table_First', 'Table_Last'
GO

Following fig. Shows how we can change Table Name.

Now, the table name “Table_First” is renamed as “Table_Last”.

“Table_First” will no longer be available in database. We can verify this by running script:

USE AdventureWorks
GO
SELECT *
FROM Table_First
GO


The Messages shows an error “Invalid object name ‘Table_First’.”

To check that the new renamed table exist in database run script:

USE AdventureWorks
GO
SELECT *
FROM Table_Last
GO

You can see the same data now available in new table named “Table_Last”

Reference : Pinal Dave (http://blog.SQLAuthority.com)

This is very common request recently – How to import CSV file into SQL Server? How to load CSV file into SQL Server Database Table? How to load comma delimited file into SQL Server? Let us see the solution in quick steps.

CSV stands for Comma Separated Values, sometimes also called Comma Delimited Values.

Create TestTable

USE TestData
GO
CREATE TABLE CSVTest
(ID INT,
FirstName VARCHAR(40),
LastName VARCHAR(40),
BirthDate SMALLDATETIME)
GO

Create CSV file in drive C: with name csvtest.txt with following content. The location of the file is C:\csvtest.txt

1,James,Smith,19750101

2,Meggie,Smith,19790122

3,Robert,Smith,20071101

4,Alex,Smith,20040202

Now run following script to load all the data from CSV to database table. If there is any error in any row it will be not inserted but other rows will be inserted.

BULK
INSERT CSVTest
FROM 'c:\csvtest.txt'
WITH
(
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n'
)
GO
--Check the content of the table.
SELECT *
FROM CSVTest
GO
--Drop the table to clean up database.
SELECT *
FROM CSVTest
GO

Reference : Pinal Dave (http://blog.SQLAuthority.com)

One of the fairly frequently asked questions on the Microsoft replication discussion boards concerns how to alter a replicated article. For simple cases this is quite straightforward – adding a column is achieved using sp_repladdcolumn, while sp_repldropcolumn is used to drop a column. However, what if we want to change an existing column – e.g. change the Fname varchar(50) column below to Fname varchar(100)?

Another article I’ve written illustrates how this can be achieved in SQL Server 2000; the article lists 2 alternative methods, both of which are rather ‘clunky’ and result in a huge amount of transactions being replicated. While the article illustrates a useable workaround for DDL changes to replicated tables, there is no correspondingly obvious way of reactively replicating a change to a replicated view or other programming object. So, if we publish a view, when the view definition is changed on the publisher, the new definition may be subsequently pumped to the subscribers using sp_addscriptexec, reinitializing or manually connecting to the subscriber and issuing an ‘alter view’ statement. However, the problem is that there is no way in SQL 2000 to automatically pick up the view definition changes, and the onus lies on the constant diligence of the DBA to prevent any non-synchronization between the view definition on the publisher and its subscribers. The new DDL replication features now available in SQL Server 2005 may be used to overcome these and other issues and this current article explains how to take advantage of this functionality.

Implementation

In SQL Server 2005 replication, DDL changes may be replicated for tables, views, stored procedures, functions and triggers. To take advantage of this new methodology is straightforward. For example, adding a column is now done using ‘ALTER TABLE’ syntax eg

ALTER TABLE tPersonnel ADD Salary INT NULL

Note that the column above is nullable and that this is a requirement – either the new column is nullable or has a default constraint.

During synchronization of the distribution/merge agent, this change is replicated to the subscriber as the same ‘ALTER TABLE’ statement, along with the requisite stored procedure changes (transactional) and metadata/trigger changes (merge). These DDL changes must always be made at the publisher and never at the subscriber, and this also applies to republishing scenarios, where the schema change will be automatically propagated from the publisher to the publisher-subscriber and finally to the subscriber.

Note that the SQL Management Studio graphical interface may be used to directly add or drop a column to the replicated table, but unfortunately, altering a column is disallowed. On changing an existing column, the GUI chooses to drop and recreate the table behind the scenes, resulting in the error message below:

(In case you’re wondering, the ‘save text file’ button refers to the error message text rather than the necessary TSQL script to run). This is followed by a standard ‘User cancelled out of save dialog’ message. So, to make the DDL change mentioned initially, we open a query window and run

ALTER TABLE tPersonnel ALTER COLUMN FName VARCHAR(100) NULL

and the changes are replicated as painlessly as when we add a column.

Which DDL changes may now be replicated? Basically almost all aspects of the ‘ALTER TABLE’ syntax are supported. Adding / dropping / changing a column comes in to this category but remember that index creation uses ‘CREATE INDEX’ so isn’t included and we’ll still need to use sp_addscriptexec for this. The exceptions are:

(a) as you would expect for transactional replication, altering a primary key is disallowed and results in an error (‘Msg 4929, Level 16, State 1, Line 1 Cannot alter the table ‘tPersonnel’ because it is being published for replication. Msg 3727, Level 16, State 0, Line 1 Could not drop constraint. See previous errors.’)

(b) although it doesn’t result in an error, adding an identity column to a published table is not supported, because it can result in non-convergence when the column is replicated to the Subscriber. Altering or dropping identity columns that are managed by replication is also not supported.

The SQL Server 2000 procedure sp_repladdcolumn is still available but is deprecated and is only recommended for exceptional circumstances, namely SQL Server 2000 publishers,  SQL Server 2000 republishing subscribers and SQL Server 2000 merge subscribers.

Enabling / Disabling

To control DDL replication, there is a publication property on the ‘Subscription Options’ section (see below). It can be enabled or disabled on the fly without causing a required reinitialization, and by default is enabled. Once disabled, schema changes are still possible and are not replicated. To achieve the same end in TSQL, use sp_addpublication / sp_addmergepublication / sp_changepublication / sp_changemergepublication  specifying a value of 0 for the parameter @replicate_ddl.

The one exception to consider is that ‘ALTER TABLE DROP COLUMN’ is always replicated to all subscriptions which replicate the column, regardless of the value of the @replicate_ddl parameter.

Working with Different Versions of SQL Server

How does all this tie in if you have multiple versions of SQL Server? The most common combinations will involve a SQL Server 2005 Pub\Dist and a SQL Server 2000 Subscriber and vice versa. The table below shows the resulting behaviour if we add a column:

Finally – Error-Handling

According to BOL setting @replicate_ddl to 0 is the recommended method of making certain changes to avoid errors and enforced reinitialization, with the example being the addition of a foreign key to a publication table when the related table doesn’t exist on the subscriber. As far as I can tell this BOL example is obsolete as far as Transactional replication is concerned, as the code used to create the FK constraint (stored in the MSreplCommands table) is prefixed with an ‘IF EXISTS’ clause which looks for the related table, thus preventing this problem from occurring. The -SkipErrors method would be the first choice to try if DDL replication causes an error, but so far I haven’t found a way of testing this as I can’t initiate the error itself . However, in the case of merge replication the schema change command stored in sysmergeschemachange has no such ‘IF EXISTS’ check so this can indeed result in the error mentioned in BOL. In this case there is a ‘get out of jail’ card you can play if you are ever in this situation – the stored procedure sp_markpendingschemachange (in conjunction with sp_enumeratependingschemachanges) will mark schema changes to be skipped so synchronization can continue.

Reference – http://www.replicationanswers.com

“Cannot alter/drop the table ‘tablename’ because it is being published for replication”.

So, how to change an existing column without breaking replication? Consider if we wanted to make the following schema change:

to

The method we choose depends in part on the replication type and size of the table, but there are 2 main options:

(a) altering the subscriptions

  exec sp_dropsubscription   @publication =  'tTestFNames' 
     ,  @article =  'tEmployees' 
     ,  @subscriber =  'RSCOMPUTER'
     ,  @destination_db =  'testrep' 

  exec sp_droparticle  @publication =  'tTestFNames'
     ,  @article =  'tEmployees'

  alter table tEmployees alter column Forename varchar(100) null

  exec sp_addarticle  @publication =  'tTestFNames' 
     ,  @article =  'tEmployees' 
     ,  @source_table =  'tEmployees' 

  exec sp_addsubscription  @publication =  'tTestFNames'
     ,  @article =  'tEmployees'
     ,  @subscriber =  'RSCOMPUTER' 
     ,  @destination_db =  'testrep'

For snapshot replication this is the obvious choice. We drop the subscription to this article, drop the article, then change the table. Afterwards the process is reversed. The next time the snapshot agent is run, it’ll pick up the new schema without any issues.

For transactional replication we may choose to proceed using the script above. However, we must be more careful in this case. By default, an insert, update or delete statement performed on the publisher is propagated to the subscriber in the form of a stored procedure call. By changing the column definition, we may need to change the related stored procedures on all the subscribers. Addition of a default would be fine, but changing the datatype itself as above would require the stored procedure arguments to be modified. For the example table above, these 3 procedures exist on the subscriber in the form:

sp_MSins_tEmployees,
sp_MSupd_tEmployees,
sp_MSdel_tEmployees.

They can be generated at the publisher using sp_scriptpublicationcustomprocs but this would of course require the system to be quiesced, i.e. during this (quick) change there shouldn’t be any alterations made to the publisher’s data and all the subscribers should be completely synchronized.

This is not ideal, and there is also a hidden problem here waiting to be discovered. Usually, when you add a new article to an existing publication in transactional replication, running the snapshot agent will create a snapshot of just the new article. In our case, it’ll also create a snapshot of the ‘tEmployees’ table. So, to avoid all the issues and complications mentioned above, it’s simplest to run the snapshot agent immediately after executing sp_addsubscription and then synchronize.

In merge replication, there is no possibility of dropping the subscription on a per article basis using the script above, as there is in transactional and snapshot replication. If we drop the subscription entirely including all other articles (sp_dropmergesubscription), then try to run sp_dropmergearticle there will be an error if the snapshot has already been run, so we have to set @forceinvalid_snapshot to 1, make the table change on the publisher then read the article and subscriptions and initialize which would necessitate a new snapshot generation of all articles in this publication. A nosync initialization is possible, but this can be extremely restrictive for future changes, and I’ll leave that for another article.

(b) altering the table in-place

OK, in some cases the table is large and we don’t want to run a new snapshot – either of the individual table (transactional) or of the whole publication (merge) – so there is an alternative method. We might use the built in stored procedures sp_repladdcolumn and sp_repldropcolumn to make the changes (note that these procedures limit the subscribers to be SQL Server 2000 only). Using these procedures we can add a dummy column to hold the data, remove the old column, add in the correct definition of the original column then transfer back the data. Now the script becomes:

  exec sp_repladdcolumn  @source_object =  'tEmployees'
     ,  @column =  'TempForename' 
     ,  @typetext =  'varchar(100) NULL' 
     ,  @publication_to_add =  'tTestFNames' 

  update tEmployees set TempForename = Forename

  exec sp_repldropcolumn  @source_object =  'tEmployees' 
     ,  @column =  'Forename' 

  exec sp_repladdcolumn  @source_object =  'tEmployees'
     ,  @column =  'Forename' 
     ,  @typetext =  'varchar(100) NULL' 
     ,  @publication_to_add =  'tTestFNames' 

  update tEmployees set Forename = TempForename

  exec sp_repldropcolumn  @source_object =  'tEmployees' 
     ,  @column =  'TempForename'

Although the above script can be used for transactional replication or merge replication, the internal methodology is different due to the differing nature of these 2 techniques. For merge replication, details of the rows updated are kept in MSmerge_contents, and if a particular row has been changed once or a hundred times, there will still only be one entry in this system table, while in transactional replication, 100 updates to a row is propagated as 100 subscriber updates. This means merge has an advantage over transactional because we need to perform 2 updates to each row to make the schema change.

Paul Ibison, SQL Server MVP, 2005, http://ssisblog.replicationanswers.com/

You can create a dump device using SSMS or T-SQL.

To create a dump device using SSMS:

1. Expand “Server Objects” in Object Explorer,

2. Right Click on “Backup Devices” and choose “New Backup Device”

3. Provide a logical Device name and the physical backup file location for dump device

4. Click “OK” to create the dump device.

To create a dump device using T-SQL:

To create a dump device using T-SQL you can use system stored procedure sp_addumpdevice.

USE [master]

GO

EXEC master.dbo.sp_addumpdevice

@devtype          = N’disk’,

@logicalname      = N’MyBackups’,

@physicalname     = N’C:\Database\Backup\BackupDisk.bak’

GO

Result Set:

(1 row(s) affected)

View all dump devices:

You can get the list of existing dump devices on server using sys.backup_devices catalog view:

SELECT      *

FROM        sys.backup_devices

GO

Result Set:

Name          type   type_desc     physical_name

———–   —–  ———–   ——————————–

MyBackups     2      DISK          C:\Database\Backup\BackupDisk.bak

(1 row(s) affected)

Using the dump device for BACKUP:

Once the dump device is created you can use it to store backups, The dump device will be listed in “Select Backup Destination” dialog box:

You can use it in T-SQL as below:

/*

BACKUP DATABASE [SqlAndMe]

TO DISK = N’C:\Database\Backup\SqlAndMeBackup.bak’

WITH NOFORMAT, NOINIT, NAME = N’SqlAndMe – Full Backup’,

SKIP, NOREWIND, NOUNLOAD,  STATS = 10

GO

*/

BACKUP DATABASE [SqlAndMe]

TO [MyBackups]

WITH NOFORMAT, NOINIT, NAME = N’SqlAndMe – Full Backup’,

SKIP, NOREWIND, NOUNLOAD,  STATS = 10

GO

Result Set:

10 percent processed.

20 percent processed.

30 percent processed.

40 percent processed.

50 percent processed.

60 percent processed.

70 percent processed.

80 percent processed.

90 percent processed.

Processed 44680 pages for database ‘SqlAndMe’, file ‘SqlAndMe’ on file 2.

100 percent processed.

Processed 1 pages for database ‘SqlAndMe’, file ‘SqlAndMe_log’ on file 2.

BACKUP DATABASE successfully processed 44681 pages in 23.542 seconds (14.827 MB/sec).

Changing Physical File location for dump devices:

To change the physical file location for dump device, you need to drop and recreate the dump device. If you need to move the current physical file to a new location, it can be done using Windows Explorer or any other File Manager. The physical file is not locked unless a BACKUP/RESTORE is in progress.

USE [master]

GO

EXEC master.dbo.sp_dropdevice

@logicalname = N’MyBackups’

GO

EXEC master.dbo.sp_addumpdevice

@devtype          = N’disk’,

@logicalname      = N’MyBackups’,

@physicalname     = N’C:\NewLocation\BackupDisk.bak’

GO

SELECT      *

FROM        sys.backup_devices

GO

Result Set:

Device dropped.

Name          type   type_desc     physical_name

————  —— ————  ———————–

MyBackups     2      DISK          C:\NewLocation\BackupDisk.bak

(1 row(s) affected)

Hope This Helps! Cheers!

Reference : Vishal (http://SqlAndMe.com)

USE   [AdventureWorks2008R2]

GO

SELECT      SCHEMA_NAME(A.schema_id) + ‘.’ +

A.Name, SUM(B.rows) AS ‘RowCount’

FROM        sys.objects A

INNER JOIN sys.partitions B ON A.object_id = B.object_id

WHERE       A.type = ‘U’

GROUP BY    A.schema_id, A.Name

GO

Result Set:

Person.Address                    78456

Person.AddressType                18

dbo.AWBuildVersion                1

dbo.BCPTest                       5

Production.BillOfMaterials        8037

Person.BusinessEntity             41554

Person.BusinessEntityAddress      78456
…

However, for views row count is not available in sys.partitions. To get the row count for a view; you must query the view itself.

USE   [AdventureWorks2008R2]

GO

SELECT COUNT(*) FROM HumanResources.vEmployee

GO

Result Set:

290

(1 row(s) affected)

This can be encapsulated in a stored procedure to query all available views and then display the result set. The procedure can be created as:

USE   [AdventureWorks2008R2]

GO

CREATE PROCEDURE dbo.ViewsRowCount

AS

BEGIN
SET NOCOUNT ON

CREATE TABLE #tempRowCount

(

Name        VARCHAR(100),

Row_Count   INT

)

DECLARE     @SQL VARCHAR(MAX)

SET         @SQL = ”

SELECT @SQL = @SQL + ‘INSERT INTO #tempRowCount SELECT ”’ +

SCHEMA_NAME(schema_id) + ‘.’ + name + ”’, COUNT(*) FROM ‘ +

SCHEMA_NAME(schema_id) + ‘.’ + name +

CHAR(13) FROM sys.objects WHERE type = ‘V’

EXEC (@SQL)

SELECT      Name, Row_Count

FROM        #tempRowCount

END

GO

Once created this stored procedure returns row count for all views in database as bellow:

USE   [AdventureWorks2008R2]

GO

EXEC  dbo.ViewsRowCount

GO

Result Set:

Name                           Row_Count

dbo.vApplicationSpecialists    3

Person.vAdditionalContactInfo  10

HumanResources.vEmployee       290

Sales.vIndividualCustomer      18508

Sales.vPersonDemographics      19972

HumanResources.vJobCandidate   13

…

Reference – http://sqlandme.com

http://sqlandme.com

To attach a database from Management Studio:

Right click on Database node and choose attach:

This will open the “Attach Databases” dialogue box, where you can select the .mdf file using “Add…” button:

Note, that is says “Not Found” for log file, if you click on “OK”, it will raise an error:

The detailed error message can be seen by click on “Message” link:

Moral of the story, you can’t attach single .mdf  using GUI. You need to use T-SQL to achieve this:

– © 2011 – Vishal (http://SqlAndMe.com)

CREATE DATABASE [TestDB]

ON (FILENAME = ‘C:\123\TestDB.mdf’)

FOR ATTACH_REBUILD_LOG ;

On successful completion, you will get the below message:

File activation failure. The physical file name “C:\Program Files\Microsoft SQL Server\MSSQL11.DENALI\MSSQL\DATA\TestDB_1.ldf” may be incorrect.

New log file ‘C:\123\TestDB_log.ldf’ was created.

Hope This Helps! Cheers!

Reference : Vishal (http://SqlAndMe.com)

He did send me his database; however, his method made me write this quick note here. Instead of taking a full backup of the database and sending it to me, he sent me only the .mdf (primary database file). In fact, I asked for a complete backup (I wanted to review file groups, files, as well as few other details).  Upon calling my friend,  I found that he was not available. Now,  he left me with only a .mdf file. As I had some extra time, I decided to checkout his database structure and get back to him regarding the full backup, whenever I can get in touch with him again.

Technical Talk:
If the database is shutdown gracefully and there was no abrupt shutdown (power outrages, pulling plugs to machines, machine crashes or any other reasons), it is possible (there’s no guarantee) to attach .mdf file only to the server. Please note that there can be many more reasons for a database that is not getting attached or restored. In my case, the database had a clean shutdown and there were no complex issues. I was able to recreate a transaction log file and attached the received .mdf file.

There are multiple ways of doing this. I am listing all of them here. Before using any of them, please consult the Domain Expert in your company or industry. Also, never attempt this on live/production server without the presence of a Disaster Recovery expert.

USE [master]
GO
-- Method 1: I use this method
EXEC sp_attach_single_file_db @dbname='TestDb',
@physname=N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf'
GO
-- Method 2:
CREATE DATABASE TestDb ON
(FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf')
FOR ATTACH_REBUILD_LOG
GO

Method 2: If one or more log files are missing, they are recreated again.

There is one more method which I am demonstrating here but I have not used myself before. According to Book Online, it will work only if there is one log file that is missing. If there are more than one log files involved, all of them are required to undergo the same procedure.

-- Method 3:
CREATE DATABASE TestDb ON
( FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf')
FOR ATTACH
GO


Reference: Pinal Dave (http://blog.SQLAuthority.com)