With the introduction of Internet Explorer 11, Microsoft completely overhauled the F12 Developer Tools.
We rebuilt the F12 tools from the ground up in IE11. They have a brand new UI and new functionality to make your developing and debugging faster and easier.
With the new F12 Developer tools, you can debug, test, profile, update the CSS layout, find a memory leak, emulate and checkout UI responsiveness, plus a lot more.
There is a great article on the Internet Explorer Dev Center for Using the F12 developer tools. I recommend you take a look at the article as it goes in depth for how to use the new tool.
Internet Explorer 11 comes with Windows 8.1 and will be made available for Windows 7 at around the same time that Windows 8.1 is released or shortly there after I would imagine. There is a IE11 RC available for Windows 7 now.
These updated developer tools are a welcome breath of fresh air and should provide to be very useful for every developers needs.
The other day I found myself looking at how I can include reference data in a new database as part of my SQL Server Database Project. Typically for my existing databases, I’ve just create post-deployment scripts to add/update/delete reference data as needed with each release. However with my new database, I have a number of tables and rows in each that I’ll need to deploy the first time.
The first option that comes to mind would be that I can do this as per usual and create a v1.0 script to populate the data, but I thought there should be a better way to maintain and deploy this data. What if it ever changes and I need it updated? I’ll then have to script specific post-deployment scripts. Not ideal.
I did a little searching and came across this old post on the SQL Server Data Tools Team Blog for Including Data in SQL Server Database Projects. This seems like a great option, but I already see there are a number of people complaining that this isn’t good enough and I would agree. I also have the added annoyance that I’m still stuck using SQL Server 2005, so the MERGE option isn’t even an option for me.
Further research shows another post on how to Mimic MERGE with the OUTPUT statement in SQL Server 2005. This looks like it will work for SQL Server 2005, but makes things more complex in my opinion. I really just want to declare in my database project the values the table should have on deployment and then let the build and deployment process determine what needs to be done.
I think for now I’ll stick with my first option and create an initial v1.0 post-deployment script. I’ll then take a look at what comes in Visual Studio 2013 later this year and if there are new options for addressing this issue.
We are moving to SQL Server 2012 by year end, so I can at least migrate to doing the MERGE approach at that time if there is nothing else available.
I hope this helps others in the same situation.