In one of my project I was working on SQL Server 2000 to SQL Server 2008 upgradation. It’s a side by side upgrade so I need to restore the database from SQL Server 2000 to SQL Server 2008, in which some of the databases are readonly. I know I will be able to restore readonly database however in this case when I tried to restore the database in SQL Server 2008 I got the error below

I was working in a package and I was requested to set the import task as transaction consistent. In SSIS you can do all sorts of ETL stuff so when you import data you need to make sure the import is in consistent state which means either all the data should gets loaded or it should be rolled back to the previous state. You can enable this option either in package level or container level or at task level. Based on your requirement you can set the transaction property so the final output is in consistent state.

Couple of weeks back I was working with a SSIS package development. My requirement is to check whether the file exists before I start importing the data. If it doesn’t exist then the package should update the db table. When I heard this requirement I thought I can make use of the “File System Task” in SSIS toolbox. When I start the work I came to know that you can’t get this piece of information from that task. It’s really weird for me as you can move\copy a file or folder using this task however checking the file existence is not possible with that task as shown below.

This might be a simple article for the intermediate folks, however I would like to show you the screen’s in SQL Server 2012 installation. As far as I know the setup is similar to the one which we did for SQL Server 2008 R2, there are some additions to the installation part. Before jumping into the installation lets see the add-ons related to installation.

As you know there are so many security measures are taken during every release of SQL Server. This version of SQL Server will be using Managed Service account to run SQL server related services. In other terms earlier versions we used Local system account as service account for all SQL Server related services however in this version we be will using individual local accounts for all SQL server related services. In this case whatever application runs on local system are allowed to access SQL Server. So to overcome this MS team has started using managed service accounts in SQL Server.